Ethereum sẽ trải qua những thay đổi lớn này trong 3 ngày nữa.

Bản gốc của Sahil Sojitra

Biên soạn bởi Odaily Planet Daily Golem ( @web3_golem )

Hard fork Fusaka, dự kiến ​​kích hoạt vào ngày 3 tháng 12 năm 2025, là một bản nâng cấp mạng lưới lớn khác cho Ethereum sau Pectra, đánh dấu một bước tiến quan trọng khác của gã khổng lồ tiền điện tử này hướng tới việc mở rộng quy mô.

EIP nâng cấp của Pectra tập trung vào việc cải thiện hiệu suất, bảo mật và các công cụ dành cho nhà phát triển. Mặt khác, EIP nâng cấp của Fusaka nhấn mạnh vào khả năng mở rộng, cập nhật mã lệnh và bảo mật thực thi.

PeerDAS (EIP-7594) cải thiện tính khả dụng của dữ liệu bằng cách cho phép các nút xác minh blob mà không cần tải xuống toàn bộ dữ liệu. Một số 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 giới hạn gas giao dịch (EIP-7825) và cập nhật chi phí gas ModExp (EIP-7883). Bản nâng cấp Fusaka này cũng cải thiện việc tạo khối thông qua cơ chế xem trước người đề xuất xác định (EIP-7917) và duy trì phí blob ổn định bằng cách đặt "giá đặt chỗ" liên kết với chi phí thực thi (EIP-7918).

Những cải tiến khác bao gồm giới hạn kích thước khối của định dạng RLP (EIP-7934), thêm mã lệnh CLZ mới để tăng tốc hoạt động bit (EIP-7939) và giới thiệu biên dịch trước secp256r1 (EIP-7951) để tương thích tốt hơn với mật mã hiện đại và khóa bảo mật phần cứng.

Fusaka là tên gọi kết hợ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 một tương lai giàu dữ liệu và có khả năng mở rộng cao, nơi các 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ẽ cung cấp phân tích chuyên sâu về chín đề xuất EIP cốt lõi của hard fork Fusaka.

EIP-7594: PeerDAS — Lấy mẫu tính khả dụng của dữ liệu nút

Ethereum cần đề xuất này vì mạng lưới muốn cung cấp khả năng truy cập dữ liệu tốt hơn cho người dùng, đặc biệt là người dùng Rollup.

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

Lấy mẫu tính khả dụng của dữ liệu (DAS) giải quyết vấn đề này bằng cách cho phép các nút 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 có và không gây áp lực tính toán lớn lên các nhà sản xuất khối. PeerDAS được tạo ra để đáp ứng những nhu cầu này và tăng thông lượng blob một cách an toàn trong khi vẫn giữ yêu cầu về node ở mức thấp.

PeerDAS là một hệ thống mạng cho phép các nút chỉ tải xuống các đoạn dữ liệu nhỏ để xác minh xem toàn bộ dữ liệu đã được công bố hay chưa. Thay vì tải xuống toàn bộ dữ liệu, các nút sử dụng phương thức chia sẻ mạng tin đồn thông thường để tìm ra nút nào nắm giữ một 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 một đoạn dữ liệu, một nút 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ụ: một nút 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 nút sẽ lấy mẫu các phần khác nhau, bất kỳ dữ liệu nào bị thiếu sẽ được phát hiện nhanh chóng.

Để đạt được hiệu quả lấy mẫu, PeerDAS sử dụng phương pháp mã hóa xóa cơ bản để mở rộng từng phân đoạn dữ liệu trong EIP-4844. Mã hóa xóa là một kỹ thuật bổ sung dữ liệu dư thừa để có thể khôi phục dữ liệu gốc ngay cả khi một số phân đoạn dữ liệu bị thiếu—tương tự như trò chơi xếp hình, có thể ghép lại ngay cả khi thiếu một số mảnh.

Blob được chuyển đổi thành một "hàng" chứa dữ liệu gốc cùng với một số dữ liệu được mã hóa bổ sung để cho phép tái tạo dữ liệu sau này. Hàng này sau đó được chia thành các phần nhỏ hơn gọi là "ô", là các đơn vị xác minh nhỏ nhất liên quan đến cam kết KZG. Tất cả các "hàng" sau đó được sắp xếp lại thành các "cột", mỗi cột chứa các ô từ cùng vị trí trên tất cả các hàng. Mỗi cột được gán cho một mạng con tin đồn cụ thể.

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

Hơn nữa, EIP-7594 đưa ra một quy tắc quan trọng: không giao dịch nào có thể chứa quá 6 blob. Hạn chế này phải được thực thi trong quá trình xác minh giao dịch, lan truyền tin đồn, tạo khối và xử lý khối. Điều này giúp giảm thiểu trường hợp cực đoan khi một giao dịch duy nhất có thể làm quá tải hệ thống blob.

PeerDAS đã bổ sung một tính năng gọi là "bằng chứng KZG cell". Bằng chứng KZG cell chứng minh rằng một 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 các nút chỉ tải xuống các cell mà chúng muốn lấy mẫu. Việc lấy được toàn bộ blob đồng thời đảm bảo tính toàn vẹn của dữ liệu là rất quan trọng đối với việc lấy mẫu tính khả dụng của dữ liệu.

Tuy nhiên, việc tạo ra tất cả các bằng chứng đơn vị này rất tốn kém. Người tạo khối cần phải tính toán lại các bằng chứng này trên nhiều blob, một việc quá chậm. Tuy nhiên, chi phí xác minh bằng chứng rất thấp; do đó, EIP-7594 yêu cầu người gửi giao dịch blob phải tạo trước tất cả các bằng chứng đơn vị và đưa chúng vào trình bao bọc giao dịch.

Vì lý do này, giao dịch gossip (PooledTransactions) hiện sử dụng trình bao bọc đã sửa đổi:

rlp([tx_payload_body, wrapper_version, blobs, cam kết, cell_proofs])

Trong wrapper mới, `cell_proofs` chỉ đơn giản là một danh sách chứa tất cả các proof cho mỗi cell của mỗi blob (ví dụ: `[cell_proof_0, cell_proof_1, ...]`). Các trường khác `tx_payload_body`, `blobs` và `commitments` giống hệt với các trường trong EIP-4844. Điểm khác biệt là trường "proofs" ban đầu đã bị xóa và thay thế bằng một danh sách `cell_proofs` mới, và một trường mới gọi là `wrapper_version` đã được thêm vào để biểu thị định dạng wrapper hiện đang được sử dụng.

PeerDAS cho phép Ethereum cải thiện tính khả dụng của dữ liệu mà không làm 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 còn 1/16 hoặc 1/32, do đó cải thiện khả năng mở rộng của Ethereum. Hệ thống hoạt động tốt vì mỗi node có nhiều node ngang hàng, vì vậy nếu một node không thể cung cấp dữ liệu cần thiết, node đó có thể yêu cầu dữ liệu từ các node khác. Điều này tự nhiên tạo ra sự dự phòng và cải thiện bảo mật. Các node cũng có thể chọn lưu trữ nhiều dữ liệu hơn mức cần thiết, giúp tăng cường bảo mật mạng hơn nữa.

Các nút xác thực chịu trách nhiệm nhiều hơn các nút đầy đủ thông thường. Vì các nút xác thực chạy trên phần cứng mạnh hơn, PeerDAS phân bổ tải lưu trữ dữ liệu tương ứng cho chúng dựa trên tổng số nút xác thực. Điều này đảm bảo luôn có một nhóm nút ổn định để lưu trữ và chia sẻ nhiều dữ liệu hơn, từ đó cải thiện độ tin cậy của mạng. Tóm lại, nếu có 900.000 nút xác thực, mỗi nút xác thực có thể được phân bổ một phần nhỏ tổng dữ liệu để lưu trữ và bảo trì. Vì các nút xác thực có máy móc mạnh hơn, mạng có thể tin tưởng chúng để đảm bảo tính khả dụng của dữ liệu.

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

Lấy mẫu cột cho phép các nút chuẩn bị trước dữ liệu hàng bổ sung, và các bằng chứng cần thiết sẽ được tính toán bởi bên gửi giao dịch (thay vì bên tạo khối). Điều này duy trì tốc độ và hiệu quả của việc tạo khối. Ví dụ, giả sử một blob là một lưới ô 4x4. Lấy mẫu hàng nghĩa là lấy cả bốn ô từ một hàng, nhưng một số hàng mở rộng vẫn chưa sẵn sàng, vì vậy bên tạo khối phải tạo chúng ngay tại chỗ; mặt khác, lấy mẫu cột trích xuất một ô từ mỗi hàng (mỗi cột), và các ô bổ sung cần thiết cho việc tái cấu trúc có thể được chuẩn bị trước, cho phép các nút xác minh dữ liệu mà không làm chậm quá trình tạo khối.

EIP-7594 hoàn toàn tương thích với EIP-4844, do đó sẽ không làm gián đoạn 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 thông số kỹ thuậ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", trong đó nhà sản xuất khối giả vờ dữ liệu có sẵn nhưng thực chất lại ẩn một phần dữ liệu. PeerDAS ngăn chặn điều này bằng cách sử dụng phương pháp lấy mẫu ngẫu nhiên: các nút kiểm tra các phần dữ liệu ngẫu nhiên. Càng nhiều nút được lấy mẫu, 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 toán xác suất thành công của một cuộc tấn công như vậy dựa trên tổng số nút (n), tổng số mẫu (m) và số mẫu trên mỗi nút (k). Trên mạng chính Ethereum, với khoảng 10.000 nút, xác suất thành công của một cuộc tấn công là cực kỳ thấp, do đó PeerDAS được coi là an toàn.

EIP-7823: Đặt kích thước tối đa là 1024 byte cho MODEXP

Sự cần thiết của đề xuất này nằm ở chỗ cơ chế tiền biên dịch MODEXP hiện tại của Ethereum đã dẫn đến vô số lỗ hổng đồng thuận trong những năm qua. Những lỗ hổng này phần lớn xuất phát từ việc MODEXP cho phép lượng dữ liệu đầu vào cực lớn và không thực tế, buộc khách hàng phải xử lý vô số trường hợp ngoại lệ.

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

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

EIP-7823 giới thiệu một quy tắc đơn giản: cả ba trường độ dài được MODEXP sử dụng (cơ số, số mũ và môđun) phải nhỏ hơn hoặc bằng 8192 bit, hay 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 các giá trị độ dài. Nếu bất kỳ độ dài nào vượt quá 1024 byte, quá trình tiền xử lý 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 radix 2000 byte, lệnh 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 mọi tình huống ứng dụng thực tế. Xác minh RSA thường sử dụng độ dài khóa là 1024 bit, 2048 bit hoặc 4096 bit, tất cả đều nằm trong giới hạn mới. Các phép toán đường cong elliptic sử dụng kích thước đầu vào nhỏ hơn, thường nhỏ hơn 384 bit, và do đó không bị ảnh hưởng.

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

Để xác nhận rằng thay đổi này sẽ không làm gián đoạn các giao dịch trước đó, các tác giả đã phân tích toàn bộ việc sử dụng MODEXP từ khối 5.472.266 (ngày 20 tháng 4 năm 2018) đến khối 21.550.926 (ngày 4 tháng 1 năm 2025). Kết quả cho thấy không có lệnh gọi MODEXP thành công nào trong lịch sử sử dụng quá 513 byte dữ liệu đầu vào, thấp hơn nhiều so với giới hạn 1024 byte mới. Hầu hết các lệnh gọi thực tế đều sử dụng các độ dài nhỏ hơn, chẳng hạn như 32 byte, 128 byte hoặc 256 byte.

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

Từ góc độ bảo mật, việc giảm kích thước đầu vào được phép không gây ra rủi ro mới. Thay vào đó, nó loại bỏ các trường hợp cực đoan không cần thiết trước đây dẫn đến lỗi và sự không nhất quán giữa các máy khách. Bằng cách giới hạn đầu vào MODEXP ở một 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 bất thường và giảm khả năng xảy ra lỗi giữa các lần triển khai khác nhau. Những hạn chế này cũng giúp chuẩn bị cho quá trình chuyển đổi mượt mà hơn nếu các bản nâng cấp trong tương lai (như EVMMAX) giới thiệu các đường dẫn thực thi được tối ưu hóa.

EIP-7825: Giới hạn giao dịch 16,7 triệu Gas

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

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

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

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 thụ quá 16.777.216 (2²⁴) Gas. Quy tắc này trở thành giới hạn cấp độ giao thức, nghĩa là nó áp dụng cho tất cả các giai đoạn: người dùng gửi giao dịch, nhóm giao dịch kiểm tra giao dịch và trình xác thực đóng gói giao dịch thành các khối. Nếu ai đó gửi nhiều Gas hơn giới hạn này, máy khách phải ngay lập tức từ chối 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 khối. Ví dụ, ngay cả khi giới hạn gas khối là 40 triệu, mức tiêu thụ gas của bất kỳ giao dịch đơn lẻ nào cũng không được vượt quá 16,7 triệu. Mục đích là để đảm bảo mỗi khối có thể xử lý nhiều giao dịch, thay vì để một giao dịch chiếm toàn bộ khối.

Để hiểu rõ hơn, hãy giả sử một khối 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 từ 35 triệu đến 40 triệu Gas. Giao dịch này sẽ độc quyền khối, không chừa chỗ cho các giao dịch khác, giống như việc ai đó thuê cả một chiếc xe buýt, ngăn cản bất kỳ ai khác lên xe. Giới hạn 16,7 triệu Gas mới sẽ cho phép các khối tự nhiên chứa được nhiều giao dịch, do đó ngăn chặn việc lạm dụng như vậy.

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

Con số 16.777.216 (2²⁴) được chọn vì nó thể hiện ranh giới lũy thừa 2 rõ ràng, giúp dễ triển khai và vẫn đủ lớn để xử lý hầu hết các giao dịch thực tế, chẳng hạn như triển khai hợp đồng thông minh, tương tác DeFi phức tạp hoặc lệnh gọi hợp đồng nhiều bước. Giá trị này chỉ bằng khoảng một nửa kích thước khối thông thường, nghĩa là ngay cả những giao dịch phức tạp nhất cũng có thể dễ dàng nằm trong giới hạn này.

EIP này cũng duy trì khả năng tương thích với các cơ chế gas hiện có. Hầu hết người dùng sẽ không nhận thấy sự thay đổi này vì hầu hết các giao dịch hiện tại đều tiêu thụ dưới 16 triệu gas. Người xác thực và người tạo khối vẫn có thể tạo các khối với tổng gas vượt quá 16,7 triệu, miễn là mỗi giao dịch tuân thủ giới hạn mới.

Các giao dịch bị ảnh hưởng duy nhất là những giao dịch trước đó đã cố gắng vượt quá giới hạn mới và trở nên cực kỳ lớn. Các giao dịch này giờ đây phải được chia nhỏ thành nhiều thao tác nhỏ hơn, tương tự như việc chia một tệp tải lên rất lớn thành hai tệp nhỏ hơn. 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 kỳ hiếm gặp này, nhưng số lượng người dùng bị ảnh hưởng dự kiến ​​sẽ rất nhỏ.

Về mặt 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 các trình xác thực xử lý các giao dịch cực lớn. Nó cũng giúp duy trì khả năng dự đoán thời gian xác thực khối, giúp các nút dễ dàng đồng bộ hóa hơn. Trường hợp cực đoan chính là một vài triển khai hợp đồng rất lớn có thể không đáp ứng được các yêu cầu về giới hạn, đòi hỏi phải thiết kế lại hoặc chia thành nhiều bước triển khai.

Nhìn chung, EIP-7825 nhằm mục đích tăng cường bảo vệ mạng chống lại việc lạm dụng, duy trì nhu cầu nút hợp lý, cải thiện tính công bằng trong việc sử dụng không gian khối và đảm bảo rằng blockchain vẫn có thể hoạt động nhanh chóng và ổn định khi mức gas cap tăng lên.

EIP-7883: Tăng giá gas ModExp

Ethereum cần đề xuất này vì giá của ModExp được biên dịch sẵn (được sử dụng cho phép lũy thừa mô-đun) luôn thấp so với lượng tài nguyên mà nó thực sự tiêu thụ.

Trong một số trường hợp, nhu cầu tính toán của một hoạt động ModExp vượt xa mức phí mà người dùng hiện đang phải trả. Sự chênh lệch này đặt ra một rủi ro: nếu các lệnh ModExp phức tạp được định giá quá thấp, chúng có thể trở thành nút thắt cổ chai, khiến mạng lưới khó có thể tăng giới hạn gas một cách an toàn. Điều này là do các nhà sản xuất khối có thể buộc phải xử lý các hoạt động cực kỳ nặng nề với chi phí rất thấp.

Để giải quyết vấn đề này, Ethereum cần điều chỉnh công thức định giá ModExp sao cho mức tiêu thụ gas phản ánh chính xác khối lượng công việc thực tế mà khách hàng 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 hoạt động với khối lượng dữ liệu đầu vào lớn (đặc biệt là các phép toán mũ, cơ số hoặc modulo vượt quá 32 byte) trở nên tốn kém hơn, từ đó điều chỉnh giá gas cho phù hợp với nhu cầu tính toán thực tế.

Đề xuất này làm tăng chi phí theo một số cách chính, qua đó sửa đổi thuật toán định giá ModExp ban đầu được xác định trong EIP-2565.

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

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

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

Đề xuất này định nghĩa một hàm tính toán Gas mới và cập nhật các quy tắc về độ phức tạp và số lần lặp. Độ phức tạp của phép nhân hiện sử dụng giá trị mặc định là 16 cho độ dài cơ số/môđun 32 byte trở xuống, trong khi đối với các đầu vào lớn hơn, nó chuyển sang công thức phức tạp hơn: 2 × words², trong đó "words" chỉ số lượng khối 8 byte. Số lần lặp cũng đã được cập nhật để các số mũ 32 byte trở xuống sử dụng độ dài bit của chúng để xác định độ phức tạp, trong khi các số mũ lớn hơn 32 byte sẽ phải chịu mức phạt Gas lớn hơn.

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

Việc tăng giá này được thúc đẩy bởi các bài kiểm tra chuẩn cho thấy giá được biên dịch sẵn theo ModExp bị định giá thấp đáng kể trong nhiều trường hợp. Công thức sửa đổi làm tăng chi phí gas lên 150% đối với các hoạt động nhỏ, khoảng 200% đối với các hoạt động thông thường, và thậm chí cao hơn gấp nhiều lần, đôi khi vượt quá 80 lần, đối với các hoạt động lớn hoặc không cân bằng, tùy thuộc vào kích thước của số mũ, cơ số hoặc môđun .

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

Kết quả thử nghiệm cho thấy mức tăng chi phí gas là đáng kể. Khoảng 99,69% các lệnh gọi ModExp trước đây hiện yêu cầu 500 Gas (trước đây là 200 Gas) hoặc gấp ba lần giá trước đó. Tuy nhiên, mức tăng chi phí gas thậm chí còn lớn hơn đối với một số trường hợp thử nghiệm tải cao. Ví dụ, trong một thử nghiệm "tính toán theo cấp số nhân", mức tiêu thụ gas đã tăng vọt từ 215 lên 16.624, tăng khoảng 76 lần, vì giá cho các số mũ cực cao hiện đã hợp lý hơn.

Về mặt bảo mật, đề xuất này không đưa ra các vectơ tấn công mới, cũng không làm giảm chi phí tính toán. Thay vào đó, nó tập trung vào việc giảm thiểu một rủi ro đáng kể: các phép toán ModExp có giá quá thấp có thể cho phép kẻ tấn công lấp đầy các khối bằng các phép tính cực kỳ tốn kém với chi phí rất thấp. Nhược điểm tiềm ẩn duy nhất là một số phép toán ModExp có thể trở nên quá tốn kém, nhưng điều này tốt hơn nhiều so với vấn đề hiện tại là giá quá thấp. Đề xuất không đưa ra bất kỳ thay đổi giao diện hay tính năng mới nào, do đó các hành vi số học và vectơ kiểm tra hiện có 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 của những người đề xuất cho kỷ nguyên tiếp theo của mạng không thể được dự đoán đầy đủ. Ngay cả khi hạt giống RANDAO cho kỷ nguyên N+1 được biết đến trong kỷ nguyên N, danh sách những người đề xuất thực tế vẫn có thể thay đổi do các cập nhật về số dư hiệu dụng (EB) trong kỷ nguyên N.

Những thay đổi EB này có thể xuất phát từ việc cắt giảm, phạt, phần thưởng vượt quá 1 ETH, hợp nhất trình xác thực hoặc các khoản tiền gửi mới, đặc biệt là sau khi EIP-7251 tăng số dư hiệu dụng tối đa lên hơn 32 ETH. Sự không chắc chắn này đặt ra vấn đề cho các hệ thống dựa trên việc biết trước người đề xuất tiếp theo (chẳng hạn như các giao thức được xác nhận trước), vốn đòi hỏi các mốc thời gian ổn định và có thể dự đoán được để hoạt động trơn tru. Trình xác thực thậm chí có thể cố gắng "bơm" hoặc thao túng số dư hiệu dụng của mình để tác động đến người đề xuất của kỷ nguyên tiếp theo.

Do những vấn đề này, Ethereum cần một cách để làm cho mốc thời gian của người đề xuất có tính xác định hoàn toàn trong vài kỷ nguyên tiếp theo, để mốc thời gian này không thay đổi do các bản cập nhật EB vào phút chót và có thể dễ dàng truy cập vào lớp ứng dụng.

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

Ví dụ, khi kỷ nguyên N bắt đầu, danh sách đã chứa các đề xuất cho mỗi khe trong kỷ nguyên N và kỷ nguyên N+1. Sau đó, khi mạng bước vào kỷ nguyên N+1, danh sách sẽ được dịch chuyển lên phía trước: mục đề xuất cho kỷ nguyên N bị xóa, mục cho kỷ nguyên N+1 được chuyển lên đầu danh sách, và một mục đề xuất mới cho kỷ nguyên N+2 được thêm vào cuối danh sách. Điều này giúp việc lập lịch được cố định và có thể dự đoán được, và máy khách có thể đọc trực tiếp mà không cần tính toán lại các đề xuất cho mỗi khe.

Để giữ cho danh sách được cập nhật, nó sẽ di chuyển về phía trước tại mỗi ranh giới kỷ nguyên: dữ liệu từ kỷ nguyên trước đó được xóa, và một tập hợp các chỉ số đề xuất mới cho kỷ nguyên tương lai tiếp theo được tính toán và thêm vào danh sách. Quy trình này sử dụng cùng các quy tắc hạt giống và số dư hiệu dụng như trước, nhưng việc lập lịch hiện được tính toán sớm hơn, do đó tránh được tác động của những thay đổi số dư hiệu dụng sau khi hạt giống được xác định. Khối đầu tiên sau khi phân nhánh cũng điền vào toàn bộ phạm vi nhìn trước để đảm bảo rằng tất cả các kỷ nguyên tương lai đều đã khởi tạo lập lịch chính xác.

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

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

Trước đề xuất này, khách hàng chỉ tính toán các bên đề xuất cho khung thời gian hiện tại. Với EIP-7917, giờ đây họ tính toán danh sách các bên đề xuất cho tất cả các khung thời gian của kỷ nguyên tiếp theo cùng một lúc trong mỗi lần chuyển tiếp kỷ nguyên. Điều này tốn thêm một chút công sức, nhưng việc tính toán chỉ số bên đề xuất rất nhẹ, chủ yếu liên quan đến việc lấy mẫu danh sách các bên xác thực bằng cách sử dụng một hạt giống. Tuy nhiên, khách hàng cần đánh giá chuẩn để đảm bảo rằng việc tính toán bổ sung này không gây ra vấn đề về hiệu suất.

EIP-7918: Phí cơ sở blob bị giới hạn bởi chi phí thực hiện.

Ethereum cần đề xuất này vì hệ thống phí Blob hiện tại (bắt nguồn từ EIP-4844) sẽ không hoạt động khi gas trở thành chi phí chính để triển khai.

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

Ví dụ, giả sử một Rollup muốn công bố dữ liệu của mình: cần phải trả khoảng 25.000.000 gwei cho gas thực thi (khoảng 1.000.000 gas cần 25 gwei), trong khi phí Blob chỉ khoảng 200 gwei. Điều này có nghĩa là tổng chi phí là khoảng 25.000.200 gwei, với hầu hết chi phí đến từ gas thực thi chứ không phải phí Blob. Nếu Ethereum tiếp tục giảm phí Blob, chẳng hạn từ 200 gwei xuống 50 gwei, sau đó xuống 10 gwei, và cuối cùng là 1 gwei, thì tổng chi phí sẽ hầu như không thay đổi, vẫn ở mức 25.000.000 gwei.

EIP-7918 giải quyết vấn đề này bằng cách đưa ra “giá đặt trước” tối thiểu dựa trên chi phí cơ sở thực hiện, do đó ngăn giá Blob trở nên quá thấp và làm cho giá Blob của Rollup ổn định và có thể dự đoán được hơn.

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

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

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

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

Một lý do khác để thêm mức giá đặt trước này là các nút cần phải thực hiện rất nhiều công việc bổ sung để xác minh bằng chứng KZG của dữ liệu blob. Những bằng chứng này đảm bảo rằng dữ liệu trong blob khớp với lời hứa của nó. Theo EIP-4844, các nút chỉ cần xác minh một bằng chứng cho mỗi blob, điều này rất tiết kiệm chi phí. Tuy nhiên, trong EIP-7918, các nút cần xác minh số lượng bằng chứng lớn hơn nhiều. Điều này hoàn toàn là do trong EIP-7594 (PeerDAS), các blob được chia thành nhiều phần nhỏ gọi là cell, mỗi cell có một bằng chứng riêng, làm tăng đáng kể khối lượng công việc xác minh.

Về lâu dài, EIP-7918 cũng giúp Ethereum chuẩn bị cho tương lai. Khi công nghệ phát triển, chi phí lưu trữ và chia sẻ dữ liệu sẽ tự nhiên giảm xuống, và 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 lên, phí Blob (tính bằng ETH) sẽ tự nhiên giảm xuống. Đề xuất này hỗ trợ điều này vì giá duy trì được gắn với giá gas thực thi, thay vì một giá trị cố định, do đó có thể điều chỉnh khi mạng lưới phát triển.

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

Khi phí gas thực hiện đột ngột tăng vọt, có một chi tiết nhỏ cần lưu ý. Vì giá của một blob phụ thuộc vào chi phí thực hiện cơ bản, nên việc chi phí thực hiện tăng độ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 hiện. Ví dụ: giả sử phí gas thực hiện đột ngột tăng từ 20 gwei lên 60 gwei trong một khối. Vì giá của một blob được cố định theo giá trị này, nên phí blob không thể giảm xuống dưới mức cao hơn mới. Nếu blob vẫn đang được sử dụng, phí của nó sẽ tiếp tục 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 đủ để phù hợp với chi phí thực hiện cao hơn. Điều này có nghĩa là trong vòng một vài khối, phí blob có thể tăng chậm hơn chi phí thực hiện. Sự chậm trễ tạm thời này là vô hại—nó thực sự ngăn chặn sự biến động mạnh về giá blob và làm cho hệ thống mượt mà hơn.

Các tác giả cũng đã tiến hành phân tích thực nghiệm về hoạt động giao dịch khối thực tế từ tháng 11 năm 2024 đến tháng 3 năm 2025, áp dụng quy tắc giá dự trữ. Trong giai đoạn phí thực hiện cao (trung bình khoảng 16 gwei), ngưỡng dự trữ đã làm tăng đáng kể phí khối cơ sở so với cơ chế cũ. Trong giai đoạn phí thực hiện thấp (trung bình khoảng 1,3 gwei), phí khối gần như không đổi trừ khi phí khối cơ sở được tính toán thấp hơn giá dự trữ. Bằng cách so sánh hàng nghìn khối, các tác giả cho thấy cơ chế mới tạo ra giá ổn định hơn trong khi vẫn duy trì phản ứng tự nhiên với nhu cầu. Biểu đồ tần suất phí khối trong bốn tháng cho thấy giá dự trữ ngăn phí khối giảm mạnh xuống 1 gwei, do đó làm giảm sự biến động cực đoan.

Về mặt bảo mật, thay đổi này không gây ra bất kỳ rủi ro nào. Phí khối cơ sở sẽ 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 mức phí tối thiểu, và việc đặt giá sàn không ảnh hưởng đến tính chính xác của giao thức. Nó chỉ đơn giản là đảm bảo hoạt động kinh tế lành mạnh.

EIP-7934: RLP thực thi giới hạn kích thước khối

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

Nếu một khối quá lớn, các nút sẽ mất nhiều thời gian hơn để tải xuống và xác minh nó, làm chậm quá trình lan truyền khối và tăng khả năng xảy ra các đợt fork blockchain tạm thời. Tệ hơn nữa, kẻ tấn công có thể cố tình tạo ra một khối cực lớn để làm quá tải các nút, gây ra sự chậm trễ hoặc thậm chí khiến chúng ngoại tuyến - một kiểu tấn công từ chối dịch vụ kinh điển. Hơn nữa, giao thức Gossip trên lớp đồng thuận (CL) của Ethereum đã từ chối lan truyền bất kỳ khối nào lớn hơn 10MB, nghĩa là các khối thực thi quá lớn có thể không lan truyền qua mạng, gây ra sự phân mảnh trên chuỗi hoặc bất đồng giữa các nút. Với những rủi ro này, Ethereum cần một quy tắc rõ ràng ở cấp độ giao thức để ngăn chặn các khối quá lớn và duy trì sự ổn định và bảo mật của mạng lưới.

EIP-7934 giải quyết vấn đề này bằng cách giới thiệu mã hóa RLP ở cấp giao thức để áp dụng giới hạn kích thước khối. Kích thước khối tối đa được phép (MAX_BLOCK_SIZE) được đặt thành 10 MiB (10.485.760 byte), nhưng Ethereum thêm 2 MiB (2.097.152 byte) vào giới hạn này vì các khối beacon cũng chiếm một phần không gian (SAFETY_MARGIN).

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

Việc lựa chọn giới hạn 10 MiB là có chủ đích vì nó phù hợp với các giới hạn hiện có 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 phát tán trên mạng, do đó EIP này giữ cho lớp thực thi nhất quán với các giới hạn của lớp đồng thuận. Điều này đảm bảo tính nhất quán trên tất cả các thành phần và ngăn các khối đã thực thi hợp lệ trở nên "vô hình" do CL từ chối truyền bá.

Thay đổi này không tương thích ngược với các khối lớn hơn giới hạn mới, nghĩa là thợ đào và người xác thực phải cập nhật máy khách của họ để tuân thủ quy tắc. Tuy nhiên, vì các khối quá lớn vốn dĩ đã gây ra nhiều vấn đề và không phổ biến trong thực tế, nên tác động là rất nhỏ.

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

EIP-7939: Tính toán mã lệnh số 0 đứng đầu (CLZ)

Trước EIP này, Ethereum không có mã lệnh tích hợp để tính toán số lượng số 0 đứng đầu trong một số 256 bit. Các nhà phát triển phải tự tay triển khai hàm CLZ bằng Solidity, đòi hỏi nhiều phép toán bit và so sánh.

Đây là một vấn đề đáng kể vì việc triển khai tùy chỉnh chậm, tốn kém và tiêu tốn một lượng lớn mã bytecode, làm tăng mức tiêu thụ Gas . Đối với các hệ thống chứng minh không kiến ​​thức, chi phí thậm chí còn cao hơn; chi phí chứng minh của các phép dịch phải cực kỳ cao, vì vậy các phép toán như CLZ làm chậm đáng kể các mạch chứng minh không kiến ​​thức. Vì CLZ là một hàm cấp thấp rất phổ biến được sử dụng rộng rãi trong các 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 toán nhanh hơn và tiết kiệm hơn.

EIP-7939 giải quyết vấn đề này bằng cách giới thiệu một mã lệnh mới gọi là CLZ (0x1e). Mã lệnh này đọc một giá trị 256 bit từ ngăn xếp và trả về số lượng các số 0 đứng đầu. Nếu số đầu vào là 0, mã lệnh trả về 256 vì số 0 256 bit có 256 số 0 đứng đầu.

Điều này phù hợp với cách CLZ hoạt động trong nhiều kiến ​​trúc CPU như ARM và x86, nơi các thao tác CLZ được hỗ trợ sẵn. Việc bổ sung CLZ có thể giảm đáng kể chi phí của nhiều thuật toán: các thao tác như lnWad, powWad, LambertW, nhiều hàm toán học, so sánh chuỗi byte, quét bitmap, lệnh gọi nén/giải nén dữ liệu và các lược đồ chữ ký hậu lượng tử đều có thể được hưởng lợi từ khả năng phát hiện zero-lookahead nhanh hơn.

Chi phí gas của CLZ được đặt ở mức 5, tương tự như ADD, và cao hơn một chút so với giá MUL trước đó, nhằm tránh nguy cơ bị tấn công từ chối dịch vụ (DoS) do định giá thấp. Các điểm chuẩn cho thấy chi phí tính toán của CLZ gần bằng ADD, và trong môi trường chứng minh SP1 rv32im, chi phí chứng minh của CLZ thực sự thấp hơn ADD, do đó giảm chi phí của chứng minh không kiến ​​thức.

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

Nhìn chung, EIP-7939 giúp Ethereum nhanh hơn, rẻ hơn và thân thiện hơn với nhà phát triển bằng cách thêm một nguyên mẫu đơn giản và hiệu quả vốn đã được CPU hiện đại hỗ trợ—giảm phí gas, giảm kích thước mã byte và giảm chi phí cho bằng chứng không kiến ​​thức đối với nhiều hoạt động phổ biến.

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

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

Đường cong này là tiêu chuẩn được sử dụng bởi 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. Nếu không có sự hỗ trợ này, các ứng dụng và ví không thể dễ dàng thực hiện chữ ký bằng bảo mật phần cứng cấp thiết bị. Một nỗ lực trước đó (RIP-7212) đã gặp phải 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ý không chính xác. Những vấn đề này có thể dẫn đến lỗi xác minh và thậm chí là lỗi đồng thuận. EIP-7951 giải quyết các vấn đề bảo mật này và giới thiệu một giao thức gốc, được biên dịch sẵn, an toàn, cuối cùng cho phép Ethereum hỗ trợ chữ ký từ phần cứng hiện đại một cách an toàn và hiệu quả.

EIP-7951 bổ sung một hợp đồng được biên dịch sẵn mới có tên P256VERIFY tại địa chỉ 0x100, thực hiện xác minh chữ ký ECDSA bằng đường cong secp256r1. Điều này giúp việc xác minh chữ ký nhanh hơn và ít tốn kém hơn so với việc triển khai thuật toán trực tiếp trong Solidity.

EIP-7951 cũng định nghĩa các quy tắc xác thực đầu vào nghiêm ngặt. Nếu tồn tại bất kỳ trường hợp nào không hợp lệ, quá trình tiền biên dịch sẽ trả về lỗi mà không khôi phục, tiêu tốn cùng lượng gas như một lệnh gọi thành công. Thuật toán xác thực tuân theo chuẩn ECDSA: tính toán s⁻¹ mod n, tái tạo điểm chữ ký R', từ chối nếu R' ở vô cực, và cuối cùng kiểm tra xem tọa độ x của R' có khớp với r (mod n) hay 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 nó theo modulo n trước.

Phí gas cho hoạt động này được đặt ở mức 6900 gas, cao hơn phiên bản RIP-7212, nhưng phù hợp với điểm chuẩn hiệu suất thực tế được xác minh bởi secp256r1. Quan trọng là, giao diện này hoàn toàn tương thích với các mạng Lớp 2 đã triển khai RIP-7212 (cùng địa chỉ, cùng định dạng đầu vào/đầu ra), do đó các hợp đồng thông minh hiện có sẽ tiếp tục hoạt động bình thường mà không có bất kỳ thay đổi nào. Điểm khác biệt duy nhất là hành vi được sửa đổi và phí gas cao hơn.

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

Tóm lại, EIP-7951 hướng đến mục tiêu mang lại tính năng xác thực hiện đại được hỗ trợ bởi phần cứng cho Ethereum một cách an toàn, khắc phục các sự cố bảo mật trong các đề xuất trước đó và cung cấp một phương pháp đáng tin cậy, chuẩn hóa để xác minh chữ ký P-256 trên toàn hệ sinh thái.

Tóm tắt

Bảng dưới đây tóm tắt những máy khách Ethereum nào cần thay đổi cho các EIP Fusaka khác nhau. Dấu kiểm bên dưới "Máy khách Đồng thuận" cho biết EIP cần cập nhật máy khách lớp đồng thuận, trong khi dấu kiểm bên dưới "Máy khách Thực thi" cho biết việc nâng cấp ảnh hưởng đến máy khách lớp thực thi. Một số EIP yêu cầu cập nhật cho cả lớp đồng thuận và lớp thực thi, trong khi một số khác chỉ yêu cầu cập nhật một trong hai.

Tóm lại, đây là những EIP chính được đưa vào hard fork Fusaka. Mặc dù bản nâng cấp này bao gồm một số cải tiến đối với các máy khách đồng thuận và thực thi, từ điều chỉnh gas và cập nhật mã lệnh cho đến các phiên bản biên dịch sẵn mới, cốt lõi của bản nâng cấp này vẫn là PeerDAS, giới thiệu tính năng lấy mẫu dữ liệu ngang hàng, cho phép xử lý dữ liệu Blob hiệu quả và phi tập trung hơn trên toàn mạng.