Đếm ngược 2029: Cuộc đua kháng lượng tử của Ethereum bắt đầu từ Hegotá

Tác giả gốc: KarenZ, Foresight News

Máy tính lượng tử chưa gõ cửa blockchain, nhưng Ethereum Foundation đã khoanh tròn một ngày trên lịch: tháng 12 năm 2029.

Đó là hạn chót kỹ thuật mà nhóm giao thức của Ethereum Foundation đặt ra cho chính mình: chuẩn bị theo kịch bản mối đe dọa lượng tử có thể xuất hiện sớm, phấn đấu hoàn tất nâng cấp kháng lượng tử cho lớp 1 của Ethereum trước khi rủi ro thực sự đến gần.

Hegotá đang được lên kế hoạch, dù không trực tiếp biến Ethereum thành một blockchain hoàn toàn kháng lượng tử, nhưng sẽ quyết định liệu các kế hoạch tiếp theo có thể tiến hành đúng hạn hay không.

EF đặt hạn chót 2029 cho "Q-day"

"Q-day" thường được dùng để chỉ một thời điểm giả định: máy tính lượng tử có khả năng tấn công thực tế xuất hiện, khiến các hệ mật mã khóa công khai hiện tại đối mặt với mối đe dọa thực chất.

Không ai có thể dự đoán chính xác khi nào nó đến. Ethereum Foundation cũng thừa nhận rõ ràng rằng hầu hết các dự đoán đáng tin cậy cho rằng Q-day sẽ muộn hơn năm 2030, thậm chí có thể muộn hơn nhiều, và cũng có khả năng nó sẽ không bao giờ đến.

Nhóm giao thức của Ethereum Foundation áp dụng một giả định kỹ thuật thiên về thận trọng: lớp 1 của Ethereum nên chuẩn bị trước theo kịch bản Q-day có thể đến sớm nhất vào năm 2030.

Vì vậy, nhóm giao thức đã đề ra một mục tiêu—phấn đấu trước tháng 12 năm 2029, ba phần thực thi, đồng thuận và dữ liệu của lớp 1 Ethereum có đầy đủ năng lực kháng lượng tử.

Mục tiêu này cũng không phải là bất biến. Nhóm giao thức dự kiến vào tháng 1 năm 2027 sẽ kết hợp ý kiến chuyên gia bên ngoài để đánh giá lại tình hình phát triển của máy tính lượng tử. Trước thời điểm đó, hạn chót 2029 sẽ được coi là một mục tiêu công việc không dễ nhượng bộ.

Lý do cần chuẩn bị trước nhiều năm cho nâng cấp kháng lượng tử là vì Ethereum không chỉ sử dụng một loại công nghệ mật mã, cũng không phải chỉ thay một thuật toán chữ ký là có thể hoàn tất di chuyển. Cách tài khoản người dùng chứng minh giao dịch được ủy quyền, cách validator tham gia đồng thuận, cách dữ liệu được xác minh, đều liên quan đến các cấu trúc mật mã khác nhau. Bất kỳ sửa đổi nào cũng phải trải qua thiết kế đặc tả, triển khai client, đánh giá bảo mật, thử nghiệm trên mạng phát triển và điều phối mainnet, không thể đợi đến khi mối đe dọa xuất hiện mới bắt đầu xử lý.

Hegotá không phải là "nâng cấp kháng lượng tử", nhưng là bài kiểm tra đầu tiên của toàn bộ kế hoạch

Theo lộ trình cơ sở hiện được nhóm giao thức Ethereum Foundation công bố, nâng cấp mạng Glamsterdam dự kiến lên mainnet vào tháng 12 năm 2026, còn năng lực kháng lượng tử đầy đủ được sắp xếp vào hard fork thứ năm L* sau Glamsterdam, với thời gian mục tiêu là tháng 12 năm 2029. Từ Glamsterdam đến L* chỉ có ba năm, nếu phải lần lượt hoàn thành Hegotá, I*, J*, K* và L*, trung bình mỗi lần nâng cấp chỉ cách nhau khoảng 7,2 tháng.

Đây là một lịch trình khá tham vọng. Hiện tại Ethereum Foundation chưa công bố thời gian lên mainnet cụ thể cho Hegotá, I*, J* và K*. Điều chắc chắn là các nhóm client dự kiến sớm nhất vào cuối quý 4 năm 2026 sẽ bắt đầu triển khai Hegotá, còn nghiên cứu, đặc tả và thử nghiệm của nhiều phiên bản tiếp theo phải được tiến hành song song.

Theo lộ trình hiện tại, các giai đoạn chính được sắp xếp như sau:

• Hegotá: nằm ở điểm khởi đầu của lộ trình này. Định vị chính thức về nó rất rõ ràng: bản thân Hegotá không phải là nâng cấp kháng lượng tử, nhưng sẽ quyết định liệu các nâng cấp kháng lượng tử tiếp theo có thể tiến hành đúng hạn hay không.
• I*: triển khai sổ đăng ký khóa công khai kháng lượng tử, thiết lập nền tảng giao thức cho việc đăng ký và sử dụng khóa công khai kháng lượng tử của tài khoản; đồng thời, tách rời đồng thuận là hướng ứng viên cốt lõi dẫn đầu hiện tại của phiên bản này, công việc thiết kế và di chuyển cấu trúc trạng thái quy mô lớn cũng dự kiến bắt đầu từ I*.
• J*: thiết lập lớp 1 "kháng lượng tử khả thi tối thiểu", tức MV-PQ. Các thành phần chính bao gồm cơ chế heartbeat kháng lượng tử ở lớp đồng thuận, lấy mẫu leanDA hậu lượng tử ở lớp dữ liệu, và giao dịch leanSPHINCS hậu lượng tử ở lớp thực thi.
• K*: theo thứ tự cơ sở hiện tại, giới thiệu bằng chứng thực thi bắt buộc. Khi đó hướng phát triển của validator là xác minh bằng chứng thực thi ngắn gọn, thay vì mỗi validator đều thực thi lại toàn bộ khối.
• L*: theo thứ tự cơ sở hiện tại, bổ sung các thông điệp chứng thực kháng lượng tử cần thiết để đạt được đồng thuận kháng lượng tử đầy đủ, tức post-quantum attestations, và đạt mục tiêu kháng lượng tử đầy đủ ở lớp thực thi, lớp đồng thuận và lớp dữ liệu vào tháng 12 năm 2029.

Tuy nhiên, thứ tự nhiệm vụ của K* và L* vẫn chưa được xác định cuối cùng. Nhóm giao thức đang đánh giá một phương án hoán đổi: đưa thông điệp chứng thực kháng lượng tử từ L* lên K*, để năng lực kháng lượng tử đầy đủ được hiện thực hóa sớm hơn; đồng thời lùi bằng chứng thực thi bắt buộc từ K* xuống L*. Nếu áp dụng phương án này, trách nhiệm cụ thể và nhịp độ nâng cấp của K* và L* sẽ thay đổi tương ứng. Do đó, cách nói chính xác nhất ở giai đoạn hiện tại là: tháng 12 năm 2026 là mục tiêu mainnet hiện tại của Glamsterdam, tháng 12 năm 2029 là mục tiêu của L* và năng lực kháng lượng tử đầy đủ trong lộ trình cơ sở; thứ tự nội bộ của K* và L* vẫn có thể điều chỉnh.

Các nhà nghiên cứu, nhà phát triển client, nhân viên đánh giá bảo mật và nhóm thử nghiệm vừa phải hoàn thành Hegotá, vừa phải chuẩn bị trước đặc tả và nguyên mẫu cho I*, J*, K* và L*. Nếu Hegotá đưa vào quá nhiều tính năng ảnh hưởng lẫn nhau, nó không chỉ có thể trì hoãn việc lên mainnet của chính mình, mà còn chiếm dụng các nhóm cần thiết cho công việc kháng lượng tử tiếp theo.

Vì vậy, nhóm giao thức Ethereum Foundation đã phân loại các đề xuất ứng viên của Hegotá thành các cấp S (2 mục), A (15 mục), B (8 mục), C (7 mục), DFI (28 mục) và TBD (2 mục), tổng cộng 62 đề xuất ứng viên. Cấp S nghĩa là bắt buộc phải bàn giao; cấp A nghĩa là ưu tiên cao, dự kiến bàn giao; cấp B còn cần đáp ứng các điều kiện như đặc tả, nguyên mẫu hoặc xác nhận người phụ trách; cấp C tạm thời dưới ngưỡng được đưa vào; DFI nghĩa là không khuyến nghị đưa vào lần nâng cấp này; TBD nghĩa là chưa xác định.

Hai mục cấp S của Hegotá: FOCIL và Frames

Trong phân loại Hegotá do nhóm giao thức công bố, chỉ có hai EIP vào cấp S: EIP-7805 FOCIL ở lớp đồng thuận, và EIP-8141 Frame Transactions ở lớp thực thi.

Chúng lần lượt xử lý hai vấn đề then chốt trong vòng đời giao dịch: liệu một giao dịch đủ điều kiện có thể vào khối hay không, và một tài khoản có thể xác minh và thực thi giao dịch bằng cách nào.

FOCIL (EIP-7805) là viết tắt của "Fork-choice enforced Inclusion Lists" (Danh sách bao gồm được thực thi bởi quy tắc lựa chọn fork). Mục tiêu của nó là cải thiện đảm bảo bao gồm giao dịch của Ethereum.

Hiện tại, các nhà xây dựng khối chuyên nghiệp chi phối việc tạo khối. Sự phân công này giúp nâng cao hiệu quả xây dựng khối, nhưng nếu việc sản xuất khối tập trung lâu dài vào tay một số ít nhà xây dựng, họ cũng có thể có được khả năng sàng lọc giao dịch mạnh hơn. FOCIL vì vậy bổ sung thêm một lớp ràng buộc bao gồm từ phía validator bên ngoài quy trình xây dựng khối thông thường.

Theo thiết kế của FOCIL, mỗi Slot sẽ chọn ra một nhóm validator tạo thành "Ủy ban danh sách bao gồm" (IL committee). Các thành viên ủy ban dựa trên các giao dịch đang chờ xử lý mà họ nhìn thấy, lần lượt tạo và phát sóng danh sách bao gồm. Nhà xây dựng khối của Slot tiếp theo thu thập các danh sách này, và khi xây dựng khối sẽ thêm vào các giao dịch đủ điều kiện thực thi trong đó. Các validator chịu trách nhiệm chứng thực khối mới cũng sẽ lưu các danh sách bao gồm mà họ nhận được kịp thời, và kiểm tra xem khối có đáp ứng các yêu cầu tương ứng hay không.

Nếu khối bỏ sót các giao dịch trong danh sách mà validator đã lưu mà không có lý do chính đáng, người chứng thực sẽ không bỏ phiếu cho khối đó. Một khối như vậy dù vẫn là khối hợp lệ ở lớp thực thi, cũng không thể nhận được sự ủng hộ đồng thuận cần thiết để vào chuỗi chuẩn. Đây chính là ý nghĩa của FOCIL: nó không để các thành viên ủy ban trực tiếp sửa đổi khối, mà thông qua việc validator có bỏ phiếu hay không để ràng buộc lựa chọn của nhà xây dựng khối.

EIP-8369 đi kèm mô tả thêm những giao dịch nào phù hợp để nhận được đảm bảo bao gồm bắt buộc của FOCIL. Lý do bỏ sót giao dịch thông thường tương đối dễ xác minh; giao dịch Frames cho phép xác minh lập trình được, chi phí phán đoán cao hơn, do đó cần giới hạn thêm phạm vi trạng thái có thể đọc và ngân sách xác minh.

Nói một cách dễ hiểu, FOCIL không phải để validator cướp công việc của nhà xây dựng khối, mà là thêm một quy tắc lớp đồng thuận cho nhà xây dựng: bạn vẫn có thể sắp xếp phần lớn giao dịch trong khối, nhưng không thể liên tục bỏ qua các giao dịch đủ điều kiện do ủy ban liệt kê mà không có lý do hợp lý.

Frame Transactions (EIP-8141) xử lý vấn đề ở lớp tài khoản. Nó dự kiến làm cho việc xác minh giao dịch, thực thi giao dịch và thanh toán Gas trở nên lập trình được hơn ở lớp giao thức, tạo nền tảng cho trừu tượng hóa tài khoản gốc. Vitalik là một trong những đồng tác giả của EIP-8141.

Hiện tại, hầu hết các tài khoản Ethereum thông thường phụ thuộc vào chữ ký khóa riêng loại cố định. Frames muốn cho phép tài khoản sử dụng logic xác minh linh hoạt hơn, ví dụ áp dụng sơ đồ chữ ký mới, kết hợp nhiều điều kiện ủy quyền, hoặc để tài khoản khác thanh toán phí giao dịch. Nó cũng có thể hỗ trợ tổng hợp chữ ký, và cho phép sau này giới thiệu các sơ đồ chữ ký mới mà không cần thực hiện một hard fork riêng cho từng sơ đồ.

Nhưng bản thân Frames không phải là sơ đồ chữ ký kháng lượng tử hoàn chỉnh, cũng sẽ không loại bỏ ngay các khóa hiện có sau khi Hegotá lên mainnet. Nó cung cấp "tính linh hoạt mật mã": trong tương lai nếu cần thay đổi sơ đồ chữ ký, tài khoản có thể hoàn tất di chuyển thông qua xác minh lập trình, thay vì bị khóa vĩnh viễn vào một hệ thống khóa duy nhất.

Frames còn cần hai đề xuất cấp A làm thành phần cốt lõi đi kèm. EIP-8250 Keyed Nonces cho phép cùng một người gửi sử dụng các kênh nonce độc lập với nhau, giúp các giao dịch khác nhau không bị chặn lẫn nhau do chia sẻ một thứ tự nghiêm ngặt; EIP-8272 cho phép giao dịch sử dụng trạng thái on-chain gần đây mà validator có thể kiểm tra, giúp các giao dịch riêng tư liên quan cũng nhận được đảm bảo bao gồm do FOCIL cung cấp.

Do đó, FOCIL và Frames không phải là hai tính năng không liên quan. Cái trước thay đổi những giao dịch đủ điều kiện nào khối phải bao gồm, cái sau thay đổi cấu trúc xác minh của chính giao dịch. Liệu hai cái có thể phối hợp an toàn hay không, là một trong những nhiệm vụ thử nghiệm quan trọng nhất của Hegotá.

Ngoài cấp S, còn những EIP nào đáng chú ý?

Các đề xuất cấp S định nghĩa tuyến chính của Hegotá, nhưng nhiều đề xuất cấp A cũng sẽ ảnh hưởng đến bảo mật tài khoản, di chuyển kháng lượng tử, bằng chứng thực thi và định giá tài nguyên trong tương lai của Ethereum.

Đầu tiên là EIP-8365. Nó dự kiến khởi động việc loại bỏ dần một số thông tin rút tiền BLS, vì những thông tin này vẫn phụ thuộc vào công nghệ mật mã có thể mất an toàn khi đối mặt với tấn công lượng tử đủ mạnh. Nhóm giao thức cho rằng việc di chuyển này có thể bắt đầu sớm, không cần chờ thiết kế đồng thuận kháng lượng tử hoàn chỉnh được xác định.

Về bảo mật tài khoản, EIP-7906, EIP-8298 và EIP-8151 được coi là tổ hợp mở rộng của Frames.

EIP-7906 giới thiệu cơ chế Transaction Assertions (Khẳng định giao dịch), cho phép giao dịch trước khi gửi cuối cùng kiểm tra xem kết quả chỉ định có xảy ra hay không. Cơ chế này nhằm giảm thiểu tổn thất do hợp đồng độc hại rút tài sản ví và một số hành vi MEV gây ra. Tuy nhiên, phạm vi đọc cụ thể của đề xuất này vẫn đang được nghiên cứu và thu hẹp, do đó không thể coi thiết kế hiện tại là đặc tả cuối cùng đã khóa.

EIP-8298 cho phép tài khoản tái sử dụng mã hợp đồng hiện có, giúp tài khoản được ủy quyền chuyển đổi thêm thành tài khoản hợp đồng thông minh có mã đầy đủ. EIP-8151 hạn chế các địa chỉ đã có mã tài khoản tiếp tục phụ thuộc vào xác thực ecRecover truyền thống.

Sau khi kết hợp hai đề xuất này, tài khoản mới có thể thực sự ngừng coi khóa secp256k1 cũ là thông tin kiểm soát tối cao, thiết lập lộ trình hoàn chỉnh cho việc loại bỏ hệ thống khóa cũ trong tương lai.

EIP-8025 (bằng chứng thực thi tùy chọn) liên quan đến lộ trình zkEVM trong tương lai. Nó dự kiến đưa các thay đổi cần thiết cho bằng chứng thực thi tùy chọn vào đặc tả thực thi thống nhất, giảm vấn đề các dự án zkVM khác nhau phải duy trì lâu dài các phiên bản fork riêng.

EIP-8279 (lớp Byte danh sách truy cập khối) và EIP-8131 (lớp nội dung giao dịch thống nhất) là một nhóm đề xuất bảo mật thực thi. Hai đề xuất này lần lượt đặt tiêu chuẩn định giá tối thiểu cho danh sách truy cập khối và nội dung giao dịch, nhằm hạn chế kẻ tấn công lợi dụng nội dung bị định giá thấp để tạo ra gánh nặng tài nguyên cực đoan. Chúng trước tiên giải quyết chi phí xử lý khối trong trường hợp xấu nhất, chứ không trực tiếp tuyên bố tăng dung lượng mạng. Việc có tận dụng biên độ an toàn tạo ra từ đó để mở rộng dung lượng hay không cần được quyết định riêng sau này.

EIP-3298 dự kiến loại bỏ hoàn toàn cơ chế hoàn Gas, giảm các trường hợp đặc biệt trong đo lường, triển khai và thử nghiệm; EIP-5920 (PAY Opcode) cho phép hợp đồng chuyển ETH mà không thực thi mã của hợp đồng nhận, tách bạch rõ ràng "chuyển giá trị" và "gọi hợp đồng".

Đồng thời, một số đề xuất được quan tâm vẫn ở cấp B.

Ví dụ, EIP-8198 (Quick Slots) muốn rút ngắn thời gian Slot, nhưng nhóm giao thức yêu cầu nó trước tiên phải hoàn thành đặc tả bao gồm các thay đổi giao thức cốt lõi, nguyên mẫu đầy đủ, đánh giá tác động hạ nguồn, và chứng minh không can thiệp vào thiết kế tách rời đồng thuận tiếp theo. Lý do là thời gian Slot không chỉ ảnh hưởng đến tốc độ tạo khối, mà còn ảnh hưởng đến truyền tải mạng, phán đoán đồng thuận và giả định của ứng dụng về thời gian.

Ngoài ra, EIP-8368 và EIP-8372 được liệt kê là "TBD" (chưa xác định). Hai đề xuất này liên quan đến giới hạn Gas và định giá tài nguyên trạng thái, nhóm giao thức quyết định chờ dữ liệu mainnet sau khi Glamsterdam lên mainnet vào tháng 12 năm 2026, rồi mới phán đoán xem có cần hiệu chỉnh lại hay không.

Số lượng EIP cuối cùng được đưa vào Hegotá không phải là tiêu chuẩn duy nhất để đánh giá thành công của lần nâng cấp này.

Quan trọng hơn là liệu nó có thể bàn giao FOCIL, Frames và các thành phần cốt lõi đi kèm mà không hy sinh an toàn và chất lượng thử nghiệm, đồng thời để lại đủ nguồn lực nghiên cứu phát triển cho đăng ký khóa công khai và tách rời đồng thuận của I*, năng lực kháng lượng tử khả thi tối thiểu của J*, cũng như bằng chứng thực thi và đồng thuận kháng lượng tử đầy đủ của K*, L*.

Theo mục tiêu hiện tại, Glamsterdam sẽ khởi động chu kỳ nâng cấp dày đặc này vào tháng 12 năm 2026, còn L* trong lộ trình cơ sở sẽ về đích vào tháng 12 năm 2029. Mỗi lần nâng cấp ở giữa không thể chỉ lo hoàn thành chức năng của mình, mà còn phải đảm bảo giai đoạn tiếp theo có thể tiếp tục tiến hành.

Liệu mối đe dọa lượng tử có trở thành hiện thực trước năm 2030 hay không, không ai có thể đưa ra câu trả lời chắc chắn. Nhưng lựa chọn hiện tại của Ethereum đã rất rõ ràng: trước tiên đặt hạn chót cho rủi ro, sau đó để mỗi đề xuất dùng đặc tả, nguyên mẫu và thử nghiệm chứng minh mình đủ điều kiện vào mainnet.

Bài viết tham khảo:

https://blog.ethereum.org/2026/09/07/protocol-hegota-eips

https://blog.ethereum.org/2026/09/07/protocol-priorities

https://x.com/VitalikButerin/status/2073459000398463446