Giới thiệu về Ethereum Pectra Hard Fork

Tác giả: NIC Lin, Medium

Dự kiến ​​hard fork Pectra sẽ triển khai mạng chính vào tháng 3 năm 2025. Bản nâng cấp Pectra bao gồm 11 giao thức kỹ thuật (EIP), đó là:

• EIP-2537: Biên dịch trước hoạt động đường cong BLS12-381

• EIP-2935: Lưu các giá trị băm khối lịch sử trong Trạng thái

• EIP-6110: Cung cấp tiền gửi xác thực trên chuỗi

• EIP-7002: Thoát kích hoạt lớp thực thi

• EIP-7251: Tăng MAX_EFFECTIVE_BALANCE

• EIP-7549: Di chuyển chỉ mục ủy ban ra khỏi xác thực

• EIP-7623: Tăng chi phí dữ liệu cuộc gọi

• EIP-7685: Yêu cầu lớp thực thi chung

• EIP-7691: Tăng thông lượng Blob

• EIP-7702: Đặt mã tài khoản EOA

• EIP-7840: Thêm kế hoạch Blob vào hồ sơ EL

Các giao thức kỹ thuật liên quan đến Staking

EIP-6110: Biên dịch trước hoạt động đường cong BLS12-381

Đơn giản hóa quy trình để người dùng tham gia đặt cược và rút ngắn đáng kể thời gian chờ đợi.

Cách để người dùng tham gia staking là gửi 32 ETH vào lớp thực thi và ghi lại trong nhật ký sự kiện. Sau đó, lớp đồng thuận sẽ phân tích nhật ký sự kiện để xác định xem có ai tham gia staking hay không, và sau đó những người dùng tham gia staking sẽ trở thành người xác thực.

Tuy nhiên, các trình xác thực ở lớp đồng thuận trước tiên cần đạt được sự đồng thuận về thời điểm thực hiện khoản tiền gửi. Nếu không, sẽ thấy rằng một số trình xác thực thấy 5 khoản tiền gửi mới, trong khi một số trình xác thực chỉ thấy 3. Do đó, các trình xác thực ở lớp đồng thuận sẽ bỏ phiếu về khối lớp thực thi nào (eth1data) để tham chiếu nhằm đảm bảo rằng mọi người đều thấy cùng một khối lớp thực thi.

Tuy nhiên, để tránh các lỗi lớn trong lớp thực thi có thể dẫn đến các nhánh chuỗi, khối lớp thực thi tham chiếu (eth1data) là khối lớp thực thi từ khoảng 10 giờ trước, đảm bảo rằng khi xảy ra lỗi lớn, các nhà phát triển của lớp đồng thuận có đủ thời gian để phản hồi. Tuy nhiên, điều này cũng có nghĩa là phải mất ít nhất 10 giờ để việc tham gia staking có hiệu lực.

△ 10900000 eth1data trong khối CL, Block Hash được ghi lại trong đó là khối lớp thực thi 21683339, xuất hiện trước nó 10 giờ.

Sau khi thực hiện giao thức kỹ thuật EIP-6110, thông tin cam kết của người dùng trên hợp đồng sẽ trực tiếp trở thành một phần của lớp thực hiện. Vì bản thân khối lớp đồng thuận sẽ chứa khối lớp thực hiện (nhưng không phải eth1data), nên những người xác thực lớp đồng thuận không còn cần phải xem xét vấn đề "xác nhận rằng khối bộ nhớ lớp thực hiện tham chiếu là giống nhau". Miễn là khối bộ nhớ lớp đồng thuận được hơn hai phần ba số người xác thực bỏ phiếu và xác nhận, thì mọi người sẽ đạt được sự đồng thuận rằng họ đang thấy cùng một khối lớp thực hiện. Do đó, sau khi người dùng tham gia staking, lời cam kết sẽ có hiệu lực chỉ sau 13 phút kể từ khi khối bộ nhớ lớp thực thi được xử lý và máy khách lớp đồng thuận cũng có thể loại bỏ logic phức tạp ban đầu được sử dụng để xử lý dữ liệu staking.

EIP-7002: Lưu các giá trị băm khối lịch sử trong Trạng thái

Có thể được sử dụng để cải thiện quy trình người xác thực thoát khỏi việc đặt cược hoặc rút tiền gửi và thu nhập, đồng thời giảm rủi ro cho người xác thực.

Để tham gia staking, bạn cần có hai khóa, đó là Khóa xác thực và Thông tin xác thực rút tiền.

Khóa xác thực được sử dụng cho nội dung công việc của trình xác thực và Chứng chỉ rút tiền được sử dụng cho địa chỉ nơi tiền gửi và thu nhập sẽ được rút khi trình xác thực thoát khỏi cam kết. Ngoài ra, Khóa xác thực phải được sử dụng để thoát khỏi cam kết tại thời điểm hiện tại.

Nếu bạn mất Khóa xác thực, bạn sẽ không thể thực hiện công việc xác thực và sẽ không thể rút tiền khỏi staking; nếu bạn mất Thông tin xác thực rút tiền, bạn sẽ mất tất cả tiền gửi và thu nhập của mình. Ngoài ra, một số người dùng sẽ sử dụng dịch vụ staking của bên thứ ba như Lido. Khi sử dụng các nền tảng này, người dùng cần tự giữ Withdrawal Credential, trong khi Validator Key được nhà cung cấp dịch vụ giữ và thực hiện công việc của trình xác thực thay mặt cho họ.

Bằng cách thực hiện giao thức kỹ thuật EIP-7002, người dùng có thể sử dụng Chứng chỉ rút tiền để gọi "Hợp đồng rút tiền" (được triển khai tại 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) để thoát khỏi staking (Thoát) hoặc rút tiền gửi và thu nhập (Rút một phần), điều này có thể giảm thiểu rủi ro liên quan đến việc sử dụng dịch vụ staking của bên thứ ba. Nếu người dùng tự mình tham gia staking nhưng làm mất Khóa xác thực, họ cũng có thể sử dụng khóa này để rút khỏi staking.

• Các tham số để khởi tạo yêu cầu bao gồm validator_pubkey và amount: validator_pubkey là Khóa xác thực (công khai) của trình xác thực và amount là số tiền cần rút.

• Thông tin xác thực rút tiền khởi tạo yêu cầu phải là Thông tin xác thực rút tiền của trình xác minh validator_pubkey.

• Khi gọi hợp đồng Rút tiền để khởi tạo yêu cầu, phí Gas (ETH) phải được đính kèm. Phí Gas sẽ được tính dựa trên số lượng yêu cầu rút tiền hiện tại. Nếu số lượng yêu cầu lớn, phí Gas sẽ tăng lên.

• Nếu Thông tin xác thực rút tiền của người dùng là hợp đồng, thì trước tiên bạn có thể đến hợp đồng Rút tiền để lấy số tiền phí hiện tại, sau đó khởi tạo yêu cầu và đính kèm phí; nhưng nếu Thông tin xác thực rút tiền là tài khoản EOA, thì không có cách nào để lấy được phí chính xác và bạn chỉ có thể mô phỏng trước ngoài chuỗi và trả phí vượt mức (sẽ không được hoàn lại) để đảm bảo rằng yêu cầu sẽ được thực hiện thành công.

Lưu ý: Nếu Thông tin rút tiền của bạn vẫn ở định dạng khóa công khai BLS, hãy nhớ chuyển sang định dạng địa chỉ EL trước.

EIP-7251: Tăng MAX_EFFECTIVE_BALANCE

Nó có thể tăng đáng kể giới hạn trên của số tiền đặt cược để giảm số lượng người xác thực và những người xác thực chưa đạt đến giới hạn trên có thể tự động hưởng thu nhập từ việc đặt cược.

Người dùng cam kết trở thành người xác thực phải cung cấp số lượng MAX_EFFECTIVE_BALANCE ETH, không ít hơn và không nhiều hơn (hiện tại MAX_EFFECTIVE_BALANCE là 32 ETH). Nếu người dùng nắm giữ 1024 ETH để đặt cược, họ có thể tham gia đặt cược 32 lần, kích hoạt 32 trình xác thực và chạy 32 nút xác thực. Sự tham gia tích cực của mọi người vào việc staking cũng dẫn đến số lượng người xác thực hiện tại vào khoảng 1 triệu và tiếp tục tăng. Ngoài việc làm cho dữ liệu trạng thái của lớp đồng thuận lớn hơn và nhiều hơn, tải trên lớp mạng p2p của lớp đồng thuận còn đáng kể hơn, vì mỗi khe (mỗi 12 giây) có hàng chục nghìn chữ ký của người xác thực cần được truyền liên tục và tổng hợp trong lớp mạng p2p.

Sau khi thực hiện thỏa thuận kỹ thuật EIP-7251, giới hạn staking thấp hơn (MIN_ACTIVATION_BALANCE) vẫn sẽ là 32 ETH, nhưng giới hạn trên (MAX_EFFECTIVE_BALANCE) sẽ tăng đáng kể lên 2048 ETH. Bạn có thể staking bất kỳ số lượng ETH nào trong khoảng từ 32 đến 2048 và bạn có thể nhận được thu nhập staking. Bạn không cần phải rút thu nhập thường xuyên nữa. Bạn có thể tiếp tục staking ETH mới sau khi tích lũy được 32 ETH.

Hiện tại, các trình xác thực hiện tại không cần phải rút tiền cược của họ trước rồi mới hợp nhất chúng lại với nhau để tham gia lại tiền cược. Thay vào đó, họ có thể trực tiếp sử dụng "hợp đồng hợp nhất tiền gửi" mới được thêm vào trên lớp thực thi (được triển khai tại 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) và Withdrawal Crendential của trình xác thực sẽ gọi hợp đồng để khởi tạo yêu cầu hợp nhất tiền gửi.

• Các tham số của yêu cầu gửi tiền được hợp nhất bao gồm source_pubkey và target_pubkey: hai khóa này là khóa xác thực của trình xác thực và trình xác thực nguồn sẽ được hợp nhất vào trình xác thực đích.

• Thông tin xác thực rút tiền khởi tạo yêu cầu phải là Thông tin xác thực rút tiền của bên xác minh nguồn.

• Khi gọi hợp đồng ký quỹ hợp nhất để khởi tạo yêu cầu, phải đính kèm phí xử lý (ETH). Phí xử lý sẽ được tính dựa trên số lượng yêu cầu hiện tại. Nếu số lượng yêu cầu lớn, phí xử lý sẽ tăng lên.

• Nếu Chứng chỉ rút tiền của người dùng là hợp đồng, thì trước tiên bạn có thể gọi hợp đồng gửi tiền kết hợp để lấy số tiền phí hiện tại, sau đó khởi tạo yêu cầu và đính kèm phí; nhưng nếu Chứng chỉ rút tiền là tài khoản EOA, thì không có cách nào để lấy được phí chính xác và bạn chỉ có thể mô phỏng trước ngoài chuỗi và trả phí vượt mức (sẽ không được hoàn lại) để đảm bảo rằng yêu cầu sẽ được thực hiện thành công.

Lưu ý: Nếu Thông tin rút tiền của bạn ở định dạng khóa công khai BLS, trước tiên bạn cần chuyển nó sang định dạng địa chỉ EL.

EIP-7685: Yêu cầu lớp thực thi chung

Thiết lập đường truyền thông tin EL -> CL chính thức để tạo điều kiện cho người dùng và dịch vụ đặt cược gửi yêu cầu trực tiếp đến lớp đồng thuận.

Người dùng có thể gửi yêu cầu trực tiếp từ lớp thực thi đến lớp đồng thuận, cho phép các dịch vụ đặt cược (như Lido) hoạt động theo cách phi tập trung hơn. Ví dụ: yêu cầu EIP-7002 đã đề cập trước đó để thoát khỏi việc đặt cược và yêu cầu EIP-7251 để hợp nhất các khoản tiền gửi. Nếu không có giao thức kỹ thuật này, người dùng Lido phải tin tưởng rằng nhà cung cấp dịch vụ nút Lido sẽ thực hiện trung thực việc thoát khỏi thế chấp hoặc sáp nhập tiền gửi tại lớp đồng thuận; với giao thức kỹ thuật này, người dùng Lido có thể gửi yêu cầu trực tiếp thông qua hợp đồng quản trị tại lớp thực hiện.

Những yêu cầu này sẽ có Request Type để phân biệt các loại yêu cầu khác nhau và khởi tạo yêu cầu thông qua các hợp đồng khác nhau. Cuối cùng, những yêu cầu này sẽ được ghi vào khối bộ nhớ của lớp thực thi, do đó lớp đồng thuận có thể trực tiếp lấy thông tin này thông qua khối bộ nhớ của lớp thực thi mà không cần phải viết logic phân tích riêng lẻ.

EIP-6110, EIP-7002 và EIP-7251 đều xây dựng các yêu cầu dựa trên các tiêu chuẩn do EIP-7685 xác định:

• EIP-6110 thêm một yêu cầu cam kết: Request Type=0 và khởi tạo một yêu cầu thông qua hợp đồng ký quỹ

  (0x00000000219ab540356cbb839cbe05303d7705fa).

• Yêu cầu rút tiền đặt cược EIP-7002: Loại yêu cầu=1, khởi tạo yêu cầu thông qua hợp đồng Rút tiền

  (0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA).

• Yêu cầu gửi tiền hợp nhất EIP-7251: Loại yêu cầu=2, khởi tạo yêu cầu thông qua hợp đồng hợp nhất

  (0x00431F263cE400f4455c2dCf564e53007Ca4bbBb).

Thỏa thuận kỹ thuật để cải thiện trải nghiệm của người dùng

EIP-7702: Đặt mã tài khoản EOA

Cho phép chuyển đổi tài khoản EOA thành tài khoản hợp đồng theo ý muốn, cải thiện đáng kể trải nghiệm của người dùng.

Tài khoản EOA có một số nhược điểm khi sử dụng, bao gồm:

• Cần phải ghi lại và lưu giữ khóa riêng hoặc ký hiệu ghi nhớ, và ngưỡng để người dùng mới đăng ký và sử dụng tương đối cao.

• Một tài khoản EOA chỉ có thể thực hiện một thao tác trong một giao dịch. Ví dụ, nếu bạn muốn đổi USDT lấy ETH trên Uniswap, trước tiên bạn phải khởi tạo một giao dịch để chấp thuận USDT, sau đó gửi một giao dịch khác để thực hiện trao đổi.

• Không thể kiểm soát quyền chi tiết, chẳng hạn như chuyển giao một số hoạt động của tài khoản cho bên thứ ba. Người dùng phải tự mình xử lý mọi công việc và ký và phát hành giao dịch cho mỗi hoạt động.

• Không có cơ chế phục hồi và bạn chỉ có thể giữ khóa riêng hoặc cụm từ ghi nhớ của mình. Nếu bạn làm mất chúng, bạn sẽ không bao giờ lấy lại được tài sản của mình.

Nếu là tài khoản hợp đồng thông minh (như Safe), các vấn đề trên có thể được giải quyết:

• Người dùng có thể sử dụng khóa riêng trong chip bảo mật của điện thoại di động (hoặc máy tính) để ký và ủy quyền mà không cần phải nhớ bất kỳ khóa riêng hoặc mã ghi nhớ nào, hoặc sử dụng email để ký và ủy quyền hoặc nhiều phương pháp ủy quyền khác.

• Nhiều hoạt động có thể được gộp lại với nhau và thực hiện cùng nhau trong cùng một giao dịch. Các hoạt động DApp phức tạp ban đầu có thể được hoàn thành chỉ với một xác thực chữ ký và một giao dịch.

• Có thể có kiểm soát quyền rất chi tiết. Người dùng có thể ủy quyền cho bên thứ ba kiểm soát tài khoản của riêng họ, nhưng đồng thời chỉ định các hạn chế như "có thể tương tác với hợp đồng nào", "không thể thực hiện hoạt động nào", "có thể sử dụng bao nhiêu tài sản để chuyển nhượng tài sản" hoặc "có thể thực hiện bao nhiêu hoạt động mỗi tuần".

• Có thể thêm cơ chế phục hồi để khi bạn mất cụm từ ghi nhớ, số điện thoại di động hoặc email, bạn có thể chuyển tài sản tài khoản sang tài khoản mới thông qua cơ chế phục hồi.

Đề xuất EIP-7702 là cung cấp cho các tài khoản EOA khả năng chuyển đổi thành tài khoản hợp đồng. Người dùng ký tin nhắn đã chuyển đổi bằng khóa riêng EOA. Nội dung chữ ký bao gồm "ID chuỗi", "địa chỉ hợp đồng đã chuyển đổi" và "giá trị Nonce EOA":

• ID chuỗi: được sử dụng để ngăn chữ ký của chuỗi A được chuyển đến chuỗi B để phát lại. Tuy nhiên, nếu Chain ID bằng 0, điều đó có nghĩa là bạn sẵn sàng chuyển đổi trên mọi chuỗi.

• Địa chỉ hợp đồng bạn muốn thay đổi thành: Nếu bạn điền địa chỉ hợp đồng An toàn, tài khoản EOA của bạn sẽ trở thành hợp đồng An toàn; nếu bạn điền địa chỉ trống (địa chỉ(0)), điều đó có nghĩa là bạn muốn hủy thay đổi và đổi lại thành tài khoản EOA đơn giản.

• Giá trị Nonce EOA: được sử dụng để ngăn chặn chữ ký bị phát lại. Nếu giá trị Nonce tăng lên, chữ ký gốc sẽ không còn hợp lệ.

Tuy nhiên, có một số điểm cần lưu ý:

1. Khóa riêng EOA vẫn có thể tiếp tục được sử dụng

Ngay cả khi tài khoản EOA của người dùng trở thành hợp đồng, họ vẫn có thể tiếp tục sử dụng nó theo cùng một cách như tài khoản EOA ban đầu. Ví dụ, nếu tài khoản EOA của bạn trở thành hợp đồng An toàn, bạn có thể sử dụng giao diện An toàn và làm theo quy trình giao dịch An toàn hoặc bạn có thể tiếp tục ký và gửi giao dịch bằng ví EOA ban đầu. Tuy nhiên, điều này cũng có nghĩa là tính bảo mật của tài khoản vẫn bị giới hạn ở khóa riêng.

2. Vẫn là tính bảo mật của khóa riêng EOA

Ngay cả khi EOA của người dùng trở thành đa chữ ký, miễn là người dùng không làm mất khóa riêng EOA thì tính bảo mật của tài khoản của người dùng sẽ luôn là tính bảo mật của khóa riêng EOA: người dùng vẫn cần phải giữ khóa riêng hoặc cụm từ ghi nhớ của mình tốt và tài khoản của người dùng sẽ không trở nên an toàn như đa chữ ký.

3. Lưu trữ tài khoản EOA sẽ không được định dạng

Khi tài khoản EOA được chuyển đổi thành hợp đồng và ghi dữ liệu vào Storage của nó, trừ khi dữ liệu được xóa một cách rõ ràng, dữ liệu được ghi vào Storage sẽ không được định dạng vì tài khoản EOA được chuyển đổi thành hợp đồng khác hoặc quá trình chuyển đổi bị hủy bỏ. Do đó, các nhà phát triển nên chú ý đến Storage không đọc dữ liệu còn lại của hợp đồng chuyển đổi trước đó. Vui lòng tham khảo ERC-7201.

4. Quy trình EIP-7702 không bao gồm khởi tạo

Nói chung, tài khoản hợp đồng yêu cầu một bước khởi tạo để ghi đồng bộ thông tin của chủ tài khoản (như khóa công khai hoặc địa chỉ) khi tài khoản được triển khai để tránh bước triển khai bị chạy trước và gây mất quyền sở hữu tài khoản. Điều này thường được thực hiện bởi hợp đồng Factory triển khai tài khoản hợp đồng để thực hiện "triển khai + khởi tạo", nhưng vì EIP-7702 là một thay đổi trực tiếp, thay vì Factory triển khai hợp đồng cho EOA, kẻ tấn công có thể sao chép chữ ký chuyển đổi của người dùng và gửi giao dịch đến chuỗi để chuyển đổi người dùng nhưng khởi tạo tài khoản để kẻ tấn công có thể kiểm soát, do đó các nhà phát triển cần chú ý đến EIP-7702. Các phương pháp phòng ngừa khả thi bao gồm kiểm tra chữ ký của tài khoản EOA trong hàm khởi tạo, do đó, ngay cả khi bị chiếm dụng, kẻ tấn công sẽ không thể tạo chữ ký của tài khoản EOA để hoàn tất quá trình khởi tạo.

5. Ví phải kiểm tra yêu cầu thay đổi

Ví phải kiểm tra người dùng. Khi một trang web DApp độc hại yêu cầu người dùng ký một giao dịch đã thay đổi, yêu cầu đó phải bị chặn và người dùng phải được cảnh báo. Nếu không, nếu người dùng ký một giao dịch đã thay đổi độc hại, tài sản sẽ bị chuyển đi ngay lập tức. Sau đây là một số ví dụ về việc triển khai hợp đồng đã chuyển đổi:

• Tài khoản Ithaca an toàn đã sửa đổi

• Tài khoản Ithaca

Giao thức công nghệ DApp

EIP-2537: Biên dịch trước hoạt động đường cong BLS12-381

Giảm chi phí cho các ứng dụng chứng minh không kiến ​​thức dựa trên đường cong BLS và làm cho nó khả thi hơn.

EIP-2537 bổ sung một số hợp đồng được biên dịch trước (Biên dịch trước) để cung cấp các hoạt động đường cong BLS giá rẻ, giúp việc phát triển các ứng dụng chứng minh không cần kiến ​​thức dựa trên đường cong BLS khả thi hơn.

EIP-2935: Lưu giá trị băm khối lịch sử trong Trạng thái

Cho phép các nhà phát triển hoặc các nút đọc giá trị băm (Block Hash) của các khối bộ nhớ trước đó trực tiếp từ Bộ lưu trữ của hợp đồng hệ thống.

Nếu nhà phát triển cần chứng minh nội dung của một khối bộ nhớ trước đó, ví dụ, trong thử thách gian lận Optimismtic Rollup, thì cần phải chứng minh rằng một giao dịch nhất định đã tồn tại trong 1.000 khối bộ nhớ trước đó. Người thách thức không thể nói trực tiếp.

“Xin hãy tin tôi rằng giao dịch này thực sự đã tồn tại cách đây 1000 khối bộ nhớ”, anh ta phải đưa ra bằng chứng, nhưng không có bằng chứng trực tiếp nào chứng minh trực tiếp rằng “khối bộ nhớ 1000 năm trước chứa những nội dung này”, vì vậy anh ta phải sử dụng phương pháp “chuỗi” khối bộ nhớ, từng khối bộ nhớ một, để chứng minh cho đến khi anh ta đạt đến khối bộ nhớ 1000 năm trước, và sau đó chứng minh rằng giao dịch tồn tại trong khối bộ nhớ đó.

△ Mỗi khối trỏ đến một khối cha, do đó bất kỳ khối nào trong lịch sử đều có thể được chứng minh cho đến tận tương lai.

Giả sử rằng khối bộ nhớ hiện tại được đánh số 10000 và thử thách gian lận yêu cầu bằng chứng cho thấy một giao dịch X nhất định tồn tại trong khối bộ nhớ được đánh số 9000. Bên thách thức cần bắt đầu từ giá trị băm của khối bộ nhớ 10000, trước tiên chứng minh giá trị băm của khối bộ nhớ cha 9999 mà khối bộ nhớ 10000 được kết nối, sau đó chứng minh khối bộ nhớ 9998... cho đến khối bộ nhớ 9000 và cuối cùng đề xuất rằng nội dung của khối bộ nhớ 9000 chứa giao dịch X.

Sau EIP-2935, sẽ có một hợp đồng hệ thống (được triển khai tại 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC), trong đó Storage sẽ lưu trữ các giá trị băm của tối đa 8192 khối bộ nhớ trước đó. Bất cứ khi nào một khối bộ nhớ mới được tạo ra, hợp đồng hệ thống sẽ tự động cập nhật và ghi giá trị băm của khối bộ nhớ trước đó vào hợp đồng hệ thống (giá trị băm của 8192 khối bộ nhớ trước đó sẽ bị ghi đè).

Theo cách này, trong ví dụ về thử thách gian lận Optimismtic Rollup, người thách thức không phải chứng minh từng khối bộ nhớ một, mà có thể chứng minh trực tiếp rằng ở trạng thái hiện tại của chuỗi khối bộ nhớ 10000, giá trị của một Lưu trữ nhất định của hợp đồng hệ thống (tương ứng với khối bộ nhớ 9000) chính là giá trị băm của khối bộ nhớ 9000. Nếu phạm vi vượt quá 8192, chẳng hạn như khối bộ nhớ 1000, thì nhiều nhất chỉ có thêm một bước nữa, đầu tiên là chứng minh giá trị băm của khối bộ nhớ 1808 (= 10000 - 8192), sau đó chứng minh giá trị băm của khối bộ nhớ 1000 trong hợp đồng hệ thống ở trạng thái chuỗi hiện tại của khối bộ nhớ 1808.

Điều này cũng mở đường cho các máy khách không trạng thái trong tương lai: các nút ánh sáng trong tương lai sẽ không còn cần phải lưu trữ tất cả các tiêu đề khối trong lịch sử. Thay vào đó, khi cần giá trị băm hoặc nội dung của một khối bộ nhớ nhất định trong lịch sử, những nút khác có thể cung cấp bằng chứng bằng phương pháp bằng chứng trong ví dụ về thử thách gian lận trước đó.

EIP-7623: Tăng chi phí calldata

Tăng chi phí xuất bản dữ liệu bằng calldata để tạo đủ không gian an toàn nhằm tăng Giới hạn khí khối và số lượng blob.

Khi nhu cầu xuất bản dữ liệu Rollup ngày càng cao, sau khi Blob được giới thiệu trong EIP-4844 để cho phép Rollup xuất bản dữ liệu theo cách rất rẻ, việc tăng số lượng Blobs luôn là một bản nâng cấp mà cộng đồng mong đợi. Hoặc, giống như chương trình khuyến mãi gần đây của cộng đồng nhằm tăng Block Gas Limit, nó phản ánh nhu cầu của hệ sinh thái về việc tăng thêm tài nguyên.

△ Ngày càng có nhiều người xác thực bày tỏ sự ủng hộ đối với việc tăng Giới hạn khí khối.

Tuy nhiên, cho dù Block Gas Limit hay số lượng blob tăng lên thì cũng sẽ gây thêm áp lực lên mạng lưới p2p của Ethereum vì lượng dữ liệu giao dịch tăng lên, điều này sẽ làm tăng hiệu quả tấn công của kẻ tấn công, trừ khi chi phí công bố dữ liệu cũng tăng lên.

Sau khi phát hành giao thức EIP-7623, chi phí dữ liệu cuộc gọi sẽ tăng 2,5 lần từ "Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas" ban đầu thành "Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas".

Ban đầu, nếu kẻ tấn công sử dụng toàn bộ Giới hạn khí khối (30M) để lưu trữ dữ liệu rác, kích thước dữ liệu của khối bộ nhớ sẽ là khoảng 1,79 MB (30M / 16), so với kích thước khối bộ nhớ trung bình chỉ khoảng 100 KB; và nếu Giới hạn khí khối được nâng lên 40M, kẻ tấn công có thể tạo ra khối bộ nhớ khoảng 2,38 MB. Khi chi phí calldata tăng lên 2,5 lần, hiệu quả của kẻ tấn công sẽ giảm xuống mức tối đa là 0,72MB cho 30M và 0,95MB cho 40M, do đó có thể tăng Giới hạn khí khối và số lượng Blob với độ tin cậy cao hơn. Tuy nhiên, giao thức kỹ thuật này không muốn ảnh hưởng đến người dùng thông thường "không sử dụng calldata để xuất bản dữ liệu", do đó, nó sẽ tính toán tổng lượng Gas sử dụng của giao dịch theo hai cách và lấy cách cao hơn:

1. Phương pháp tính toán lượng Gas sử dụng giao dịch ban đầu được kết hợp với chi phí calldata cũ: nghĩa là calldata được tính là "Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas", sau đó cộng thêm Gas tiêu thụ khi thực hiện giao dịch và Gas tiêu thụ khi triển khai hợp đồng.

2. Chỉ cần tính toán mức sử dụng Gas calldata, nhưng sử dụng chi phí mới: nghĩa là tính toán calldata là "Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas", nhưng không bao gồm Gas tiêu thụ khi thực hiện hoặc Gas tiêu thụ khi triển khai hợp đồng. Do đó, đối với những người dùng "không sử dụng calldata để xuất bản dữ liệu" (chẳng hạn như trao đổi trên Uniswap), mức tiêu thụ Gas chính nằm ở phần thực hiện. Ngay cả khi calldata được tính toán theo chi phí mới, nó sẽ không vượt quá Gas tiêu thụ khi thực hiện, do đó người dùng nói chung sẽ không bị ảnh hưởng.

Những Rollup thực sự bị ảnh hưởng là Rollup quy mô nhỏ, vì Blob có kích thước cố định và phí cố định, do đó Rollup nhỏ sử dụng Blob không hiệu quả và sử dụng calldata tiết kiệm chi phí hơn. Tuy nhiên, sau EIP-7623, chi phí của Rollup nhỏ này sẽ tăng gấp 2,5 lần, do đó họ có thể phải chuyển sang sử dụng Blob hoặc tìm cách hợp nhất để chia sẻ Blob.

EIP-7691: Tăng thông lượng Blob

Tăng số lượng blob và thêm không gian để xuất bản dữ liệu lên Rollup.

EIP-7691 tăng số lượng blob từ "mục tiêu: 3 blob, giới hạn trên: 6 blob" thành "mục tiêu: 6 blob, giới hạn trên: 9 blob", thêm nhiều không gian hơn để xuất bản dữ liệu lên Rollup.

Lưu ý: Ngoài ra, còn một số thiết kế trong thị trường phí Blob cần được tinh chỉnh, chẳng hạn như tốc độ điều chỉnh phí chưa đủ nhanh và mức phí sàn quá thấp, nhưng đây không phải là vấn đề mà giao thức kỹ thuật này hướng tới giải quyết.

Các giao thức kỹ thuật khác

EIP-7549: Di chuyển chỉ mục ủy ban ra khỏi phạm vi xác minh

Điều chỉnh nội dung phiếu bầu của người xác thực để dễ tổng hợp phiếu bầu hơn và giảm áp lực lên mạng ngang hàng.

Trong mỗi Epoch, các trình xác thực sẽ được phân công ngẫu nhiên vào một nhóm ủy ban và bỏ phiếu cho các khối bộ nhớ. Các phiếu bầu của các trình xác thực trong mỗi ủy ban có thể được tổng hợp lại với nhau, điều này có thể làm giảm số lượng phiếu bầu được truyền trong mạng p2p. Tuy nhiên, phiếu bầu của trình xác thực sẽ chứa thông tin về "trình xác thực thuộc ủy ban nào", điều này có nghĩa là các phiếu bầu của các ủy ban khác nhau không thể được tổng hợp lại với nhau, ngay cả khi tất cả chúng đều bỏ phiếu cho cùng một khối bộ nhớ.

EIP-7549 xóa thông tin "người xác thực thuộc ủy ban nào" khỏi nội dung bỏ phiếu, do đó, những người xác thực từ các ủy ban khác nhau có thể được tổng hợp lại với nhau khi nội dung bỏ phiếu giống nhau, qua đó giúp giảm thêm số lượng phiếu bầu được truyền trong mạng p2p và giảm áp lực lên mạng p2p.

EIP-7840: Thêm kế hoạch Blob vào tệp cấu hình EL

Tạo tệp cấu hình cho các tham số Blob ở lớp thực thi để tránh tình trạng các nút lớp thực thi phải yêu cầu các nút lớp đồng thuận cung cấp các tham số liên quan đến Blob.

Các tham số liên quan đến Blob hiện được lưu trữ trong các nút lớp đồng thuận, nhưng các nút lớp thực thi vẫn cần các tham số này trong một số trường hợp (chẳng hạn như RPC eth_feeHistory), do đó chúng phải yêu cầu các nút lớp đồng thuận.

EIP-7840 tạo tệp cấu hình cho các tham số liên quan đến Blob tại lớp thực thi. Các nút lớp thực thi có thể đọc trực tiếp các tham số liên quan đến Blob thông qua tệp cấu hình này mà không cần phải hỏi các nút lớp đồng thuận.