Sau Pectra, Fusaka đã đến: Bước tiến quan trọng nhất của Ethereum hướng tới “mở rộng vô hạn”

Fusaka hard fork, dự kiến sẽ được kích hoạt vào ngày 3 tháng 12 năm 2025, là một nâng cấp mạng lớn tiếp theo của Ethereum sau Pectra, đánh dấu một bước tiến quan trọng nữa của gã khổng lồ crypto này trong việc mở rộng quy mô.

Các EIP của nâng cấp Pectra tập trung vào việc cải thiện hiệu suất, bảo mật và công cụ dành cho nhà phát triển. Các EIP của nâng cấp Fusaka lại chú trọng vào mở rộng quy mô, cập nhật opcode và bảo mật thực thi.

PeerDAS (EIP-7594) nâng cao tính khả dụng của dữ liệu bằng cách cho phép node xác thực Blob mà không cần tải xuống toàn bộ dữ liệu. Nhiều nâng cấp cũng tăng cường bảo mật thực thi, bao gồm giới hạn ModExp (EIP-7823), giới hạn gas tối đa cho giao dịch (EIP-7825) và cập nhật chi phí gas cho ModExp (EIP-7883). Nâng cấp Fusaka còn cải thiện việc tạo block thông qua cơ chế xác định người đề xuất trước (EIP-7917) và giữ cho phí Blob ổn định bằng cách đặt "giá dự trữ" liên kết với chi phí thực thi (EIP-7918).

Các tính năng tăng cường khác bao gồm giới hạn kích thước block định dạng RLP (EIP-7934), thêm opcode CLZ mới để tăng tốc thao tác bit (EIP-7939), và giới thiệu precompile secp256r1 (EIP-7951) để tương thích tốt hơn với mật mã học hiện đại và khóa bảo mật phần cứng.

Fusaka là tên ghép của Fulu (lớp thực thi) và Osaka (lớp đồng thuận). Nó đại diện cho một bước tiến nữa của Ethereum hướng tới tương lai mở rộng quy mô cao và dữ liệu phong phú, nơi Layer 2 Rollup có thể hoạt động với chi phí thấp hơn và tốc độ nhanh hơn.

Bài viết này sẽ phân tích sâu 9 đề xuất EIP cốt lõi của hard fork Fusaka.

EIP-7594: PeerDAS — Sampling tính khả dụng dữ liệu của node

Ethereum cần đề xuất này vì mạng lưới mong muốn cung cấp tính khả dụng dữ liệu cao hơn cho người dùng (đặc biệt là người dùng Rollup).

Tuy nhiên, trong thiết kế EIP-4844 hiện tại, mỗi node vẫn cần tải xuống một lượng lớn dữ liệu blob để xác thực xem nó đã được xuất bản hay chưa. Điều này gây ra vấn đề mở rộng, vì nếu tất cả node đều phải tải xuống toàn bộ dữ liệu, nhu cầu về băng thông và phần cứng của mạng sẽ tăng lên, đồng thời mức độ phi tập trung cũng bị ảnh hưởng. Để giải quyết vấn đề này, Ethereum cần một phương pháp cho phép node xác nhận dữ liệu khả dụng mà không cần tải xuống toàn bộ dữ liệu.

Data Availability Sampling (DAS) giải quyết vấn đề này bằng cách cho phép node chỉ kiểm tra một lượng nhỏ dữ liệu ngẫu nhiên.

Tuy nhiên, Ethereum cũng cần một phương pháp DAS tương thích với mạng Gossip hiện tại và không tạo gánh nặng tính toán lớn cho block producer. PeerDAS được tạo ra để đáp ứng các nhu cầu này, đồng thời tăng thông lượng blob một cách an toàn mà vẫn giữ yêu cầu đối với node ở mức thấp.

PeerDAS là một hệ thống mạng cho phép node chỉ tải xuống một số mảnh dữ liệu nhỏ để xác thực toàn bộ dữ liệu đã được xuất bản. Node không cần tải xuống toàn bộ dữ liệu mà sử dụng mạng gossip thông thường để chia sẻ dữ liệu, phát hiện node nào giữ phần dữ liệu cụ thể và chỉ yêu cầu mẫu nhỏ cần thiết. Ý tưởng cốt lõi là, bằng cách chỉ tải xuống một phần nhỏ ngẫu nhiên của dữ liệu, node vẫn có thể chắc chắn về sự tồn tại của toàn bộ đoạn dữ liệu. Ví dụ, node có thể chỉ tải xuống khoảng 1/8 dữ liệu thay vì toàn bộ đoạn dữ liệu 256 KB — nhưng vì nhiều node sẽ lấy mẫu các phần khác nhau, bất kỳ dữ liệu nào bị thiếu sẽ nhanh chóng bị phát hiện.

Để thực hiện sampling, PeerDAS sử dụng một loại mã sửa lỗi cơ bản để mở rộng mỗi đoạn dữ liệu trong EIP-4844. Mã sửa lỗi là một kỹ thuật thêm dữ liệu dư thừa, cho phép khôi phục dữ liệu gốc ngay cả khi một số mảnh bị thiếu — giống như một bức tranh ghép vẫn có thể hoàn thành dù thiếu một vài mảnh.

Blob sẽ trở thành một "hàng", chứa dữ liệu gốc cùng một số dữ liệu mã hóa bổ sung để có thể khôi phục sau này. Sau đó, hàng này được chia thành nhiều mảnh nhỏ gọi là "cell", cell là đơn vị xác thực nhỏ nhất liên kết với cam kết KZG. Tất cả các "hàng" sau đó được tổ chức lại thành "cột", mỗi cột chứa các cell ở cùng vị trí từ tất cả các hàng. Mỗi cột được phân bổ cho một subnet gossip cụ thể.

Node chịu trách nhiệm lưu trữ một số cột nhất định dựa trên node ID của mình và lấy mẫu một số cột từ các node ngang hàng trong mỗi slot. Nếu một node thu thập được ít nhất 50% số cột, nó có thể khôi phục hoàn toàn dữ liệu. Nếu thu thập được ít hơn 50%, nó cần yêu cầu các cột còn thiếu từ các node ngang hàng. Điều này đảm bảo rằng nếu dữ liệu thực sự đã được xuất bản, thì luôn có thể khôi phục lại. Nói ngắn gọn, nếu tổng cộng có 64 cột, một node chỉ cần khoảng 32 cột để khôi phục toàn bộ blob. Nó tự giữ một số cột và tải xuống một số cột từ các node ngang hàng. Miễn là có một nửa số cột tồn tại trong mạng, node có thể khôi phục mọi thứ, ngay cả khi một số cột bị thiếu.

Ngoài ra, EIP-7594 còn đưa ra một quy tắc quan trọng: bất kỳ giao dịch nào cũng không được chứa quá 6 blob. Giới hạn này phải được thực thi trong quá trình xác thực giao dịch, truyền gossip, tạo block và xử lý block. Điều này giúp giảm thiểu các trường hợp cực đoan khi một giao dịch đơn lẻ làm quá tải hệ thống blob.

PeerDAS bổ sung một tính năng gọi là "cell KZG proof". Cell KZG proof chứng minh rằng cam kết KZG thực sự khớp với một cell cụ thể (một đơn vị nhỏ) trong blob. Điều này cho phép node chỉ tải xuống cell mà nó muốn lấy mẫu. Trong khi vẫn đảm bảo tính toàn vẹn của dữ liệu, node có thể lấy toàn bộ blob, điều này rất quan trọng đối với sampling tính khả dụng dữ liệu.

Tuy nhiên, chi phí tạo tất cả các cell proof này là rất cao. Block producer cần tính toán các proof này nhiều lần cho nhiều blob, khiến tốc độ quá chậm. Tuy nhiên, chi phí xác thực proof lại rất thấp, do đó, EIP-7594 yêu cầu người gửi giao dịch blob phải tạo sẵn tất cả cell proof và đưa chúng vào wrapper của giao dịch.

Chính vì vậy, transaction gossip (PooledTransactions) hiện sử dụng một wrapper đã được sửa đổi:

rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs])

Trong wrapper mới, cell_proofs chỉ là một danh sách chứa tất cả proof của từng cell trong mỗi blob (ví dụ: [cell_proof_0, cell_proof_1, ...]). Các trường khác tx_payload_body, blobs và commitments hoàn toàn giống với EIP-4844. Khác biệt ở chỗ, trường "proofs" đơn lẻ trước đây bị loại bỏ và thay bằng danh sách cell_proofs mới, đồng thời thêm trường wrapper_version để chỉ định định dạng wrapper hiện tại.

PeerDAS cho phép Ethereum tăng tính khả dụng dữ liệu mà không tăng khối lượng công việc của node. Hiện tại, một node chỉ cần lấy mẫu khoảng 1/8 tổng dữ liệu. Trong tương lai, tỷ lệ này thậm chí có thể giảm xuống 1/16 hoặc 1/32, giúp tăng khả năng mở rộng của Ethereum. Hệ thống này hoạt động tốt vì mỗi node đều có nhiều node ngang hàng, nên nếu một node ngang hàng không cung cấp được dữ liệu cần thiết, node đó có thể yêu cầu từ các node ngang hàng khác. Điều này tự nhiên xây dựng cơ chế dự phòng và tăng cường bảo mật, node cũng có thể chọn lưu trữ nhiều dữ liệu hơn mức cần thiết, càng tăng cường bảo mật cho mạng lưới.

Validator node chịu trách nhiệm nhiều hơn node đầy đủ thông thường. Vì validator node chạy phần cứng mạnh hơn, PeerDAS sẽ phân bổ tải lưu trữ dữ liệu phù hợp với tổng số validator node. Điều này đảm bảo luôn có một nhóm node ổn định để lưu trữ và chia sẻ nhiều dữ liệu hơn, tăng độ tin cậy của mạng. Nói ngắn gọn, nếu có 900,000 validator node, mỗi node có thể được phân bổ một phần nhỏ tổng dữ liệu để lưu trữ và phục vụ. Vì validator node có máy mạnh hơn, mạng có thể tin tưởng họ đảm bảo tính khả dụng dữ liệu.

PeerDAS sử dụng sampling theo cột thay vì theo hàng vì điều này đơn giản hóa đáng kể việc khôi phục dữ liệu. Nếu node lấy mẫu theo hàng (toàn bộ blob), cần tạo ra các "blob mở rộng" không tồn tại ban đầu, làm chậm tốc độ block producer.

Với sampling theo cột, node có thể chuẩn bị trước dữ liệu hàng bổ sung, và người gửi giao dịch (không phải block producer) sẽ tính toán các proof cần thiết. Điều này giữ cho việc tạo block nhanh và hiệu quả. Ví dụ: giả sử một blob là một lưới 4×4 cell. Sampling theo hàng nghĩa là lấy cả 4 cell từ một hàng, nhưng một số hàng mở rộng chưa được chuẩn bị, nên block producer phải tạo chúng tại chỗ; sampling theo cột là lấy một cell từ mỗi hàng (mỗi cột), các cell bổ sung cần thiết có thể chuẩn bị trước, giúp node xác thực dữ liệu mà không làm chậm tốc độ tạo block.

EIP-7594 hoàn toàn tương thích với EIP-4844, nên không phá vỡ bất kỳ chức năng hiện có nào trên Ethereum. Tất cả các bài kiểm tra và quy tắc chi tiết đều được bao gồm trong đặc tả đồng thuận và thực thi.

Rủi ro bảo mật chính của bất kỳ hệ thống DAS nào là "tấn công che giấu dữ liệu", tức là block producer giả vờ dữ liệu khả dụng nhưng thực tế che giấu một phần dữ liệu. PeerDAS ngăn chặn điều này bằng sampling ngẫu nhiên: node kiểm tra các phần ngẫu nhiên của dữ liệu. Càng nhiều node sampling, kẻ tấn công càng khó gian lận. EIP-7594 thậm chí còn cung cấp một công thức tính xác suất thành công của kiểu tấn công này dựa trên tổng số node (n), tổng số mẫu (m) và số mẫu mỗi node (k). Trên mainnet Ethereum với khoảng 10,000 node, xác suất tấn công thành công là cực kỳ thấp, do đó PeerDAS được coi là an toàn.

EIP-7823: Đặt giới hạn 1024 byte cho MODEXP

Đề xuất này cần thiết vì cơ chế precompile MODEXP hiện tại của Ethereum trong nhiều năm qua đã gây ra nhiều lỗ hổng đồng thuận. Các lỗ hổng này chủ yếu xuất phát từ việc MODEXP cho phép đầu vào dữ liệu cực kỳ lớn và phi thực tế, khiến client phải xử lý vô số trường hợp ngoại lệ.

Vì mỗi node đều phải xử lý toàn bộ đầu vào do giao dịch cung cấp, nên không có giới hạn khiến MODEXP khó kiểm thử hơn, dễ xảy ra lỗi hơn và dễ có hành vi khác nhau trên các client khác nhau. Đầu vào quá lớn cũng khiến công thức tính phí gas khó dự đoán, vì khi dữ liệu có thể tăng vô hạn, rất khó để định giá. Những vấn đề này cũng khiến việc thay thế MODEXP bằng mã cấp EVM bằng các công cụ như EVMMAX trong tương lai trở nên khó khăn, vì nếu không có giới hạn cố định, nhà phát triển không thể tạo ra đường dẫn thực thi an toàn và tối ưu.

Để giảm các vấn đề này và tăng tính ổn định cho Ethereum, EIP-7823 thêm giới hạn nghiêm ngặt cho lượng dữ liệu đầu vào MODEXP, giúp quá trình precompile an toàn hơn, dễ kiểm thử hơn và dễ dự đoán hơn.

EIP-7823 đưa ra một quy tắc đơn giản: cả ba trường độ dài (cơ số, số mũ và modulus) mà MODEXP sử dụng đều phải nhỏ hơn hoặc bằng 8192 bit, tức là 1024 byte. Đầu vào MODEXP tuân theo định dạng được định nghĩa trong EIP-198: <len(BASE)> <len(EXPONENT)> <len(MODULUS)> <BASE> <EXPONENT> <MODULUS>, do đó EIP này chỉ giới hạn giá trị độ dài. Nếu bất kỳ độ dài nào vượt quá 1024 byte, precompile sẽ dừng ngay lập tức, trả về lỗi và tiêu tốn toàn bộ gas.

Ví dụ, nếu ai đó cố gắng cung cấp một cơ số dài 2000 byte, lời gọi sẽ thất bại trước khi bất kỳ công việc nào bắt đầu. Các giới hạn này vẫn đáp ứng được tất cả các trường hợp sử dụng thực tế. Xác thực RSA thường sử dụng độ dài khóa 1024 bit, 2048 bit hoặc 4096 bit, đều nằm trong phạm vi giới hạn mới. Các phép toán đường cong elliptic sử dụng đầu vào nhỏ hơn, thường dưới 384 bit, nên cũng không bị ảnh hưởng.

Các giới hạn mới này cũng giúp ích cho các nâng cấp trong tương lai. Nếu sau này MODEXP được viết lại thành mã EVM bằng EVMMAX, nhà phát triển có thể thêm đường dẫn tối ưu cho các kích thước đầu vào phổ biến (ví dụ: 256 bit, 381 bit hoặc 2048 bit) và dùng phương án dự phòng chậm hơn cho các trường hợp hiếm. Bằng cách cố định kích thước đầu vào tối đa, nhà phát triển thậm chí có thể xử lý đặc biệt cho modulus rất phổ biến. Trước đây, vì kích thước đầu vào không bị giới hạn, không gian thiết kế quá lớn và khó quản lý an toàn, nên các điều này không thể thực hiện được.

Để xác nhận thay đổi này không phá vỡ các giao dịch trước đây, tác giả đã phân tích tất cả các trường hợp sử dụng MODEXP từ block 5,472,266 (20 tháng 4 năm 2018) đến block 21,550,926 (4 tháng 1 năm 2025). Kết quả cho thấy, trong lịch sử, tất cả các lời gọi MODEXP thành công đều không sử dụng đầu vào vượt quá 513 byte, thấp hơn nhiều so với giới hạn mới 1024 byte. Hầu hết các lời gọi thực tế đều sử dụng độ dài nhỏ hơn, như 32 byte, 128 byte hoặc 256 byte.

Có một số lời gọi không hợp lệ hoặc bị hỏng, như đầu vào rỗng, đầu vào lặp lại byte, và một đầu vào rất lớn nhưng không hợp lệ. Các lời gọi này cũng sẽ không hợp lệ dưới giới hạn mới, vì bản thân chúng đã không hợp lệ. Do đó, dù EIP-7823 về mặt kỹ thuật là một thay đổi lớn, nhưng thực tế nó không làm thay đổi kết quả của bất kỳ giao dịch nào trước đây.

Xét về bảo mật, việc giảm kích thước đầu vào cho phép không tạo ra rủi ro mới. Ngược lại, nó loại bỏ các trường hợp cực đoan không cần thiết từng gây ra lỗi và không nhất quán giữa các client. Bằng cách giới hạn đầu vào MODEXP trong phạm vi hợp lý, EIP-7823 giúp hệ thống dễ dự đoán hơn, giảm các trường hợp cực đoan kỳ lạ và giảm xác suất lỗi giữa các implementation khác nhau. Các giới hạn này cũng giúp chuẩn bị tốt hơn nếu các nâng cấp trong tương lai (như EVMMAX) giới thiệu đường dẫn thực thi tối ưu, hệ thống có thể chuyển đổi mượt mà hơn.

EIP-7825: Giới hạn gas giao dịch ở mức 16.7 triệu

Ethereum thực sự cần đề xuất này vì hiện tại một giao dịch gần như có thể tiêu tốn toàn bộ giới hạn gas của block.

Điều này gây ra một số vấn đề: một giao dịch có thể tiêu tốn phần lớn tài nguyên của block, dẫn đến độ trễ chậm giống như tấn công DoS; các thao tác tiêu tốn nhiều gas sẽ làm tăng trạng thái Ethereum quá nhanh; tốc độ xác thực block chậm lại, node khó theo kịp.

Nếu một người dùng gửi một giao dịch tiêu tốn gần như toàn bộ gas của block (ví dụ, một giao dịch tiêu tốn 38 triệu gas trong block 40 triệu gas), các giao dịch thông thường khác sẽ không thể được đưa vào block đó, và mỗi node phải mất thêm thời gian xác thực block. Điều này đe dọa sự ổn định và phi tập trung của mạng, vì tốc độ xác thực chậm đồng nghĩa với việc các node yếu hơn sẽ bị tụt lại phía sau. Để giải quyết vấn đề này, Ethereum cần một giới hạn gas an toàn, giới hạn lượng gas mà mỗi giao dịch có thể sử dụng, giúp tải block dễ dự đoán hơn, giảm nguy cơ tấn công DoS và cân bằng tải cho node.

EIP-7825 đưa ra một quy tắc cứng: bất kỳ giao dịch nào cũng không được tiêu tốn quá 16,777,216 (2²⁴) gas. Đây là giới hạn ở cấp độ giao thức, nghĩa là áp dụng cho tất cả các khâu: người dùng gửi giao dịch, mempool kiểm tra giao dịch và validator đóng gói giao dịch vào block. Nếu ai đó gửi giao dịch có giới hạn gas vượt quá giá trị này, client phải từ chối ngay giao dịch đó và trả về lỗi như MAX_GAS_LIMIT_EXCEEDED.

Giới hạn này hoàn toàn độc lập với giới hạn gas của block. Ví dụ, ngay cả khi giới hạn gas của block là 40 triệu, bất kỳ giao dịch nào cũng không được tiêu tốn quá 16.7 triệu gas. Mục đích là đảm bảo mỗi block có thể chứa nhiều giao dịch, thay vì để một giao dịch chiếm trọn block.

Để hiểu rõ hơn, giả sử một block có thể chứa 40 triệu gas. Nếu không có giới hạn này, ai đó có thể gửi một giao dịch tiêu tốn 35-40 triệu gas. Giao dịch đó sẽ độc chiếm block, không còn chỗ cho giao dịch khác, giống như một người thuê trọn xe buýt, người khác không thể lên xe; giới hạn mới 16.7 triệu gas sẽ giúp block tự nhiên chứa nhiều giao dịch, tránh lạm dụng kiểu này.

Đề xuất này cũng đưa ra yêu cầu cụ thể về cách client xác thực giao dịch. Nếu gas của giao dịch vượt quá 16,777,216, mempool phải từ chối giao dịch đó, nghĩa là giao dịch này thậm chí không được vào hàng đợi. Trong quá trình xác thực block, nếu block chứa giao dịch vượt quá giới hạn, block đó cũng phải bị từ chối.

Lựa chọn con số 16,777,216 (2²⁴) vì nó là một mốc lũy thừa của 2 rõ ràng, dễ triển khai, đồng thời vẫn đủ lớn để xử lý hầu hết các giao dịch thực tế. Ví dụ như triển khai smart contract, các tương tác DeFi phức tạp hoặc gọi contract nhiều bước. Giá trị này khoảng một nửa kích thước block điển hình, nghĩa là ngay cả giao dịch phức tạp nhất cũng dễ dàng nằm trong giới hạn này.

EIP này cũng giữ nguyên tính tương thích với cơ chế gas hiện tại. Hầu hết người dùng sẽ không nhận thấy thay đổi này, vì gần như tất cả các giao dịch hiện tại đều tiêu tốn gas thấp hơn nhiều so với 16 triệu. Validator và block producer vẫn có thể tạo block tổng gas vượt quá 16.7 triệu, miễn là mỗi giao dịch đều tuân thủ giới hạn mới.

Giao dịch duy nhất bị ảnh hưởng là những giao dịch cực lớn trước đây từng cố gắng vượt quá giới hạn mới. Các giao dịch này giờ phải chia nhỏ thành nhiều thao tác nhỏ hơn, giống như chia một tệp rất lớn thành hai tệp nhỏ hơn để upload. Về mặt kỹ thuật, thay đổi này không tương thích ngược với các giao dịch cực đoan hiếm gặp này, nhưng số lượng người dùng bị ảnh hưởng dự kiến là rất ít.

Về bảo mật, giới hạn gas giúp Ethereum chống lại các cuộc tấn công DoS dựa trên gas tốt hơn, vì kẻ tấn công không còn có thể buộc validator xử lý giao dịch cực lớn. Nó cũng giúp giữ cho thời gian xác thực block có thể dự đoán được, giúp node dễ dàng đồng bộ hơn. Trường hợp cực đoan duy nhất là một số contract triển khai quy mô rất lớn có thể không đáp ứng được giới hạn, cần thiết kế lại hoặc chia thành nhiều bước triển khai.

Tổng thể, EIP-7825 nhằm tăng cường phòng chống lạm dụng mạng, giữ yêu cầu đối với node hợp lý, tăng công bằng trong sử dụng không gian block và đảm bảo blockchain vẫn chạy nhanh và ổn định khi giới hạn gas tăng lên.

EIP-7883: Tăng phí gas cho ModExp

Ethereum cần đề xuất này vì precompile ModExp (dùng cho phép toán lũy thừa mô-đun) có giá quá thấp so với tài nguyên thực tế tiêu tốn.

Trong một số trường hợp, lượng tính toán cần thiết cho ModExp vượt xa chi phí mà người dùng hiện trả. Sự không tương xứng này gây rủi ro: nếu các lời gọi ModExp phức tạp có giá quá thấp, chúng có thể trở thành nút thắt, khiến mạng khó tăng giới hạn gas một cách an toàn. Vì block producer có thể bị buộc xử lý các thao tác cực nặng với chi phí cực thấp.

Để giải quyết vấn đề này, Ethereum cần điều chỉnh công thức định giá ModExp để lượng gas tiêu tốn phản ánh chính xác khối lượng công việc thực tế mà client thực hiện. Do đó, EIP-7883 đưa ra các quy tắc mới, tăng chi phí gas tối thiểu, tăng tổng chi phí gas và làm cho các thao tác với đầu vào lớn (đặc biệt là số mũ, cơ số hoặc modulus vượt quá 32 byte) đắt hơn, giúp giá gas phù hợp với lượng tính toán thực tế.

Đề xuất này tăng chi phí thông qua một số điểm quan trọng, sửa đổi thuật toán định giá ModExp ban đầu trong EIP-2565.

Đầu tiên, gas tiêu tốn tối thiểu tăng từ 200 lên 500, và tổng gas tiêu tốn không còn chia cho 3, nghĩa là tổng gas thực tế tăng gấp ba lần. Ví dụ, nếu trước đây một lời gọi ModExp tiêu tốn 1200 gas, theo công thức mới, nó sẽ tiêu tốn khoảng 3600 gas.

Thứ hai, chi phí cho số mũ lớn hơn 32 byte tăng gấp đôi, vì hệ số nhân tăng từ 8 lên 16. Ví dụ, nếu số mũ dài 40 byte, EIP-2565 sẽ tăng số vòng lặp thêm 8 × (40 − 32) = 64 lần, còn EIP-7883 dùng 16 × (40 − 32) = 128 lần, chi phí tăng gấp đôi.

Thứ ba, định giá giờ giả định kích thước cơ số/modulus tối thiểu là 32 byte, và khi các giá trị này vượt quá 32 byte, chi phí tính toán tăng mạnh. Ví dụ, nếu modulus là 64 byte, quy tắc mới áp dụng độ phức tạp gấp đôi (2 × words²), thay vì công thức đơn giản trước đây, phản ánh đúng chi phí thực tế của phép toán số lớn. Các thay đổi này đảm bảo các phép ModExp nhỏ trả phí tối thiểu hợp lý, còn các phép lớn, phức tạp sẽ có chi phí phù hợp với kích thước.

Đề xuất này định nghĩa một hàm tính gas mới, cập nhật quy tắc độ phức tạp và số vòng lặp. Độ phức tạp nhân giờ dùng giá trị mặc định 16 cho cơ số/modulus không vượt quá 32 byte, còn với đầu vào lớn hơn thì chuyển sang công thức phức tạp hơn 2 × words², trong đó "words" là số khối 8 byte. Số vòng lặp cũng được cập nhật, với số mũ 32 byte hoặc nhỏ hơn dùng độ dài bit để xác định độ phức tạp, còn số mũ lớn hơn 32 byte sẽ bị phạt gas lớn hơn.

Điều này đảm bảo các phép toán với số mũ cực lớn có chi phí gas cao hơn. Quan trọng là, chi phí gas tối thiểu trả về được ép buộc là 500, thay vì 200 như trước, giúp ngay cả lời gọi ModExp đơn giản nhất cũng hợp lý hơn.

Động lực tăng giá này đến từ các benchmark cho thấy trong nhiều trường hợp, định giá precompile ModExp thấp hơn thực tế. Công thức sửa đổi tăng phí gas cho thao tác nhỏ lên 150%, thao tác điển hình tăng khoảng 200%, còn thao tác lớn hoặc không cân đối tăng nhiều lần, đôi khi hơn 80 lần, tùy vào kích thước số mũ, cơ số hoặc modulus.

Mục đích của thay đổi này không phải là thay đổi cách ModExp hoạt động, mà là đảm bảo ngay cả trong các trường hợp tiêu tốn tài nguyên nhất, nó cũng không còn đe dọa sự ổn định mạng hoặc cản trở việc tăng giới hạn gas block trong tương lai. Vì EIP-7883 thay đổi lượng gas cần thiết cho ModExp, nó không tương thích ngược, nhưng việc định giá lại gas đã nhiều lần xảy ra trên Ethereum và đã được hiểu rõ.

Kết quả kiểm thử cho thấy mức tăng phí gas lần này rất đáng kể. Khoảng 99.69% các lời gọi ModExp trong lịch sử giờ sẽ cần 500 gas (trước là 200 gas) hoặc gấp ba lần giá trước đây. Nhưng một số trường hợp kiểm thử tải nặng có mức tăng phí gas lớn hơn nhiều. Ví dụ, trong một kiểm thử "tập trung vào số mũ", gas tiêu tốn tăng từ 215 lên 16,624, tăng khoảng 76 lần, vì giờ định giá cho số mũ cực lớn hợp lý hơn.

Về bảo mật, đề xuất này không tạo ra lỗ hổng mới, cũng không giảm chi phí cho bất kỳ phép toán nào. Ngược lại, nó tập trung vào việc phòng ngừa rủi ro quan trọng: định giá quá thấp cho ModExp có thể cho phép kẻ tấn công lấp đầy block bằng các phép toán cực nặng với chi phí cực thấp. Nhược điểm duy nhất có thể là một số phép toán ModExp sẽ có giá quá cao, nhưng điều này tốt hơn nhiều so với vấn đề định giá quá thấp hiện tại. Đề xuất này không thay đổi bất kỳ giao diện hoặc tính năng mới nào, nên hành vi số học và test vector hiện tại vẫn hợp lệ.

EIP-7917: Dự đoán chính xác người đề xuất tiếp theo

Ethereum cần đề xuất này vì lịch trình người đề xuất cho epoch tiếp theo của mạng không thể dự đoán hoàn toàn. Ngay cả khi đã biết seed RANDAO của epoch N+1 tại epoch N, danh sách người đề xuất thực tế vẫn có thể thay đổi do cập nhật số dư hiệu lực (EB) trong epoch N.

Các thay đổi EB này có thể đến từ slashing, phạt, thưởng vượt quá 1 ETH, hợp nhất validator hoặc nạp tiền mới, đặc biệt sau khi EIP-7251 tăng số dư hiệu lực tối đa lên trên 32 ETH. Sự không chắc chắn này gây khó khăn cho các hệ thống phụ thuộc vào việc biết trước người đề xuất tiếp theo (ví dụ: các giao thức dựa trên pre-confirmation), vốn cần lịch trình ổn định và có thể dự đoán để hoạt động trơn tru. Validator thậm chí có thể cố "quét" hoặc thao túng số dư hiệu lực để ảnh hưởng đến người đề xuất epoch tiếp theo.

Vì các vấn đề này, Ethereum cần một phương pháp để lịch trình người đề xuất trong vài epoch tới hoàn toàn xác định, không bị thay đổi bởi cập nhật EB vào phút chót, và dễ dàng truy cập từ tầng ứng dụng.

Để đạt được điều này, EIP-7917 giới thiệu một cơ chế dự đoán người đề xuất xác định, tức là tại đầu mỗi epoch sẽ tính trước và lưu trữ lịch trình người đề xuất cho MIN_SEED_LOOKAHEAD + 1 epoch tiếp theo. Nói đơn giản, trạng thái beacon giờ chứa một danh sách tên là `prosoperer_lookahead`, luôn bao phủ hai chu kỳ đầy đủ của người đề xuất (tổng cộng 64 slot).

Ví dụ, khi epoch N bắt đầu, danh sách này đã chứa người đề xuất cho từng slot của epoch N và N+1. Sau đó, khi mạng chuyển sang epoch N+1, danh sách này di chuyển về phía trước: loại bỏ mục của epoch N, chuyển mục của epoch N+1 lên đầu danh sách và thêm mục mới cho epoch N+2 vào cuối danh sách. Điều này giúp lịch trình cố định, có thể dự đoán và client có thể đọc trực tiếp mà không cần tính lại người đề xuất ở mỗi slot.

Để duy trì cập nhật, danh sách sẽ di chuyển về phía trước ở mỗi ranh giới epoch: loại bỏ dữ liệu của epoch trước và tính toán một nhóm chỉ số người đề xuất mới cho epoch tương lai tiếp theo rồi thêm vào danh sách. Quá trình này sử dụng cùng seed và quy tắc số dư hiệu lực như trước, nhưng giờ lịch trình được tính sớm hơn, tránh việc thay đổi số dư hiệu lực sau khi seed xác định ảnh hưởng đến nó. Block đầu tiên sau fork cũng sẽ điền đầy toàn bộ phạm vi dự đoán để đảm bảo mọi epoch tương lai đều có lịch trình được khởi tạo đúng.

Giả sử mỗi epoch có 8 slot thay vì 32 (để đơn giản). Nếu không có EIP này, trong epoch 5, dù bạn biết seed của epoch 6, nếu validator bị phạt hoặc nhận thưởng đủ để thay đổi số dư hiệu lực trong epoch 5, người đề xuất thực tế cho slot 2 của epoch 6 vẫn có thể thay đổi. Với EIP-7917, Ethereum sẽ tính trước người đề xuất cho toàn bộ epoch 5, 6 và 7 khi epoch 5 bắt đầu và lưu trữ theo thứ tự trong `prosopers_lookahead`. Như vậy, dù số dư thay đổi vào cuối epoch 5, danh sách người đề xuất cho epoch 6 vẫn cố định và có thể dự đoán.

EIP-7917 khắc phục một thiếu sót lâu dài trong thiết kế beacon chain. Nó đảm bảo rằng một khi seed RANDAO của epoch trước đã có, việc chọn validator cho epoch tương lai không thể thay đổi. Điều này cũng ngăn chặn "quét số dư hiệu lực", tức là validator cố điều chỉnh số dư sau khi thấy RANDAO để ảnh hưởng đến danh sách người đề xuất epoch tiếp theo. Cơ chế dự đoán xác định loại bỏ hoàn toàn kiểu tấn công này, đơn giản hóa đáng kể phân tích bảo mật. Nó cũng giúp client đồng thuận biết trước ai sẽ đề xuất block sắp tới, hỗ trợ triển khai và cho phép tầng ứng dụng xác minh lịch trình người đề xuất dễ dàng qua bằng chứng Merkle của beacon root.

Trước đề xuất này, client chỉ tính người đề xuất cho slot hiện tại. Với EIP-7917, chúng sẽ tính toàn bộ danh sách người đề xuất cho epoch tiếp theo trong mỗi lần chuyển epoch. Điều này tăng thêm một chút công việc, nhưng việc tính chỉ số người đề xuất rất nhẹ, chủ yếu là lấy mẫu danh sách validator bằng seed. Tuy nhiên, client cần benchmark để đảm bảo tính toán bổ sung này không gây vấn đề hiệu suất.

EIP-7918: Phí cơ bản Blob bị giới hạn bởi chi phí thực thi

Ethereum cần đề xuất này vì hệ thống phí Blob hiện tại (nguồn gốc từ EIP-4844) sẽ thất bại khi gas thực thi trở thành chi phí chính của Rollup.

Hiện tại, phần lớn Rollup phải trả phí gas thực thi (chi phí đưa giao dịch Blob vào block) cao hơn nhiều so với phí Blob thực tế. Điều này gây ra một vấn đề: ngay cả khi Ethereum liên tục giảm phí cơ bản Blob, tổng chi phí của Rollup thực tế không thay đổi, vì phần đắt nhất vẫn là gas thực thi. Do đó, phí cơ bản Blob sẽ tiếp tục giảm cho đến khi chạm mức tối thiểu tuyệt đối (1 wei), lúc này giao thức không còn kiểm soát được nhu cầu qua phí Blob. Sau đó, khi sử dụng Blob tăng đột ngột, phí Blob cần rất nhiều block mới phục hồi về mức bình thường. Điều này khiến giá cả không ổn định và khó dự đoán cho người dùng.

Ví dụ, giả sử một Rollup muốn xuất bản dữ liệu: nó cần trả khoảng 25,000,000 gwei gas thực thi (khoảng 1,000,000 gas với 25 gwei), còn phí Blob chỉ khoảng 200 gwei. Tổng chi phí là khoảng 25,000,200 gwei, trong đó gần như toàn bộ là gas thực thi chứ không phải phí Blob. Nếu Ethereum tiếp tục giảm phí Blob, ví dụ từ 200 gwei xuống 50 gwei, rồi 10 gwei, cuối cùng là 1 gwei, tổng chi phí gần như không đổi, vẫn là 25,000,000 gwei.

EIP-7918 giải quyết vấn đề này bằng cách đưa ra một "giá dự trữ" tối thiểu dựa trên phí cơ bản thực thi, ngăn không cho giá Blob xuống quá thấp và giúp định giá Blob của Rollup ổn định, dễ dự đoán hơn.

Ý tưởng cốt lõi của EIP-7918 rất đơn giản: giá Blob không bao giờ được thấp hơn một lượng chi phí gas thực thi nhất định (gọi là BLOB_BASE_COST). Giá trị calc_excess_blob_gas() được đặt là 2¹³, cơ chế này được thực hiện bằng cách sửa đổi nhỏ hàm calc_excess_blob_gas().

Thông thường, hàm này sẽ tăng hoặc giảm phí cơ bản Blob dựa trên việc blob gas sử dụng trong block cao hơn hay thấp hơn giá trị mục tiêu. Theo đề xuất này, nếu Blob trở nên "quá rẻ" so với gas thực thi, hàm này sẽ ngừng trừ blob gas mục tiêu. Điều này làm cho blob gas dư thừa tăng nhanh hơn, ngăn phí cơ bản Blob giảm thêm. Do đó, phí cơ bản Blob giờ có một giá trị tối thiểu, bằng BLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_BLOB.

Để hiểu tại sao cần làm vậy, hãy xem xét nhu cầu Blob. Rollup quan tâm đến tổng chi phí phải trả: chi phí thực thi cộng chi phí blob. Nếu phí gas thực thi rất cao, ví dụ 20 gwei, thì ngay cả khi phí Blob giảm từ 2 gwei xuống 0.2 gwei, tổng chi phí gần như không đổi. Điều này nghĩa là giảm phí cơ bản Blob gần như không ảnh hưởng đến nhu cầu. Trong kinh tế học, đây gọi là "thiếu tính co giãn của phí". Nó tạo ra một đường cầu gần như thẳng đứng: giảm giá không làm tăng nhu cầu.

Trong trường hợp này, cơ chế phí cơ bản Blob trở nên mù quáng — dù nhu cầu không phản ứng, nó vẫn tiếp tục giảm giá. Đó là lý do tại sao phí cơ bản Blob thường giảm xuống 1 gwei. Sau đó, khi nhu cầu thực tế tăng lên, giao thức cần hàng giờ hoặc lâu hơn với block gần đầy mới nâng được phí lên mức hợp lý. EIP-7918 giải quyết vấn đề này bằng cách đặt giá dự trữ liên kết với gas thực thi, đảm bảo ngay cả khi chi phí thực thi chiếm ưu thế, phí Blob vẫn có ý nghĩa.

Một lý do khác để thêm giá dự trữ là node cần làm nhiều việc bổ sung để xác thực proof KZG của dữ liệu Blob. Các proof này đảm bảo dữ liệu trong Blob khớp với cam kết của nó. Dưới EIP-4844, node chỉ cần xác thực một proof cho mỗi Blob, chi phí thấp. Nhưng trong EIP-7918, số lượng proof node cần xác thực nhiều hơn. Tất cả là vì trong EIP-7594 (PeerDAS), blob được chia thành nhiều cell nhỏ, mỗi cell có proof riêng, làm tăng đáng kể khối lượng xác thực.

Về lâu dài, EIP-7918 cũng giúp Ethereum sẵn sàng cho tương lai. Khi công nghệ tiến bộ, chi phí lưu trữ và chia sẻ dữ liệu sẽ giảm tự nhiên, Ethereum dự kiến sẽ cho phép lưu trữ nhiều dữ liệu Blob hơn theo thời gian. Khi dung lượng Blob tăng, phí Blob (tính bằng ETH) sẽ giảm tự nhiên. Đề xuất này hỗ trợ điều đó, vì giá dự trữ liên kết với giá gas thực thi thay vì giá trị cố định, nên nó có thể điều chỉnh theo sự phát triển của mạng.

Khi không gian Blob và không gian block thực thi mở rộng, mối quan hệ giá của chúng sẽ giữ cân bằng. Chỉ trong trường hợp hiếm hoi Ethereum tăng mạnh dung lượng Blob mà không tăng dung lượng gas thực thi, giá dự trữ mới có thể quá cao. Khi đó, phí Blob cuối cùng có thể cao hơn mức cần thiết. Nhưng Ethereum không có kế hoạch mở rộng theo cách này — không gian Blob và không gian block thực thi dự kiến sẽ tăng đồng bộ. Do đó, giá trị được chọn (BLOB_BASE_COST = 2¹³) được coi là an toàn và cân bằng.

Khi phí gas thực thi tăng đột biến, cần chú ý một chi tiết nhỏ. Vì giá Blob phụ thuộc vào phí cơ bản thực thi, việc tăng phí thực thi đột ngột có thể tạm thời đưa phí Blob vào trạng thái bị chi phối bởi chi phí thực thi. Ví dụ, giả sử phí gas thực thi tăng từ 20 gwei lên 60 gwei chỉ trong một block. Vì giá Blob liên kết với giá trị này, phí Blob không thể thấp hơn mức mới cao hơn. Nếu Blob vẫn được sử dụng, phí của nó vẫn tăng bình thường, nhưng giao thức sẽ không cho phép nó giảm cho đến khi tăng đủ để khớp với chi phí thực thi cao hơn. Điều này nghĩa là trong vài block, tốc độ tăng phí Blob có thể chậm hơn phí thực thi. Sự chậm trễ ngắn này không gây hại — thực tế nó giúp ngăn giá Blob biến động mạnh và làm hệ thống mượt mà hơn.

Tác giả cũng đã phân tích thực nghiệm hoạt động giao dịch block từ tháng 11 năm 2024 đến tháng 3 năm 2025, áp dụng quy tắc giá dự trữ. Trong thời kỳ phí thực thi cao (trung bình khoảng 16 gwei), ngưỡng dự trữ tăng đáng kể phí cơ bản block so với cơ chế cũ. Trong thời kỳ phí thực thi thấp (trung bình khoảng 1.3 gwei), phí block gần như không đổi, trừ khi phí cơ bản tính toán thấp hơn giá dự trữ. So sánh hàng nghìn block, tác giả cho thấy cơ chế mới vừa giữ phản ứng tự nhiên với nhu cầu, vừa tạo ra định giá ổn định hơn. Biểu đồ histogram phí block trong bốn tháng cho thấy giá dự trữ ngăn phí block giảm xuống 1 gwei, giảm biến động cực đoan.

Về bảo mật, thay đổi này cũng không tạo ra rủi ro nào. Phí cơ bản block luôn bằng hoặc cao hơn chi phí đơn vị BLOB_BASE_COST của gas thực thi. Điều này an toàn vì cơ chế chỉ tăng phí tối thiểu, đặt giới hạn dưới không ảnh hưởng đến tính đúng đắn của giao thức. Nó chỉ đảm bảo vận hành kinh tế lành mạnh.

EIP-7934: Giới hạn kích thước block thực thi RLP

Trước EIP-7934, Ethereum không có giới hạn nghiêm ngặt về kích thước block thực thi mã hóa RLP. Về lý thuyết, nếu block chứa nhiều giao dịch hoặc dữ liệu rất phức tạp, kích thước của nó có thể rất lớn. Điều này gây ra hai vấn đề chính: mạng không ổn định và nguy cơ tấn công từ chối dịch vụ (DoS).

Nếu block quá lớn, node sẽ mất nhiều thời gian hơn để tải xuống và xác thực, làm chậm tốc độ truyền block và tăng khả năng blockchain bị phân nhánh tạm thời. Tệ hơn, kẻ tấn công có thể cố tình tạo block cực lớn để làm quá tải node, gây trễ hoặc thậm chí làm node offline — đây là kiểu tấn công DoS điển hình. Đồng thời, giao thức Gossip của lớp đồng thuận (CL) của Ethereum đã từ chối truyền bất kỳ block nào vượt quá 10MB, nghĩa là block thực thi quá lớn có thể không được truyền trong mạng, gây phân mảnh chuỗi hoặc bất đồng giữa các node. Trước các rủi ro này, Ethereum cần một quy tắc rõ ràng ở cấp giao thức để ngăn block quá lớn và giữ mạng ổn định, an toàn.

EIP-7934 giải quyết vấn đề này bằng cách đưa ra giới hạn kích thước block thực thi mã hóa RLP ở cấp giao thức. Kích thước block tối đa cho phép (MAX_BLOCK_SIZE) được đặt là 10 MiB (10,485,760 byte), nhưng vì block beacon cũng chiếm một phần không gian (SAFETY_MARGIN), Ethereum cộng thêm 2 MiB (2,097,152 byte).

Điều này nghĩa là kích thước block thực thi mã hóa RLP tối đa thực tế là MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE - SAFETY_MARGIN. Nếu block mã hóa vượt quá giới hạn này, block đó sẽ bị coi là không hợp lệ, node phải từ chối. Với quy tắc này, block producer phải kiểm tra kích thước mã hóa của từng block họ xây dựng, validator phải xác thực giới hạn này trong quá trình xác thực block. Giới hạn kích thước này độc lập với giới hạn gas, nghĩa là ngay cả khi block "dưới giới hạn gas", nếu kích thước mã hóa quá lớn, vẫn bị từ chối. Điều này đảm bảo cả lượng gas sử dụng và giới hạn byte thực tế đều được tuân thủ.

Lựa chọn giới hạn 10 MiB là có chủ ý vì nó trùng với giới hạn hiện tại trong giao thức gossip của lớp đồng thuận. Bất kỳ dữ liệu nào lớn hơn 10 MiB sẽ không được truyền trong mạng, nên EIP này giúp lớp thực thi đồng bộ với giới hạn của lớp đồng thuận. Điều này đảm bảo tính nhất quán giữa các thành phần và ngăn tình trạng block thực thi hợp lệ nhưng "vô hình" vì CL từ chối truyền.

Thay đổi này không tương thích ngược với các block lớn hơn giới hạn mới, nghĩa là miner và validator phải cập nhật client để tuân thủ quy tắc này. Tuy nhiên, vì block quá lớn vốn đã có vấn đề và hiếm gặp trong thực tế, nên ảnh hưởng là rất nhỏ.

Về bảo mật, EIP-7934 tăng cường đáng kể khả năng chống lại tấn công DoS nhắm vào kích thước block cụ thể bằng cách đảm bảo không ai có thể tạo block làm tê liệt mạng. Tổng thể, EIP-7934 bổ sung một ranh giới bảo mật quan trọng, tăng tính ổn định, đồng bộ hóa hành vi của lớp thực thi (EL) và CL, và ngăn chặn nhiều kiểu tấn công liên quan đến việc tạo và truyền block quá lớn.

EIP-7939: Opcode tính số bit 0 đầu (CLZ)

Trước EIP này, Ethereum không có opcode tích hợp để tính số bit 0 đầu trong số 256 bit. Nhà phát triển phải tự triển khai hàm CLZ trong Solidity, cần nhiều thao tác dịch bit và so sánh.

Đây là vấn đề lớn vì triển khai thủ công chậm, tốn phí gas và chiếm nhiều bytecode, làm tăng gas tiêu tốn. Đối với hệ thống bằng chứng không kiến thức, chi phí càng cao, vì thao tác dịch phải chứng minh rất tốn kém, nên các thao tác như CLZ sẽ làm chậm đáng kể mạch bằng chứng. Vì CLZ là hàm nền tảng rất phổ biến, được dùng rộng rãi trong thư viện toán học, thuật toán nén, bitmap, lược đồ chữ ký và nhiều tác vụ mã hóa hoặc xử lý dữ liệu, Ethereum cần một phương pháp tính nhanh và tiết kiệm hơn.

EIP-7939 giải quyết vấn đề này bằng cách thêm một opcode mới tên là CLZ (0x1e). Opcode này đọc một giá trị 256 bit từ stack và trả về số bit 0 đầu. Nếu số đầu vào là 0, opcode trả về 256 vì một số 256 bit toàn 0 có 256 bit 0 đầu.

Điều này giống với cách CLZ hoạt động trên nhiều kiến trúc CPU như ARM và x86, nơi CLZ là thao tác gốc. Thêm CLZ giúp giảm đáng kể chi phí cho nhiều thuật toán: lnWad, powWad, LambertW, các hàm toán học, so sánh chuỗi byte, quét bitmap, nén/giải nén calldata và các lược đồ chữ ký hậu lượng tử đều hưởng lợi từ phát hiện bit 0 đầu nhanh hơn.

Chi phí gas của CLZ được đặt là 5, giống như ADD và cao hơn một chút so với giá MUL trước đây, để tránh định giá quá thấp gây nguy cơ tấn công DoS. Benchmark cho thấy tính toán CLZ tương đương với ADD, và trong môi trường chứng minh SP1 rv32im, chi phí chứng minh CLZ thực tế còn thấp hơn ADD, giúp giảm chi phí bằng chứng không kiến thức.

EIP-7939 hoàn toàn tương thích ngược vì nó chỉ thêm một opcode mới mà không sửa đổi bất kỳ hành vi nào hiện tại.

Tổng thể, EIP-7939 giúp Ethereum chạy nhanh hơn, rẻ hơn và thân thiện hơn với nhà phát triển — giảm phí gas, giảm kích thước bytecode và giảm chi phí bằng chứng không kiến thức cho nhiều thao tác phổ biến — bằng cách bổ sung một primitive đơn giản, hiệu quả mà CPU hiện đại đã hỗ trợ.

EIP-7951: Hỗ trợ chữ ký phần cứng hiện đại

Trước EIP này, Ethereum không có cách an toàn, gốc để xác thực chữ ký số tạo bởi đường cong secp256r1 (P-256).

Đường cong này là tiêu chuẩn cho các thiết bị hiện đại như Apple Secure Enclave, Android Keystore, HSM, TEE và khóa bảo mật FIDO2/WebAuthn. Vì thiếu hỗ trợ này, ứng dụng và ví không thể dễ dàng sử dụng chữ ký bảo mật phần cứng ở cấp thiết bị. Trước đây từng có một nỗ lực (RIP-7212), nhưng nó có hai lỗ hổng bảo mật nghiêm trọng liên quan đến xử lý điểm vô cực và so sánh chữ ký sai. Các vấn đề này có thể dẫn đến xác thực sai, thậm chí gây lỗi đồng thuận. EIP-7951 khắc phục các vấn đề bảo mật này và bổ sung một precompile gốc, an toàn, giúp Ethereum cuối cùng có thể hỗ trợ chữ ký từ phần cứng hiện đại một cách an toàn, hiệu quả.

EIP-7951 thêm một precompile mới tên là P256VERIFY tại địa chỉ 0x100, sử dụng đường cong secp256r1 để xác thực chữ ký ECDSA. So với việc triển khai thuật toán này trực tiếp trong Solidity, cách này nhanh hơn và rẻ hơn nhiều.

EIP-7951 cũng định nghĩa quy tắc xác thực đầu vào nghiêm ngặt. Nếu có bất kỳ trường hợp không hợp lệ nào, precompile sẽ trả về thất bại mà không rollback, tiêu tốn gas như gọi thành công. Thuật toán xác thực tuân thủ chuẩn ECDSA: tính s⁻¹ mod n, dựng lại điểm chữ ký R', nếu R' là điểm vô cực thì từ chối, cuối cùng kiểm tra tọa độ x của R' có khớp với r (mod n) không. Điều này sửa lỗi trong RIP-7212, vốn so sánh trực tiếp r' thay vì rút gọn mod n trước.

Chi phí gas cho thao tác này được đặt là 6900 gas, cao hơn phiên bản RIP-7212, nhưng phù hợp với benchmark hiệu suất xác thực secp256r1 thực tế. Quan trọng là, giao diện này hoàn toàn tương thích với các mạng Layer 2 đã triển khai RIP-7212 (địa chỉ giống nhau, định dạng đầu vào/đầu ra giống nhau), nên smart contract hiện tại vẫn hoạt động bình thường, không cần thay đổi gì. Khác biệt duy nhất là hành vi đã được sửa và phí gas cao hơn.

Về bảo mật, EIP-7951 khôi phục hành vi đúng của ECDSA, loại bỏ vấn đề biến dạng ở cấp precompile (kiểm tra tùy chọn để ứng dụng xử lý), và nêu rõ precompile không cần thực thi thời gian hằng số. Đường cong secp256r1 cung cấp bảo mật 128 bit và đã được kiểm tra, tin cậy rộng rãi, nên có thể áp dụng an toàn cho Ethereum.

Nói ngắn gọn, EIP-7951 nhằm mục đích đưa xác thực phần cứng hiện đại vào Ethereum một cách an toàn, sửa các vấn đề bảo mật của đề xuất trước, và cung cấp phương pháp chuẩn hóa, đáng tin cậy để xác thực chữ ký P-256 trên toàn hệ sinh thái.

Tổng kết

Bảng dưới đây tóm tắt các client Ethereum cần thay đổi gì cho từng EIP của Fusaka. Dấu tick dưới consensus client nghĩa là EIP đó cần cập nhật client lớp đồng thuận, còn tick dưới execution client nghĩa là nâng cấp ảnh hưởng đến client lớp thực thi. Một số EIP cần cập nhật cả hai lớp, số khác chỉ cần cập nhật một lớp.

Tổng thể, trên đây là các EIP then chốt trong Fusaka hard fork. Dù nâng cấp này liên quan đến nhiều cải tiến cho cả client đồng thuận và thực thi — từ điều chỉnh gas, cập nhật opcode đến precompile mới — cốt lõi của nâng cấp vẫn là PeerDAS, hệ thống sampling tính khả dụng dữ liệu ngang hàng, cho phép xử lý dữ liệu Blob trên toàn mạng hiệu quả và phi tập trung hơn.