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.

Xem bài gốc

律动BlockBeats2024/04/12 05:25

Theo:律动BlockBeats

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ọ.

Đội ngũ hỗ trợ khách hàng tại Prague bao gồm EOF. Beiko đề xuất rằng các nhà phát triển chuyển cuộc thảo luận sang các EIP khác và sau đó xem xét lại cuộc thảo luận về EOF sau trong cuộc gọi hội nghị. EIP 3074, Mã Opcodes AUTH và AUTHCALL Beiko hỏi nhóm khách hàng về ý kiến của họ về EIP 3074, cụ thể là việc giới thiệu các mã Opcodes AUTH và AUTHCALL. Các mã Opcodes này sẽ cho phép hợp đồng thông minh ủy quyền giao dịch từ các tài khoản sở hữu bên ngoài (EOAs) và thêm tính lập trình cho tài khoản được người dùng kiểm soát. Nhiều nhà phát triển trong cuộc gọi, bao gồm Georgios Konstantopoulos, Danno Ferrin và "protolambda," đã ủng hộ thay đổi mã này. Protolambda đã giới thiệu lại EIP 7664 đề xuất của mình, nhằm sửa logic của EIP 3074 khi tương tác với danh sách truy cập. Nhóm phát triển Geth và cộng tác viên của EIP 3074, Matt Garnett, còn được biết đến với tên "Lightclient," đã bày tỏ sự ủng hộ cho EIP 7664. Một nhà phát triển khác hỏi về cách EIP 3074 sẽ ảnh hưởng đến mã OPCODE ORIGIN, trả về địa chỉ khởi tạo giao dịch. Beiko nêu rõ rằng những ảnh hưởng này được liệt kê trong EIP và hỏi xem có nhà phát triển nào phản đối việc bao gồm thay đổi mã này tại Prague không. Không có ý kiến phản đối nào. EIP 2935, Lưu trạng thái Hash Block lịch sử Ballet giới thiệu EIP 2935 trong ACDE #184, một thay đổi mã sẽ mang lại lợi ích cho việc triển khai Verkle trong tương lai. Nhóm phát triển Reth thể hiện một thái độ "trung lập tích cực" đối với EIP này và đề cập rằng, xem xét rằng đây là một thay đổi đơn giản, họ không phản đối việc bao gồm nó tại Prague. Nhóm phát triển Erigon chia sẻ một thái độ tương tự nhưng lưu ý rằng sự tự tin của họ trong việc bao gồm nó tại Prague sẽ thấp hơn nếu các thay đổi mã lớn như EOF được bao gồm. Beiko đề xuất tiếp tục thảo luận về các EIP khác và xem xét lại EIP 2935 sau trong cuộc gọi hội nghị. EIP 7667, Tăng Chi phí Gas của Hàm Hash Người đồng sáng lập Ethereum Vitalik Buterin đề xuất EIP 7667 để tăng chi phí gas của các hàm hash opcode và precompiles để điều chỉnh với chi phí thực thi thông qua các hệ thống không chứng minh (ZK) như ZK EVMs. Để biết thêm thông tin về ZK EVMs, vui lòng tham khảo báo cáo nghiên cứu Galaxy Research. Đối với động lực để định giá lại các hoạt động hàm hash trên Ethereum, Buterin viết trong tài liệu EIP 7667: "Chi phí gas của các hàm hash opcode và precompiles ban đầu được thiết lập dựa trên thời gian thực thi chúng trên một CPU thông thường. Tuy nhiên, sau đó, một trường hợp sử dụng quan trọng khác đã xuất hiện: hệ thống chứng minh không chứng minh (ZK-SNARK). Theo tiêu chuẩn đó, các opcode và precompiles này đang bị định giá thấp hơn so với các hoạt động khác." Buterin cũng đề cập trong cuộc gọi hội nghị rằng dễ dàng đánh giá thấp sự phổ biến ngày càng tăng của các chứng minh ZK, không chỉ để xác minh Layer-2 rollups mà còn liên quan đến các chuỗi Layer-1 như Ethereum. Ông nói, "Tôi nghĩ rằng ngay cả trong một hoặc hai năm tới, chúng ta có thể có khả năng thực hiện chứng minh thời gian thực cho Ethereum L1. Vì vậy, tôi nghĩ rằng quan trọng là phải thích nghi với việc không còn phân biệt giữa các chuỗi ZK và các chuỗi không ZK. Chúng ta đang bước vào một chế độ mà mọi chuỗi nghiêm túc đều là chuỗi ZK." Xem xét rằng nâng cấp Verkle trong cú đúp Osaka sẽ thay đổi giá gas và lịch trình, Ferrin đề xuất thực hiện EIP này cùng với Verkle. Nhà nghiên cứu EF Carl Beekhuizen nhấn mạnh rằng EIP này đòi hỏi nghiên cứu kỹ lưỡng và các nhà phát triển phải phân tích cẩn thận cách mà những thay đổi gas này sẽ ảnh hưởng đến hợp đồng thông minh trên Ethereum. Van der Wijden đồng ý với cách tiếp cận cẩn thận của Beekhuizen đối với việc tiến hành EIP này. Ferrin cũng đề xuất có thể thực hiện những thay đổi này trước tiên trên Layer-2 rollups và sau đó điều tra tác động của chúng đối với Layer-1 Ethereum. Beiko đồng ý với cách tiếp cận này và đề xuất nhà phát triển xem xét việc bao gồm EIP 7667 cùng với Verkle trong nâng cấp Osaka, đưa nó vào tình trạng "CFI" hoặc "xem xét để bao gồm." Không có ý kiến phản đối nào. EIP 7623, Tăng Chi phí calldata Cộng tác viên của EIP 7623, nhà nghiên cứu EF Toni Wahrstätter, chia sẻ đề xuất của mình để tăng chi phí của calldata và hỏi nhóm khách hàng ý kiến của họ. Nhà nghiên cứu EF Ansgar Dietrichs và nhà phát triển Nethermind Ahmad Bitar đã表达 quan điểm của họ.Hỗ trợ. Beekhuizen cho biết không có ý kiến phản đối việc triển khai EIP 7623 khi nó được đề xuất tại cuộc họp Rollcall mới nhất, một loạt các cuộc họp giữa các nhóm Layer-2 rollup. Beiko đề xuất tiếp tục thảo luận về các EIP khác và xem xét lại EIP này sau trong cuộc gọi hội nghị. EIP 7645, Đổi tên ORIGIN thành SENDER Beiko hỏi ý kiến của nhóm phát triển về EIP 7645, mục tiêu là thay đổi hành vi của mã ORIGIN để ngăn chặn lạm dụng hợp đồng thông minh. Cyrus Adkisson, một nhà đầu tư Ethereum sớm và tác giả của EIP 7645, chỉ ra rằng việc cập nhật mã ORIGIN có ba con đường khả thi, mỗi con đường đều có các sự đánh đổi khác nhau. Ferrin nhấn mạnh rằng các con đường đề xuất thay đổi hành vi mã cần được xem xét cẩn thận bởi các chuyên gia bảo mật và các công ty kiểm toán, vì các nhà phát triển giao thức Ethereum không thể đánh giá đầy đủ tác động của những thay đổi đó đối với các hợp đồng thông minh hiện có và người dùng cuối. Beiko đề xuất rằng, vì yếu tố thời gian, các nhà phát triển tiếp tục thảo luận về các EIP khác. EIP 7547, Danh sách bao gồm Beiko hỏi các nhà phát triển về ý kiến về việc bao gồm EIP 7547 tại Prague. Dựa trên phản hồi từ nhóm phát triển EL, không có sự ủng hộ rộng rãi cho thay đổi mã này. Beiko đề xuất loại bỏ nó khỏi bản nâng cấp. Không có ý kiến phản đối. Đề xuất Điều chỉnh Đường cong Phát hành Dietrichs đề xuất giảm phát hành Ethereum. Xem xét rằng thay đổi này chủ yếu ảnh hưởng đến lớp thực thi của Ethereum, Beiko đề xuất rằng các nhà phát triển tiếp tục thảo luận về các lợi ích của đề xuất này trong cuộc gọi hội nghị ACDC. Xem xét lại EOF, EIP 7623 và 2935 cho Prague Sau đó, các nhà phát triển xem xét lại các EIP được đề xuất cho Prague mà chưa đạt được sự đồng thuận. Beiko hỏi xem EOF có thể được gói gọn với bản nâng cấp Verkle hay không. Ballet mạnh mẽ phản đối ý tưởng này, cho biết cả hai thay đổi mã đều phức tạp, và triển khai chúng đồng thời sẽ "quá rủi ro." Protolambda nhấn mạnh rằng EIP 7664 là một EIP khác cần được xem xét để bao gồm vào Prague. Garnett thêm rằng EIP 7639, một đề xuất liên quan đến việc ngừng cung cấp dữ liệu lịch sử bởi các máy khách trước bản nâng cấp hợp nhất (Tháng 9 năm 2022), cũng nên được xem xét. Đã đề xuất về gánh nặng bổ sung mà việc bao gồm EOF sẽ đặt lên nhóm phát triển máy khách, với nhà phát triển Georgios Konstantopoulos của Reth khuyến khích các nhà phát triển "tất cả vào." Tuy nhiên, vẫn chưa có sự đồng thuận về EOF. Các nhà phát triển cuối cùng đã đồng ý tiếp tục làm việc trên EOF, đặc biệt là việc kiểm thử cần thiết, và quyết định sau này liệu nó có nên được bao gồm trong Prague hay không. Họ cũng đồng ý hoãn quyết định về EIP 7623. Đối với EIP 2935, các nhà phát triển đã đồng ý bao gồm nó trong Prague. Tóm lại tất cả các quyết định được đưa ra trong cuộc gọi hội nghị, Beiko cho biết các nhà phát triển sẽ bao gồm EIP 3074 và EIP 2935 trong mạng phát triển đầu tiên của bản nâng cấp Pectra. Sau mạng phát triển này, họ đã đồng ý quyết định liệu có nên bao gồm EOF và/hoặc EIP 7623 trong mạng phát triển Pectra thứ hai. [Liên kết bài viết gốc] Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats: Nhóm Đăng ký Telegram: https://t.me/theblockbeats Nhóm Truyền thông Telegram: https://t.me/BlockBeats_App Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia

Tuyên bố miễn trừ trách nhiệm: Mọi thông tin trong bài viết đều thể hiện quan điểm của tác giả và không liên quan đến nền tảng. Bài viết này không nhằm mục đích tham khảo để đưa ra quyết định đầu tư.

Bạn cũng có thể thích

Cuộc trò chuyện với Đồng sáng lập Farcaster: Làm thế nào Mạng xã hội Phi tập trung có thể phát triển từ 100,000 lên 1 tỷ người dùng

Các nhà đồng sáng lập Farcaster, Dan Romero và Varun Srinivasan, đã chia sẻ quan điểm của họ về một loạt các chủ đề.

Chaincatcher•2024/05/23 02:37

Hệ sinh thái Ethereum bùng nổ trở lại: Giải thích chi tiết về ERC-7683 do Uniswap dẫn đầu

Thế giới đã phải chịu đựng các vấn đề liên chuỗi từ lâu.

Chaincatcher•2024/05/23 01:40

FUD Lan Tràn Như Cháy Rừng: Liệu Vị Vua AI Mới Bittensor Có Sụp Đổ?

Mỗi thế hệ đều có câu chuyện và anh hùng của riêng mình; không có triều đại nào tồn tại mãi mãi.

Chaincatcher•2024/05/22 13:14

Giao thức Ràng buộc Nostr

Trong bài viết này, chúng tôi đề xuất một giao thức kết hợp các cấu trúc dữ liệu cơ bản của giao thức Nostr với blockchain CKB. Thông qua sự kết hợp này, chúng tôi cho phép dữ liệu gốc của Nostr thừa hưởng các đặc điểm của UTXO/Cell trên blockchain CKB, mang lại những khả năng mới cho giao thức Nostr dựa trên các cơ chế trên chuỗi. Một trường hợp sử dụng tiềm năng là phát hành tài sản gốc trên Nostr. Giao thức kết hợp Nostr cũng giới thiệu một mô hình phát triển mới cho dApps. Thay vì chia dApp của bạn thành hai hệ thống (một là máy chủ ngoài chuỗi và một là hợp đồng thông minh trên chuỗi), chúng tôi sử dụng một hệ thống thống nhất với các mức dữ liệu khác nhau để xây dựng dApps. Điều này khác biệt cơ bản so với mô hình Ethereum.

Chaincatcher•2024/05/22 12:52