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

Dự kiến ​​hard fork Pectra sẽ bắt đầu triển khai mainnet 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).

Bài viết gốc: Giới thiệu về Ethereum Pectra Hard Fork

Tác giả: NIC Lin

Biên soạn bởi: imToken

Bìa: Ảnh của Shubham Dhage trên Unsplash

Dự kiến ​​hard fork Pectra sẽ ra mắt 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 khối băm 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: Lớp thực thi kích hoạt thoát
• EIP-7251: Tăng MAX_EFFECTIVE_BALANCE
• EIP-7549: Di chuyển chỉ mục ủy ban ra khỏi phạm vi 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 tệp cấu hình EL

Các thỏa thuận kỹ thuật liên quan đến thế chấp

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 staking 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 thực thi và phân tích nhật ký sự kiện để xác định xem có ai tham gia staking hay không, 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, một số trình xác thực sẽ 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 (eth1data) nào để tham chiếu đến 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 fork 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 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à việc tham gia staking sẽ mất ít nhất 10 giờ để có hiệu lực.

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 các trình 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ố trình xác thực bỏ phiếu và xác nhận, 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 khối băm lịch sử trong Trạng thái

Nó có thể được sử dụng để cải thiện quá 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à lợi nhuận, đồng thời giảm thiểu rủi ro cho người xác thực.
Để tham gia staking, bạn cần hai khóa, cụ thể là Key xác thực và Thông tin xác thực rút tiền.
Key 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à lợi nhuận sẽ được rút khi trình xác thực thoát khỏi staking. Ngoài ra, Key xác thực phải được sử dụng để thoát khỏi staking tại thời điểm hiện tại.
Nếu bạn mất Key xác thực, bạn sẽ không thể thực hiện công việc xác thực và 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à lợi nhuận 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à lợi nhuận(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 Key xác thực, họ cũng có thể sử dụng khóa này để rút tiền staking.

• Các tham số để khởi tạo yêu cầu bao gồm validator_pubkey và amount: validator_pubkey là Key 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 được sử dụng để 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ải đính kèm Phí Gas (ETH). 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.
• 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

Giới hạn trên của số tiền đặt cược có thể được tăng đáng kể để 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 lợi nhuận từ việc đặt cược.

Để trở thành người xác thực, người dùng 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ũng đá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 giao thức 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 lợi nhuận staking. Bạn không cần phải rút lợi nhuận định kì 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ọ và sau đó hợp nhất chúng lại với nhau để đặt 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à sử dụng Thông tin xác thực rút tiền của trình xác thực để gọi hợp đồng để bắt đầu 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 hợp nhất bao gồm source_pubkey và target_pubkey: hai Key này là Key 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 được sử dụng để 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 tiền gửi 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.
• Nếu Chứng nhận rút tiền của người dùng là hợp đồng, thì hợp đồng tiền gửi kết hợp có thể được gọi trước để lấy số tiền phí hiện tại, sau đó có thể khởi tạo yêu cầu và đính kèm phí. Tuy nhiên, nếu Chứng nhận 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. Bạn chỉ có thể mô phỏng trước ngoài chuỗi và thanh toán 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 để người dùng và dịch vụ đặt cược có thể 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 sẽ 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 việc hợp nhất 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.

Các 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 các yêu cầu thông qua các hợp đồng khác nhau. Cuối cùng, các yêu cầu này sẽ được ghi vào khối bộ nhớ 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ớ 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 được xác định bởi EIP-7685:

• EIP-6110 thêm yêu cầu đặt cược: Loại yêu cầu = 0 và khởi tạo yêu cầu thông qua hợp đồng Gửi tiền (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.

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

• Khóa riêng tư hoặc cụm từ ghi nhớ cần được ghi lại và lưu giữ, và ngưỡng để người dùng mới có thể đăng ký và sử dụng là cao.
• Tài khoản EOA chỉ có thể thực hiện một thao tác cho mỗi 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 trước khi bạn có thể 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à gửi giao dịch lần mỗi hoạt động.
• Không có cơ chế phục hồi, vì vậy 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 cụm từ ghi nhớ nào, hoặc ký và ủy quyền qua email hoặc sử dụng 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 trước đây có thể được hoàn thành chỉ với lần xác thực chữ ký và lần giao dịch.
• Có thể có quyền kiểm soát rất chi tiết và người dùng có thể ủy quyền cho bên thứ ba kiểm soát tài khoản của họ, nhưng đồng thời cũng chỉ định các hạn chế như "có thể tương tác với những hợp đồng nào", "không được thực hiện những 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 lần 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 của mình sang tài khoản mới thông qua cơ chế phục hồi.

Đề án 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 sang 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 Safe , tài khoản EOA của bạn sẽ trở thành hợp đồng An Safe ; 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 của 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ều cần lưu ý:

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

Ngay cả khi tài khoản EOA của người dùng trở thành hợp đồng, người đó 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 Safe , bạn có thể sử dụng giao diện An Safe và làm theo quy trình giao dịch An Safe 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 đảm bảo 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 an toàn như đa chữ ký.

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

Khi một 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. 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

Nhìn 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 trước để 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í nên kiểm tra yêu cầu thay đổi

Ví cần phải thực hiện tốt việc sàng lọc 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 đã chuyển đổ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 đã chuyển đổ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ề cách thực hiện hợp đồng chuyển đổi:

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

Giao thức kỹ thuật DApp

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

Điều này sẽ 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à khiến chúng 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 các khối băm lịch sử trong Trạng thái

Cho phép các nhà phát triển hoặc nút đọc giá trị băm (Băm khối) 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 một 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 một thử thách gian lận Optimistic 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." Do đó, anh ta phải sử dụng phương pháp "chuỗi" khối bộ nhớ để chứng minh từng khối bộ nhớ một cho đến khi anh ta đạt đến khối bộ nhớ 1000 năm trước, sau đó chứng minh rằng giao dịch tồn tại trong khối bộ nhớ đó.

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 chứng minh rằng 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 trong

0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC), Bộ nhớ của nó 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 Optimistic Rollup, bên 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 Lưu trữ 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ử, chúng có thể yêu cầu những người khác cung cấp bằng chứng bằng phương pháp bằng chứng trong ví dụ thử thách gian lận trước đó.

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

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

Khi nhu cầu phát hành dữ liệu Rollup tăng lên, sau khi Blob được giới thiệu trong EIP-4844 để cho phép Rollup phát hành 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ư nỗ lực gần đây 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 tài nguyên.

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ộ Block Gas Limit (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 Block Gas Limit đượ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. Theo cách này, Block Gas Limit và số Blob có thể tăng lên 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 để công bố 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 mức sử dụng gas 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 đó Gas tiêu thụ khi thực hiện giao dịch và Gas tiêu thụ khi triển khai hợp đồng sẽ được cộng lại.
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 cái thực sự bị ảnh hưởng là các Rollup quy mô nhỏ, vì Blobs có kích thước cố định và chi phí cố định, do đó Rollup nhỏ sử dụng Blobs 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 các 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 Blobs hoặc tìm cách kết hợp với nhau để chia sẻ một Blob.

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

Tăng số lượng blob để thêm không gian cho việc 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ó 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 đủ tức thời 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 thỏa thuận kỹ thuật khác

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

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

Người xác thực sẽ được phân công ngẫu nhiên vào một nhóm ủy ban tại mỗi Kỷ nguyên và

Đối với việc bỏ phiếu khối bộ nhớ, các phiếu bầu của người xác thực của 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 người xác thực sẽ chứa thông tin về "ủy ban mà người xác thực thuộc về", đ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ả họ đề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 ngang hàng và giảm áp lực lên mạng ngang hàng.

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, giúp các nút lớp thực thi không phải mất công 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.

Tuyên bố miễn trừ trách nhiệm: Là một nền tảng thông tin blockchain, các bài viết được đăng trên trang web này chỉ đại diện cho quan điểm cá nhân của tác giả và khách và không liên quan gì đến quan điểm của Web3Caff. Thông tin trong bài viết chỉ mang tính tham khảo và không cấu thành bất kỳ lời khuyên hoặc đề nghị đầu tư nào. Vui lòng tuân thủ luật pháp và quy định có liên quan của quốc gia hoặc khu vực của bạn.