Tác giả: Christine Kim, Galaxy; Người biên soạn: Wu Baht, Golden Finance

Vào ngày 12 tháng 9 năm 2024, các nhà phát triển giao thức Ethereum đã gặp nhau qua Zoom cho cuộc gọi hội nghị Thực thi Nhà phát triển Toàn lõi (ACDE) lần thứ 196. Tuần này, cuộc gọi được chủ trì bởi Tim Beiko, người đứng đầu bộ phận hỗ trợ giao thức tại Ethereum Foundation (EF). Cuộc gọi hội nghị ACDE là chuỗi hội nghị hai tuần một lần, 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).

Tại ACDE #196, các nhà phát triển đã chia sẻ các bản cập nhật mới nhất về bản phát hành Pectra Devnet 3 và thảo luận về các thay đổi mã Pectra khác nhau sẽ được triển khai trên mạng phát triển trong tương lai. Họ đã thảo luận nghiêm túc về việc chia bản nâng cấp thành hai phần để có thể phát hành các thay đổi mã trên Devnet 3 theo dòng thời gian nhanh hơn, có thể là vào tháng 2 năm sau. Các nhà phát triển đã đồng ý đưa ra quyết định cuối cùng về vấn đề này trong cuộc gọi ACD tiếp theo. Cuối cùng, một kỹ sư vận hành nhà phát triển EF có tên là "pk910" đã chia sẻ thông tin cập nhật về công việc của anh ấy trong việc dọn dẹp kho lưu trữ GitHub của mạng thử nghiệm công khai Ethereum và tái cấu trúc nó để dễ sử dụng hơn.

Pectra Devnet 3

Kỹ sư EF DevOps Parithosh Jayanthi giải thích về việc phát hành Pectra Devnet 3. Mạng lưới phát triển sẽ ra mắt vào Thứ Tư, ngày 11 tháng 9. Nó bao gồm các bản sửa lỗi cho việc hợp nhất trình xác thực trong EIP 7251 và thông số kỹ thuật cập nhật cho EIP 7702. Dựa trên thử nghiệm trên Devnet 3 cho đến nay, cả EIP 7251 và EIP 7702 đều hoạt động như mong đợi. Jayanthi lưu ý rằng một số vấn đề đã được phát hiện trong ứng dụng khách Nethermind và EthereumJS và hai nhóm khách hàng đang nỗ lực giải quyết chúng. Jayanthi nói thêm rằng kể từ khi EIP 7702 xuất hiện trên Devnet 3, sẽ là một ý tưởng hay nếu để các nhà phát triển ví thử nghiệm việc triển khai và cung cấp phản hồi về việc họ sử dụng nó. Tất cả thông tin về Pectra Devnet 3, bao gồm các vòi để yêu cầu testnet ETH, có thể được tìm thấy trên trang web này.

Cập nhật thông số kỹ thuật Pectra

Nhà phát triển Geth, Felix Lange đã đề xuất các thay đổi đối với việc mã hóa các yêu cầu kích hoạt EL trong Pectra. Về cơ bản, Pectra sẽ cho phép các hợp đồng thông minh trên EL bắt đầu việc rút tiền và hợp nhất của trình xác thực trên CL. Trong cuộc gọi ACD gần đây nhất, Lange đã chia sẻ đề xuất nhằm giảm lượng công việc mà khách hàng EL yêu cầu để phân tích các yêu cầu này. Kể từ cuộc gọi vào tuần trước, Lange đã chính thức hóa các đề xuất của mình và công việc mà nhóm khách hàng EL cần thực hiện để cập nhật mã hóa của bốn EIP sau:

  • EIP 7685, Yêu cầu lớp thực thi chung;

  • EIP 7002, EL có thể kích hoạt việc rút tiền;

  • EIP 6110, tiền gửi xác thực nguồn cung trên chuỗi;

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

Các nhà phát triển nhìn chung đồng ý với đề xuất của Lange. Tuy nhiên, một nhà phát triển Nimbus tên là "Dustin" tin rằng đề xuất này "linh hoạt một cách vô nghĩa" và không tương thích về phía trước với những thay đổi trong tương lai đối với định dạng tuần tự hóa EL. Ông cũng nhấn mạnh rằng cần có các thông số kỹ thuật bổ sung để quy định rõ ràng thứ tự yêu cầu từ khách hàng EL và hành vi của khách hàng CL khi EL gửi yêu cầu không hợp lệ tới CL. Lange đồng ý thêm nhiều văn bản hơn vào API Engine để chỉ định thứ tự yêu cầu. Anh ấy cũng đồng ý với Dustin rằng cần xem xét sâu hơn về hành vi của máy khách CL khi máy khách CL phát hiện yêu cầu không hợp lệ từ máy khách EL.

Nhà nghiên cứu Peter Miller của Ethereum Foundation đã chỉ ra rằng dựa trên hành vi logic của các máy khách CL theo đặc tả hiện tại, các máy khách CL nên từ chối các khối từ EL không được sắp xếp theo cách chính xác. Ngoài ra, nếu có các yêu cầu không hợp lệ trong danh sách được EL chia sẻ với CL, CL chỉ cần xử lý tất cả các yêu cầu hợp lệ trong danh sách và bỏ qua các yêu cầu không hợp lệ. Dustin đồng ý với Miller và khuyến nghị các nhà phát triển nên chỉ định hành vi này trong tài liệu phù hợp. Beiko cho biết các nhà phát triển nên nỗ lực khắc phục các vấn đề trong đề xuất của Lange và hoàn thành nó trước cuộc gọi ACD tiếp theo.

Sau đó, nhà phát triển Erigon Andrew Ashikhmin đã đề xuất bản cập nhật cho EIP 7702, thiết lập mã tài khoản EOA. Ông lưu ý rằng việc kiểm tra tính hợp lệ được chỉ định trong EIP không nhất quán với các quy định trong EIP cũ. Nhà phát triển Geth, Matt Garnett (còn gọi là "Lightclient") cho biết ông có một giải pháp thay thế để giải quyết các vấn đề về tính nhất quán và đơn giản hóa việc kiểm tra tính hợp lệ của EIP 7702. Các nhà phát triển chủ yếu ủng hộ việc hoàn thiện đề xuất Lightclient và thêm nó vào Pectra Devnet 4.

Cuộc thảo luận tiếp theo liên quan đến Pectra là về giá của quá trình biên dịch trước BLS theo EIP 2537. Nhà phát triển Geth, Jared Wasinger cho biết dựa trên phân tích điểm chuẩn của ông, quá trình biên dịch trước BLS sẽ có chi phí cao gấp đôi so với hiện tại. Hiện tại, chi phí được tính dựa trên việc thực thi đa luồng, đây không phải là tiêu chuẩn để định giá các hoạt động thực thi được biên dịch trước khác. Do đó, dựa trên phân tích của mình bằng cách sử dụng thực thi đơn luồng, Wasinger đã đề xuất thay đổi bảng chiết khấu cho các hoạt động trong EIP 2537. Nhóm Nethermind báo cáo rằng họ đang phát triển một công cụ để các nhóm khách hàng khác có thể dễ dàng tiến hành phân tích điểm chuẩn EIP của riêng họ. Beiko đề nghị nhóm tiến hành các tiêu chuẩn riêng của mình về quá trình biên dịch trước BLS và đưa ra ý tưởng về việc định giá lại các hoạt động này trong vòng hai tuần tới.

Bổ sung Pectra EIP

Các nhà phát triển sau đó bắt đầu thảo luận về việc thêm EIP mới để nâng cấp Pectra. Khi bắt đầu cuộc thảo luận, Beiko cảnh báo: "Chúng tôi đã có một số lượng lớn EIP trong Pectra. Đây đã là đợt phân nhánh lớn nhất cho đến nay về mặt khối lượng EIP." Theo quan điểm được chia sẻ bởi các nhà phát triển trước cuộc gọi, Beiko. cho biết, Rõ ràng, EIP 7742 (tách biệt số lượng blob giữa EL và CL) là ít gây tranh cãi nhất trong danh sách các EIP vẫn đang được xem xét để đưa vào bản nâng cấp.

Nhà nghiên cứu Alex Stokes của EF một lần nữa đưa ra ý tưởng chia Pectra thành hai hard fork nhỏ hơn. “Tôi nghĩ mọi người đều đồng ý rằng đây là một fork rất lớn. Vì vậy, việc đương nhiên phải làm là chia nó làm hai. Nói chung, fork nhỏ hơn sẽ ít rủi ro hơn. Đặc biệt, Pectra hiện có rất nhiều EIP xuyên lớp, điều đó thực sự làm tăng gánh nặng kiểm tra, bảo mật và đánh giá,” Stokes nói. Jayanthi, người cũng nêu ra ý tưởng này trong cuộc gọi trước đó, cho biết anh vẫn ủng hộ ý tưởng này. “Tôi nghĩ lý do chính là hiện tại chúng tôi có rất nhiều EIP và chúng tôi có xu hướng chạm vào nhiều lớp của ngăn xếp, và càng thêm nhiều thì bất kỳ ai cũng khó có cái nhìn toàn cảnh về tất cả những thay đổi, ngay cả dưới tải hiện tại", Jayanthi nói.

Về cách chia Pectra EIP hiện tại thành hai nhánh, Stokes đề xuất sử dụng tất cả các EIP hiện đang chạy trên mạng phát triển để phát hành phần đầu tiên của Pectra, sau đó sử dụng PeerDAS, EOF và một số EIP bổ sung khác để phát hành phần thứ hai của Pectra. Các nhà phát triển tự tin rằng bằng cách này, họ sẽ có thể phát hành phần đầu tiên của Pectra vào tháng 2 năm sau. Nhà nghiên cứu Ansgar Dietrichs của EF cho biết trong một cuộc trò chuyện trên Zoom: “Tôi nghĩ đợt fork này sẽ thất bại nếu chúng tôi vẫn chỉ phát hành nửa đầu vào tháng 6”.

Beiko ủng hộ ý tưởng về một phân nhánh, nhưng cảnh báo không nên xóa bất kỳ EIP nào khỏi devnet, vì điều này có thể tạo ra nhiều công việc hơn cho các nhóm khách hàng và kéo dài, thay vì rút ngắn, dòng thời gian chuẩn bị những thay đổi mã này để kích hoạt mạng chính. Nhà phát triển giao thức Ethereum độc lập Danno Ferrin khuyến nghị hoàn thành EIP trên Devnet 3 càng sớm càng tốt để kích hoạt mạng chính, sau đó làm việc song song bắt đầu với Devnet 4 hoặc 5 để chuyển PeerDAS và EOF sang Pectra EIP. Trên thực tế, trong bản nâng cấp sau Pectra, Devnet 4 hoặc 5 sẽ trở thành Devnet 0, và các nhà phát triển cũng chưa biết đặt tên như thế nào.

Trong cuộc gọi trước đó, các nhà phát triển đã đồng ý đặt tên bản nâng cấp theo tên Pectra Fusaka, nhưng họ cũng đồng ý dành bản nâng cấp cho quá trình chuyển đổi Verkle. Lưu ý đó, Ferrin khuyên các nhà phát triển không nên đặt hàng trước các bản nâng cấp cho đến khi họ tin tưởng rằng các thay đổi mã đã sẵn sàng để kích hoạt mạng chính. Điều này đã thu hút sự tức giận của nhà phát triển Geth Guillaume Ballet, người đang dẫn đầu nỗ lực chuyển đổi Verkle và nhấn mạnh rằng quá trình chuyển đổi Verkle đã sẵn sàng "từ lâu". Để giảm bớt căng thẳng, Beiko cho biết mục đích chia đôi Pectra cuối cùng là cố gắng phát hành các thay đổi mã Pectra theo dòng thời gian nhanh hơn, điều này sẽ giúp dọn đường cho quá trình chuyển đổi Verkle sau đó.

Tuy nhiên, có nguy cơ là phần thứ hai của bản nâng cấp Pectra có thể trở nên lớn hơn khi có nhiều EIP được thêm vào và do đó sẽ mất nhiều thời gian hơn để được phát hành so với danh sách Pectra EIP hiện tại được phát hành cùng lúc. Nhà phát triển Nethermind Ben Adams đã đặt câu hỏi về quá trình thử nghiệm của Pectra sẽ hoạt động như thế nào nếu bản nâng cấp được chia thành hai phần. Cho rằng quyết định này sẽ thay đổi hoàn toàn phạm vi nâng cấp ngay lập tức tiếp theo của Ethereum, Beiko khuyến nghị các nhà phát triển nên dành một tuần để xem xét ý tưởng này. Ông yêu cầu các nhà phát triển chuẩn bị đưa ra quyết định cuối cùng về vấn đề này trong cuộc gọi đồng thuận toàn bộ các nhà phát triển cốt lõi vào thứ Năm tới.

Căn chỉnh cấu trúc cấu hình mạng

Cuối cùng nhưng không kém phần quan trọng, Kỹ sư EF DevOps "pk910" đã chia sẻ bản cập nhật về công việc của mình để dọn dẹp kho lưu trữ GitHub của mạng thử nghiệm công khai Ethereum và cơ cấu lại nó để sử dụng dễ dàng hơn. Anh ấy đã yêu cầu nhóm tài khoản kiểm tra cấu hình nút của mạng chính và mạng thử nghiệm Ethereum, đồng thời thêm mọi thông tin còn thiếu vào kho lưu trữ tương ứng.

#ETH