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: Nâng cấp Pectra có thể được chia thành hai hard fork
Tiêu đề gốc: "Lời kêu gọi đồng thuận của tất cả các nhà phát triển cốt lõi của Ethereum #134 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 gọi đồng thuận dành cho tất cả các nhà phát triển cốt lõi của Ethereum (ACDC) đượ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 gọi hội nghị 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 nhánh cứng để nâng cấp và các vấ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 đã được thảo luận.
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:
Đá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 Nó đã được đồ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 phức tạp thêm việc nâng cấp, 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 mà không thay đổi hành vi xác thực trước và sau phân nhánh.
Về 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 đặt cược 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 đặt cược 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à thay vào đó có thể được thực hiện 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 đặt cược trình xác thực trong vài tuần trước khi quyết định xem họ nên hoạt động EL hay 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 đã kết luận trong Nhận xét GitHub trước hội nghị về các giải pháp cho những vấn đề này. Nhà phát triển Lighthouse "sean" đã đặt ra câu hỏi về việc tạo phiên bản cho yêu cầu "GetPayloadBodies" trong API Engine. Stokes khuyến nghị các nhà phát triển nên xuất bản tác phẩm của họ trong yêu cầu kéo được tạo cho vấn đề này trên Chế độ xem GitHub .
Những thay đổi về EIP 7549
Nhà phát triển Nimbus Etan Kissling đã đề xuất một thay đổi đối với việc triển khai EIP 7549. Sự thay đổi nhỏ. "Đâ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 các nhà phát triển nên xem 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 sẽ 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 các 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 GitHub Đề xuất này.
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 chính thức phê duyệt bao gồm hoặc loại trừ trong bản nâng cấp Pectra xa hơn. 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. Như phần giới thiệu cơ bản, 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, hãy xem trước Minutes của cuộc họp. PeerDAS là một triển khai lấy mẫu tính khả dụng của dữ liệu trên Ethereum, đượ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ự kiế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 hoặc nhiều hơn trên mỗi khối.
Kỹ sư vận hành nhà phát triển Ethereum Foundation Barnabas Busa 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 "Nishant" đã khôi phục đề xuất tách việc 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 loại bỏ EIP 7549 và EIP 7688 khỏi Pectra để thay thế cho PeerDAS. Điều này đã thúc đẩy cuộc thảo luận về chi tiết triển khai của EIP 7688. Các nhà phát triển không thể đồng ý về những thay đổi trong quy tắc và đề xuất này 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. Đế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ì đó từ một năm hoặc một năm rưỡi trước, 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 ý, lập luận rằng sẽ không có nhiều rủi ro khi 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 nghị tiếp tục thử nghiệm Pectra EIP và PeerDAS, nhưng thiết kế các thay đổi mã để PeerDAS được kích hoạt muộn hơn một kỷ nguyên so với Pectra EIP trên các mạng thử nghiệm và phát triển. Ông lưu ý rằng đây đã là cách thử nghiệm Pectra EIP và PeerDAS được thực hiện 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 đưa EIP 7688 vào Pectra cho đến cuộc gọi tiếp theo của ACDC.
「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
Bài viết liên quan
