Tựa gốc: "Cuộc gọi thực thi tất cả các nhà phát triển cốt lõi của Ethereum #189 Writeup" Tác giả gốc: Christine Kim Biên soạn gốc: Luccy, BlockBeats Ghi chú của biên tập viên: Cuộc gọi thực thi 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, 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 gọi hội nghị lần thứ 189 của ACDE. Tại cuộc họp này, các nhà phát triển đã thảo luận một số vấn đề quan trọng trong bản nâng cấp Pectra, bao gồm các thay đổi bao gồm EOF và EIP 7702, cải thiện phạm vi Pectra và chuẩn bị cho khía cạnh chuyển đổi Verkle. Cuộc họp cũng thảo luận về cách EOF và Pectra EIP khác được đóng gói và cách kiểm tra những thay đổi mã này. Ngoài ra, một số đề xuất đã được đưa ra để cải thiện quy trình nâng cấp mạng Ethereum, bao gồm điều chỉnh tần suất thảo luận về chủ đề cuộc gọi hội nghị ACD và đề xuất nhãn EIP mới. Tiến trình tích hợp EIP 4444 và Portal Network cũng được đề cập. 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 6 tháng 6 năm 2024, các nhà phát triển Ethereum đã tập trung trên Zoom để tham gia cuộc gọi số 189 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 đã đồng ý đưa EOF và EIP 7702 vào bản nâng cấp Pectra. Để tránh sự chậm trễ trong quá trình nâng cấp thử nghiệm nhiều khách hàng do những thay đổi mã này, các nhà phát triển đã đồng ý kích hoạt EOF trên mạng sau phát triển, có thể ở một chu kỳ kích hoạt khác với các EIP khác, giống như các nhà phát triển dự địnhthử nghiệm PeerDAS . Họ cũng thảo luận về cách ngừng hoạt động EIP 158 trong bản nâng cấp Osaka để chuẩn bị cho Verkle và các bước tiếp theo để triển khai EIP 4444 thông qua tích hợp với Portal Network. Cuối cùng, Beiko và nhóm Điều hành Nhà phát triển EF (DevOps) đã chia sẻ những cập nhật mới nhất về quy trình quản trị và các kênh liên lạc để lập kế hoạch nâng cấp Ethereum.

Phạm vi của Pectra

Trước cuộc họp ACD tuần này, nhiều nhóm khách hàng EL và nhóm EF DevOps đã chia sẻ suy nghĩ của họ về phạm vi của Pectra.

Dựa trên các ý kiến ​​được chia sẻ trước cuộc họp, rõ ràng là phần lớn các nhóm khách hàng ủng hộ việc đưa EOF vào Pectra. Nhóm khách hàng duy nhất phản đối mạnh mẽ EOF là Geth. Nhà phát triển Geth Guillaume Ballet cho biết: "Tôi lo lắng rằng chúng ta càng chờ đợi thì Verkle càng mất nhiều thời gian để chuyển đổi. EOF có thực sự cấp bách đến thế không? Tôi không nghĩ vậy. Tôi đã đọc một số lập luận ủng hộ việc phát hành EOF trong Praha "Càng đọc, tôi càng nhận ra rằng không có gì thực sự chứng minh được EOF là cần thiết." Một số nhà phát triển đã phản đối.

Một nhà phát triển có tên "Kamil Sliwak" cho biết EOF sẽ là "một cải tiến lớn" từ góc độ người dùng tương tác với trình biên dịch ngôn ngữ lập trình hợp đồng thông minh Ethereum Solidity. Nhà phát triển Reth, Dragan Rakita nói thêm rằng sẽ thật thiếu trung thực khi nghĩ rằng EOF sẽ trì hoãn đáng kể quá trình chuyển đổi Verkle. Rakita nói: “Chúng tôi đang nói về việc kéo dài thời gian chuyển đổi từ 10% đến 20%. EOF sẽ không tăng trạng thái và ba tháng bổ sung để phát hành thêm một phần fork sẽ không làm trì hoãn đáng kể Verkle”. Để biết thêm thông tin về EOF là gì và nó sẽ cải thiện Máy ảo Ethereum (EVM như thế nào), hãy nghe tập này của podcast Infinite Jungle .

Beiko đã hỏi các nhà phát triển xem họ muốn gộp EOF với EIP của Pectra khác hay chia EIP của Pectra thành hai nhánh cứng. Nhà phát triển Erigon Andrew Ashikhmin cho biết ông tin rằng các nhà phát triển nên cố gắng phát hành tất cả các EIP của Pectra cùng nhau hoặc trì hoãn EOF cho đến sau quá trình chuyển đổi Verkle. “Điều cuối cùng tôi muốn là một fork giữa Pectra và Verkle sẽ giải phóng EOF. Bởi vì tôi đồng ý với Guillaume rằng bang đang phát triển, tôi nghĩ Verkle quan trọng hơn EOF. Vì vậy, theo tôi, đây là kết quả tồi tệ nhất có thể xảy ra. " Ashikhmin nói. Beiko khuyên bạn nên phát hành tất cả EIP của Pectra, bao gồm cả EOF, trong một phiên bản máy khách. Tuy nhiên, vì mục đích thử nghiệm, ông cho biết các nhà phát triển nên cân nhắc việc sử dụng mạng phát triển để triển khai những thay đổi mã này theo từng giai đoạn. Beiko nói: “Sử dụng mạng phát triển như một cách để chúng tôi ưu tiên thử nghiệm nhiều khách hàng và sau đó nếu chúng tôi thấy EOF trì hoãn mọi thứ trong một thời gian dài, chúng tôi có thể quyết định chia nhỏ nó ra”.

Giữa các cuộc thảo luận này về cách kết hợp EOF vào Pectra, các nhà phát triển Geth tiếp tục bày tỏ nghi ngờ trong cuộc trò chuyện trên Zoom và trong suốt cuộc họp về việc liệu EOF có nên được đưa vào bản nâng cấp hay không. Trả lời cuộc tranh luận đang diễn ra của nhóm Geth về EOF, nhà phát triển Reth George Konstantinopoulos nói: "Hãy cứ làm đi. Có một chút khó hiểu về việc cuộc trò chuyện sẽ diễn ra ở đâu. Chúng tôi không ngại kéo dài quá trình chuyển đổi Verkle thêm vài ngày. Dữ liệu cho thấy rằng trạng thái đang giảm, vì vậy đây là một lập luận khó hiểu và bạn có rất nhiều ứng dụng cho bạn biết đây là một tính năng tốt, vậy tại sao chúng ta lại phải cân nhắc việc không triển khai nó khi hầu hết mọi người đều ủng hộ nó?”

Beiko đồng ý và nhắc lại rằng EOF nên được đưa vào Pectra nhưng được thử nghiệm theo từng giai đoạn trên mạng phát triển, nghĩa là các nhóm khách hàng nên thử nghiệm trên các EIP Devnet 1 đã được triển khai trên Devnet 0. Sau đó, trên mạng phát triển trong tương lai, hãy thêm EOF để thử nghiệm. Chiến lược này sẽ đảm bảo rằng nhóm khách hàng tập trung vào việc phát hành một phần EIP của Pectra theo cùng một dòng thời gian và có thể tiếp tục đạt được tiến bộ trên mạng phát triển nhiều khách hàng. Mario Vega, kỹ sư DevOps tại Ethereum Foundation (EF), cho biết ông hy vọng sẽ hoàn thành các bài kiểm tra đặc tả lớp thực thi (EL) của EOF trong vòng hai tháng. Kỹ sư Parithosh Jayanthi của EF DevOps cho biết EOF có thể được kiểm tra riêng biệt với các EIP lớp thực thi (EL) khác trong Pectra. Tuy nhiên, ông lo ngại về sự phụ thuộc lẫn nhau giữa các EIP lớp đồng thuận (CL) trong Pectra và sự phức tạp của việc kiểm tra những thay đổi mã này.

Nhà phát triển trình biên dịch Vyper, Charles Cooper, cho biết theo quan điểm của ông, EOF không khẩn cấp bằng những thay đổi mã mà ông đề xuất để bảo vệ chống lại các cuộc tấn công reentrancy rẻ và phổ biến. Beiko nhắc Cooper rằng mặc dù có sự đồng thuận rộng rãi về EOF nhưng vẫn chưa rõ liệu các nhóm khách hàng có đủ năng lượng để bổ sung thêm nhiều thay đổi mã hay không, chẳng hạn như những thay đổi liên quan đến các cuộc tấn công reentrancy. Beiko nói: “Tôi nghĩ rõ ràng là nếu chúng tôi tiếp tục phát triển EOF thì sẽ còn rất ít năng lượng để làm những việc khác. Đây sẽ là đợt fork lớn nhất cho đến nay”.

Ngoài việc bao gồm EOF, các nhà phát triển cũng đồng ý sử dụng EIP 7702 để thay thế cho EIP 3074. Các nhà phát triển vẫn đang thảo luận về các thông số kỹ thuật của EIP 7702 trong các cuộc họp nhóm riêng biệt . Beiko đề xuất cách tiếp cận tương tự với EOF cho EIP 7702. "Tôi sẽ đưa nó vào fork, nhưng nếu chúng tôi không hài lòng với thông số kỹ thuật, đừng biến nó thành một phần của Devnet 1 hoặc 2, sau đó dành tháng tiếp theo để phân loại lại thông số kỹ thuật để chúng tôi có được bản thu hồi A tốt hơn cơ chế hơn những gì được đề xuất hiện nay. Một EIP không quá lớn sẽ được thêm vào sau trong quá trình này”, Beiko nói. Nhà phát triển Geth "Lightclient" cho biết nếu nhóm khách hàng đã sẵn sàng, họ nên triển khai EIP 7702 càng sớm càng tốt. Không có phản đối nào về việc đưa EIP 7702 vào mạng phát triển Pectra khẩn cấp tiếp theo, Devnet 1.

đặc điểm kỹ thuật Pectra

Sau đó, nhà phát triển Teku Mikhail Kalinin đã chia sẻ một số cập nhật cho thông số kỹ thuật Pectra EIP hiện có. Đầu tiên là đề xuất xử lý các yêu cầu kích hoạt lớp đồng thuận (CL) thông qua cơ chế sidecar thay vì trực tiếp trong khối lớp thực thi (EL). Nhà phát triển Prysm "Potuz" đã chỉ ra rằng chiến lược này sẽ phá vỡ logic cần thiết cho những thay đổi mã trong tương lai, cụ thể là sự phân tách rõ ràng giữa người đề xuất và người xây dựng (ePBS). “Khối beacon không nên dựa vào tải trọng đã có sẵn ở đó. Vì vậy, cho dù đó là rút tiền hay gửi tiền, bạn không muốn khối beacon phụ thuộc vào những gì có trong tải trọng vì điều đó sẽ phá vỡ luồng ePBS,” Potuz nói. Do vấn đề này, Kalinin đã đồng ý rút lại đề xuất của mình và đóng yêu cầu kéo trên GitHub.

Kalinin đã chia sẻ một số thay đổi khác đối với thông số kỹ thuật EL và API động cơ của Pectra, một trong số đó là cho phép hợp nhất EL được kích hoạt theo EIP 7251, tăng MAX_EFFECTIVE_Balance. Beiko khuyến nghị các nhà phát triển nên xem xét những thay đổi này trước lệnh gọi ACD tiếp theo để chúng có thể được hoàn thiện và sẵn sàng thử nghiệm trong Devnet 1.

Chuẩn bị Verkle

Dựa trên công trình của mình về quá trình chuyển đổi Verkle, Ballet nói rằng EIP 158 sẽ gây ra các vấn đề tương tự với opcode SELFDESTRUCT không được dùng nữa. Để tránh những rắc rối trên mạng sau khi chuyển đổi, Ballet khuyên bạn nên tắt EIP 158 trong các bản nâng cấp Pectra. Tuy nhiên, ông lưu ý rằng nếu việc triển khai EIP 7702 được tinh chỉnh ở Pectra thì việc ngừng hoạt động EIP 158 có thể bị trì hoãn và trùng với quá trình chuyển đổi Verkle. Beiko đề nghị Guillaume bắt đầu soạn thảo đề xuất hủy kích hoạt EIP 158.

Lịch sử hết hạn

Ngoài Pectra và Verkle, các nhà phát triển giao thức Ethereum cũng đang nghiên cứu EIP 4444, một ngày hết hạn lịch sử. Như đã nêu trong tài liệu tóm tắt và kế hoạch EIP 4444 , lý do cho sự thay đổi mã này là do "lịch sử khối chiếm nhiều dung lượng trên nút và khi khối đã được hoàn thành, nó chỉ cần thiết cho sự không đồng thuận hạn chế." các trường hợp sử dụng quan trọng." Tài liệu tiếp tục nêu rõ , "Lịch sử khối sẽ không còn được lưu trữ vĩnh viễn bởi các nút đầy đủ. Sau một khoảng thời gian, nó sẽ bị xóa khỏi nút và các thực thể cần nó sẽ cần truy vấn nó từ đó. ở nơi khác." Mạng Cổng thông tin là một Mạng thay thế, phi tập trung, được sử dụng bởi các nút để truy vấn dữ liệu lịch sử Ethereum.

Merriam nhắc lại sự sẵn lòng của nhóm ông trong việc cung cấp hỗ trợ tích hợp với Portal Network cho các nhóm tài khoản EL. Ông cho biết, nếu không có bất kỳ sự hỗ trợ nào, quá trình tích hợp sẽ mất khoảng sáu tháng để phát triển. Tuy nhiên, với sự hướng dẫn và hợp tác chặt chẽ, ông lạc quan rằng EIP 4444 có thể đạt được tiến bộ đáng kể trong vòng hai tháng tới. Jayanthi hỏi liệu đã có cuộc kiểm tra bảo mật đối với đặc tả Mạng Cổng thông tin hay chưa. Merriam nói không. Nhà nghiên cứu Ansgar Dietrichs của Ethereum Foundation đã hỏi liệu các nhóm khách hàng có thể tự quyết định cách giao tiếp với mạng hay không, bao gồm tích hợp gói với khách hàng hiện tại, xây dựng khách hàng mới hay không thực hiện bất kỳ tích hợp nào cả. Merriam xác nhận rằng quyết định này là theo quyết định của nhóm khách hàng.

Merriam đã hỏi nhóm tài khoản EL trong cuộc gọi về tiến trình và ý định của họ đối với EIP 4444. Nhà phát triển Nethermind Łukasz Rozmej cho biết: “Nhìn chung, đó là một ưu tiên. Chúng tôi thậm chí đã có cuộc họp với nhóm Portal ngày hôm qua. Vấn đề là có quá nhiều ưu tiên. Vì vậy, đó là một ưu tiên kém cấp bách hơn. , chẳng hạn như một hard fork, nhưng Nethermind sẽ nỗ lực phát triển nó và chúng tôi sẽ ưu tiên nó." Nhà phát triển Besu Matt Nelson cho biết anh ấy cũng cảm thấy như vậy. Nhà phát triển Geth Guillaume Ballet cho biết nhóm của ông chưa thảo luận về việc tích hợp Portal Network.

Cải tiến quy trình ACD

Cải tiến quy trình ACD Tiếp theo, Beiko đã chia sẻ một số đề xuất để cải thiện quy trình nâng cấp mạng Ethereum. Trước tiên, anh ấy đề xuất giảm tần suất thảo luận về các cuộc gọi ACD về các chủ đề mà nhóm tài khoản chưa xem xét chi tiết. Beiko khuyên bạn nên gắn cờ các chủ đề này để xem xét trong cuộc gọi ACD trước khi cho phép các nhà phát triển tham gia vào các cuộc thảo luận chuyên môn và sau đó thảo luận chi tiết hơn về các cuộc gọi ACD tiếp theo nếu cần.

Đề xuất thứ hai mà Beiko đưa ra liên quan đến trạng thái “Cân nhắc để đưa vào” (CFI) thường được gắn với Đề xuất cải tiến Ethereum (EIP) đang được xem xét để đưa vào một hard fork. Trạng thái này trước đây không phải là một chỉ báo hữu ích về việc EIP nào có nhiều khả năng được đưa vào hard fork hơn. Beiko đề xuất tạo một nhãn khác, "Đang chờ đưa vào" (PFI), để các nhà phát triển có thể phân biệt rõ hơn EIP nào có nhiều khả năng được đưa vào hard fork và EIP nào không.

Nhà nghiên cứu Ansgar Dietrichs của Ethereum Foundation đã viết trong một cuộc trò chuyện trên Zoom rằng việc tạo nhãn mới cho EIP là “một hướng đi sai lầm” và sẽ chỉ dẫn đến việc nhãn CFI trở nên “hoàn toàn vô dụng”. Beiko cho biết các nhà phát triển có thể tiếp tục thảo luận về việc cải thiện quy trình nâng cấp mạng trên GitHub và EthMagicians.

Ngoài ra, Mario Vega, kỹ sư DevOps tại Ethereum Foundation, cho biết anh hy vọng sẽ tạo ra một kênh con Discord mới để cập nhật liên quan đến thử nghiệm. Vega cho biết hiện tại trong Ethereum R&D Discord, thông tin phát hành thử nghiệm nằm rải rác trên nhiều kênh. Tuy nhiên, anh hy vọng diễn đàn mới sẽ trở thành nơi tham khảo “một cửa” cho các nhóm khách hàng nhận được các bản cập nhật thử nghiệm từ nhóm DevOps của Ethereum Foundation. Anh ấy đã yêu cầu nhóm tài khoản cung cấp phản hồi về việc này.

Cuối cùng, Beiko nhắc nhở các nhà phát triển rằng hai cuộc họp nhóm được lên lịch trong vài ngày tới, một trên ePBS, sẽ được tổ chức vào ngày 7 tháng 6 và một cuộc họp khác trên PeerDAS, sẽ được tổ chức vào ngày 11 tháng 6.