Tác giả gốc: KarenZ, Foresight News
Máy tính lượng tử chưa gõ cửa blockchain, nhưng Quỹ Ethereum đã đánh dấu sẵn một ngày trên lịch: tháng 12 năm 2029.
Đây là thời hạn kỹ thuật mà nhóm giao thức của Quỹ Ethereum tự đặt ra: chuẩn bị cho tình huống mối đe dọa lượng tử có thể xuất hiện sớm, nhằm hoàn thành việc cải tạo mạng lớp một của Ethereum chống lại mối đe dọa lượng tử trước khi rủi ro thực sự đến gần.
Hegotá đang được lên kế hoạch, mặc dù không trực tiếp biến Ethereum thành một blockchain hoàn toàn chống lại máy tính lượng tử, nhưng sẽ quyết định liệu các kế hoạch tiếp theo có thể được triển khai đúng tiến độ hay không.
EF đã đặt hạn chót cho "Q-day" vào năm 2029
「Q-day」 thường được dùng để chỉ một điểm thời gian giả định: sự xuất hiện của máy tính lượng tử có khả năng tấn công thực tế, khiến các hệ thống 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 nó sẽ đến khi nào. Quỹ Ethereum cũng đã công nhận rõ ràng rằng hầu hết các dự báo đáng tin cậy cho rằng Q-day sẽ diễn ra sau 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ờ xảy ra.
Đội ngũ giao thức của Quỹ Ethereum áp dụng một giả định kỹ thuật bảo thủ: Ethereum Layer 1 nên được chuẩn bị sẵn sàng cho khả năng Q-day xảy ra sớm nhất vào năm 2030.
Để đạt được điều này, nhóm giao thức đã đặt ra một mục tiêu – nỗ lực đảm bảo ba thành phần thực thi, đồng thuận và dữ liệu của Ethereum Layer 1 có khả năng chống lại máy tính lượng tử đầy đủ trước tháng 12 năm 2029.
Mục tiêu này cũng không phải là không thay đổi vĩnh viễn. Đội ngũ giao thức dự kiến đánh giá lại tình hình phát triển của máy tính lượng tử vào tháng 1 năm 2027, kết hợp ý kiến từ các chuyên gia bên ngoài. Trước thời điểm đó, mốc thời gian năm 2029 sẽ được coi là một mục tiêu công việc không dễ dàng nhượng bộ.
Việc chuyển đổi chống lại máy tính lượng tử cần được chuẩn bị trước nhiều năm vì Ethereum không chỉ sử dụng một công nghệ mật mã, và cũng không thể hoàn thành việc di chuyển chỉ bằng cách thay đổi một thuật toán chữ ký. Cách tài khoản người dùng chứng minh quyền hạn giao dịch, cách người xác thực tham gia vào sự đồng thuận, và 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ỳ thay đổi nào cũng cần trải qua thiết kế tiêu chuẩn, triển khai client, đánh giá bảo mật, kiểm thử trên mạng phát triển và phối hợp trên mainnet, không thể chờ đế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 chống lượng tử", nhưng lại là bài kiểm tra đầu tiên của toàn bộ kế hoạch
Theo lộ trình tham chiếu do nhóm đội ngũ của Quỹ Ethereum công bố hiện tại, nâng cấp mạng Glamsterdam dự kiến ra mắt trên mainnet vào tháng 12 năm 2026, trong khi khả năng chống lượng tử đầy đủ được lên kế hoạch thực hiện tại lần hard fork thứ năm sau Glamsterdam, mang tên L*, với mục tiêu vào tháng 12 năm 2029. Chỉ có ba năm từ Glamsterdam đến L*, nếu phải lần lượt thực hiện Hegotá, I*, J*, K* và L*, trung bình mỗi lần nâng cấp cách nhau khoảng 7,2 tháng.
Đây là một lịch trình khá tích cực. Hiện tại, Quỹ Ethereum chưa công bố thời gian chính thức để triển khai Hegotá, I*, J* và K*. Tuy nhiên, có thể xác định rằng các đội ngũ client dự kiến bắt đầu triển khai Hegotá vào cuối quý 4 năm 2026, đồng thời các nghiên cứu, tiêu chuẩn và kiểm thử cho nhiều phiên bản tiếp theo phải được tiến hành song song.
The main arrangements for each stage according to the current roadmap are as follows:
- Hegotá: Nằm ở điểm khởi đầu của con đường này. Định vị chính thức của nó rất rõ ràng: Hegotá bản thân không phải là bản nâng cấp chống lượng tử, nhưng sẽ quyết định liệu bản nâng cấp chống lượng tử tiếp theo có thể được triển khai đúng hạn hay không.
- I*: Triển khai registry khóa công khai chống lượng tử để thiết lập nền tảng giao thức cho việc đăng ký tài khoản và sử dụng khóa công khai chống lượng tử; đồng thời, tách rời sự đồng thuận là hướng dẫn đầu hiện tại của phiên bản này, và các công việc thiết kế cũng như di chuyển cấu trúc trạng thái quy mô lớn dự kiến sẽ bắt đầu từ I*.
- J*: Xây dựng lớp "kháng lượng tử tối thiểu khả thi" gọi là MV-PQ. Các thành phần chính bao gồm cơ chế heartbeat kháng lượng tử ở tầng đồng thuận, mẫu leanDA hậu lượng tử ở tầng dữ liệu và giao dịch leanSPHINCS hậu lượng tử ở tầng thực thi.
- K*: Theo thứ tự chuẩn 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 người xác minh là xác minh các bằng chứng thực thi ngắn gọn, thay vì mỗi người xác minh đều thực thi lại toàn bộ khối.
- L*: Theo thứ tự tiêu chuẩn hiện tại, bổ sung các thông điệp chứng thực chống lượng tử (post-quantum attestations) cần thiết để đạt được sự đồng thuận chống lượng tử đầy đủ, và đạt mục tiêu toàn diện về chống lượng tử tại các lớp thực thi, đồng thuận và 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: chuyển tin nhắn chống lượng tử từ L* lên trước K*, để đạt được khả năng chống lượng tử đầy đủ sớm hơn; đồng thời dời việc thực thi chứng minh từ K* sang sau L*. Nếu áp dụng phương án này, trách nhiệm cụ thể của K* và L* cũng như nhịp độ nâng cấp sẽ tương ứng thay đổi. Do đó, tuyên bố chính xác nhất hiện tại là: tháng 12 năm 2026 là mục tiêu mạng chính hiện tại của Glamsterdam, tháng 12 năm 2029 là mục tiêu trong lộ trình cơ bản cho L* và khả năng chống lượng tử đầy đủ; thứ tự nội bộ của K và L* vẫn có thể được điều chỉnh.
Các nhà nghiên cứu, nhà phát triển client, nhân viên kiểm tra bảo mật và đội ngũ kiểm thử cần hoàn thành Hegotá đồng thời chuẩn bị trước các tiêu chuẩn và bản mẫu cho I*, J*, K* và L*. Nếu Hegotá tích hợp quá nhiều tính năng tương tác lẫn nhau, không chỉ có thể làm chậm tiến độ ra mắt của chính nó mà còn chiếm dụng đội ngũ cần thiết cho các công việc chống lượng tử tiếp theo.
Do đó, nhóm giao thức của Quỹ Ethereum đã phân loại 62 đề xuất ứng cử thành các cấp độ: S (2 đề xuất), A (15 đề xuất), B (8 đề xuất), C (7 đề xuất), DFI (28 đề xuất) và TBD (2 đề xuất). Cấp S đại diện cho các đề xuất bắt buộc phải hoàn thành; cấp A đại diện cho các đề xuất ưu tiên cao, dự kiến sẽ được triển khai; cấp B cần đáp ứng các điều kiện như tiêu chuẩn, bản mẫu hoặc xác nhận từ người phụ trách; cấp C hiện tại nằm dưới ngưỡng đưa vào; DFI cho biết không khuyến nghị đưa vào đợt nâng cấp này; TBD có nghĩa là chưa xác định.
Hegotá hai dự án cấp S: FOCIL và Frames
Trong phân cấp Hegotá do nhóm giao thức công bố, chỉ có hai EIP đạt cấp độ S: EIP-7805 FOCIL ở lớp đồng thuận và EIP-8141 Frame Transaction ở lớp thực thi.
Chúng xử lý hai vấn đề then chốt trong vòng đời giao dịch: một giao dịch đủ điều kiện có thể được đưa vào khối hay không, và một tài khoản có thể xác thực và thực hiện 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 đưa vào được thực thi bởi quy tắc lựa chọn phân nhánh). Mục tiêu của nó là cải thiện khả năng đảm bảo đưa vào giao dịch trên Ethereum.
Hiện tại, các nhà xây dựng khối chuyên nghiệp thống trị quá trình 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 bị tập trung lâu dài vào một số ít nhà xây dựng, họ cũng có thể giành được khả năng lọc giao dịch mạnh mẽ. Do đó, FOCIL thêm một lớp ràng buộc từ các người xác thực vào quy trình xây dựng khối bình thường.
Theo thiết kế của FOCIL, mỗi Slot sẽ chọn ra một nhóm người xác thực để tạo thành "Ủy ban danh sách đưa vào" (IL committee). Các thành viên trong ủy ban sẽ dựa trên các giao dịch đang chờ xử lý mà họ quan sát được, lần lượt tạo và phát sóng danh sách đưa vào. Người xây dựng khối của Slot tiếp theo sẽ thu thập các danh sách này và thêm vào khối các giao dịch đáp ứng điều kiện thực thi. Những người xác thực chịu trách nhiệm chứng minh khối mới cũng sẽ lưu giữ các danh sách đưa vào 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 một khối bỏ sót danh sách giao dịch được lưu bởi người xác thực mà không có lý do chính đáng, các người chứng thực sẽ không bỏ phiếu cho khối đó. Dù khối như vậy vẫn hợp lệ về mặt thực thi, nó sẽ không nhận được sự đồng thuận cần thiết để được đưa vào chuỗi chuẩn. Đây chính là ý nghĩa của FOCIL: nó không cho phép các thành viên ủy ban trực tiếp sửa đổi khối, mà thay vào đó ràng buộc lựa chọn của người xây dựng khối thông qua việc người xác thực có bỏ phiếu hay không.
EIP-8369 đi kèm mô tả chi tiết các giao dịch nào phù hợp để được bảo đảm đưa vào bắt buộc bởi FOCIL. Lý do bỏ sót các giao dịch thông thường tương đối dễ xác minh; các giao dịch Frames cho phép xác minh có thể lập trình, nhưng chi phí xác minh cao hơn, do đó cần giới hạn bổ sung phạm vi trạng thái có thể đọc được và ngân sách xác minh.
Nói một cách đơn giản, FOCIL không nhằm mục đích để các người xác thực chiếm lấy công việc của người xây dựng khối, mà là thêm một quy tắc lớp đồng thuận cho người 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 được liên tục bỏ qua các giao dịch đủ điều kiện được liệt kê bởi ủy ban mà không có lý do hợp lý.
Frame Transactions (EIP-8141) giải quyết các vấn đề ở cấp độ tài khoản. Nó nhằm mục tiêu làm cho việc xác thực giao dịch, thực thi giao dịch và thanh toán Gas trở nên có thể lập trình hơn ở cấp độ giao thức, tạo nền tảng cho việc trừu tượng hóa tài khoản bản địa. 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 có kiểu cố định. Frames mong muốn cho phép tài khoản sử dụng logic xác thực linh hoạt hơn, chẳng hạn như áp dụng các sơ đồ chữ ký mới, kết hợp nhiều điều kiện ủy quyền, hoặc cho phép cá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 giới thiệu các sơ đồ chữ ký mới trong tương lai mà không cần thực hiện một hard fork riêng biệt cho từng loại.
Tuy nhiên, Frames bản thân không phải là một giải pháp chữ ký chống lượng tử hoàn chỉnh, và cũng sẽ không ngay lập tức thay thế các khóa hiện có sau khi Hegotá ra mắt. Nó cung cấp “tính linh hoạt mật mã”: trong tương lai, nếu cần thay đổi giải pháp chữ ký, tài khoản có thể thực hiện chuyển đổi thông qua xác minh có thể lập trình, thay vì bị khóa vĩnh viễn trong một hệ thống khóa duy nhất.
Frames cần thêm hai đề xuất cấp A làm hỗ trợ cốt lõi. 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 phải 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 trên chuỗi gần đây có thể được người xác minh kiểm tra, giúp các giao dịch bảo mật liên quan cũng nhận được sự đảm bảo về việc đưa vào từ FOCIL.
Do đó, FOCIL và Frames không phải là hai tính năng độc lập. Tính năng đầu tiên thay đổi các giao dịch đủ điều kiện phải được đưa vào khối, trong khi tính năng thứ hai thay đổi cấu trúc xác thực của giao dịch. Việc hai tính năng này có thể phối hợp an toàn với nhau là một trong những nhiệm vụ kiểm thử quan trọng nhất của Hegotá.
Ngoài các EIP cấp S, những EIP nào khác đáng để quan tâm?
Đề xuất cấp S xác định tuyến đường chính của Hegotá, nhưng nhiều đề xuất cấp A cũng ảnh hưởng đến bảo mật tài khoản tương lai của Ethereum, chuyển đổi chống lại máy tính lượng tử, bằng chứng thực thi và định giá tài nguyên.
Trước tiên là EIP-8365. Nó lên kế hoạch khởi động quá trình rút dần đối với các chứng từ rút BLS một phần, vì những chứng từ này vẫn dựa vào các kỹ thuật mật mã có thể mất an toàn trước các cuộc 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 hơn, mà không cần chờ thiết kế đồng thuận chố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 xem là tổ hợp mở rộng của Frames.
EIP-7906 giới thiệu cơ chế Trình xác thực giao dịch (Transaction Assertions), cho phép kiểm tra xem kết quả được chỉ định có xảy ra hay không trước khi giao dịch được gửi cuối cùng. Cơ chế này nhằm giảm thiểu tổn thất do hợp đồng độc hại trích cạn tài sản ví và một số hành vi MEV. 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à tiêu chuẩn cuối cùng đã được cố định.
EIP-8298 cho phép tài khoản tái sử dụng mã hợp đồng hiện có, giúp các tài khoản đã được ủy quyền chuyển đổi thành tài khoản hợp đồng thông minh có đầy đủ mã. EIP-8151 hạn chế các địa chỉ tài khoản hiện có tiếp tục phụ thuộc vào xác thực ecRecover truyền thống.
Khi kết hợp hai đề xuất này, tài khoản mới có thể thực sự ngừng sử dụng khóa secp256k1 cũ làm chứng nhận kiểm soát cao nhất, tạo ra lộ trình hoàn chỉnh để thoát khỏi hệ thống khóa cũ trong tương lai.
EIP-8025 (Chứng minh thực thi tùy chọn) liên quan đến lộ trình zkEVM trong tương lai. Nó dự kiến tích hợp các thay đổi cần thiết cho chứng minh thực thi tùy chọn vào tiêu chuẩn thực thi thống nhất, nhằm giảm thiểu vấn đề duy trì các phiên bản phân nhánh riêng biệt của các dự án zkVM trong dài hạn.
EIP-8279 (Byte Layer của 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 bộ đề xuất an toàn thực thi. Cả hai đều thiết lập 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 tạo ra gánh nặng tài nguyên cực đoan bằng cách tận dụng nội dung có giá thấp. Chúng đầu 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 sử dụng khoảng an toàn tạo ra để mở rộng dung lượng sẽ cần được quyết định riêng biệt sau này.
EIP-3298 dự định loại bỏ hoàn toàn cơ chế hoàn lại Gas, giảm các trường hợp đặc biệt trong đo lường, triển khai và kiểm thử; EIP-5920 (PAY Opcode) cho phép hợp đồng chuyển ETH mà không thực thi mã bên nhận, tách biệt rõ ràng giữa “chuyển giá trị” và “gọi hợp đồng”.
Meanwhile, some notable proposals remain at Level B.
Ví dụ, EIP-8198 (Quick Slots) mong muốn rút ngắn thời gian Slot, nhưng nhóm giao thức yêu cầu nó phải hoàn thành trước các tài liệu quy chuẩn, bản mẫu đầy đủ, đánh giá tác động downstream liên quan đến các thay đổi cốt lõi của giao thức, đồng thời chứng minh rằng nó không gây nhiễu đến thiết kế đồng thuận tách rời trong tương lai. Lý do là thời gian Slot không chỉ ảnh hưởng đến tốc độ tạo khối, mà còn tác động đến mạng truyền thông, đánh giá đồng thuận và các giả định về thời gian của ứng dụng.
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 ra mắt vào tháng 12 năm 2026 trước khi đánh giá xem có cần hiệu chỉnh lại hay không.
Số lượng EIP được đưa vào cuối cùng bởi Hegotá không phải là tiêu chí duy nhất để đánh giá mức độ thành công của đợt nâng cấp này.
Quan trọng hơn, liệu nó có thể triển khai FOCIL, Frames và các thành phần cốt lõi đi kèm mà không làm giảm chất lượng bảo mật và kiểm thử, đồng thời dành đủ nguồn lực nghiên cứu và phát triển cho việc đăng ký khóa công khai và tách rời đồng thuận của I*, khả năng chống lượng tử tối thiểu của J*, cũng như bằng chứng thực thi và đồng thuận chống lượng tử đầy đủ của K* và L*.
Theo mục tiêu hiện tại, Glamsterdam sẽ khởi động chu kỳ nâng cấp chặt chẽ này vào tháng 12 năm 2026, trong khi L* trong lộ trình cơ sở sẽ đạt đến điểm kết thúc vào tháng 12 năm 2029. Mỗi lần nâng cấp ở giữa đều không chỉ cần hoàn thành chức năng của riêng mình, mà còn phải đảm bảo giai đoạn tiếp theo có thể tiếp tục tiến triển.
Không ai có thể đưa ra câu trả lời chắc chắn 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. Nhưng lựa chọn hiện tại của Ethereum đã rất rõ ràng: đặt thời hạn cho rủi ro, sau đó để từng đề xuất chứng minh khả năng đáp ứng các điều kiện để đưa lên mainnet thông qua tiêu chuẩn, bản mẫu và kiểm thử.
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

