Nhật ký cuộc họp mới nhất của các nhà phát triển Ethereum: EIP-2935 và EIP-3074 sẽ được bao gồm trong bản nâng cấp Pectra.

Tiêu đề Gốc: "Ethereum All Core Developers Execution Call #185 Writeup"

Tác Giả Gốc: Christine Kim

Dịch Gốc: Luccy, BlockBeats

Ghi Chú của Biên Tập:

Ethereum All Core Developers Consensus Call (ACDE) được tổ chức hàng hai tuần một lần để thảo luận và phối hợp các thay đổi cho Ethereum Execution Layer (EL). Đây là cuộc họp ACDE lần thứ 185, nơi các nhà phát triển đã có cuộc thảo luận sâu sắc và đánh giá về các thay đổi mã cần thiết cho bản cập nhật cứng Prague sắp tới và các EIP khác.

Các nhà phát triển tham gia vào các cuộc tranh luận gay gắt về các đề xuất khác nhau, đạt được sự đồng thuận sơ bộ về việc xem xét xem một số đề xuất nên được bao gồm trong Prague hay không. Tuy nhiên, cũng có những tranh cãi, như cuộc thảo luận về việc EOF có nên được kết hợp với nâng cấp Verkle hay không. Cuối cuộc họp, các nhà phát triển đã đạt được thỏa thuận về các bước tiếp theo của kế hoạch công việc và quyết định tiếp tục thử nghiệm và đánh giá tác động của các đề xuất khác nhau trong các mạng phát triển tương lai.

Christine Kim, Phó Chủ Tịch Nghiên Cứu tại Galaxy Digital, đã trình bày các điểm chính của cuộc họp này, và BlockBeats đã dịch văn bản gốc như sau:

Vào ngày 11 tháng 4 năm 2024, các nhà phát triển Ethereum đã tụ tập trên Zoom cho cuộc họp All Core Developers Execution (ACDE) lần thứ 185. Cuộc họp ACDE là một chuỗi các cuộc họp hàng tuần được hỗ trợ bởi quản lý giao thức của Ethereum Foundation Tim Beiko, nơi các nhà phát triển thảo luận và phối hợp các thay đổi cho Ethereum Execution Layer (EL). Tuần này, các nhà phát triển thảo luận về các thay đổi mã để thêm vào bản nâng cấp Ethereum EL sắp tới - bản cập nhật cứng Prague. Prague dự kiến sẽ được kích hoạt đồng thời với bản nâng cấp CL Electra, với việc kích hoạt dự kiến sẽ hoàn thành vào cuối năm 2024.

Ban đầu, các nhà phát triển đã đồng thuận xác định phạm vi của Prague/Electra (Pectra) để bao gồm năm Ethereum Improvement Proposals (EIPs). Chúng là:

EIP 2537, precompile cho các hoạt động trên đường cong BLS12-381

EIP 6110, xác minh tiền gửi cung cấp trên chuỗi

EIP 7002, các lối thoát dựa trên EL trigger

EIP 7251, tăng cường số dư hiệu quả tối đa

EIP 7549, loại bỏ chỉ số ủy ban khỏi xác thực

Tuần này, họ đã đồng thuận bao gồm EIP 3074 (các mã lệnh AUTH và AUTHCALL) và EIP 2935 (lưu trữ các mã hash khối lịch sử trong trạng thái) vào danh sách trên. Họ cũng quyết định loại trừ EIP 7547 (chứa danh sách) và EIP 7667 (tăng chi phí gas của các hàm hash) khỏi Prague. Các nhà phát triển mạnh mẽ ủng hộ việc kết hợp EIP 7667 với Verkle trong bản nâng cấp EL tiếp theo sau Prague, Osaka. Hiện tại, có sự xem xét để bao gồm 10 Ethereum Object Format (EOF) EIPs và EIP 7623 (tăng chi phí calldata) vào Prague.

Đánh Giá Nội Dung Được Bao Gồm trong Prague

Trước khi đi sâu vào danh sách EIP đang được xem xét cho Prague, các nhà phát triển đã dành một thời gian ngắn để xem xét các vấn đề hiện có trong các EIP đã được bao gồm trong bản nâng cấp.

EIP 7251

Một trong các EIP, EIP 7251, sẽ cho phép các nhà điều hành nút hợp nhất các nhà xác minh với số dư hiệu quả lên đến 32 ETH thành một nhà xác minh lớn duy nhất với số dư hiệu quả lên đến 2048 ETH. Số dư hiệu quả đề cập đến số dư ETH đã đặt cược mà các nhà xác minh nhận được phần thưởng phát hành từ đó. Số dư vượt quá 32 ETH không mang lại thêm phần thưởng phát hành cho các nhà xác minh, đó là lý do tại sao các nhà điều hành nút phải chạy nhiều nhà xác minh để tăng phần thưởng phát hành của họ. EIP 7251 nhằm giảm số lượng nhà xác minh hoạt động trên Ethereum bằng cách cho phép hợp nhất nhà xác minh và tự động tích lũy phần thưởng đặt cược. Sau các cuộc thảo luận với ma

Trong các nhóm Ethereum staking pools như Lido, các nhà phát triển đã đồng ý xem xét việc thay đổi EIP để thực hiện việc gộp validator thông qua một hợp đồng thông minh trên EL. Nhà nghiên cứu của Ethereum Foundation, Alex Stokes, nhấn mạnh trong bài báo của mình về cách thức hoạt động của việc gộp nội bộ và yêu cầu phản hồi từ các nhóm phát triển về các thay đổi mã mà anh ấy đề xuất trong cuộc gọi.

EIP 2537

Stokes cũng chia sẻ thông tin mới nhất về EIP 2537, mở rộng các hoạt động cho Máy Ảo Ethereum (EVM) cho phép các nhà phát triển thực hiện xác minh chữ ký mật mã một cách hiệu quả bằng cách sử dụng đường cong BLS12-381. Đây là một cách an toàn và nhanh chóng hơn so với việc sử dụng đường cong secp256k1 trên EL để tạo ra chữ ký ECDSA. Stokes đề cập rằng công việc đánh giá ban đầu về giá của các hoạt động này đã hoàn thành, và các nhà phát triển có thể mong đợi cập nhật cuối cùng về chi phí gas chính xác trong vài tuần tới. Trong khi đó, các nhóm phát triển khuyến khích triển khai EIP trong phạm vi hiện tại cho mạng thử nghiệm phát triển Pectra đầu tiên, pectra-devnet-0.

Tranh luận về Những Gì Prague Nên Bao Gồm

Trước cuộc gọi tuần này, các nhóm phát triển EL đã cung cấp cập nhật bằng văn bản về các EIPs bổ sung mà họ muốn bao gồm trong Prague, ngoài năm EIPs mà họ đã đồng ý bao gồm trong bản nâng cấp. Beiko liên kết sở thích của các nhóm phát triển EL trong chương trình cuộc gọi và cung cấp thông tin sau đây để tham khảo lâu dài:

Ưu tiên Erigon

Ưu tiên Besu

Ưu tiên Reth

Ưu tiên Nethermind

Ưu tiên Geth

Mega EOF Endgame

Khi thảo luận về các EIP bổ sung để bao gồm trong Prague, nhà phát triển Geth Guillaume Ballet bày tỏ sự phản đối với các thay đổi liên quan đến EOF trong bản nâng cấp. Anh ấy lo lắng rằng những thay đổi này có thể làm cho việc triển khai Verkle trong bản nâng cấp tiếp theo sau Prague (được gọi là Osaka) trở nên khó khăn hoặc không thể thực hiện được. Trong khi đó, Danno Ferrin, Kỹ sư Phần mềm Chính tại Swirlds Labs, trình bày một quan điểm đối lập, khẳng định rằng EOF có thể "100% tương thích" với các thay đổi mã Verkle. Ballet bày tỏ sự hoài nghi đối với đánh giá của Ferrin, nhấn mạnh lại những bình luận trước đó từ cuộc gọi ACDE về mong muốn thấy EOF trên một mạng thử nghiệm Verkle. Beiko giải thích rằng đánh giá tính tương thích của EOF với Verkle dựa trên chức năng của nó trong các mạng thử nghiệm hard fork tương lai không hợp lý và yêu cầu Ballet làm rõ các mối quan ngại cụ thể về tính tương thích của EOF với Verkle. Ballet không đáp lại, nói rằng không có thông số mã EOF nào để anh ấy xem xét. Một nhà phát triển chia sẻ liên kết mới nhất về thông số mã EOF trong cửa sổ chat Zoom. Chat cũng chia sẻ một liên kết về sự sẵn sàng của EOF dựa trên các triển khai của các nhóm phát triển.

Nhà phát triển Geth Marius van der Wijden hỏi về số lượng opcode mà EOF sẽ thêm hoặc cập nhật. Beiko chỉ ra rằng theo thông số kỹ thuật mới nhất, EOF sẽ thay đổi 18 opcode. EOF là một bản gộp các thay đổi mã EVM từ 10 EIPs khác nhau. Van der Wijden lưu ý rằng mối quan ngại chính của anh về EOF là sự phức tạp và lượng công việc mà các nhóm phát triển cần để kiểm tra hoàn toàn tất cả các trường hợp biên trong EOF. Nhà phát triển Nethermind Marek Moraczyński đồng ý rằng EOF có thể tiềm ẩn "nhiều lỗi đồng thuận mới" và sẽ cần "kiểm tra cẩn thận," nhưng không triển khai các EIPs này sẽ có nghĩa là phải chờ đợi thêm hai đến ba năm nữa để có những cải tiến cho EVM.

Ferrin chỉ ra rằng khi các nhà phát triển tranh luận về việc EOF có nên được bao gồm trong bản nâng cấp Shanghai, họ phản đối phạm vi hẹp của những thay đổi mã này. Bây giờ, Ferrin và các nhà phát triển khác đã làm việc để mở rộng EOF, nhưng các nhóm phát triển phản đối do sự phức tạp và khó khăn trong việc triển khai các thay đổi mã. Ferrin nói, "Chúng ta không thể nhận được yêu cầu nhất quán từ tất cả các nhóm phát triển lõi." Anh ấy thêm rằng nghe thấy phàn nàn về hai phiên bản của EOF là "đau lòng." Các nhóm phát triển Reth và Erigon cũng bày tỏ mối quan ngại của họ.