Trong 3 ngày nữa, Ethereum sẽ mở ra những thay đổi lớn này
Giải thích chi tiết cốt lõi về 9 đề xuất EIP chính để nâng cấp Fusaka.
Văn bản gốc từ Sahil Sojitra
Tổng hợp｜Odaily Planet Daily Golem (@web 3_golem)
Hard fork Fusaka, dự kiến được kích hoạt vào ngày 3 tháng 12 năm 2025, là phiên bản kế thừa của Pectra. Một bản nâng cấp mạng lớn khác sau đó đã đánh dấu một bước quan trọng khác để gã khổng lồ mã hóa mở rộng công suất.
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. EIP nâng cấp của Fusaka tập trung vào việc mở rộng dung lượng, cập nhật opcode 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 thực các đốm màu mà không cần tải xuống tất cả 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 hạn chế ModExp (EIP-7823), hạn chế 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 bằng cơ chế xem trước người đề xuất xác định (EIP-7917) và giữ phí blob ổn định bằng cách đặt “giá dự trữ” gắn với chi phí thực hiện (EIP-7918).
Các 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ã opcode CLZ mới để tăng tốc hoạt động bit (EIP-7939) và giới thiệu tính năng biên dịch trước secp256r1 (EIP-7951) để tương thích tốt hơn với các khóa bảo mật phần cứng và mật mã hiện đại.
Fusaka là tên kết hợp của Fulu (lớp thực thi) và Osaka (lớp đồng thuận). Nó thể hiện một bước tiến khác hướng tới một tương lai giàu dữ liệu, có khả năng mở rộng cao cho Ethereum, nơi các Bản cuộn lớp 2 có thể chạy 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ề 9 đề 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 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, 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 rằng nó đã được xuất bản. Điều này tạo 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 tất cả dữ liệu thì yêu cầu về băng thông và phần cứng của mạng sẽ tăng lên và mức độ phân cấp bị ảnh hưởng. Để giải quyết vấn đề này, Ethereum cần một cách để các nút xác nhận rằng dữ liệu có sẵn mà không cần tải xuống tất cả dữ liệu.
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.
Nhưng 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 đặt gánh nặng tính toán nặng 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ề nút ở 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 rằng dữ liệu hoàn chỉnh đã được xuất bản. Thay vì tải xuống toàn bộ dữ liệu, các nút có thể tận dụng mạng tin đồn thông thường để chia sẻ dữ liệu, khám phá xem nút nào chứa 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, nút vẫn có thể bị thuyết phục về sự tồn tại của toàn bộ đoạn dữ liệu. Ví dụ: một nút chỉ có thể tải xuống khoảng 1/8 dữ liệu, thay vì tải xuống toàn bộ đoạn dữ liệu 256 KB - nhưng vì nhiều nút lấy mẫu các phần khác nhau nên mọi dữ liệu bị thiếu sẽ được phát hiện nhanh chóng.
Để lấy mẫu, PeerDAS sử dụng mã xóa cơ bản để mở rộng từng đoạn dữ liệu trong EIP-4844. Mã hóa xóa là một kỹ thuật bổ sung thêm phần dư thừa cho dữ liệu để có thể khôi phục dữ liệu gốc ngay cả khi một số phần dữ liệu bị thiếu - tương tự như cách có thể hoàn thành một câu đố ngay cả khi thiếu một vài phần.
Blob trở 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 để dữ liệu có thể được xây dựng lại sau này. Hàng này sau đó được chia thành nhiều phần nhỏ gọi là "ô", là đơn vị xác minh nhỏ nhất liên quan đến các cam kết KZG. Sau đó, tất cả "hàng" được sắp xếp lại thành "cột", với mỗi cột chứa các ô có 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ể.
Các 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 chúng và lấy mẫu một số cột từ các nút ngang hàng tại mỗi khung thời gian. Nếu một nút thu thập ít nhất 50% số cột, nó có thể tái tạo lại hoàn toàn dữ liệu. Nếu ít hơn 50% số cột được thu thập, nó sẽ yêu cầu các cột bị thiếu từ thiết bị 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ì nó luôn có thể được xây dựng lại. Nói tóm lại, nếu có tổng cộng 64 cột thì một nút chỉ cần khoảng 32 cột để xây dựng lại blob hoàn chỉnh. Nó giữ lại một số cột và tải xuống một số cột từ các đồng nghiệp. Miễn là một nửa số cột có mặt trong mạng, nút có thể xây dựng lại mọi thứ, ngay cả khi một số cột bị thiếu.
Ngoài ra, EIP-7594 đưa ra một quy tắc quan trọng: không giao dịch nào có thể chứa nhiều hơn 6 đốm màu. Hạn chế này phải được thực thi trong quá trình xác minh giao dịch, truyền bá tin đồn, tạo khối và xử lý khối. Điều này giúp giảm thiểu các trường hợp nghiêm trọng khi một giao dịch đơn lẻ làm quá tải hệ thống blob.
PeerDAS đã thêm một tính năng gọi là "Bằng chứng đơn vị KZG". Bằng chứng KZG ô cho thấy rằng cam kết KZG không khớp với một ô cụ thể (một đơn vị nhỏ) trong blob. Điều này cho phép một nút chỉ tải xuống các ô mà nó muốn lấy mẫu. Việc lấy được toàn bộ blob trong khi vẫn đả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. Các nhà sản xuất khối cần phải tính toán các bằng chứng này nhiều lần qua nhiều đốm màu, điều này khiến chúng quá chậm. Tuy nhiên, xác minh bằng chứng rất rẻ, vì vậy EIP-7594 yêu cầu người gửi giao dịch blob tạo trước tất cả bằng chứng đơn vị và đưa chúng vào trình bao bọc giao dịch.
Do đó, tin đồn về giao dịch (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 trình bao bọc mới, cell_proofs chỉ là một danh sách chứa tất cả các bằng chứng cho từng ô của mỗi blob (ví dụ: [cell_proof_0, cell_proof_1, ...]). Các trường tx_payload_body, blob và cam kết khác giống hệt với các trường trong EIP-4844. Sự khác biệt là trường "bằng chứng" đơn ban đầu bị xóa và thay thế bằng danh sách cell_proofs mới, đồng thời một trường mới có tên là Wrapper_version được thêm vào để biểu thị định dạng trình bao bọc hiện đang được sử dụng.
PeerDAS cho phép Ethereum tăng 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 nút. Ngày nay, một nút chỉ cần lấy mẫu khoảng 1/8 tổng số 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 nút có nhiều nút ngang hàng, vì vậy nếu một nút ngang hàng không thể cung cấp dữ liệu cần thiết thì nút đó có thể yêu cầu dữ liệu đó từ các nút ngang hàng khác. Điều này tự nhiên tạo ra một cơ chế dự phòng và cải thiện tính bảo mật, đồng thời các nút cũng có thể chọn lưu trữ nhiều dữ liệu hơn mức thực sự cần thiết, điều này giúp tăng cường hơn nữa tính bảo mật của mạng.
Các nút xác thực chịu nhiều trách nhiệm hơn các nút đầy đủ thông thường. Vì bản thân các nút trình xác thực chạy phần cứng mạnh hơn nên PeerDAS sẽ phân bổ tải lưu trữ dữ liệu tương ứng cho tổng số nút trình xác thực. Điều này đảm bảo luôn có sẵn một nhóm nút ổ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 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ỏ trong tổng số dữ liệu để lưu trữ và phục vụ. Vì người xác nhận có máy mạnh hơn nên mạng có thể tin cậy họ để đả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 tạo dữ liệu. Nếu một nút lấy mẫu toàn bộ hàng (toàn bộ blob), nó sẽ cần tạo thêm "các đốm màu mở rộng" không tồn tại, điều này làm chậm quá trình tạo khối.
Với việc lấy mẫu cột, các nút có thể chuẩn bị trước các hàng dữ liệu bổ sung và các bằng chứng cần thiết được tính toán bởi người gửi giao dịch (chứ không phải nhà sản xuất 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 đốm màu là một lưới ô 4×4. Lấy mẫu hàng có nghĩa là lấy tất cả 4 ô 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 nhà sản xuất khối phải tạo chúng ngay tại chỗ; lấy mẫu cột có nghĩa là lấy 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 để các nút có thể 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 và do đó sẽ không phá vỡ bất kỳ chức năng hiện có nào trên Ethereum. Tất cả các thử nghiệm 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à "cuộc tấn công che giấu dữ liệu", trong đó nhà sản xuất khối giả vờ rằng dữ liệu có sẵn nhưng thực tế lại che giấu một số dữ liệu. PeerDAS ngăn chặn điều này bằng cách sử dụng lấy mẫu ngẫu nhiên: các nút kiểm tra các phần ngẫu nhiên của dữ liệu. Càng lấy mẫu nhiều nút thì kẻ tấn công càng khó gian lận. EIP-7594 thậm chí còn cung cấp công thức để tính toán khả năng 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ố lượng mẫu trên mỗi nút (k). Trên mạng chính Ethereum có khoảng 10.000 nút, xác suất tấn công thành công là cực kỳ thấp nên PeerDAS được coi là an toàn.
EIP-7823: Đặt 1024 cho MODEXP Byte Cap
Đề xuất này là cần thiết vì cơ chế biên dịch trước MODEXP hiện tại của Ethereum đã dẫn đến nhiều lỗ hổng đồng thuận trong những năm qua. Hầu hết các lỗ hổng này đều xuất phát từ lượng dữ liệu đầu vào cực lớn và không thực tế mà MODEXP cho phép, khiến máy khách phải xử lý nhiều trường hợp ngoại lệ.
Vì mỗi nút phải xử lý tất cả đầu vào do giao dịch cung cấp nên việc không có giới hạn trên khiến MODEXP khó kiểm tra hơn, dễ xảy ra lỗi hơn và có nhiều 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 công thức chi phí gas khó dự đoán, vì khó định giá dữ liệu khi 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 trong tương lai bằng các công cụ như EVMMAX, 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 đường dẫn thực thi an toàn và tối ưu hóa.
Để 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ề kích thước 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 hoặc 1024 byte. Đầu vào MODEXP tuân theo định dạng được xác định trong EIP-198:
Ví dụ: nếu một người cố gắng cung cấp cơ sở dài 2000 byte, cuộc gọi sẽ thất bại trước khi bất kỳ công việc nào có thể bắt đầu. Những hạn chế này vẫn đủ cho tất cả các kịch bản ứng dụng thực tế. Xác thực RSA thường sử dụng độ dài khóa như 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 trên đường cong elip 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 sẽ hỗ trợ cho việc nâng cấp trong tương lai. Nếu MODEXP được viết lại thành mã EVM bằng EVMMAX trong tương lai, nhà phát triển có thể thêm đường dẫn tối ưu hóa 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 sơ đồ dự phòng chậm hơn trong một số trường hợp hiếm gặp. Bằng cách sửa kích thước đầu vào tối đa, nhà phát triển thậm chí có thể thêm cách xử lý đặc biệt cho 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 bị giới hạn và không gian thiết kế quá lớn để có thể quản lý một cách an toàn.
Để xác nhận rằng thay đổi này không phá vỡ các giao dịch trong quá khứ, các tác giả đã phân tích tất cả 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 chưa có cuộc gọi MODEXP thành công nào trong lịch sử từng sử dụng hơn 513 byte đầ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 cuộc gọi thực tế sử dụng độ dài nhỏ 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ị hỏng, chẳng hạn như đầu vào trống, đầu vào chứa đầy byte lặp lại và đầu vào rất lớn nhưng không hợp lệ. Hoạt động của các lệnh gọi này theo các hạn chế mới cũng không hợp lệ vì bản thân chúng không hợp lệ. Vì vậy, mặc dù về mặt kỹ thuật EIP-7823 là một thay đổi đột phá 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 khó khăn không cần thiết mà trước đây đã gây ra 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 ở kích thước hợp lý, EIP-7823 giúp hệ thống dễ dự đoán hơn, giảm các trường hợp góc lạ và giảm khả năng xảy ra lỗi giữa các lần triển khai. Những giới hạn này cũng giúp hệ thống chuẩn bị cho quá trình chuyển đổi suôn sẻ hơn nếu các bản nâng cấp trong tương lai (chẳng hạn như EVMMAX) đưa ra các đường dẫn thực thi được tối ưu hóa.
EIP-7825: 16,7 triệu Gas giới hạn cho các giao dịch
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 thụ gần như toàn bộ giới hạn Gas của khối.
Điều này sẽ gây ra một số vấn đề: một giao dịch có thể tiêu tốn hầu hết tài nguyên của khối, dẫn đến độ trễ chậm tương tự như các cuộc tấn công DoS; các hoạt động tiêu tốn nhiều Gas sẽ làm tăng cập nhật trạng thái của Ethereum quá nhanh; xác minh khối sẽ chậm lại và các nút sẽ gặp khó khăn trong việc theo kịp.
Nếu người dùng gửi một giao dịch lớn tiêu thụ gần như toàn bộ Gas (ví dụ: giao dịch tiêu thụ 38 triệu Gas trong 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 minh khối. Điều này đe dọa sự ổn định và phân cấp của mạng, vì việc xác thực chậm hơn có nghĩa là các nút 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 có thể được sử dụng cho một giao dịch, từ đó giúp tải khối dễ dự đoán hơn, giảm nguy cơ tấn công DoS và làm cho tải của các nút cân bằng hơn.
EIP-7825 đưa ra một quy tắc cứng: mọi giao dịch không được tiêu thụ quá 16.777.216 (2²⁴) Gas. Điều này trở thành giới hạn trên ở cấp giao thức, nghĩa là nó áp dụng cho tất cả mọi người: người dùng gửi giao dịch, nhóm giao dịch kiểm tra giao dịch và người xác thực đóng gói giao dịch thành các khối. Nếu ai đó gửi nhiều hơn giới hạn gas này, khách hàng phải từ chối giao dịch ngay lập tức và trả về lỗi như MAX_GAS_LIMIT_EXCEEDED.
Giới hạn trên này hoàn toàn độc lập với giới hạn trên của khối gas. 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 rằng mỗi khối có thể đáp ứng nhiều giao dịch, thay vì chỉ có một giao dịch duy nhất chiếm toàn bộ khối.
Để hiểu rõ hơn về điều này, hãy tưởng tượng rằng 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 35 triệu đến 40 triệu gas. Giao dịch này sẽ độc quyền khối, không còn chỗ cho các giao dịch khác, giống như một người thuê toàn bộ xe buýt và không ai có thể lên xe. Giới hạn 16,7 triệu Gas mới sẽ cho phép khối thực hiện nhiều giao dịch một cách tự nhiên, do đó tránh được sự lạm dụng đó.
Đề xuất cũng đưa 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 giao dịch vượt quá 16.777.216, nhóm giao dịch phải từ chối giao dịch, điều đó có nghĩa là các giao dịch đó thậm chí sẽ không được đưa vào hàng đợi. 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.
Số 16.777.216 (2²⁴) được chọn vì đây là giới hạn lũy thừa 2 sạch để dễ thực hiện và vẫn đủ lớn để xử lý hầu hết các giao dịch thực. Ví dụ: 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 gần bằ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ơ 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 tất cả các giao dịch hiện tại đều tiêu thụ ít hơn 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 lượ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à các giao dịch quá lớn mà trước đây đã cố gắng sử dụng vượt quá giới hạn mới. Các giao dịch này bây giờ phải được chia thành nhiều hoạt động 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 đoan 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, Gas cap giúp Ethereum có khả năng chống lại các cuộc tấn công DoS dựa trên Gas tốt hơn, vì những kẻ tấn công không còn có thể buộc người xác thực xử lý các giao dịch cực lớn. Nó cũng giúp dự đoán được 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 số hoạt động triển khai hợp đồng rất lớn có thể không đáp ứng được yêu cầu giới hạn và cần được 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 củng cố mạng lưới để ngăn chặn lạm dụng, giữ cho nhu cầu nút ở mức 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 khi giới hạn gas tăng lên, chuỗi khối vẫn có thể duy trì hoạt động nhanh và ổn định.
EIP-7883: Tăng phí gas ModExp
Lý do Ethereum cần đề xuất này là vì giá tiền biên dịch ModExp (được sử dụng để lũy thừa mô-đun) luôn ở mức thấp so với tài nguyên mà nó thực sự tiêu thụ.
Trong một số trường hợp, các hoạt động ModExp yêu cầu tính toán nhiều hơn mức người dùng hiện phải trả. Sự không khớp này gây ra rủi ro: nếu các lệnh gọi ModExp phức tạp được định giá quá thấp, chúng có thể trở thành nút cổ chai, khiến mạng khó có thể tăng giới hạn gas một cách an toàn. Bởi vì các nhà sản xuất khối có thể buộc phải xử lý những hoạt động cực kỳ nặng nhọc 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á của ModExp để mức tiêu thụ gas phản ánh chính xác lượng công việc thực sự được khách hàng hoàn thành. Do đó,EIP-7883 đưa ra các quy tắc mới làm tăng chi phí gas tối thiểu, tăng tổng chi phí gas và khiến các hoạt động với kích thước dữ liệu đầu vào lớn (đặc biệt là các phép toán số mũ, cơ sở hoặc mô đun trên 32 byte) trở nên đắt hơn, từ đó khớp giá gas với lượng tính toán thực tế được yêu cầu.
Đề xuất này sửa đổi thuật toán định giá ModExp ban đầu được xác định trong EIP-2565 bằng cách tăng chi phí theo một số cách quan trọng.
Đầu tiên, mức tiêu thụ gas tối thiểu tăng từ 200 lên 500 và tổng lượng gas tiêu thụ không còn chia cho 3, điều đó có nghĩa là tổng lượng gas tiêu thụ thực sự đã tăng gấp ba lần. Ví dụ: nếu lệnh gọi ModExp trước đây tốn 1200 gas thì giờ đây nó sẽ tốn khoảng 3600 gas theo công thức mới.
Thứ hai, các phép toán có số mũ lớn hơn 32 byte sẽ có chi phí gấp đôi vì hệ số nhân tăng từ 8 lên 16. Ví dụ: nếu độ dài chỉ mục là 40 byte, EIP-2565 sẽ tăng số lần lặp lên 8 × (40 − 32) = 64 lần, trong khi EIP-7883 hiện sử dụng 16 × (40 − 32) = 128 lần, gấp đôi chi phí.
Thứ ba, việc định 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 thì quy tắc mới sẽ áp dụng độ phức tạp gấp đôi (2 × từ²) thay vì công thức đơn giản hơn trước đó, do đó phản ánh chi phí thực của các phép toán số lượng lớn. Cùng với nhau, những thay đổi này đảm bảo rằng các hoạt động ModExp nhỏ phải trả một khoản phí tối thiểu hợp lý và chi phí của các hoạt động lớn, phức tạp sẽ tăng theo quy mô của chúng.
Đề xuất này xác định 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 nhân hiện sử dụng giá trị mặc định là 16 cho độ dài cơ sở/mô đun lên tới 32 byte, chuyển sang công thức phức tạp hơn 2 × từ² cho đầu vào lớn hơn, trong đó "từ" đề cập đến số khối 8 byte. Số lần lặp cũng đã được cập nhật để số mũ từ 32 byte trở xuống sử dụng độ dài bit của chúng để xác định độ phức tạp, trong khi số mũ lớn hơn 32 byte sẽ thêm mức phạt gas lớn hơn.
Điều này đảm bảo rằng các chỉ số rất lớn, thực sự rất tốn kém về mặt tính toán, giờ đây có chi phí gas cao hơn. Điều quan trọng là chi phí gas tối thiểu được trả về buộc phải là 500 thay vì 200 trước đó, khiến ngay cả những 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 điểm chuẩn cho thấy rằng các bản biên dịch trước ModExp được định giá thấp hơn đá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à gấp nhiều lần đối với các hoạt động lớn hoặc không cân bằng, đôi khi thậm chí còn hơn 80 lần, 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 nguyên tắc hoạt động của ModExp mà là để đảm bảo rằng ngay cả trong những trường hợp tiêu thụ tài nguyên tối đa cực độ, nó sẽ không còn đe dọa đến sự ổn định của mạng hoặc cản trở việc tăng giới hạn gas khối trong tương lai. Do EIP-7883 thay đổi lượng Gas mà ModExp yêu cầu 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 trong Ethereum và được hiểu rõ.
Kết quả thử nghiệm cho thấy chi phí gas tăng là rất đáng kể. Khoảng 99,69% lệnh gọi ModExp lịch sử hiện yêu cầu 500 Gas (trước đây là 200 Gas) hoặc gấp ba lần mức giá trước đó. Nhưng một số trường hợp thử nghiệm tải cao còn thấy phí gas thậm chí còn tăng hơn nữa. Ví dụ: trong một thử nghiệm "chuyên sâu theo cấp số nhân", mức tiêu thụ khí đã tăng từ 215 lên 16.624, tăng khoảng 76 lần, vì số mũ cực lớn hiện có giá hợp lý hơn.
Về mặt bảo mật, đề xuất này sẽ không đưa ra các vectơ tấn công mới cũng như không làm giảm chi phí của bất kỳ tính toán nào. Thay vào đó, nó tập trung vào việc bảo vệ khỏi một rủi ro quan trọng: các hoạt động ModExp được định giá 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ỳ nặng với chi phí rất thấp. Nhược điểm duy nhất có thể xảy ra là một số hoạt động ModExp có thể được định giá quá cao, nhưng điều đó tốt hơn nhiều so với vấn đề hiện tại là bị định giá quá thấp. Đề xuất không đưa ra bất kỳ thay đổi giao diện hoặc chức năng mới nào, vì vậy hành vi số học và vectơ thử nghiệm 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ì không thể dự đoán hoàn toàn lịch trình của những người đề xuất cho kỷ nguyên tiếp theo của mạng. Ngay cả khi hạt giống RANDAO cho kỷ nguyên N+1 được biết đến ở kỷ nguyên 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 dụng (EB) trong kỷ nguyên N.
Những thay đổi EB này có thể đến từ dấu gạch chéo, hình phạt, phần thưởng trên 1 ETH, sáp nhập trình xác thực hoặc 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 trên 32 ETH. Sự không chắc chắn này tạo ra vấ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, chẳng hạn như các giao thức dựa trên xác nhận trước, yêu cầu lịch trình ổn định và có thể dự đoán được để hoạt động trơn tru. Những người xác thực thậm chí có thể cố gắng “quét sạch” hoặc thao túng số dư hiệu dụng của họ để tác động đến những người đề xuất cho kỷ nguyên tiếp theo.
Do những vấn đề này, Ethereum cần một cách để làm cho lịch trình của người đề xuất hoàn toàn mang tính xác định trong một vài kỷ nguyên tiếp theo, để nó không thay đổi do cập nhật EB vào phút cuối và lớp ứng dụng có thể dễ dàng truy cập.
Để đạt được điều này, EIP-7917 giới thiệu cơ chế xem trước người đề xuất xác định giúp tính toán trước và lưu trữ lịch trình của người đề xuất cho MIN_SEED_LOOKAHEAD + 1 kỷ nguyên tiếp theo vào đầu mỗi kỷ nguyên. Nói một cách đơn giản, trạng thái báo hiệu hiện chứa một danh sách có tên `prosoperer_lookahead`, danh sách này luôn bao gồm hai chu kỳ đầy đủ của những người đề xuất (tổng cộng 64 vị trí).
Ví dụ: khi kỷ nguyên N bắt đầu, danh sách đã chứa sẵn những người đề xuất cho mọi vị trí trong kỷ nguyên N và kỷ nguyên N+1. Sau đó, khi mạng bước vào giai đoạn N+1, danh sách sẽ được chuyển tiếp: mục nhập người đề xuất cho giai đoạn N bị xóa, mục nhập cho giai đoạn N+1 được chuyển lên đầu danh sách và mục nhập người đề xuất mới cho giai đoạn N+2 được thêm vào cuối danh sách. Điều này làm cho lịch trình được cố định, có thể dự đoán và có thể đọc được trực tiếp bởi khách hàng mà không cần phải tính toán lại người đề xuất ở từng vị trí.
Để luôn cập nhật, danh sách được 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 đó sẽ bị xóa và một tập hợp chỉ số đề xuất mới cho kỷ nguyên tiếp theo trong tương lai sẽ được tính toán và thêm vào danh sách. Quá trình này sử dụng các quy tắc cân bằng hạt giống và hiệu quả tương tự như trước đây, nhưng bây giờ lịch trình được tính toán sớm hơn, tránh tác động của những thay đổi cân bằng hiệu quả sau khi hạt giống được xác định. Khối đầu tiên sau ngã ba cũng lấp đầy toàn bộ phạm vi xem trước để đảm bảo rằng tất cả các kỷ nguyên trong tương lai đều có lịch trình được khởi tạo hợp lý.
Giả sử có 8 vị trí cho mỗi kỷ nguyên thay vì 32 vị trí (để đơn giản). Nếu không có EIP này, trong kỷ nguyên 5, trong khi bạn biết hạt giống cho kỷ nguyên 6, người đề xuất thực tế của vị trí 2 cho kỷ nguyên 6 vẫn có thể thay đổi nếu người xác nhận bị cắt hoặc nhận đủ phần thưởng để thay đổi số dư hiệu dụng của nó trong kỷ nguyên 5. Với EIP-7917, Ethereum tính toán trước tất cả những người đề xuất cho kỷ nguyên 5, 6 và 7 vào đầu kỷ nguyên 5 và lưu trữ chúng trong `prosopers_lookahead` theo thứ tự. Sau đó, ngay cả khi số dư thay đổi vào cuối 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 sửa lỗi tồn tại lâu dài trong thiết kế chuỗi đèn hiệu. Nó đảm bảo rằng việc lựa chọn trình xác nhận cho các kỷ nguyên trong tương lai không thể thay đổi một khi RANDAO cho kỷ nguyên trước đó có sẵn. Điều này cũng ngăn cản việc "xóa số dư hợp lệ", trong đó người xác thực cố gắng điều chỉnh số dư của họ sau khi nhìn thấy RANDAO để tác động đến danh sách người đề xuất cho kỷ nguyên tiếp theo. Cơ chế xác định trước sẽ loại bỏ toàn bộ vectơ tấn công và đơ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 khách hàng đồng thuận biết trước ai sẽ đề xuất các khối sắp tới, điều này tạo điều kiện thuận lợi cho việc triển khai và cho phép 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 beacon root.
Trước đề xuất này, khách hàng chỉ tính những người đề xuất cho vị trí hiện tại. Với EIP-7917, giờ đây họ tính toán danh sách người đề xuất cho tất cả các vị trí của kỷ nguyên tiếp theo trong một lần trong mỗi lần chuyển đổi kỷ nguyên. Điều này làm tăng thêm một lượng công việc nhỏ, nhưng việc tính toán chỉ mục người đề xuất rất nhẹ và chủ yếu liên quan đến việc lấy mẫu danh sách người xác nhận bằng cách sử dụng hạt giống. Tuy nhiên, khách hàng cần phải được điểm chuẩn để đảm bảo phép tính bổ sung này không gây ra vấn đề về hiệu suất.
EIP-7918: Phí cơ sở blob chịu chi phí thực thi
Ethereum cần đề xuất này vì hệ thống phí blob hiện tại (bắt nguồn từ EIP-4844) bị hỏng khi khí thực thi trở thành chi phí chính của quá trình tổng hợp.
Hiện tại, hầu hết các đợt rollup đều trả phí gas thực thi (chi phí để đưa giao dịch blob vào một khối) 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 tiếp tục giảm phí cơ bản Blob, tổng chi phí của quá trình triển khai không thực sự thay đổi, bởi vì phần đắt nhất vẫn là khí thực thi. Do đó, phí blob cơ sở sẽ tiếp tục giảm cho đến khi đạt đến mức tối thiểu tuyệt đối (1 wei), tại thời điểm đó giao thức không thể sử dụng phí blob để kiểm soát nhu cầu nữa. Sau đó, khi mức sử dụng blob đột ngột tăng đột biến, phải mất nhiều khối để phí blob trở lại mức bình thường. Điều này khiến giá cả không ổn định và khó đoán đối với người dùng.
Ví dụ: giả sử một Rollup muốn xuất bản dữ liệu của mình: nó cần trả khoảng 25.000.000 gwei khí 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ừ khí 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à duy trì ở mức 25.000.000 gwei.
EIP-7918 giải quyết vấn đề này bằng cách đưa ra "giá dự trữ" tối thiểu dựa trên phí cơ sở thực thi, từ đó ngăn giá blob bị định giá thấp và làm cho giá blob của Rollup ổn định hơn và có thể dự đoán được.
Ý 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 mức chi phí gas thực thi nhất định (được gọi là BLOB_BASE_COST). Giá trị của calc_excess_blob_gas() được đặt thành 2¹³, cơ chế này được thực hiện bằng cách thực hiện một sửa đổi nhỏ đối với hàm calc_excess_blob_gas().
Thông thường, chức năng này tăng hoặc giảm phí cơ bản blob dựa trên việc khí 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, chức năng này sẽ ngừng khấu trừ khí blob mục tiêu nếu blob trở nên "quá thấp" so với khí thực thi. Điều này khiến lượng khí 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ằngBLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_BLOB.
Để hiểu tại sao điều này lại cần thiết, chúng ta có thể xem xét các yêu cầu của Blobs. Tổng chi phí tập trung vào tổng chi phí mà nó phải trả: chi phí thực hiện cộng với chi phí blob. If the execution gas cost is very high, say 20 gwei, then even if the blob cost drops from 2 gwei to 0.2 gwei, the total cost will be almost the same. This means that lowering the Blob base fee will have little impact on demand. In economics, this is called "cost inelasticity." It creates a situation where the demand curve is almost vertical: lowering the price does not increase demand.
In this case, the Blob base fee mechanism becomes blind - it will continue to reduce the price even if demand does not respond. This is why blob base charges often drop to 1 gwei. Then, when actual demand increases later, the protocol requires an hour or more of nearly full blocks to bring fees up to reasonable levels. EIP-7918 solves this problem by establishing a reserve price tied to execution gas, ensuring that blob fees still make sense even if execution costs dominate.
Another reason for adding this reserve price is that nodes need to do a lot of extra work to verify the KZG proof of the blob data. These proofs guarantee that the data in Bob matches its promise. Under EIP-4844, nodes only need to verify one proof per blob at a very low cost. But in EIP-7918, the number of proofs that nodes need to verify is larger. This is all because in EIP-7594 (PeerDAS), the blob is divided into many small pieces called cells, and each cell has its own proof, which greatly increases the verification workload.
In the long term, EIP-7918 will also help Ethereum prepare for the future. As technology advances, the cost of storing and sharing data will naturally decrease, and Ethereum is expected to allow the storage of more blobs of data over time. When blob capacity increases, blob fees (in ETH) naturally decrease. The proposal supports this because the reservation price is tied to the execution gas price, rather than a fixed value, so it can adjust as the network grows.
As the blob space and execution block space expand, their price relationship will remain balanced. Only in the rare case where Ethereum significantly increases blob capacity without increasing execution gas capacity, the reserve price may be too high. In this case, the blob charge may end up being higher than needed. But Ethereum has no plans to scale in this way – blob space and execution block space are expected to grow in tandem. Therefore, the chosen value (BLOB_BASE_COST = 2¹³) is considered safe and balanced.
When execution gas costs suddenly spike, there is a small detail that needs to be understood. Since the price of a blob depends on the execution base fee, a sudden increase in execution costs may temporarily put the blob fee into a state dominated by execution costs. For example, suppose the execution gas fee suddenly jumps from 20 gwei to 60 gwei within a block. Since the price of a blob is pegged to this value, the blob fee cannot drop below a new higher level.如果 Blob 仍在被使用，其费用仍会正常增长，但协议不会允许其下降，直到其增长到足以匹配更高的执行成本为止。这意味着在几个区块内，Blob 费用的增长速度可能会慢于执行成本。这种短暂的延迟并无害处——它实际上可以防止 Blob 价格出现剧烈的波动，并使系统更加平稳。
作者还对 2024 年 11 月至 2025 年 3 月的实际区块交易活动进行了实证分析，应用了保留价格规则。在高执行费时期（平均约 16 gwei），与旧机制相比，储备阈值显著提高了区块基础费用。在低执行费时期（平均约 1.3 gwei），区块费用几乎保持不变，除非计算出的区块基础费用低于储备价格。通过比较数千个区块，作者表明，新机制在保持对需求自然响应的同时，还能创造更稳定的定价。四个月的区块费用直方图显示，储备价格防止区块费用暴跌至 1 gwei，从而降低了极端波动。
就安全性而言，此变更也不会引入任何风险。基本区块费用始终会等于或高于执行 Gas 的 BLOB_BASE_COST 单位成本。这是安全的，因为该机制仅提高了最低费用，而设定价格下限不会影响协议的正确性。它只是确保了健康的经济运行。
EIP-7934：RLP 执行区块大小限制
在 EIP-7934 之前，以太坊对 RLP 编码的执行区块的大小没有严格的上限。理论上，如果区块包含大量交易或非常复杂的数据，则其大小可能会非常大。这造成了两个主要问题：网络不稳定和拒绝服务 (DoS) 攻击风险。
如果区块过大，节点下载和验证它所需的时间就会更长，这会减慢区块传播速度并增加区块链临时分叉的可能性。更糟糕的是，攻击者可以故意创建一个非常大的区块来使节点过载，导致延迟甚至使其离线——这是一种典型的拒绝服务攻击。同时，以太坊的共识层（CL）Gossip 协议已经拒绝传播任何超过 10MB 的区块，这意味着过大的执行区块可能无法在网络中传播，从而造成链上的碎片化或节点间的分歧。鉴于这些风险，以太坊需要一条清晰的协议级规则来防止区块过大，并保持网络的稳定和安全。
EIP-7934 通过引入协议级的 RLP 编码执行区块大小上限来解决这个问题。允许的最大区块大小（MAX_BLOCK_SIZE）设置为 10 MiB（10,485,760 字节），但由于信标区块也会占用一些空间（SAFETY_MARGIN），以太坊在此基础上增加了 2 MiB（2,097,152 字节）。
这意味着实际允许的最大 RLP 编码执行块大小为 MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE - SAFETY_MARGIN。如果编码后的块大于此限制，则该块将被视为无效，节点必须拒绝它。有了这条规则，区块生产者必须检查他们构建的每个区块的编码大小，验证者必须在区块验证期间验证此限制。此大小上限独立于 Gas 限制，这意味着即使区块“低于 Gas 限制”，如果其编码大小过大，仍然会被拒绝。这确保了 Gas 使用量和实际字节大小限制都得到遵守。
选择 10 MiB 的上限是有意为之，因为它与共识层 gossip 协议中现有的限制相匹配。 任何大于 10 MiB 的数据都不会在网络中广播，因此此 EIP 使执行层与共识层的限制保持一致。这确保了所有组件的一致性，并防止了由于 CL 拒绝传播而导致有效执行区块“不可见”的情况。
此变更不向下兼容大于新限制的区块，这意味着矿工和验证者必须更新其客户端以遵守该规则。然而，由于超大区块本身就存在问题，且在实际运行中并不常见，因此影响微乎其微。
在安全性方面，EIP-7934 通过确保任何参与者都无法创建会使网络瘫痪的区块，显著增强了以太坊抵御针对特定区块大小的 DoS 攻击的能力。 总而言之，EIP-7934 增加了一条重要的安全边界，提高了稳定性，统一了执行逻辑 (EL) 和 CL 的行为，并防止了与超大区块的创建和传播相关的多种攻击。
EIP-7939：计算前导零 (CLZ) 操作码
在此 EIP 之前，以太坊没有内置的操作码来计算 256 位数字中前导零的位数。开发者不得不使用 Solidity 手动实现 CLZ 函数，这需要大量的位移操作和比较。
这是一个很大的问题，因为自定义实现速度慢、成本高，而且会占用大量字节码，从而增加 Gas 消耗。对于零知识证明系统来说，成本更高，右移操作的证明成本极高，因此像 CLZ 这样的操作会显著降低零知识证明电路的运行速度。由于 CLZ 是一个非常常见的底层函数，广泛应用于数学库、压缩算法、位图、签名方案以及许多加密或数据处理任务中，以太坊需要一种更快、更经济的计算方法。
EIP-7939 通过引入一个名为 CLZ (0x1e) 的新操作码解决了这个问题。该操作码从栈中读取一个 256 位的值，并返回前导零的个数。如果输入数字为零，则操作码返回 256，因为一个 256 位的零有 256 个前导零。
这与 ARM 和 x86 等许多 CPU 架构中 CLZ 的工作方式一致，在这些架构中，CLZ 操作是原生支持的。添加 CLZ 可以显著降低许多算法的开销：lnWad、powWad、LambertW、各种数学函数、字节串比较、位图扫描、调用数据压缩/解压缩以及后量子签名方案等操作都能受益于更快的先行零检测。
CLZ 的 gas 成本设置为 5，与 ADD 类似，并且略高于之前的 MUL 价格，以避免定价过低而导致拒绝服务 (DoS) 攻击的风险。基准测试表明，CLZ 的计算量与 ADD 大致相同，并且在 SP1 rv32im 证明环境中，CLZ 的证明成本实际上比 ADD 更低，从而降低了零知识证明的成本。
EIP-7939 完全向后兼容，因为它引入了一个新的操作码，并且没有修改任何现有行为。
总体而言，EIP-7939 通过添加一个现代 CPU 已支持的简单高效的原语，使以太坊运行速度更快、成本更低，并且对开发者更加友好——降低 Gas 费用、减小字节码大小，并降低许多常见操作的零知识证明成本。
EIP-7951：支持现代硬件的签名
在此 EIP 之前，以太坊没有安全、原生的方式来验证使用 secp256r1 (P-256) 曲线创建的数字签名。
该曲线是 Apple Secure Enclave、Android Keystore、HSM、TEE 和 FIDO2/WebAuthn 安全密钥等现代设备使用的标准。由于缺少这种支持，应用程序和钱包无法轻松地使用设备级硬件安全进行签名。此前曾有过一次尝试 (RIP-7212)，但它存在两个严重的安全漏洞，分别与无穷远点处理和错误的签名比较有关。这些问题可能导致验证错误，甚至可能导致共识失败。 EIP-7951 修复了这些安全问题，并引入了一个安全、原生的预编译程序，使以太坊最终能够安全高效地支持来自现代硬件的签名。
EIP-7951 在地址 0x100 处添加了一个名为 P256VERIFY 的新预编译合约，该合约使用 secp256r1 曲线执行 ECDSA 签名验证。与直接在 Solidity 中实现该算法相比，这使得签名验证更加快速且成本更低。
EIP-7951还定义了严格的输入验证规则。如果存在任何无效情况，预编译将返回失败，且不会回滚，消耗的 Gas 与成功调用相同。验证算法遵循标准的 ECDSA：它计算 s⁻¹ mod n，重建签名点 R'，如果 R' 为无穷远则拒绝，最后检查 R' 的 x 坐标是否与 r (mod n) 匹配。这修正了 RIP-7212 中的错误，RIP-7212 直接比较了 r'，而不是先将其模 n 化简。
该操作的 Gas 费用设定为 6900 gas，高于 RIP-7212 版本，但与 secp256r1 验证的实际性能基准相符。重要的是，该接口与已部署 RIP-7212 的 Layer 2 网络完全兼容（地址相同，输入/输出格式相同），因此现有的智能合约将继续正常运行，无需任何更改。唯一的区别在于修正后的行为和更高的 Gas 费用。
从安全角度来看，EIP-7951 恢复了 ECDSA 的正确行为，消除了预编译级别的可塑性问题（将可选检查留给应用程序），并明确指出预编译不需要恒定时间执行。 secp256r1 曲线提供 128 位安全性，并已获得广泛的信任和分析，因此可安全应用于以太坊。
简而言之，EIP-7951 旨在安全地将现代硬件支持的身份验证引入以太坊，修复早期提案的安全问题，并提供一种可靠、标准化的方式来验证整个生态系统中的 P-256 签名。
总结
下表总结了哪些以太坊客户端需要针对不同的 Fusaka EIP 进行更改。共识客户端下的勾选标记表示该 EIP 需要更新共识层客户端，而执行客户端下的勾选标记则表示该升级影响执行层客户端。某些 EIP 需要同时更新共识层和执行层，而其他 EIP 则仅需更新其中一层。
总而言之，以上就是包含在Fusaka 硬分叉中的关键 EIP。虽然此次升级涉及共识和执行客户端的多项改进，从 Gas 调整和操作码更新再到新的预编译，但此次升级的核心还是 PeerDAS，它引入了点对点数据可用性采样，从而能够更高效、更去中心化地处理整个网络中的 Blob 数据。