Máy tính lượng tử và chuỗi khối: Cân bằng mức độ cấp bách với mối đe dọa thực tế
Tuyển chọn TechFlowTuyển chọn TechFlow
Máy tính lượng tử và chuỗi khối: Cân bằng mức độ cấp bách với mối đe dọa thực tế
Rủi ro lỗi gần đây lớn hơn nhiều so với tấn công lượng tử.
Chuyên sâu báo cáo Web3Bài viết: Justin Thaler
Dịch: Bạch thoại Blockchain
Thời điểm máy tính lượng tử liên quan đến mật mã thường bị thổi phồng — dẫn đến yêu cầu chuyển đổi khẩn cấp và toàn diện sang mật mã hậu lượng tử.
Nhưng những lời kêu gọi này thường bỏ qua chi phí và rủi ro của việc di chuyển quá sớm, đồng thời bỏ qua sự khác biệt rõ rệt về mức độ rủi ro giữa các nguyên thủy mật mã khác nhau:
Mật mã hậu lượng tử mặc dù có chi phí nhưng vẫn cần triển khai ngay lập tức: Các cuộc tấn công "thu thập trước, giải mã sau" (Harvest-Now-Decrypt-Later - HNDL) đang diễn ra, vì dữ liệu nhạy cảm được mã hóa ngày nay sẽ vẫn còn giá trị khi máy tính lượng tử xuất hiện, ngay cả khi điều đó xảy ra vài chục năm sau. Chi phí hiệu suất và rủi ro triển khai của mật mã hậu lượng tử là có thật, nhưng HNDL buộc dữ liệu cần bảo mật dài hạn phải hành động.
Chữ ký hậu lượng tử đối mặt với các yếu tố cân nhắc khác. Chúng không dễ bị tấn công HNDL, và chi phí cũng như rủi ro của chúng (kích thước lớn hơn, chi phí hiệu suất, thiếu trưởng thành trong triển khai và lỗi) đòi hỏi sự suy xét cẩn trọng chứ không phải di chuyển ngay lập tức.
Sự khác biệt này rất quan trọng. Hiểu lầm sẽ làm sai lệch phân tích chi phí-lợi ích, khiến các nhóm bỏ qua các rủi ro an ninh nổi bật hơn — ví dụ như lỗi phần mềm (bugs).
Thách thức thực sự trong việc chuyển đổi thành công sang mật mã hậu lượng tử nằm ở việc phù hợp mức độ khẩn cấp với mối đe dọa thực tế. Dưới đây, tôi sẽ làm rõ những hiểu lầm phổ biến về mối đe dọa lượng tử đối với mật mã — bao gồm mã hóa, chữ ký và bằng chứng kiến thức không tiết lộ thông tin — và đặc biệt tập trung vào ảnh hưởng đến blockchain.
Chúng ta đang tiến triển thế nào về mặt thời gian?
Bất chấp những tuyên bố thu hút sự chú ý, khả năng xuất hiện máy tính lượng tử liên quan đến mật mã (CRQC) trong thập kỷ 2020 là cực kỳ thấp.
Tôi dùng thuật ngữ “máy tính lượng tử liên quan đến mật mã” để chỉ một máy tính lượng tử chịu lỗi, sửa lỗi, có thể chạy thuật toán Shor ở quy mô đủ lớn để phá vỡ {secp}256{k}1 hoặc {RSA-2048} trong thời gian hợp lý (ví dụ, trong vòng một tháng tính toán liên tục), từ đó tấn công mật mã đường cong elliptic hoặc RSA.
Theo bất kỳ cách hiểu hợp lý nào về các mốc phát triển công khai và ước tính tài nguyên, chúng ta còn cách xa CRQC rất nhiều. Đôi khi các công ty tuyên bố CRQC có thể xuất hiện trước năm 2030 hoặc thậm chí muộn nhất là 2035, nhưng tiến triển công khai hiện tại không hỗ trợ những tuyên bố này.
Trong bối cảnh này, tất cả các kiến trúc hiện tại — ion bị giam giữ, qubit siêu dẫn và hệ thống nguyên tử trung tính — nền tảng máy tính lượng tử ngày nay đều chưa gần đến mức cần hàng trăm ngàn đến hàng triệu qubit vật lý (tùy theo tỷ lệ lỗi và phương án sửa lỗi) để chạy thuật toán Shor nhằm tấn công {RSA-2048} hoặc {secp}256{k}1.
Yếu tố hạn chế không chỉ là số lượng qubit, mà còn là độ trung thực cổng, khả năng kết nối qubit, và độ sâu mạch sửa lỗi liên tục cần thiết để chạy các thuật toán lượng tử sâu. Mặc dù một số hệ thống hiện đã vượt quá 1.000 qubit vật lý, nhưng số lượng qubit thô này bản thân nó gây hiểu lầm: các hệ thống này thiếu khả năng kết nối qubit và độ trung thực cổng cần thiết cho phép tính mật mã liên quan.
Các hệ thống gần đây bắt đầu tiếp cận tỷ lệ lỗi vật lý nơi hiệu chỉnh lỗi lượng tử bắt đầu có tác dụng, nhưng chưa có ai chứng minh được nhiều hơn vài qubit logic với độ sâu mạch hiệu chỉnh lỗi liên tục… chứ chưa nói đến hàng ngàn qubit logic chịu lỗi, có độ sâu mạch cao, độ trung thực cao cần thiết để thực sự chạy thuật toán Shor. Khoảng cách giữa việc chứng minh hiệu chỉnh lỗi lượng tử khả thi về mặt nguyên lý và đạt được quy mô cần thiết cho phân tích mật mã vẫn còn rất lớn.
Tóm lại: Trừ khi số lượng qubit và độ trung thực cùng tăng lên vài bậc độ lớn, nếu không CRQC vẫn còn rất xa vời.
Tuy nhiên, thông cáo báo chí doanh nghiệp và truyền thông dễ gây nhầm lẫn. Dưới đây là một số hiểu lầm và nguồn gây nhầm lẫn phổ biến, bao gồm:
Các minh họa tuyên bố "ưu thế lượng tử", hiện tại chỉ nhằm vào các nhiệm vụ nhân tạo. Những nhiệm vụ này được chọn không phải vì tính thực tiễn mà vì chúng có thể chạy trên phần cứng hiện tại đồng thời dường như thể hiện gia tốc lượng tử đáng kể — sự thật này thường bị làm mờ trong các thông báo.
Các công ty tuyên bố đã đạt hàng ngàn qubit vật lý. Nhưng đây là máy ủ nhiệt lượng tử, chứ không phải máy mô hình cổng cần thiết để chạy thuật toán Shor tấn công mật mã khóa công khai.
Các công ty sử dụng tự do thuật ngữ “qubit logic”. Qubit vật lý thì nhiễu. Như đã đề cập trước đó, thuật toán lượng tử cần qubit logic; thuật toán Shor cần hàng ngàn. Thông qua hiệu chỉnh lỗi lượng tử, có thể dùng nhiều qubit vật lý để tạo thành một qubit logic — thường là hàng trăm đến hàng ngàn, tùy theo tỷ lệ lỗi. Nhưng một số công ty đã kéo giãn thuật ngữ này đến mức méo mó. Ví dụ, một thông báo gần đây tuyên bố dùng mã khoảng cách 2 và chỉ hai qubit vật lý để tạo thành một qubit logic. Điều này là vô lý: mã khoảng cách 2 chỉ có thể phát hiện lỗi chứ không thể sửa lỗi. Qubit logic chịu lỗi thực sự dành cho phân tích mật mã cần hàng trăm đến hàng ngàn qubit vật lý mỗi cái, chứ không phải hai.
Nói chung hơn, nhiều lộ trình máy tính lượng tử dùng thuật ngữ “qubit logic” để chỉ các qubit chỉ hỗ trợ thao tác Clifford. Các thao tác này có thể mô phỏng hiệu quả bằng máy tính cổ điển, do đó không đủ để chạy thuật toán Shor, vốn cần hàng ngàn cổng T đã hiệu chỉnh lỗi (hoặc nói rộng hơn là các cổng không phải Clifford).
Ngay cả khi một lộ trình đặt mục tiêu “đạt hàng ngàn qubit logic vào năm X”, điều này không có nghĩa là công ty dự kiến sẽ chạy thuật toán Shor để phá mật mã cổ điển vào cùng năm X.
Những hành vi này làm sai lệch nghiêm trọng nhận thức công chúng về việc chúng ta gần CRQC đến đâu, ngay cả trong giới quan sát trưởng thành.
Dù vậy, một số chuyên gia thực sự hào hứng với tiến triển. Ví dụ, Scott Aaronson gần đây viết rằng, xét theo “tốc độ phát triển phần cứng đáng kinh ngạc hiện tại”,
Tôi hiện cho rằng việc sở hữu một máy tính lượng tử chịu lỗi chạy thuật toán Shor trước cuộc bầu cử tổng thống Mỹ tiếp theo là một khả năng thực tế.
Nhưng Aaronson sau đó làm rõ rằng tuyên bố của ông không ám chỉ CRQC: ông cho rằng ngay cả việc thực hiện hoàn chỉnh thuật toán Shor phân tích 15 = 3 × 5 cũng được xem là thành công — trong khi phép tính này có thể thực hiện nhanh hơn bằng giấy và bút chì. Tiêu chuẩn vẫn là thực hiện nhỏ thuật toán Shor, chứ không phải ở quy mô liên quan đến mật mã, vì các thí nghiệm trước đây về phân tích 15 trên máy tính lượng tử đã dùng mạch đơn giản hóa, chứ không phải thuật toán Shor đầy đủ, chịu lỗi. Và luôn có lý do tại sao các thí nghiệm này chỉ nhắm vào việc phân tích số 15: phép tính modulo 15 rất dễ, trong khi phân tích số lớn hơn chút như 21 sẽ khó hơn nhiều. Do đó, các thí nghiệm lượng tử tuyên bố phân tích 21 thường phụ thuộc vào các gợi ý hay lối tắt bổ sung.
Tóm lại, kỳ vọng về việc xuất hiện CRQC có khả năng phá {RSA-2048} hoặc {secp}256{k}1 trong vòng 5 năm tới — điều cực kỳ quan trọng với mật mã thực tế — không được hỗ trợ bởi bất kỳ tiến triển công khai nào.
Ngay cả 10 năm vẫn là mục tiêu tham vọng. Xét khoảng cách xa chúng ta với CRQC, việc hào hứng với tiến bộ hoàn toàn phù hợp với một đường thời gian dài hơn 10 năm.
Vậy còn việc chính phủ Mỹ đặt năm 2035 làm thời hạn cuối để hoàn thành chuyển đổi toàn bộ hệ thống sang hậu lượng tử (PQ)? Tôi cho rằng đây là một lộ trình hợp lý để hoàn thành một chuyển đổi quy mô lớn như vậy. Tuy nhiên, nó không phải là một dự đoán rằng CRQC sẽ tồn tại vào thời điểm đó.
Tấn công HNDL áp dụng trong trường hợp nào (và không áp dụng trong trường hợp nào)?
Tấn công "thu hoạch trước, giải mã sau" (HNDL) ám chỉ kẻ thù hiện tại lưu trữ luồng dữ liệu được mã hóa, rồi giải mã sau khi CRQC tồn tại. Các đối thủ cấp quốc gia chắc chắn đã đang lưu trữ quy mô lớn các giao tiếp được mã hóa từ chính phủ Mỹ để giải mã sau nhiều năm khi CRQC thực sự xuất hiện.
Đó là lý do vì sao việc mã hóa cần chuyển đổi ngay lập tức — ít nhất là với mọi dữ liệu yêu cầu bảo mật từ 10–50 năm trở lên.
Nhưng chữ ký số — thứ mà mọi blockchain đều phụ thuộc — khác với mã hóa: không có bí mật nào có thể bị tấn công ngược lại.
Nói cách khác, nếu CRQC xuất hiện, việc giả mạo chữ ký thực sự có thể xảy ra kể từ lúc đó, nhưng các chữ ký trong quá khứ không giống như các thông điệp mã hóa khi mà “giấu” bí mật. Miễn là bạn biết chữ ký số được tạo ra trước khi CRQC xuất hiện, thì nó không thể bị giả mạo.
Điều này khiến việc chuyển đổi sang chữ ký số hậu lượng tử ít khẩn cấp hơn so với việc chuyển đổi mã hóa hậu lượng tử.
Các nền tảng chính đang hành động tương ứng: Chrome và Cloudflare đã triển khai {X}25519+{ML-KEM} lai ghép cho mã hóa lớp bảo mật truyền tải mạng (TLS).
Trong bài viết này, để tiện đọc, tôi dùng thuật ngữ "mã hóa", mặc dù về mặt nghiêm ngặt, các giao thức bảo mật truyền thông như TLS sử dụng trao đổi khóa hoặc cơ chế đóng gói khóa chứ không phải mã hóa khóa công khai.
Ở đây, **“lai ghép” có nghĩa là đồng thời sử dụng ** cả phương án an toàn hậu lượng tử (tức là ML-KEM) và phương án hiện tại ({X}25519), để có được đảm bảo an ninh kết hợp từ cả hai. Như vậy, chúng có thể (hy vọng) ngăn chặn tấn công HNDL thông qua ML-KEM, đồng thời duy trì an ninh cổ điển thông qua {X}25519 trong trường hợp ML-KEM bị chứng minh là không an toàn ngay cả với máy tính ngày nay.
iMessage của Apple cũng đã triển khai loại mã hóa hậu lượng tử lai ghép này thông qua giao thức PQ3, Signal cũng triển khai thông qua các giao thức PQXDH và SPQR.
Ngược lại, việc phổ biến chữ ký số hậu lượng tử đến hạ tầng mạng thiết yếu đang bị trì hoãn cho đến khi CRQC thực sự đến gần, vì các phương án chữ ký hậu lượng tử hiện tại gây giảm hiệu suất (sẽ chi tiết hơn trong bài viết này).
zkSNARKs — bằng chứng ngắn gọn, không tương tác, kiến thức không tiết lộ thông tin, then chốt cho khả năng mở rộng và riêng tư lâu dài của blockchain — ở trong tình thế tương tự như chữ ký. Bởi vì, ngay cả với {zkSNARKs} không an toàn hậu lượng tử (chúng dùng mật mã đường cong elliptic, giống như các phương án mã hóa và chữ ký không hậu lượng tử ngày nay), thuộc tính không tiết lộ thông tin của chúng là an toàn hậu lượng tử.
Thuộc tính không tiết lộ thông tin đảm bảo rằng không có thông tin nào về người chứng bí mật bị rò rỉ trong bằng chứng — ngay cả với đối thủ lượng tử — do đó không có thông tin mật nào có thể bị “thu hoạch trước” để giải mã sau này.
Do đó, {zkSNARKs} không dễ bị tấn công "thu hoạch trước, giải mã sau". Cũng như các chữ ký không hậu lượng tử được tạo ra ngày nay là an toàn, mọi bằng chứng {zkSNARK} được tạo ra trước khi CRQC xuất hiện đều đáng tin cậy (tức là khẳng định được chứng minh là hoàn toàn đúng) — ngay cả khi {zkSNARK} dùng mật mã đường cong elliptic. Chỉ sau khi CRQC xuất hiện, kẻ tấn công mới có thể tìm thấy bằng chứng cho các khẳng định giả mạo thuyết phục.
Điều này có ý nghĩa gì với blockchain
Hầu hết các blockchain sẽ không bị phơi nhiễm với tấn công HNDL:
Hầu hết các chuỗi không riêng tư, như Bitcoin và Ethereum ngày nay, chủ yếu dùng mật mã không hậu lượng tử cho việc ủy quyền giao dịch — tức là chúng dùng chữ ký số, chứ không phải mã hóa.
Tương tự, các chữ ký này không có rủi ro HNDL: tấn công "thu hoạch trước, giải mã sau" áp dụng cho dữ liệu được mã hóa. Ví dụ, chuỗi khối Bitcoin là công khai; mối đe dọa lượng tử là việc giả mạo chữ ký (suy luận khóa riêng để đánh cắp tiền), chứ không phải giải mã dữ liệu giao dịch đã công khai. Điều này loại bỏ tính khẩn cấp mã hóa ngay lập tức do HNDL gây ra.
Thật không may, ngay cả các phân tích từ nguồn đáng tin như Cục Dự trữ Liên bang Mỹ cũng sai lầm khi tuyên bố Bitcoin dễ bị tấn công HNDL, sai sót này làm thổi phồng tính khẩn cấp chuyển đổi sang mật mã hậu lượng tử.
Dù vậy, giảm tính khẩn cấp không có nghĩa là Bitcoin có thể chờ đợi: nó đối mặt với áp lực thời gian khác do sự phối hợp xã hội khổng lồ cần thiết để thay đổi giao thức.
Ngoại lệ hiện nay là các chuỗi riêng tư, trong đó nhiều chuỗi mã hóa hoặc che giấu người nhận và số tiền theo cách khác. Một khi máy tính lượng tử có thể phá mật mã đường cong elliptic, tính bí mật này hiện có thể bị thu thập và sau đó bị loại ẩn danh hồi tố.
Mức độ nghiêm trọng của tấn công đối với các chuỗi riêng tư này khác nhau tùy theo thiết kế blockchain. Ví dụ, với chữ ký vòng dựa trên đường cong Monero và hình ảnh khóa (nhãn liên kết cho từng đầu ra để ngăn chi tiêu kép), sổ cái công khai bản thân nó đã đủ để tái tạo sơ đồ chi tiêu hồi tố. Nhưng ở các chuỗi khác, thiệt hại bị giới hạn hơn — chi tiết xem thảo luận của kỹ sư mã hóa và nhà nghiên cứu Sean Bowe từ Zcash.
Nếu việc giao dịch của người dùng không bị phơi nhiễm trước máy tính lượng tử liên quan đến mật mã là điều quan trọng, thì các chuỗi riêng tư nên chuyển đổi sang các nguyên thủy hậu lượng tử (hoặc phương án lai ghép) càng sớm càng tốt khi khả thi. Hoặc, chúng nên áp dụng kiến trúc tránh đặt bí mật có thể giải mã lên chuỗi.
Vấn đề đặc biệt của Bitcoin: Quản trị + Tiền bị bỏ quên
Đặc biệt với Bitcoin, có hai thực tế thúc đẩy tính khẩn cấp bắt đầu chuyển sang chữ ký số hậu lượng tử. Cả hai đều không liên quan đến công nghệ lượng tử.
Một lo ngại là tốc độ quản trị: Bitcoin thay đổi chậm. Nếu cộng đồng không thể nhất trí về giải pháp thích hợp, bất kỳ vấn đề gây tranh cãi nào cũng có thể dẫn đến hard fork phá hoại.
Một lo ngại khác là việc Bitcoin chuyển sang chữ ký hậu lượng tử không thể là chuyển đổi thụ động: chủ sở hữu phải chủ động di chuyển tiền của họ. Nghĩa là các đồng tiền bị bỏ quên, dễ bị tổn thương trước lượng tử không thể được bảo vệ. Một số ước tính cho rằng số BTC dễ bị tổn thương trước lượng tử và có thể bị bỏ quên lên tới hàng triệu đồng, trị giá hàng trăm tỷ USD theo giá hiện tại (tính đến tháng 12 năm 2025).
Tuy nhiên, mối đe dọa lượng tử đối với Bitcoin sẽ không phải là thảm họa đột ngột, trong một đêm… mà giống như một quá trình định vị mục tiêu chọn lọc, từng bước. Máy tính lượng tử sẽ không đồng thời phá tất cả các mã hóa — thuật toán Shor phải nhắm vào từng khóa công khai một. Các cuộc tấn công lượng tử ban đầu sẽ cực kỳ tốn kém và chậm chạp. Do đó, ngay khi máy tính lượng tử có thể phá từng khóa chữ ký Bitcoin riêng lẻ, kẻ tấn công sẽ chọn lọc săn các ví có giá trị cao.
Hơn nữa, người dùng tránh dùng lại địa chỉ và không dùng địa chỉ Taproot — những địa chỉ trực tiếp phơi bày khóa công khai trên chuỗi — sẽ được bảo vệ phần lớn ngay cả khi không có thay đổi giao thức: khóa công khai của họ được ẩn phía sau hàm băm cho đến khi tiền của họ được chi tiêu. Khi họ cuối cùng phát sóng giao dịch chi tiêu, khóa công khai trở nên hiển thị, và sẽ có một cuộc đua ngắn hạn thời gian thực giữa người chi tiêu trung thực muốn giao dịch được xác nhận và kẻ tấn công được trang bị lượng tử muốn tìm khóa riêng và chi tiêu tiền trước khi giao dịch của chủ sở hữu thực sự được hoàn tất. Do đó, các đồng tiền thực sự dễ bị tổn thương là những đồng có khóa công khai đã bị phơi bày: các đầu ra điểm-điểm-K thời kỳ đầu, dùng lại địa chỉ và người nắm giữ Taproot.
Đối với các đồng tiền dễ bị tổn thương đã bị bỏ quên, không có giải pháp đơn giản nào. Một số lựa chọn bao gồm:
Cộng đồng Bitcoin đồng thuận về một “ngày đánh dấu”, sau đó, bất kỳ đồng tiền nào chưa di chuyển sẽ bị tuyên bố là bị hủy.
Các đồng tiền dễ bị tổn thương trước lượng tử bị bỏ quên có thể bị chiếm đoạt bởi bất kỳ ai sở hữu máy tính lượng tử liên quan đến mật mã.
Lựa chọn thứ hai sẽ gây ra các vấn đề pháp lý và an ninh nghiêm trọng. Việc chiếm hữu tiền bằng máy tính lượng tử mà không có khóa riêng — ngay cả khi tuyên bố có quyền sở hữu hợp pháp hay ý định tốt — có thể gây ra các vấn đề nghiêm trọng theo luật trộm cắp và gian lận máy tính ở nhiều khu vực pháp lý. Hơn nữa, bản thân khái niệm “bị bỏ quên” dựa trên giả định không hoạt động. Nhưng không ai thực sự biết liệu các đồng tiền đó có còn chủ sở hữu sống sót nắm giữ khóa hay không. Bằng chứng bạn từng sở hữu các đồng tiền đó có thể không đủ để cấp quyền pháp lý để phá mã bảo vệ và lấy lại chúng. Sự mơ hồ pháp lý này làm tăng khả năng các đồng tiền dễ bị tổn thương trước lượng tử bị bỏ quên rơi vào tay những kẻ xấu sẵn sàng phớt lờ các giới hạn pháp lý.
Vấn đề cuối cùng đặc trưng cho Bitcoin là thông lượng giao dịch thấp. Ngay cả khi kế hoạch di chuyển được xác định, việc di chuyển tất cả các khoản tiền dễ bị tổn thương trước lượng tử sang địa chỉ an toàn hậu lượng tử, với tốc độ giao dịch hiện tại của Bitcoin, cũng sẽ mất vài tháng.
Những thách thức này khiến Bitcoin phải bắt đầu lên kế hoạch chuyển đổi hậu lượng tử ngay bây giờ — không phải vì CRQC có thể xuất hiện trước năm 2030, mà vì việc quản trị, phối hợp và hậu cần kỹ thuật cần thiết để di chuyển hàng tỷ USD tiền sẽ mất nhiều năm để giải quyết.
Mối đe dọa lượng tử đối với Bitcoin là có thật, nhưng áp lực thời gian đến từ các hạn chế nội tại của Bitcoin chứ không phải từ máy tính lượng tử sắp xảy ra. Các blockchain khác đối mặt với các thách thức riêng về tiền dễ bị tổn thương trước lượng tử, nhưng Bitcoin đối mặt với sự phơi nhiễm độc đáo: các giao dịch đầu tiên của nó dùng đầu ra trả cho khóa công khai (điểm-điểm-K), đặt trực tiếp khóa công khai lên chuỗi, khiến một phần đáng kể BTC đặc biệt dễ bị tấn công từ máy tính lượng tử liên quan đến mật mã. Sự khác biệt kỹ thuật này — cộng với tuổi đời, sự tập trung giá trị, thông lượng thấp và quản trị cứng nhắc của Bitcoin — khiến vấn đề trở nên nghiêm trọng đặc biệt.
Lưu ý rằng lỗ hổng tôi mô tả ở trên áp dụng cho an ninh mã hóa của chữ ký số Bitcoin — chứ không phải an ninh kinh tế của blockchain Bitcoin. An ninh kinh tế này bắt nguồn từ cơ chế đồng thuận Proof-of-Work (PoW), vốn không dễ bị tấn công bởi máy tính lượng tử vì ba lý do:
PoW dựa vào băm, do đó chỉ bị ảnh hưởng bởi gia tốc lượng tử bậc hai từ thuật toán tìm kiếm Grover, chứ không phải gia tốc mũ từ thuật toán Shor.
Chi phí thực tế để triển khai tìm kiếm Grover khiến khả năng bất kỳ máy tính lượng tử nào đạt được gia tốc thực tế dù chỉ nhẹ trên cơ chế PoW của Bitcoin là cực kỳ thấp.
Ngay cả khi đạt được gia tốc đáng kể, các gia tốc này sẽ mang lại lợi thế cho thợ đào lượng tử lớn so với thợ đào nhỏ, nhưng sẽ không phá hủy cơ bản mô hình an ninh kinh tế của Bitcoin.
Chi phí và rủi ro của chữ ký hậu lượng tử
Để hiểu tại sao blockchain không nên vội vã triển khai chữ ký hậu lượng tử, chúng ta cần hiểu chi phí hiệu suất và niềm tin của chúng ta vào an ninh hậu lượng tử vẫn đang tiếp tục phát triển.
Hầu hết mật mã hậu lượng tử dựa trên một trong năm phương pháp sau:
-
Băm (hashing)
-
Mã hóa (codes)
-
Lưới (lattices)
-
Hệ phương trình đa thức bậc hai đa biến (multivariate quadratic systems, MQ)
-
Đồng dạng (isogenies).
Tại sao lại có năm phương pháp khác nhau? Độ an toàn của bất kỳ nguyên thủy mật mã hậu lượng tử nào đều dựa trên giả định rằng máy tính lượng tử không thể giải hiệu quả một vấn đề toán học cụ thể. Vấn đề càng «có cấu trúc», các giao thức mật mã xây dựng từ đó càng hiệu quả.
Nhưng điều này vừa có lợi vừa có hại: cấu trúc bổ sung cũng tạo ra thêm không gian khai thác cho các thuật toán tấn công. Điều này tạo ra một mâu thuẫn căn bản — giả định mạnh hơn cho phép hiệu suất tốt hơn, nhưng đổi lại là nguy cơ lỗ hổng an ninh tiềm tàng (tức là khả năng giả định bị chứng minh là sai tăng lên).
Nói chung, các phương pháp dựa trên băm là thận trọng nhất về mặt an ninh, vì chúng ta tự tin nhất rằng máy tính lượng tử không thể tấn công hiệu quả các giao thức này. Nhưng chúng cũng là kém hiệu quả nhất. Ví dụ, các phương án chữ ký dựa trên băm được NIST chuẩn hóa, ngay cả ở cài đặt tham số nhỏ nhất, cũng có kích thước 7–8 KB. Trong khi đó, chữ ký số dựa trên đường cong elliptic ngày nay chỉ có 64 byte. Khoảng cách kích thước này là khoảng 100 lần.
Các phương án lưới là trọng tâm triển khai chính hiện nay. NIST đã chọn duy nhất một phương án mã hóa và hai trong ba thuật toán chữ ký để chuẩn hóa đều dựa trên lưới. Một phương án lưới (ML-DSA, trước đây gọi là Dilithium) tạo ra chữ ký có kích thước từ 2,4 KB (ở mức an toàn 128 bit) đến 4,6 KB (ở mức an toàn 256 bit) — khiến nó lớn hơn khoảng 40–70 lần so với chữ ký dựa trên đường cong elliptic ngày nay. Phương án lưới khác là Falcon có chữ ký nhỏ hơn chút (Falcon-512 là 666 byte, Falcon-1024 là 1,3 KB), nhưng kèm theo phép toán dấu phẩy động phức tạp, bản thân NIST ghi nhận là thách thức triển khai đặc biệt. Thomas Pornin, một trong những người sáng tạo ra Falcon, gọi nó là “thuật toán mật mã phức tạp nhất tôi từng triển khai”.
Việc triển khai an toàn chữ ký số dựa trên lưới cũng thách thức hơn so với các phương án dựa trên đường cong elliptic: ML-DSA có nhiều giá trị trung gian nhạy cảm hơn và logic lấy mẫu từ chối phi tầm thường, cần bảo vệ chống kênh bên và lỗi. Falcon làm tăng vấn đề dấu phẩy động thời gian hằng số; thực tế, nhiều cuộc tấn công kênh bên vào triển khai Falcon đã khôi phục được khóa bí mật.
Những vấn đề này tạo thành rủi ro tức thời, không giống với mối đe dọa xa vời từ CRQC.
Khi triển khai các phương pháp mật mã hậu lượng tử hiệu suất cao hơn, có lý do đầy đủ để thận trọng. Trong lịch sử, các ứng viên hàng đầu như Rainbow (phương án chữ ký dựa trên MQ) và SIKE/SIDH (phương án mã hóa dựa trên đồng dạng) đã bị phá trên máy cổ điển, tức là bị phá bằng máy tính ngày nay, chứ không phải máy lượng tử.
Điều này xảy ra ở giai đoạn khá muộn trong quá trình chuẩn hóa của NIST. Đây là khoa học hoạt động lành mạnh, nhưng điều này cho thấy việc chuẩn hóa và triển khai quá sớm có thể phản tác dụng.
Như đã đề cập trước đó, hạ tầng internet đang áp dụng phương pháp suy xét cẩn trọng đối với việc chuyển đổi chữ ký. Điều này đặc biệt đáng chú ý khi xem xét việc chuyển đổi mật mã của internet cần bao lâu một khi bắt đầu. Việc chuyển đổi từ các hàm băm MD5 và SHA-1 — vài năm trước đã bị các cơ quan quản lý mạng loại bỏ về mặt kỹ thuật — đã mất nhiều năm để triển khai thực tế trong hạ tầng, và trong một số trường hợp vẫn đang tiếp diễn. Điều này xảy ra vì các phương án này đã bị phá hoàn toàn, chứ không chỉ đơn giản là có khả năng dễ bị ảnh hưởng bởi công nghệ tương lai.
Thách thức độc đáo của blockchain so với hạ tầng internet
May mắn thay, các blockchain như Ethereum hay Solana, được duy trì tích cực bởi cộng đồng nhà phát triển mã nguồn mở, có thể nâng cấp nhanh hơn hạ tầng mạng truyền thống. Mặt khác, hạ tầng mạng truyền thống được lợi từ việc luân chuyển khóa thường xuyên, nghĩa là bề mặt tấn công của nó di chuyển nhanh hơn tốc độ mà máy lượng tử sơ khai có thể nhắm đến — đây là điều xa xỉ mà blockchain không có, vì tiền và khóa liên quan có thể bị phơi bày vô thời hạn.
Nhưng nhìn chung, blockchain vẫn nên tuân theo phương pháp chuyển đổi chữ ký suy xét cẩn trọng của mạng. Chữ ký trong cả hai môi trường đều không bị phơi nhiễm với tấn công HNDL, và bất kể khóa tồn tại bao lâu, chi phí và rủi ro của việc chuyển đổi quá sớm sang các phương án hậu lượng tử chưa trưởng thành vẫn rất lớn.
Cũng có các thách thức riêng biệt của blockchain khiến việc chuyển đổi quá sớm đặc biệt mạo hiểm và phức tạp: ví dụ, blockchain có yêu cầu độc đáo đối với các phương án chữ ký, đặc biệt là khả năng tập hợp nhanh nhiều chữ ký. Ngày nay, chữ ký BLS thường được dùng nhờ khả năng tập hợp cực kỳ nhanh, nhưng chúng không an toàn hậu lượng tử. Các nhà nghiên cứu đang khám phá việc tập hợp chữ ký hậu lượng tử dựa trên SNARK. Công việc này rất hứa hẹn, nhưng vẫn ở giai đoạn đầu.
Đối với SNARKs, cộng đồng hiện đang tập trung vào cấu trúc dựa trên băm như lựa chọn hậu lượng tử hàng đầu. Nhưng một sự thay đổi lớn đang đến: Tôi tin rằng trong vài tháng và vài năm tới, các lựa chọn dựa trên lưới sẽ trở thành phương án thay thế hấp dẫn. Các phương án thay thế này sẽ có hiệu suất tốt hơn ở mọi khía cạnh so với {SNARKs} dựa trên băm, ví dụ như bằng chứng ngắn hơn — tương tự như chữ ký dựa trên lưới ngắn hơn chữ ký dựa trên băm.
Vấn đề lớn hơn hiện tại: An ninh triển khai
Trong vài năm tới, các lỗ hổng triển khai sẽ là rủi ro an ninh lớn hơn so với máy tính lượng tử liên quan đến mật mã. Đối với {SNARKs}, điểm lo ngại chính là lỗi phần mềm (bugs).
Lỗi phần mềm đã là thách thức đối với chữ ký số và các phương án mã hóa, và {SNARKs} còn phức tạp hơn nhiều. Thực tế, một phương án chữ ký số có thể được xem như một {zkSNARK} rất đơn giản cho khẳng định “tôi biết khóa riêng tương ứng với khóa công khai của mình và tôi ủy quyền thông điệp này.”
Đối với chữ ký hậu lượng tử, rủi ro tức thời cũng bao gồm các cuộc tấn công triển khai, ví dụ như tấn công kênh bên và tấn công tiêm lỗi. Các loại tấn công này đã được ghi nhận đầy đủ và có thể trích xuất khóa bí mật từ các hệ thống đã triển khai. Chúng tạo thành mối đe dọa khẩn cấp hơn nhiều so với máy tính lượng tử xa vời.
Cộng đồng sẽ dành nhiều năm để xác định và sửa lỗi trong {SNARKs}, và tăng cường triển khai chữ ký hậu lượng tử để chống lại tấn công kênh bên và tiêm lỗi. Vì các vấn đề về {SNARKs} hậu lượng tử và các phương án tập hợp chữ ký vẫn chưa ngã ngũ, các blockchain chuyển đổi quá sớm đối mặt với rủi ro bị khóa vào phương án dưới mức tối ưu. Khi các lựa chọn tốt hơn xuất hiện, hoặc khi các lỗ hổng triển khai được phát hiện, họ có thể cần di chuyển lần nữa.
Chúng ta nên làm gì? 7 đề xuất
Xét theo thực tế tôi đã nêu ở trên, tôi sẽ kết luận bằng các đề xuất cho các bên liên quan khác nhau — từ người xây dựng đến người hoạch định chính sách. Nguyên tắc hàng đầu: coi trọng mối đe dọa lượng tử, nhưng đừng hành động dựa trên giả định rằng CRQC sẽ xuất hiện trước năm 2030. Giả định này không được tiến triển hiện tại xác nhận. Dù vậy, chúng ta vẫn có thể và nên làm một số việc ngay bây giờ:
Chúng ta nên triển khai ngay lập tức mã hóa lai ghép.
Hoặc ít nhất là trong các trường hợp cần bảo mật dài hạn và chi phí có thể chịu được.
Nhiều trình duyệt, CDN và ứng dụng nhắn tin (như iMessage và Signal) đã triển khai phương pháp lai ghép. Phương pháp lai ghép — hậu lượng tử + cổ điển — có thể phòng chống tấn công HNDL, đồng thời phòng ngừa các điểm yếu tiềm tàng trong phương án hậu lượng tử.
Ngay lập tức sử dụng chữ ký dựa trên băm khi kích thước có thể chấp nhận được.
Cập nhật phần mềm / firmware — và các trường hợp ít tần suất, không nhạy cảm về kích thước khác — nên ngay lập tức áp dụng chữ ký lai ghép dựa trên băm. (Lai ghép để phòng ngừa lỗi triển khai trong phương án mới, chứ không phải vì nghi ngờ về giả định an ninh của phương án dựa trên băm.)
Việc này rất thận trọng, và trong trường hợp ít có khả năng CRQC xuất hiện sớm bất ngờ, sẽ cung cấp một “thuyền cứu sinh” rõ ràng cho xã hội. Nếu không triển khai chữ ký hậu lượng tử trước cho cập nhật phần mềm, khi CRQC xuất hiện, chúng ta sẽ đối mặt với vấn đề khởi động: chúng ta sẽ không thể phân phối an toàn bản vá mật mã hậu lượng tử cần thiết để chống lại nó.
Blockchain không cần vội vã triển khai chữ ký hậu lượng tử — nhưng nên bắt đầu lên kế hoạch ngay lập tức.
Các nhà phát triển blockchain nên đi theo dẫn dắt của cộng đồng PKI mạng, áp dụng phương pháp suy xét cẩn trọng đối với việc triển khai chữ ký hậu lượng tử. Điều này cho phép các phương án chữ ký hậu lượng tử tiếp tục trưởng thành về hiệu suất và hiểu biết an ninh. Cách tiếp cận này cũng cho phép các nhà phát triển có thời gian tái cấu trúc hệ thống để xử lý chữ ký lớn hơn và phát triển các công nghệ tập hợp tốt hơn.
Đối với Bitcoin và các L1 khác: Cộng đồng cần định nghĩa đường đi di chuyển và chính sách về tiền dễ bị tổn thương trước lượng tử bị bỏ quên. Di chuyển thụ động là không thể, do đó việc lên kế hoạch là then chốt. Và vì Bitcoin đối mặt với các thách thức phi kỹ thuật đặc biệt — quản trị chậm và lượng lớn địa chỉ dễ bị tổn thương trước lượng tử có giá trị cao có thể bị bỏ quên — cộng đồng Bitcoin bắt đầu lên kế hoạch ngay bây giờ là đặc biệt quan trọng.
Đồng thời, chúng ta cần cho phép nghiên cứu về {SNARKs} hậu lượng tử và chữ ký có thể tập hợp trưởng thành (có thể cần thêm vài năm). Một lần nữa, việc di chuyển quá sớm có rủi ro bị khóa vào phương án dưới mức tối ưu hoặc cần di chuyển lần thứ hai để giải quyết lỗi triển khai.
Một ghi chú nhỏ về mô hình tài khoản của Ethereum: Ethereum hỗ trợ hai loại tài khoản, ảnh hưởng khác nhau đến việc di chuyển hậu lượng tử — tài khoản do người dùng ngoài kiểm soát (EOAs), loại tài khoản truyền thống được điều khiển bởi khóa riêng {secp}256{k}1; và ví hợp đồng thông minh có logic ủy quyền lập trình được.
Trong trường hợp không khẩn cấp, nếu Ethereum thêm hỗ trợ chữ ký hậu lượng tử, các ví hợp đồng thông minh có thể nâng cấp được có thể chuyển sang xác thực hậu lượng tử thông qua nâng cấp hợp đồng — trong khi EOAs có thể cần chuyển tiền của họ sang địa chỉ an toàn hậu lượng tử mới (mặc dù Ethereum có thể cũng sẽ cung cấp cơ chế di chuyển chuyên biệt cho EOAs).
Trong trường hợp khẩn cấp lượng tử, các nhà nghiên cứu Ethereum đã đề xuất kế hoạch hard fork để đóng băng các tài khoản dễ bị tổn thương, và cho phép người dùng khôi phục tiền bằng cách chứng minh kiến thức cụm từ khôi phục của họ bằng {SNARKs} an toàn hậu lượng tử. Cơ chế khôi phục này sẽ áp dụng cho cả EOA và bất kỳ ví hợp đồng thông minh nào chưa nâng cấp.
Tác động thực tế đến người dùng: Các ví hợp đồng thông minh được kiểm toán kỹ lưỡng, có thể nâng cấp có thể cung cấp đường đi di chuyển mượt mà hơn chút — nhưng sự khác biệt không lớn, và đi kèm với sự đánh đổi về niềm tin vào nhà cung cấp ví và quản trị nâng cấp. Quan trọng hơn là cộng đồng Ethereum tiếp tục công việc về các nguyên thủy hậu lượng tử và kế hoạch ứng phó khẩn cấp.
Bài học thiết kế rộng hơn cho người xây dựng: Ngày nay, nhiều blockchain gắn chặt danh tính tài khoản với nguyên thủy mã hóa cụ thể — Bitcoin và Ethereum với chữ ký ECDSA trên {secp}256{k}1, các chuỗi khác với EdDSA. Thách thức di chuyển hậu lượng tử làm nổi bật giá trị của việc tách rời danh tính tài khoản khỏi bất kỳ phương án chữ ký cụ thể nào. Bước tiến của Ethereum hướng tới tài khoản thông minh và các công việc trừu tượng tài khoản tương tự trên các chuỗi khác phản ánh xu hướng này: cho phép tài khoản nâng cấp logic xác thực của mình mà không cần từ bỏ lịch sử và trạng thái trên chuỗi. Việc tách rời này sẽ không làm cho việc di chuyển hậu lượng tử trở nên tầm thường, nhưng nó thực sự cung cấp linh hoạt hơn nhiều so với việc mã cứng tài khoản vào một phương án chữ ký duy nhất. (Điều này cũng hỗ trợ các chức năng không liên quan như giao dịch được tài trợ, khôi phục xã hội và đa chữ ký).
Đối với các chuỗi riêng tư, nơi chúng mã hóa hoặc che giấu chi tiết giao dịch, nếu hiệu suất cho phép, nên ưu tiên chuyển đổi sớm hơn.
Bí mật người dùng trên các chuỗi này hiện đang bị phơi nhiễm trước tấn công HNDL, mặc dù mức độ nghiêm trọng khác nhau tùy theo thiết kế. Các chuỗi mà chỉ bằng sổ cái công khai đã có thể thực hiện loại ẩn danh hồi tố hoàn toàn đối mặt với rủi ro khẩn cấp nhất.
Cân nhắc các phương án lai ghép (hậu lượng tử + cổ điển) để ngăn chặn việc các phương án hậu lượng tử bề ngoài bị chứng minh là không an toàn ngay cả trên máy cổ điển, hoặc thực hiện các thay đổi kiến trúc tránh đặt bí mật có thể giải mã lên chuỗi.
Trong ngắn hạn, ưu tiên an ninh triển khai — chứ không phải giảm thiểu mối đe dọa lượng tử.
Đặc biệt đối với các nguyên thủy mã hóa phức tạp như {SNARKs} và chữ ký hậu lượng tử, lỗi phần mềm và các cuộc tấn công triển khai (tấn công kênh bên, tiêm lỗi) sẽ là rủi ro an ninh lớn hơn nhiều so với máy tính lượng tử liên quan đến mật mã trong vài năm tới.
Ngay lập tức đầu tư vào kiểm toán, kiểm thử mù (fuzz testing), xác minh hình thức, và phương pháp phòng thủ sâu / an ninh từng lớp — đừng để lo lắng về lượng tử che khuất mối đe dọa lỗi phần mềm khẩn cấp hơn!
Tài trợ phát triển máy tính lượng tử.
Một tác động an ninh quốc gia quan trọng từ tất cả những điều trên là, chúng ta cần tài trợ liên tục và phát triển nhân tài trong lĩnh vực máy tính lượng tử.
Một đối thủ chính đạt được khả năng máy tính lượng tử liên quan đến mật mã trước Mỹ sẽ đặt ra rủi ro an ninh quốc gia nghiêm trọng đối với chúng ta và phần còn lại của thế giới.
Giữ cái nhìn thấu suốt trước các thông báo về máy tính lượng tử.
Khi phần cứng lượng tử trưởng thành, sẽ có nhiều mốc phát triển trong vài năm tới. Mâu thuẫn là, chính tần suất các thông báo này chứng minh chúng ta còn xa CRQC đến đâu: mỗi mốc đại diện cho một trong nhiều cây cầu mà chúng ta phải vượt qua trước khi đến điểm đó, và mỗi mốc sẽ tạo ra làn sóng tiêu đề và phấn khích riêng.
Hãy xem các thông cáo báo chí như các báo cáo tiến triển cần được đánh giá phê phán, chứ không phải lời nhắc để hành động đột ngột.
Tất nhiên, có thể có những tiến triển hoặc đổi mới đáng kinh ngạc làm tăng tốc đường thời gian dự kiến, cũng như có thể có các nút thắt mở rộng nghiêm trọng làm kéo dài chúng.
Tôi sẽ không tranh luận rằng việc xuất hiện CRQC trong vòng năm năm là tuyệt đối không thể, chỉ là
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
a16z
