Những EIP nào đã được xác định sẽ được đưa vào nâng cấp Pectra? Liệu điều này có làm gia tăng lạm phát ETH không?

Các EIP đã được xác định sẽ nâng cao khả năng lập trình của tài khoản, hiệu quả xác thực của Ethereum và tối ưu hóa staking, trong khi các EIP chưa xác định tập trung vào cách cải thiện khả năng mở rộng của L2.

Tác giả: 0XNATALIE

Bản nâng cấp tiếp theo của Ethereum, Pectra, có tên gọi được kết hợp từ Prague và Electra.

Prague đại diện cho nâng cấp lớp thực thi, được đặt tên theo thành phố tổ chức hội nghị các nhà phát triển Ethereum (Devcon 4) là Prague, còn Electra tượng trưng cho nâng cấp lớp đồng thuận, được đặt tên theo thứ tự chữ cái bằng tên các ngôi sao. Lần này, tên sao được chọn là Electra, tương ứng với chữ cái "E".

Bản nâng cấp Pectra, được xem là một trong những đợt hard fork có thể bao gồm nhiều Ethereum Improvement Proposals (EIP) nhất trong lịch sử Ethereum, không chỉ bao gồm một loạt các đề xuất nhằm nâng cao hoạt động của validator và hiệu suất mainnet, mà còn giới thiệu các đề xuất tối ưu hóa cho L2. Testnet Pectra Devnet 4 vừa được ra mắt, hiện đã có 8 EIP được xác định sẽ được đưa vào bản nâng cấp Pectra.

Các EIP đã xác định sẽ được đưa vào và tác động của chúng

8 EIP này sẽ ảnh hưởng đến người dùng như sau: Bằng cách thêm khả năng thực thi mã cho EOA, tăng tính linh hoạt của tài khoản, cho phép thực hiện các thao tác phức tạp hơn; nâng giới hạn staking có thể làm tăng nhu cầu đối với ETH; đồng thời, tối ưu hóa quy trình xác thực giúp tăng cường bảo mật và hiệu quả, nâng cao tốc độ và thông lượng của Ethereum.

1. EIP-2537 (Hỗ trợ chữ ký BLS): Thông qua việc giới thiệu một loạt các hợp đồng tiền biên dịch (precompiles), bổ sung hỗ trợ cho phép tính đường cong BLS12-381 trên Ethereum, có thể thực hiện xác thực chữ ký BLS và cho phép nhiều chữ ký được tổng hợp thành một chữ ký, từ đó giảm độ phức tạp khi xác thực. Chữ ký BLS là một thuật toán mật mã có thể tạo ra chữ ký nhỏ hơn và hỗ trợ tổng hợp chữ ký. Điều này sẽ giúp các L2 cần thực hiện nhiều xác thực chữ ký và xác thực dữ liệu hoạt động tốt hơn.
2. EIP-2935 (Lưu trữ hash block lịch sử trong trạng thái): Bằng cách lưu trữ hash của 8192 block gần nhất trong hợp đồng hệ thống, hỗ trợ mô hình Stateless Clients và cung cấp chức năng truy vấn hash block lịch sử linh hoạt hơn. Các hash này có thể được truy vấn trực tiếp qua hợp đồng và được đóng gói làm bằng chứng (witness) cung cấp cho Stateless Clients. Client không cần tự duy trì toàn bộ lịch sử blockchain hoặc lưu trữ dữ liệu lớn, chỉ cần dựa vào hash block lưu trong trạng thái và các bằng chứng liên quan là có thể xác thực tính hợp lệ của block và giao dịch.
3. EIP-6110 (Cung cấp tiền gửi validator trên chain): Chuyển việc xử lý tiền gửi validator từ lớp đồng thuận sang lớp thực thi, xử lý và xác thực trực tiếp trên chain, không còn phụ thuộc vào cơ chế bỏ phiếu bổ sung trong lớp đồng thuận để xác nhận tính hợp lệ của thông tin tiền gửi. Điều này tăng cường tính an toàn cho quy trình gửi tiền, giảm độ trễ xử lý, đồng thời đơn giản hóa thiết kế lớp đồng thuận và client.
4. EIP-7002 (Thoát staking có thể kích hoạt từ lớp thực thi): Cho phép chủ sở hữu chứng nhận rút tiền có thể tự chủ động khởi tạo việc thoát staking mà không cần phụ thuộc vào khóa hoạt động của validator (khóa BLS), tăng tính tự chủ cho người dùng. Hiện tại, chỉ có khóa hoạt động của validator mới có thể kích hoạt việc thoát staking, điều này có nghĩa là nếu khóa hoạt động bị mất, hoặc validator ủy quyền nhiệm vụ xác thực cho bên thứ ba (như nhà cung cấp dịch vụ staking), chủ sở hữu chứng nhận rút tiền (tức là chủ sở hữu thực sự của tài sản) không thể tự kiểm soát ETH đã staking. Đề xuất này cho phép kích hoạt việc thoát và rút ETH từ lớp thực thi, chủ sở hữu có thể sử dụng chứng nhận rút tiền để khởi tạo việc thoát mà không cần phụ thuộc vào khóa hoạt động.
5. EIP-7251 (Tăng giới hạn staking): Tăng số dư hiệu quả tối đa của validator, cho phép mỗi validator có thể staking hơn 32 ETH, trong khi ngưỡng staking tối thiểu vẫn giữ ở mức 32 ETH. Mục tiêu là để các nhà vận hành node lớn có thể hợp nhất nhiều validator, giảm số lượng validator trên mạng, từ đó giảm tải cho P2P, tổng hợp chữ ký và lưu trữ.
6. EIP-7549 (Di chuyển chỉ số committee ra khỏi bằng chứng): Bằng cách di chuyển trường chỉ số committee ra khỏi thông điệp Attestation (bằng chứng), đạt được việc tổng hợp phiếu bầu đồng thuận hiệu quả hơn. Hiện tại, trong cơ chế đồng thuận của Ethereum, mỗi validator khi bỏ phiếu bao gồm: phiếu bầu LMD GHOST (chứa root block và slot của phiếu bầu), phiếu bầu Casper-FFG (chứa thông tin nguồn và đích), chỉ số committee (số hiệu committee mà validator thuộc về). Do chỉ số committee được bao gồm trong thông điệp chữ ký, khi nhiều validator bỏ phiếu cho cùng một block, dù nội dung phiếu giống nhau, root chữ ký tạo ra vẫn khác nhau, khiến các phiếu này khó tổng hợp. Việc di chuyển trường chỉ số committee ra khỏi thông điệp chữ ký giúp tổng hợp phiếu bầu hiệu quả hơn, giảm chi phí xác thực và tải mạng.
7. EIP-7685 (Khung yêu cầu lớp thực thi chung): Định nghĩa một khung chung cho lớp thực thi (EL) để lưu trữ và xử lý các yêu cầu được kích hoạt bởi smart contract. Khung này hỗ trợ nhiều hành vi kích hoạt từ lớp thực thi hơn, đồng thời cho phép các loại yêu cầu khác nhau được xử lý thống nhất, đơn giản hóa quá trình thêm loại yêu cầu mới mà không cần sửa đổi cấu trúc block thực thi.
8. EIP-7702 (Thêm khả năng thực thi mã cho EOA): Thêm chức năng thực thi mã cho tài khoản sở hữu bên ngoài (EOA), tăng cường tính linh hoạt và khả năng lập trình của tài khoản. EOA có thể chỉ định một smart contract làm đại diện thực hiện một số thao tác nhất định, như giao dịch hàng loạt hoặc kiểm soát quyền hạn, thông qua chữ ký ủy quyền. Nhờ đó, EOA có thể có một số chức năng của smart contract mà không cần chuyển đổi thành tài khoản smart contract.

Các EIP đang được cân nhắc trọng điểm

Dưới đây là một số EIP đang được tích cực xem xét, chủ yếu thông qua việc tối ưu hóa blob, nâng cao tính ổn định của chi phí công bố dữ liệu L2, tăng cường khả năng xử lý giao dịch của L2 và giảm chi phí cho L2. Ngoài ra, việc điều chỉnh tăng chi phí calldata có thể ảnh hưởng đến lượng ETH bị đốt, làm tăng áp lực lạm phát cho ETH.

• EIP-7742 (Gỡ bỏ phụ thuộc đếm blob giữa lớp đồng thuận và lớp thực thi): Tách biệt số lượng blob giữa lớp đồng thuận và lớp thực thi, đơn giản hóa quy trình xác thực blob, giảm sự phức tạp không cần thiết, nâng cao khả năng mở rộng và linh hoạt của giao thức. Hiện tại, cả lớp thực thi và lớp đồng thuận đều mã hóa cứng giá trị tối đa của blob, dẫn đến xác thực dư thừa. Đề xuất này loại bỏ việc xác thực giá trị tối đa blob ở lớp thực thi, thay vào đó lớp đồng thuận sẽ cung cấp giá trị mục tiêu blob động cho lớp thực thi. Nhờ đó, có thể điều chỉnh linh hoạt các tham số mục tiêu blob, đáp ứng nhu cầu mở rộng trong tương lai. EIP-7742 là đề xuất ít gây tranh cãi nhất trong danh sách các EIP đang được cân nhắc đưa vào nâng cấp. Theo cuộc họp lớp đồng thuận mới nhất, các nhà phát triển đồng ý bắt đầu triển khai EIP-7742 trên pectra-devnet 5, nhưng việc có chính thức đưa vào hay không vẫn cần chờ phản hồi từ lớp thực thi tại cuộc họp ACDE (All Core Developers Execution Layer Meeting).
• EIP-7762 (Phí cơ bản tối thiểu cho blob): Tăng MIN_BASE_FEE_PER_BLOB_GAS, nhằm rút ngắn thời gian cần thiết để điều chỉnh giá blob về mức hợp lý. Hiện tại, phí cơ bản tối thiểu cho blob được đặt ở mức 1 wei, khi nhu cầu blob vượt quá nguồn cung, quá trình phát hiện giá (tức xác định giá gas blob hợp lý) diễn ra quá chậm, mất nhiều thời gian mới đạt được mức phí phù hợp. Việc tăng phí cơ bản tối thiểu cho blob sẽ rút ngắn thời gian điều chỉnh giá, giúp thị trường cân bằng nhanh hơn, đảm bảo mạng lưới vẫn ổn định khi nhu cầu tăng cao.
• EIP-7623 (Tăng chi phí calldata): Tăng chi phí calldata trong giao dịch nhằm giảm kích thước tối đa của block và phạm vi biến động của nó, đảm bảo mạng lưới xử lý giao dịch ổn định hơn. Hiện tại, kích thước block tối đa khoảng 1.79 MB, nhưng do các ứng dụng như rollups công bố dữ liệu lớn, kích thước block trung bình liên tục tăng. Việc tăng chi phí calldata chủ yếu dùng cho giao dịch liên quan đến khả năng sẵn có dữ liệu (DA), sẽ giảm kích thước block tối đa xuống khoảng 0.72 MB, tạo không gian cho việc tăng giới hạn gas block hoặc thêm nhiều blob trong tương lai. Chi phí giao dịch của người dùng thông thường không thay đổi, thay đổi này chủ yếu ảnh hưởng đến các loại giao dịch dựa vào Ethereum để lưu trữ dữ liệu quy mô lớn. Tuy nhiên, việc tăng chi phí calldata có thể làm giảm sức cạnh tranh của Ethereum trong lĩnh vực lưu trữ dữ liệu. Ngoài ra, chi phí calldata tăng, số lượng giao dịch có thể giảm, dẫn đến lượng ETH bị đốt qua cơ chế EIP-1559 cũng giảm, từ đó làm tăng áp lực lạm phát cho ETH.
• EIP-7782 (Rút ngắn thời gian slot): Giảm thời gian slot của Ethereum từ 12 giây xuống 8 giây, tạo block thường xuyên hơn để xử lý nhiều giao dịch hơn, coi đây là phương án thay thế cho việc tăng số lượng blob nhằm nâng cao thông lượng giao dịch. Tuy nhiên, điều này có thể làm hỏng một số smart contract đã mã hóa cứng thời gian slot 12 giây, đồng thời đẩy nhanh vấn đề phình trạng thái của Ethereum, tăng gánh nặng lưu trữ và tính toán.
• EIP-7783 (Tăng dần giới hạn gas block): Là phương án thay thế nhẹ nhàng hơn cho EIP-7782, bằng cách điều chỉnh động giới hạn gas của block, dần dần tăng số lượng giao dịch có thể chứa trong mỗi block, từ đó nâng cao khả năng xử lý của mạng lưới. So với việc rút ngắn thời gian slot, điều chỉnh dần giới hạn gas giúp mạng lưới mở rộng ổn định hơn. Đề xuất này không cần hard fork, nhưng có thể ảnh hưởng đến dữ liệu trạng thái.

Do bản nâng cấp Pectra bao gồm rất nhiều EIP, để giảm độ phức tạp của mỗi lần nâng cấp và đẩy nhanh việc triển khai một số EIP, vào tháng 5, đội ngũ kỹ sư của Ethereum Foundation là EthPandaOps đã đề xuất chia Pectra thành hai phần, nhưng khi đó lo ngại sẽ làm chậm tiến độ nâng cấp nên chưa được xem xét nghiêm túc. Đến tháng 9, nhà nghiên cứu Ethereum Alex Stokes lại đề xuất tách ra, lần này đã nhận được sự đồng thuận của các nhà phát triển, việc chia tách này giúp hoàn thành phần đầu tiên của nâng cấp trong vòng sáu tháng:

• Phần đầu tiên: Bao gồm các EIP đã chạy trên testnet Pectra Devnet (tức 8 EIP đã xác định), các EIP này tương đối dễ triển khai và đã trải qua nhiều thử nghiệm.
• Phần thứ hai: Đưa các EIP phức tạp hơn (như PeerDAS, các đề xuất liên quan đến EOF) và các đề xuất cần nhiều thời gian thử nghiệm hơn vào giai đoạn hai. Những đề xuất này cần phát triển, kiểm toán và thử nghiệm thêm, đặc biệt là các đề xuất liên quan đến phối hợp giữa lớp đồng thuận và lớp thực thi.