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

Tác giả gốc: Christine Kim

Bản tổng hợp gốc: Luccy, BlockBeats

Ghi chú của biên tập viên:

Cuộc kêu gọi đồng thuận của tất cả các nhà phát triển cốt lõi (ACDE) của Ethereum được tổ chức hai tuần một lần để thảo luận và điều phối sự phát triển của Ethereum .Thay đổi lớp thực thi (EL). Đây là cuộc gọi hội nghị lần thứ 185 của ACDE. Trong cuộc họp, các nhà phát triển đã tiến hành thảo luận và đánh giá chuyên sâu về những thay đổi mã và các EIP khác cần thiết cho đợt hard fork Praha sắp tới.

Các nhà phát triển đã tranh luận sôi nổi về các đề xuất và đạt được sự nhất trí tạm thời về việc liệu một số trong số chúng có nên được đưa vào Praha hay không. Tuy nhiên, đã có một số tranh cãi, chẳng hạn như cuộc thảo luận về việc liệu EOF có nên đi kèm với bản nâng cấp Verkle hay không. Kết thúc cuộc họp, các nhà phát triển đã thống nhất kế hoạch làm việc tiếp theo và quyết định thử nghiệm và đánh giá thêm tác động của từng đề xuất đối với mạng lưới phát triển trong tương lai.

Christine Kim, Phó Chủ tịch Nghiên cứu của Galaxy Digital, đã ghi lại chi tiết những điểm chính của cuộc họp này. BlockBeasts đã biên soạn 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ập trung trên Zoom để tham gia cuộc họp số 185 của All Core Developers Execution (ACDE). Cuộc gọi hội nghị ACDE là chuỗi cuộc họp hai tuần một lần do Tim Beiko, Trưởng bộ phận Hỗ trợ Giao thức tại Ethereum Foundation tổ chức, nơi các nhà phát triển thảo luận và điều phối các thay đổi đối với Lớp thực thi Ethereum (EL). Tuần này, các nhà phát triển đã thảo luận về những thay đổi mã sẽ được thêm vào bản nâng cấp Ethereum EL sắp tới, hard fork Praha. Praha sẽ được kích hoạt đồng thời với bản nâng cấp CL Electra và dự kiến sẽ hoàn thành trước cuối năm 2024.

Ban đầu, các nhà phát triển đã đồng ý đưa Praha/Electra (Pectra) vào năm Đề xuất cải tiến Ethereum (EIP). Đó là:

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

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

EIP 7002, EL đã kích hoạt thoát

EIP 7251, tăng số dư hiệu dụng tối đa

EIP 7549, chuyển chỉ số ủy ban ra khỏi chứng nhận

Tuần này, họ đã nhất trí đưa EIP 3074 (mã hoạt động AUTH và AUTHCALL) và EIP 2935 (bảo toàn băm khối lịch sử ở trạng thái) vào danh sách trên. Họ cũng quyết định loại trừ EIP 7547 (bao gồm danh sách) và EIP 7667 (tăng chi phí gas cho các hàm băm) khỏi Praha. Các nhà phát triển đang hướng tới việc kết hợp EIP 7667 với Verkle trong bản nâng cấp EL tiếp theo sau Praha, Osaka. Hiện tại, 10 EIP định dạng đối tượng máy ảo Ethereum (EOF) và EIP 7623 (chi phí dữ liệu cuộc gọi tăng) vẫn đang được xem xét để đưa vào Praha.

Đánh giá những gì đã được đưa vào Praha

Thảo luận chuyên sâu về EIP đang được xem xét ở Praha Trước khi có danh sách, các nhà phát triển đã dành một khoảng thời gian ngắn để xem xét các vấn đề với EIP đã được đưa vào bản nâng cấp.

EIP 7251

Một trong những EIP, EIP 7251, sẽ cho phép các nhà khai thác nút Trình xác thực hiệu quả với số dư lên tới 32 ETH được hợp nhất thành một trình xác thực lớn với số dư hiệu dụng lên tới 2048 ETH. Số dư hiệu dụng đề cập đến số dư ETH đã đặt cược mà người xác nhận nhận được phần thưởng phát hành. Số dư trên 32 ETH không mang lại cho người xác thực nhiều phần thưởng phát hành hơn, đó là lý do tại sao các nhà khai thác nút phải chạy nhiều trình xác thực để tăng phần thưởng phát hành của họ. EIP 7251 nhằm mục đích giảm số lượng trình xác thực đang hoạt động trên Ethereum bằng cách cho phép liên kết trình xác thực và tự động gộp các phần thưởng đặt cược.

Dựa trên các cuộc thảo luận giữa các nhà phát triển và nhóm đặt cược Ethereum lớn như Lido, họ đã đồng ý xem xét các thay đổi đối với EIP để cho phép các trình xác thực được hợp nhất thành các nhóm thông minh trên EL Hoạt động được kích hoạt bởi hợp đồng. Nhà nghiên cứu Alex Stokes của Ethereum Foundation nêu bật bài viết của mình về cách hoạt động của việc hợp nhất trong giao thức và yêu cầu nhóm khách hàng đưa ra phản hồi về những thay đổi mã được đề xuất từ nhóm khách hàng trong một cuộc gọi hội nghị.

EIP 2537

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

Tranh luận về những gì Praha nên bao gồm

Trước cuộc gọi hội nghị tuần này, khách hàng EL The nhóm cuối cùng đã cung cấp bản cập nhật bằng văn bản về các EIP bổ sung mà họ muốn đưa vào Praha, ngoài năm EIP mà họ đã đồng ý đưa vào bản nâng cấp. Beiko đã liên kết các ưu tiên của nhóm khách hàng EL trong chương trình cuộc gọi hội nghị và để duy trì lâu dài, các liên kết như sau:

Tùy chọn Erigo

Tùy chọn Besu

Tùy chọn Reth

Tùy chọn Nethermind

Tùy chọn Geth

Mega EOF Endgame

Nhà phát triển Guillaume Ballet của Geth bày tỏ sự phản đối khi thảo luận về việc đưa các EIP khác vào Praha. Bao gồm các thay đổi về EOF trong việc nâng cấp. Ông lo ngại rằng những thay đổi này có thể gây khó khăn hoặc không thể triển khai Verkle trong bản nâng cấp hậu Praha, được gọi là Osaka. Danno Ferrin, kỹ sư phần mềm trưởng tại Swirlds Labs, phản đối và nói rằng EOF "tương thích 100%" với các thay đổi mã của Verkle. Ballet bày tỏ sự nghi ngờ về đánh giá của Ferrin, nhắc lại cuộc gọi hội nghị ACDE trước đó. Nhận xét về muốn xem EOF trên mạng thử nghiệm Verkle. Beiko giải thích rằng việc đánh giá khả năng tương thích của EOF với Verkle dựa trên chức năng của nó trên mạng thử nghiệm của hard fork trong tương lai là không hợp lý và hỏi Ballet liệu anh ấy có thể làm rõ những lo ngại cụ thể về khả năng tương thích của EOF với Verkle hay không. Ballet không trả lời. Ông tuyên bố rằng không có đặc tả mã nào cho EOF để ông xem xét. Một nhà phát triển đã chia sẻ trong cuộc trò chuyện trên Zoom liên kết thông số EOF mới nhất. EOF dựa trên việc triển khai ứng dụng khách cũng đã được chia sẻ trong cuộc trò chuyện Liên kết sẵn sàng.

Nhà phát triển Geth, Marius van der Wijden đã hỏi EOF sẽ thêm hoặc cập nhật bao nhiêu opcode. Beiko lưu ý rằng theo thông số kỹ thuật mới nhất, EOF sẽ thay đổi 18 opcode. EOF có nguồn gốc từ 10 EIP khác nhau Gói thay đổi mã cho EVM. Van der Wijden cho biết mối quan tâm chính của ông với EOF là độ phức tạp của nó và các nhóm khách hàng sẽ phải mất bao nhiêu công sức để kiểm tra đầy đủ 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ể sẽ "giới thiệu nhiều lỗi đồng thuận mới" và sẽ yêu cầu "thử nghiệm cẩn thận", nhưng tác động tiêu cực của việc không triển khai các EIP này có nghĩa là những cải tiến này đối với EVM sẽ phải đợi thêm hai hoặc ba năm nữa.

Ferrin lưu ý rằng khi các nhà phát triển tranh luận về việc có nên đưa EOF vào bản nâng cấp Thượng Hải hay không, họ phản đối rằng những thay đổi mã này có phạm vi quá hẹp. Giờ đây, Ferrin và các nhà phát triển khác đã nỗ lực làm cho EOF trở nên phổ biến hơn, nhưng các nhóm khách hàng đã phải lùi bước vì những thay đổi về mã quá phức tạp và khó thực hiện. Ferrin cho biết: “Chúng tôi không thể nhận được yêu cầu nhất quán từ tất cả các nhóm nhà phát triển cốt lõi”, đồng thời cho biết thêm rằng thật “thất vọng” khi nghe những lời phàn nàn về EOF trong cả hai phiên bản. Nhóm khách hàng của Reth và Erigon hỗ trợ việc đưa EOF vào Praha. Beiko khuyến nghị các nhà phát triển nên chuyển sang các EIP khác và xem lại cuộc thảo luận về EOF sau cuộc gọi.

Mã hoạt động EIP 3074, AUTH và AUTHCALL

Beiko yêu cầu nhóm khách hàng cung cấp EIP 3074 , rằng là việc giới thiệu các mã opcode AUTH và AUTHCALL, bất kỳ ý tưởng nào. Các opcode này sẽ bổ sung thêm khả năng lập trình cho các tài khoản do người dùng kiểm soát bằng cách cho phép các hợp đồng thông minh ủy quyền các giao dịch từ EOA (tài khoản thuộc sở hữu bên ngoài của Ethereum). Nhiều nhà phát triển tham gia cuộc gọi, bao gồm Georgios Konstantopoulos, Danno Ferrin và "protolambda" đã ủng hộ việc thay đổi mã này. Protolambda đã đề xuất lại đề xuất EIP 7664 của mình, nhằm khắc phục lỗ hổng trong logic EIP 3074 khi tương tác với danh sách truy cập. Nhà phát triển Geth và đồng tác giả EIP 3074, Matt Garnett, còn được gọi là "Lightclient", cho biết EIP 7664 là một ý tưởng hay. Một nhà phát triển khác đã hỏi EIP 3074 sẽ ảnh hưởng như thế nào đến opcode ORIGIN, mã này trả về địa chỉ mà giao dịch được bắt đầu từ đó. Beiko cho biết những tác động này được liệt kê trong EIP và hỏi liệu có nhà phát triển nào phản đối việc thay đổi mã này ở Praha hay không. Không có phản đối.

EIP 2935, lưu trạng thái băm khối lịch sử

Ba lê trong ACDE #184, một sự thay đổi mã sẽ mang lại lợi ích trong tương lai. Nhóm khách hàng của Reth có lập trường "trung lập đến tích cực" đối với EIP, nói rằng coi đây là một thay đổi đơn giản, họ không phản đối việc đưa nó vào Praha. Nhóm khách hàng Erigon có lập trường tương tự, nhưng lưu ý rằng nếu những thay đổi mã lớn hơn như EOF được đưa vào Praha, họ sẽ kém tự tin hơn về việc kết hợp nó vào Praha. Beiko đề nghị tiếp tục thảo luận về các EIP khác và xem xét EIP 2935 sau cuộc gọi.

EIP 7667, tăng chi phí gas của các hàm băm

Người đồng sáng lập Ethereum Vitalik Buterin đã đề xuất một EIP nhằm mục đích tăng chi phí gas của các opcode và tiền biên dịch hàm băm để phù hợp với chi phí thực thi thông qua các hệ thống không có kiến thức (ZK) như ZK EVM. Để biết thêm thông tin về ZK EVM, vui lòng đọc Báo cáo Nghiên cứu Thiên hà. Về động lực định giá lại các hoạt động của hàm băm Ethereum, Buterin đã viết trong EIP 7667Tài liệu có nội dung: "Các mã opcode của hàm băm và chi phí gas biên dịch trước ban đầu được đặt dựa trên thời gian cần thiết để thực thi chúng trên CPU thông thường. Tuy nhiên, sau đó, một lớp triển khai khác không kém phần quan trọng đã xuất hiện: Bằng chứng không có kiến thức (ZK-SNARK) ) hệ thống. Theo tiêu chuẩn này, các opcode và tiền biên dịch này được định giá thấp so với các hoạt động khác."

Buterin trong Người gọi nói thêm rằng rất dễ đánh giá thấp rằng bằng chứng ZK sẽ ngày càng trở nên phổ biến, không chỉ để xác thực những thứ như cuộn lên Lớp 2, mà còn trên các chuỗi khối Lớp 1 như Ethereum. Ông nói: “Tôi nghĩ rằng ngay cả trong vòng một hoặc hai năm, chúng tôi có thể có khả năng chứng minh Ethereum L1 trong thời gian thực. Vì vậy, tôi nghĩ điều quan trọng là phải thích ứng với thực tế là không còn sự phân biệt giữa chuỗi ZK và chuỗi không.” -Chuỗi ZK. Sự khác biệt. Về cơ bản, chúng tôi hiện đã bước vào chế độ mà mọi chuỗi nghiêm túc đều là chuỗi ZK."

Do những thay đổi về giá khí đốt và lịch trình do Verkle trong quá trình nâng cấp Osaka, Ferrin khuyến nghị rằng EIP này nên được triển khai cùng với Verkle. Nhà nghiên cứu Carl Beekhuizen của EF cho biết EIP này cần phải điều tra rất nhiều và các nhà phát triển phải “rất cẩn thận” để phân tích xem những thay đổi về khí này sẽ ảnh hưởng như thế nào đến các hợp đồng thông minh trên Ethereum. Van der Wijden đồng ý với Beekhuizen về việc tiến hành thận trọng đối với EIP này. Ferrin cũng đề xuất rằng những thay đổi này có thể được triển khai trên các bản tổng hợp Lớp 2 trước tiên, trong khi các nhà phát triển Ethereum điều tra thêm về tác động của chúng đối với Lớp 1. Beiko đồng ý và khuyến nghị các nhà phát triển nên xem xét EIP 7667, cùng với Verkle, để đưa vào bản nâng cấp Osaka và đặt cho nó trạng thái "CFI" hoặc "Được xem xét để đưa vào". Không có phản đối.

EIP 7623, tăng chi phí dữ liệu cuộc gọi

Toni Wahrstätter, đồng tác giả của EIP 7623 và Nhà nghiên cứu của EF đã chia sẻ thông tin cập nhật về đề xuất tăng chi phí của calldata và hỏi nhóm khách hàng xem họ nghĩ gì về điều đó. Nhà nghiên cứu Ansgar Dietrichs của EF và nhà phát triển Nethermind Ahmad Bitar đồng ý. Beekhuizen nói thêm rằng khi EIP 7623 được trình bày tại Rollcall mới nhất, một loạt cuộc họp giữa các nhóm tổng hợp Lớp 2, không có phản đối nào về việc triển khai nó. Beiko đề nghị tiếp tục thảo luận về các EIP khác và xem xét EIP này sau trong cuộc gọi.

EIP 7645, đổi tên ORIGIN thành SENDER

Beiko đã yêu cầu nhóm khách hàng cung cấp EIP 7645, đề xuất này nhằm mục đích thay đổi hành vi của opcode ORIGIN để ngăn chặn việc lạm dụng hợp đồng thông minh. Cyrus Adkisson, người đã sớm đầu tư vào Ethereum và viết EIP 7645, đã chỉ ra rằng opcode ORIGIN được cập nhật có Ba con đường khả thi, mỗi con đường có những điểm cân bằng khác nhau. Ferrin cho biết con đường được đề xuất để thay đổi hành vi opcode đòi hỏi sự giám sát cẩn thận của các chuyên gia bảo mật và 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 khuyến nghị các nhà phát triển tiếp tục thảo luận về các EIP khác để có thời gian.

EIP 7547 cùng với danh sách

Beiko đã hỏi ý kiến của các nhà phát triển về việc kết hợp EIP 7547 vào Praha. Đánh giá từ phản hồi từ nhóm khách hàng EL, có vẻ như không có sự hỗ trợ rộng rãi cho việc thay đổi mã này. Beiko khuyên bạn nên loại trừ nó khỏi quá trình nâng cấp. Không có phản đối.

Đề xuất điều chỉnh đường cong phát hành

Dietrichs đề xuất giảm việc phát hành EthereumĐề xuất. 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 khuyến nghị các nhà phát triển thảo luận thêm về giá trị của đề xuất này trong cuộc gọi ACDC.

Xem lại EOF, EIP 7623 và 2935 cho Praha

Các nhà phát triển sau đó đã xem lại EIP được đề xuất cho Praha nhưng vẫn chưa đạt được sự đồng thuận. Beiko hỏi liệu EOF có thể đi kèm với bản nâng cấp Verkle hay không. Ballet phản đối mạnh mẽ ý tưởng này, nói rằng cả hai thay đổi mã đều phức tạp và thực hiện chúng đồng thời sẽ "quá rủi ro". Protolambda nhấn mạnh EIP 7664 là một EIP khác cần được xem xét đưa vào Praha. Garnett nói thêm rằng EIP 7639, một đề xuất để khách hàng ngừng cung cấp dữ liệu lịch sử trước khi nâng cấp hợp nhất (tháng 9 năm 2022), cũng nên được xem xét.

Phản ứng trước những lo ngại rằng việc đưa EOF vào sẽ tạo thêm gánh nặng cho các nhóm khách hàng, nhà phát triển Reth Georgios Konstantopoulos đã khuyến khích các nhà phát triển "cố gắng". Tuy nhiên, vẫn chưa có sự đồng thuận về EOF. Cuối cùng, các nhà phát triển đã đồng ý tiếp tục làm việc trên EOF, cụ thể là thử nghiệm bắt buộc và sau đó xác định xem liệu nó có nên được đưa vào Praha hay không. Họ cũng đồng ý trì hoãn quyết định về EIP 7623. Về EIP 2935, các nhà phát triển đã đồng ý đưa nó vào Praha.

Tóm tắt tất cả các quyết định được đưa ra trong cuộc gọi, Beiko cho biết các nhà phát triển sẽ đưa EIP 3074 và EIP vào mạng phát triển đầu tiên được Pectra 2935 nâng cấp. Theo mạng phát triển này, họ đã đồng ý quyết định có nên đưa EOF và/hoặc EIP 7623 vào mạng phát triển Pectra thứ hai hay không.

「Liên kết gốc‖

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia