Tóm tắt cuộc họp mới nhất của các nhà phát triển cốt lõi Ethereum: Chuẩn bị thực hiện EIP 3074, lộ trình Rollup

Tiêu đề gốc: 《Ethereum All Core Developers Execution Call #186 Writeup》

Tác giả gốc: Christine Kim

Biên soạn gốc: Frost, BlockBeats

Chú thích của biên tập viên:

Cuộc gọi đồng thuận của tất cả các nhà phát triển cốt lõi Ethereum (ACDE) diễn ra hai tuần một lần, chủ yếu thảo luận và phối hợp các thay đổi đối với lớp thực thi Ethereum (EL). Đây là cuộc họp thứ 186 của ACDE, trong cuộc họp này, các nhà phát triển đã thảo luận về công tác chuẩn bị cho việc triển khai Pectra Devnet 0 và EIP 3074. Họ đã trình bày chi tiết về tiến độ của các nhóm khách hàng trong việc chuẩn bị Pectra Devnet 0 và thảo luận về các đề xuất sửa đổi đối với tiêu chuẩn EIP 3074 cũng như tiến độ thử nghiệm liên quan.

Ngoài ra, bài viết còn đề cập đến các vấn đề quan trọng khác, chẳng hạn như thảo luận về các thay đổi mã khác có thể được bao gồm trong nâng cấp Pectra, cũng như thảo luận về cách các thay đổi đối với quy trình EIP của Ethereum bị ảnh hưởng bởi quy trình L2/RIP. Phó giám đốc nghiên cứu của Galaxy Digital, Christine Kim, đã ghi lại các điểm chính của cuộc họp này, BlockBeats đã biên soạn lại như sau:

Vào ngày 25 tháng 4 năm 2024, các nhà phát triển Ethereum đã tụ họp trên Zoom để tham gia cuộc gọi All Core Developers Execution (ACDE) #186. Cuộc gọi ACDE là một chuỗi cuộc họp diễn ra hai tuần một lần, do Tim Beiko, giám đốc hỗ trợ giao thức của Quỹ Ethereum, chủ trì, nơi các nhà phát triển thảo luận và phối hợp các thay đổi đối với lớp thực thi Ethereum (EL). Trong tuần này, các nhà phát triển đã thảo luận về công tác chuẩn bị cho việc triển khai Pectra Devnet 0 và EIP 3074. Họ cũng thảo luận về những EIP nào khác nên được xem xét để đưa vào nâng cấp Pectra, cũng như suy nghĩ rộng rãi về sự thay đổi quản trị trong bối cảnh "lộ trình tập trung vào Rollup" của Ethereum.

Tiến độ mới nhất của Pectra Devnet 0

Beiko đã yêu cầu các nhóm khách hàng chia sẻ tiến độ mới nhất của Pectra Devnet 0 trong cuộc gọi. Marek Moraczyński từ nhóm Nethermind cho biết, Nethermind đã thực hiện tất cả các EIP Pectra và đang tiến hành công việc thử nghiệm. Justin Florentine từ nhóm Besu cho biết, Besu đang triển khai EIP Pectra và chuẩn bị cho việc ra mắt Devnet 0 cùng với họ. Andrew Ashikhmin từ nhóm Erigon nói, "Tôi không chắc Erigon đã sẵn sàng cho toàn bộ bộ EIP của Devnet 0 hay chưa, một phần là vì các tiêu chuẩn của những EIP này vẫn đang thay đổi liên tục và khách hàng Erigon đang chuyển sang phiên bản chính mới Erigon 3, điều này đã chiếm dụng tài nguyên và thời gian của nhóm. Erigon 3 và EIP Pectra sẽ được hoàn thiện và tích hợp cùng nhau vào khách hàng Erigon." Nhóm Geth cho biết, "Lightclient" cho biết, Geth còn "vài ngày nữa" để chuẩn bị cho Devnet 0. Gajinder Singh từ nhóm Ethereum JS cho biết, Ethereum JS cũng sẽ "chuẩn bị cho Devnet 0".

EIP -7685

Lightclient đã hợp nhất EIP 7685, tạo ra một khung chung để lưu trữ các yêu cầu được kích hoạt bởi EL vào lớp đồng thuận (CL) và ảnh hưởng của nó đối với EIP 6110 và 7002. Beiko cho biết, các nhà phát triển nên đưa EIP này vào phiên bản Devnet 0 của họ và tiếp tục hoàn thiện EIP Pectra.

Về thử nghiệm, Mario Vega từ nhóm thử nghiệm EF cho biết, thử nghiệm EIP 6110 và 2537 đã hoàn thành, thử nghiệm EIP 7002 và EIP 2935 sẽ hoàn thành trong tuần này hoặc tuần sau. Thử nghiệm EIP 3074 vẫn chưa sẵn sàng cho Devnet 0. Nhà nghiên cứu EF Antonio Sanso cho biết, tiêu chuẩn EIP 2537 đã được cập nhật và các vector thử nghiệm mới đã được thêm vào kho GitHub, anh khuyên mọi người nên xem trên GitHub. Nhà nghiên cứu EF Hsiao Wei Wang chỉ ra rằng có lỗi trong các vector thử nghiệm của tiêu chuẩn CL, vì vậy lỗi đã nhanh chóng được sửa và phiên bản mới đã được phát hành.

Cập nhật EIP -3074

Cuộc gọi ACDE tuần này đã đề xuất một số thay đổi đối với tiêu chuẩn EIP 3074. Ahmad Mazen Bitar đã đề xuất thay đổi hành vi của EIP 3074 để cho phép thực hiện DELEGATECALL trước AUTH CALL, điều này sẽ mở rộng các trường hợp sử dụng của EIP. Người sáng lập và CEO của hệ điều hành ví blockchain ZeroDev, Derek Jiang, đã đề xuất tạo ra một "noncemanager" để thuận tiện cho việc hủy bỏ AUTH toàn cầu và các thay đổi khác khi cần thiết. Một số nhà phát triển tham gia cuộc gọi cho rằng nên hoãn các thay đổi đối với EIP 3074, vì điều này sẽ làm tăng đáng kể độ khó trong việc triển khai.

Beiko đã đề xuất các nhà phát triển thảo luận về các thay đổi đề xuất đối với EIP 3074 trong một cuộc họp nhóm riêng. Ông chỉ ra rằng để có đủ thời gian triển khai EIP 3074 trong Pectra, các nhà phát triển nên cố gắng "xác định tiêu chuẩn cuối cùng của nó trong vòng một hai tháng tới". Lightclient đồng ý tổ chức cuộc họp nhóm EIP 3074. Đối với Devnet 0, Beiko xác nhận rằng các nhóm khách hàng nên triển khai EIP 3074 mà không có bất kỳ thay đổi nào, ngay cả khi các nhà phát triển có thể quyết định triển khai EIP theo cách khác trong devnet tương lai hoặc loại bỏ hoàn toàn nó khỏi nâng cấp.

Ngoài các chi tiết triển khai của EIP 3074, các nhà phát triển cũng đã thảo luận nghiêm túc về việc EIP có đủ sự hỗ trợ từ cộng đồng hay không. Một nhà phát triển có tên hiển thị là "Siri" đã bày tỏ lo ngại trong cuộc gọi, "EIP 3074 về nguyên tắc là rất tệ, sẽ làm chậm tốc độ chúng ta đạt được sự trừu tượng tài khoản hoàn toàn." Beiko đã phản hồi rằng, theo các cuộc thảo luận của các nhà ảo thuật Ethereum và cuộc gọi ACD, các nhóm khách hàng dường như ủng hộ EIP 3074, thay vì các đề xuất khác liên quan đến trừu tượng tài khoản (AA). Beiko cho biết: "Đây dường như là đề xuất có sự đồng thuận nhất trong ngắn hạn, chúng ta thực sự có thể cải thiện trạng thái EOA trong lần phân nhánh tiếp theo." Đối với điều này, Siri cho rằng các nhóm khách hàng không nên đưa ra quyết định này một cách đơn độc. "Chúng ta nên lắng nghe ý kiến của các bên liên quan khác," Siri nói, và bổ sung, "Chúng ta không muốn chuyển sang lĩnh vực tạo ra các phân nhánh cứng gây tranh cãi. … Tôi nghĩ tốt hơn là hiểu quan điểm của các bên liên quan khác và họ nghĩ gì về đề xuất này."

Beiko và Siri cũng đã thảo luận về cách xây dựng sự đồng thuận rộng rãi hơn cho EIP bên ngoài cuộc gọi ACD. Chiang đã đề xuất tổ chức một cuộc họp nhóm EIP 3074 trước, để thảo luận sâu về các tiêu chuẩn kỹ thuật của EIP, sau đó quyết định xem có nên giữ nó trong nâng cấp Pectra hay không. Nhà nghiên cứu EF Ansgar Dietrichs cho biết "chúng ta nên hiểu rằng, trừ khi chúng ta đạt được tiến bộ đủ, EIP 3074 sẽ bị rút lui."

Người đồng sáng lập Ethereum Vitalik Buterin đã bổ sung rằng, "Chức năng tài khoản của người dùng sẽ thay đổi trong vài năm tới, đặc biệt là đối với tài khoản do bên ngoài sở hữu (EOA). Kích hoạt các EIP liên quan đến trừu tượng tài khoản, chẳng hạn như EIP 3074."

Các đề xuất khác của Pectra

Các nhà phát triển tiếp tục thảo luận về những thay đổi mã khác nào nên được xem xét để đưa vào nâng cấp Pectra. Nhà phát triển Geth Marius van der Wijden cho biết, điều này nên phụ thuộc vào việc các EIP có độ phức tạp cao như EOF có được đưa vào Pectra hay không. "Nếu chúng ta bao gồm EOF, thì điều đó sẽ dẫn đến sự bão hòa phân nhánh. Nếu chúng ta không bao gồm EOF, có thể chúng ta có thể bao gồm nhiều nội dung hơn," van der Wijden nói.

Siri bày tỏ lo ngại về việc đưa EIP 3074 vào Pectra mà không có kiểm tra an toàn. Beiko đã đề xuất hoãn cuộc thảo luận này cho đến khi tiêu chuẩn EIP 3074 được xác định cuối cùng.

Bitar cho biết, anh hy vọng thấy EIP 7212 được thêm vào Pectra. EIP 7212 sẽ tạo ra một bản biên dịch mới để thực hiện xác minh chữ ký trong đường cong elip secp256 r1. Điều này có thể được sử dụng cùng với các thiết bị phần cứng hỗ trợ nhận diện sinh trắc học của người dùng. Bitar cho biết, việc hỗ trợ sinh trắc học để ký các giao dịch Ethereum sẽ là một cải tiến lớn cho trải nghiệm người dùng. Ashikhmin cho biết, anh cũng ủng hộ đề xuất này. Dietrichs chỉ ra rằng, đây là đề xuất duy nhất đã được phê duyệt để triển khai thông qua quy trình "Đề xuất cải tiến Rollup" (RIP) bởi các Rollup Layer-2.

Các nhà phát triển khác bao gồm Dietrichs, van der Wijden và Moraczyński đều bày tỏ sự ủng hộ đối với EIP 7623, điều này sẽ làm tăng chi phí dữ liệu cuộc gọi, từ đó giới hạn kích thước khối tối đa. Beiko đã đề xuất đánh dấu EIP 7623 và EIP 7212 là "được xem xét để đưa vào" hoặc CFI vào Pectra, và xem xét lại băng thông của các nhóm khách hàng để hỗ trợ hai đề xuất cải tiến này sau khi Devnet 0 được khởi động.

Về gói EIP liên quan đến việc cập nhật phương pháp tuần tự của EL thành SSZ, van der Wijden bày tỏ lo ngại rằng việc vận chuyển chúng trong Pectra sẽ quá khó khăn. Đồng nghiệp của anh trong nhóm Geth, Guillaume Ballet, cũng đồng ý với đánh giá này. Buterin đã xen vào, "Ít nhất việc cập nhật phương pháp tuần tự của biên nhận giao dịch sẽ có 'giá trị lớn' vượt ra ngoài Ethereum, vì nó loại bỏ chi phí kiểm toán an toàn bổ sung cho các Rollup Layer 2 được xây dựng trên Ethereum." Người ủng hộ chính cho các EIP liên quan đến SSZ, Etan Kissling từ nhóm Nimbus, không tham dự cuộc gọi, nhưng anh đã viết một giải thích chi tiết trên GitHub về lý do tại sao những thay đổi mã này quan trọng và nên được xem xét để đưa vào Pectra.

Các nhà phát triển cũng đã thảo luận lại về EOF. Nhà phát triển giao thức Ethereum độc lập Danno Ferrin cho biết, nhóm EOF đang tiến hành thử nghiệm tiêu chuẩn EL cho các thay đổi mã. EVMOne và Reth là hai nhóm khách hàng EL, được báo cáo đã hoàn thành việc triển khai EOF. Ferrin cho biết, nhóm Geth đã đạt được "tiến bộ tốt" trong việc triển khai. Ferrin bổ sung rằng, Ballet đang làm việc với "Daniel" từ nhóm Solidity để giải quyết những lo ngại về tính tương thích với EOF và Verkle.

Ballet chỉ ra rằng, theo cuộc trò chuyện của anh với Daniel và các nhà phát triển khác như Dietrichs, rất khó để thu hẹp phạm vi của EOF mà không vi phạm mục đích của nó và tạo ra nhiều công việc hơn cho các nhà phát triển trong việc triển khai một nhóm thay đổi mã tương tự như EOF trong tương lai.

Một nhà phát triển có tên hiển thị là "Charles C" đã đề xuất tìm kiếm một cách để thực hiện EOF một cách dễ dàng thông qua cơ chế Side Car (ví dụ như cơ chế cho các giao dịch Blob), thay vì phải chọn giữa nâng cấp EOF nhỏ hoặc lớn. Dietrichs đã hỏi trong cuộc trò chuyện rằng, nếu giảm độ phức tạp của EOF trong Pectra, liệu các nhóm khách hàng có quan tâm hơn đến nó không. Nhóm Ipsilon chỉ ra rằng, các thay đổi mã có độ phức tạp cao nhất trong EOF (ví dụ như "TX create") đã được giải quyết, việc xóa các yêu cầu cụ thể như "EOF create" sẽ không làm giảm đáng kể độ phức tạp tổng thể của EOF. Để làm rõ, Ipsilon là tên của nhóm phát triển EVM được Quỹ Ethereum tài trợ. Beiko đã đề xuất các nhà phát triển tiếp tục thảo luận về việc triển khai EOF trong các cuộc thảo luận nhóm EOF lặp đi lặp lại.

ACD / EIP và L2 / RIP

Là chủ đề cuối cùng trong cuộc thảo luận ACDE #186, các nhà phát triển đã thảo luận về việc xem xét quy trình RIP mới ảnh hưởng đến quy trình EIP của Ethereum. Dietrichs chỉ ra rằng, đã sáu tháng kể từ khi các nhà phát triển khởi động chuỗi cuộc họp về phối hợp Rollup, RollCall và quy trình RIP. Vẫn còn một số câu hỏi chưa được giải quyết về cách những quy trình này sẽ và nên ảnh hưởng đến quy trình EIP của Ethereum. Dietrichs cho biết, một vấn đề nghiên cứu đang diễn ra trong L2 là liệu việc có sự tương đương lâu dài với Ethereum Virtual Machine (EVM) là điều mong muốn cho Rollup hay không. Ông cũng bổ sung rằng, một câu hỏi chưa được giải quyết là các thay đổi được triển khai trên L2 sẽ ảnh hưởng đến quyết định quy trình của Ethereum Layer 1 đến mức nào.

Nhà phát triển Geth Péter Szilágyi cho biết, một số chức năng được cung cấp trên L2 có thể không phù hợp để cung cấp trên L1, và trong một số trường hợp, ngay cả khi tuân theo các chức năng được cung cấp trên L2, có thể có sự khác biệt giữa các L2, điều này có thể gây nhầm lẫn cho các nhà phát triển quy trình Ethereum. Nhà nghiên cứu EF Carl Beekhuizen chỉ ra rằng, quy trình RollCalls và RIP không yêu cầu các nhà phát triển quy trình Ethereum phải phát hành bất kỳ chức năng nào trên L2, mà là cải thiện giao tiếp giữa các Rollup và các nhà phát triển Ethereum, để tránh những tình huống gây nhầm lẫn như Szilágyi đã mô tả. Van der Wijden bày tỏ lo ngại về việc các nhà phát triển quy trình dành thời gian hỗ trợ các thay đổi được triển khai trên L2, trong khi những thay đổi này cuối cùng có thể trở nên lỗi thời hoặc không cần thiết, vì L2 tự nó sẽ đóng cửa hoặc ngừng sử dụng.

Đối với những lo ngại này, Dietrichs cho biết: "Tôi nghĩ mọi người luôn nghĩ rằng Layer 2 có thể thử nghiệm và trở nên điên rồ hơn. Tôi nghĩ trong thực tế, chúng ta thấy rằng hầu hết trong số họ quyết định không làm như vậy, hoặc ít nhất có thể bắt đầu như vậy, nhưng theo thời gian, hầu hết đã dừng lại. Vì vậy, bây giờ họ thực sự chủ yếu tuân theo các tiêu chuẩn của lớp một. Tôi nghĩ ít nhất, xét đến lộ trình tập trung vào Rollup, hoặc chúng ta đều nghĩ rằng đây là cách tốt nhất để phát triển hệ sinh thái, chúng ta ít nhất nợ Layer 2 một hướng dẫn và giao tiếp rõ ràng về con đường tốt nhất phía trước."