Cuộc họp đồng thuận tất cả các nhà phát triển cốt lõi (ACDC) của Ethereum được tổ chức hai tuần một lần để thảo luận và điều phối các thay đổi đối với Lớp đồng thuận Ethereum (CL). Đây là cuộc họp ACDC lần thứ 134. Tại hội nghị này, các nhà phát triển đã thảo luận về chi tiết triển khai và các thách thức kỹ thuật của nhiều EIP chính, bao gồm EIP 7549, EIP 7251, EIP 6110, EIP 7688, v.v.
Ngoài ra, các nhà phát triển cũng thảo luận sâu về việc triển khai PeerDAS, một công nghệ lấy mẫu tính khả dụng của dữ liệu được kỳ vọng sẽ cải thiện đáng kể khả năng của mạng Ethereum trong việc hỗ trợ các bản tổng hợp và các yêu cầu về tính khả dụng của dữ liệu của họ. Trong cuộc họp, một đề xuất đã được đưa ra là chia Pectra thành hai hard fork để nâng cấp, đồng thời thảo luận về thời gian kích hoạt cũng như sự phụ thuộc lẫn nhau của các EIP khác nhau.
Đánh giá Devnet 0
Dựa trên sự ra mắt của Pectra trên Devnet 0, nhóm khách hàng đã đồng ý giữ nguyên hành vi xác thực bị ảnh hưởng bởi EIP 7549 trong quá trình kích hoạt hard fork. Tại cuộc họp ACDC trước đó, các nhà phát triển đã xem xét nhiều lựa chọn khác nhau để đảm bảo rằng tác động của EIP 7549 sẽ không dẫn đến một số lượng lớn các xác minh không hợp lệ trong quá trình phân nhánh. Để tránh làm cho việc nâng cấp trở nên phức tạp hơn, nhóm khách hàng đã quyết định kích hoạt EIP 7549 trong cùng thời điểm với các Pectra EIP khác và không thay đổi hành vi xác minh trước và sau phân nhánh.
Liên quan đến EIP 7251, các nhà phát triển vẫn không chắc chắn liệu việc hợp nhất ETH đã staking có được phép kích hoạt từ lớp thực thi (EL) hay không. Đây sẽ là một tính năng lý tưởng cho các nhóm staking như Lido, để việc hợp nhất các cổ phần không phải phụ thuộc vào các nhà khai thác nút mà có thể đạt được thông qua hợp đồng thông minh. Stokes khuyên bạn nên kiểm tra tiến trình của khách hàng khi triển khai hợp nhất staking trình xác thực trong vài tuần trước khi quyết định xem họ nên thực hiện hoạt động EL hay hoạt động CL.
Sau đó, các nhà phát triển đã thảo luận về một số câu hỏi chưa được giải đáp liên quan đến xác nhận cuối cùng về khoản tiền gửi của người xác thực theo EIP 6110. Nhà phát triển Teku Mikhail Kalinin đã tóm tắt các hướng giải quyết những vấn đề này trong một bình luận trên GitHub trước hội nghị. Nhà phát triển Lighthouse “sean” đã đặt ra câu hỏi về việc kiểm soát phiên bản của yêu cầu “GetPayloadBodies” trong Engine API. Stokes khuyến nghị các nhà phát triển nên bày tỏ ý kiến của mình trong yêu cầu kéo được tạo cho vấn đề này trên GitHub.
Những thay đổi của EIP 7549
Nhà phát triển Nimbus Etan Kissling đã đề xuất một thay đổi nhỏ trong việc triển khai EIP 7549. “Đây là về tính ổn định của chỉ mục tổng quát. Khi chúng tôi thêm một trường mới vào giữa vùng chứa, các trường tiếp theo sẽ được chỉ định một chỉ mục mới, điều này sẽ phá vỡ bằng chứng dựa trên EIP 4788 ở cấp độ thực thi (EL), và một số gây hiểu lầm… Vì vậy, tôi khuyên bạn nên chuyển lĩnh vực mới về cuối để tránh cả hai vấn đề”, Kissling giải thích. Không có sự phản đối nào đối với sự thay đổi này. Stokes khuyến nghị các nhà phát triển nên kiểm tra yêu cầu kéo của Kissling trên GitHub .
Một thay đổi khác đối với EIP 7549 được đề xuất tại cuộc họp là thiết kế các yêu cầu và các yêu cầu khác do EL kích hoạt với tư cách là phần bổ sung cho khối EL. Về sự thay đổi này, Kalinin cho biết: “Theo ý kiến của tôi, đây là một giải pháp thiết kế rất tốt, nó đơn giản hóa EL… và về cơ bản nó là một giải pháp thay thế cho các yêu cầu tổng quát trong khối lớp thực thi.” Stokes khuyến nghị nên có chủ đề này. sẽ được thảo luận lại tại cuộc họp CL tiếp theo để các nhà phát triển có thêm thời gian xem xét đề xuất trên GitHub .
Thảo luận về phạm vi Pectra
Có một số EIP tập trung vào lớp đồng thuận (CL) chưa được đưa vào hoặc loại trừ chính thức khỏi bản nâng cấp Pectra. Tại cuộc họp tuần này, các nhà phát triển đã thảo luận về việc có nên thêm EIP 7688 và PeerDAS vào Pectra hay không. EIP 7688 sử dụng một phần cấu trúc dữ liệu SSZ “StableContainer” để đảm bảo khả năng tương thích về phía trước của các thay đổi chứng thực của EIP 7549. Để tìm hiểu một chút về nền tảng, SSZ là cấu trúc dữ liệu được sử dụng trong CL và các nhà phát triển cũng muốn sử dụng nó trong lớp thực thi (EL). Để biết thêm thông tin về quá trình chuyển đổi SSZ, vui lòng xem biên bản cuộc họp trước đó . PeerDAS là một triển khai lấy mẫu tính khả dụng của dữ liệu trên Ethereum và được kỳ vọng sẽ nâng cao đáng kể khả năng của mạng trong việc hỗ trợ các bản tổng hợp và các yêu cầu về tính khả dụng của dữ liệu. Trong thực tế, PeerDAS dự đoán sẽ tăng số lượng giao dịch blob mà người xác nhận có thể đính kèm vào một khối từ 3 lên 64 giao dịch trở lên trên mỗi khối.
Barnabas Busa, kỹ sư vận hành nhà phát triển tại Ethereum Foundation, cho biết các nhà phát triển đã đưa ra phiên bản đầu tiên của PeerDAS trên mạng phát triển. Busa nói: “Tôi nghĩ nhiều khách hàng đã phát hiện ra nhiều vấn đề và khi chúng tôi đạt được tiến bộ đáng kể, chúng tôi luôn có thể khởi động lại mạng lưới phát triển mới”. Stokes đã hỏi các nhà phát triển liệu họ có sẵn sàng thêm PeerDAS vào Pectra mà không gây ra sự chậm trễ trong quá trình nâng cấp hay không.
Một nhà phát triển có biệt danh là “Nishant” đã hồi sinh đề xuất tách kích hoạt PeerDAS khỏi việc kích hoạt các EIP khác trong Pectra. Mặc dù điều này là khả thi nhưng một nhà phát triển khác có biệt danh “atd” nhấn mạnh rằng nếu các nhà phát triển có kế hoạch kích hoạt các bản nâng cấp này lần lượt trong một khoảng thời gian ngắn, người dùng vẫn cần phải nâng cấp phần mềm của họ cùng một lúc. atd nói: “Tôi nghĩ sẽ hơi điên rồ khi thực hiện một đợt fork hai tháng sau một lần nâng cấp khác. Nếu chúng tôi định phối hợp mọi người để nâng cấp ứng dụng khách, chúng tôi không muốn mọi người phải nâng cấp ứng dụng khách hai tháng sau đó. Điều đó sẽ xảy ra.” , thậm chí một chu kỳ phát hành cũng không đủ.”
atd nói thêm rằng theo quan điểm của mình, PeerDAS là thay đổi mã “thú vị” nhất trong EIP được đưa vào và thảo luận trong Pectra. Stokes cho biết ông hy vọng sẽ đưa PeerDAS vào Pectra ngay cả khi nó gây ra sự chậm trễ trong quá trình nâng cấp. Nhà phát triển khách hàng Grandine Saulius Grigaitis đã đề xuất xóa EIP 7549 và EIP 7688 khỏi Pectra để hỗ trợ PeerDAS. Điều này dẫn đến một cuộc thảo luận về chi tiết triển khai EIP 7688. Các nhà phát triển không thể đồng ý về các thay đổi mã và đề xuất sẽ được xem xét lại tại cuộc họp ACDC tiếp theo.
Về chủ đề PeerDAS, các nhà phát triển tiếp tục cân nhắc ý tưởng chia Pectra thành hai hard fork. Kỹ sư tùy chọn nhà phát triển Ethereum Foundation Parithosh Jayanthi cảnh báo rằng nếu các nhà phát triển chia Pectra thành hai bản nâng cấp, họ phải cẩn thận để không thêm thêm EIP trong Pectra Phần 2 trong tương lai. Jayanthi cho biết: “Một điều tôi muốn đề cập là nếu chúng tôi xem xét việc chia thành hai nhánh, chúng tôi phải hết sức cẩn thận để không thêm thêm EIP mới vào lần phân nhánh tiếp theo. Tôi không biết liệu chúng tôi có thể làm được hay không. Cho đến thời điểm này, nếu chúng tôi có thể cam kết thực hiện điều gì đó cách đây một năm hoặc một năm rưỡi, bởi vì chúng tôi luôn đưa ra những ý tưởng mới và các ưu tiên đang thay đổi, v.v.
Tiếp tục thảo luận về hai ý tưởng nâng cấp, nhà phát triển Lighthouse “sean” nói rằng ông không lường trước được nhiều sự phụ thuộc lẫn nhau giữa PeerDAS và danh sách Pectra EIP hiện tại. Do đó, cả hai có thể được thực hiện riêng biệt và sau đó dễ dàng hợp nhất khi nhà phát triển trở nên tự tin hơn trong việc triển khai chúng. Atd đồng ý với quan điểm này và tin rằng không có nhiều rủi ro trong việc hợp nhất Pectra EIP, PeerDAS và EIP 7688 sau khi phát triển và thử nghiệm chúng một cách riêng biệt.
Busa khuyên bạn nên tiếp tục thử nghiệm Pectra EIP và PeerDAS, nhưng thiết kế mã sẽ thay đổi để PeerDAS được kích hoạt muộn hơn một kỷ nguyên so với Pectra EIP trên mạng thử nghiệm và phát triển. Ông lưu ý rằng đây đã là cách tiến hành thử nghiệm Pectra EIP và PeerDAS trên Devnet 0. Busa nói: “Thực sự không có gì cần phải thay đổi”, đồng thời cho biết thêm rằng nếu PeerDAS chưa sẵn sàng khi các Pectra EIP khác sẵn sàng, các nhà phát triển có thể xóa thay đổi mã đó khỏi bản nâng cấp. Điều này đặt ra một số câu hỏi về mức độ ảnh hưởng của các giai đoạn kích hoạt khác nhau của PeerDAS đến công việc của các nhóm khách hàng. Cuối cùng, các nhà phát triển đã đồng ý tiếp tục phát triển PeerDAS và Pectra EIP, nhưng tiền đề là PeerDAS sẽ được kích hoạt ở các thời điểm khác nhau trên mạng phát triển và mạng thử nghiệm.
Như đã đề cập trước đó, các nhà phát triển đã đồng ý để lại cuộc thảo luận về việc liệu EIP 7688 có nên được đưa vào Pectra hay không cho đến cuộc gọi tiếp theo của ACDC.
