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 #129"

Tác giả gốc: Christine Kim

Bản tổng hợp gốc: Luccy, BlockBeats

Lưu ý của biên tập viên:

Cuộc kêu gọi đồng thuận của 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 sự phát triển của Ethereum .Các thay đổi đối với Lớp đồng thuận (CL). Đây là cuộc gọi hội nghị ACDC lần thứ 129. Trong cuộc họp, các nhà phát triển đã chia sẻ bản cập nhật cuối cùng về việc chuẩn bị nâng cấp Dencun và thảo luận về phạm vi cũng như EIP của bản nâng cấp Ethereum tiếp theo, Pectra.

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 7 tháng 3 năm 2024, các nhà phát triển Ethereum đã tập trung trên Zoom để tham gia cuộc họp Đồng thuận tất cả các nhà phát triển cốt lõi (ACDC) số 129. Cuộc gọi ACDC là một chuỗi các cuộc họp hai tuần một lần do nhà nghiên cứu Danny Ryan của 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 đồng thuận Ethereum (CL). Tuần này, các nhà phát triển đã chia sẻ bản cập nhật cuối cùng về việc chuẩn bị nâng cấp Dencun, dự kiến sẽ được kích hoạt trên mạng chính vào thứ Tư, ngày 13 tháng 3. Họ cũng thảo luận về phạm vi nâng cấp Ethereum tiếp theo, Pectra, cũng như một số chủ đề nghiên cứu, một trong số đó là tiêu chuẩn hóa giá trị khối giữa các khách hàng CL.

Deneb

Ryan đã nhắc nhở mọi người ngay từ đầu cuộc gọi rằng bản nâng cấp Dencun sẽ trong vòng chưa đầy Đã ra mắt trên Ethereum trong vòng một tuần. Ông cũng đề cập rằng đối với nhiều người Mỹ, nó sẽ bắt đầu vào cuối tuần ngày 10 tháng 3, DST. Vì tất cả các cuộc gọi và nâng cấp ACD đều được lên lịch dựa trên Giờ phối hợp quốc tế (UTC), không triển khai DST, nên những nhà phát triển và những người nghe cuộc gọi ở bên ngoài Hoa Kỳ sẽ cần điều chỉnh lịch trình của họ cho phù hợp.

Một số nhóm khách hàng tham gia cuộc gọi cũng chia sẻ rằng họ sẽ phát hành các phiên bản phần mềm được đề xuất trong những ngày tới để phù hợp với bản nâng cấp Dencun, trong đó các nhóm Prysm, Lighthouse và Teku đều mong đợi New phiên bản được phát hành trước cuối tuần này. Vì các phiên bản này không bắt buộc phải nâng cấp, trưởng nhóm hỗ trợ giao thức EF (Ethereum Foundation) Tim Beiko đã đề cập trong cuộc trò chuyện trên Zoom rằng bài đăng trên blog của Ethereum Foundation tổng hợp tất cả các phiên bản tương thích với Dencun sẽ không được cập nhật.

Chris Hager từ nhóm Flashbots đã chia sẻ thông tin cập nhật nhanh về mức độ sẵn sàng của phần mềm MEV-Boost. Hager xác nhận rằng MEV-Boost phiên bản 1.7, được phát hành vào tuần trước, ổn định và có thể được sử dụng bởi các nhà khai thác nút xác thực. Ông cho biết phần mềm xây dựng Flashbots cho Deneb vẫn đang được phát triển và dự kiến sẽ được hoàn thành và sáp nhập trong tuần này. Về mức độ sẵn sàng nâng cấp của người xác thực, Hager bày tỏ lo ngại rằng dường như không có đủ người xác thực đã cập nhật phần mềm MEV-Boost của họ để phù hợp với bản nâng cấp Dencun. Sau khi kiểm tra kỹ dữ liệu của mình, Hager cho biết khoảng 50% trình xác thực được kết nối với rơle Flashbots đang sử dụng phiên bản MEV-Boost mới nhất, v1.7.

Beiko nói thêm rằng nguồn thông tin của anh ấy, Metrika và Ethernet, cả hai đều cho thấy khoảng 50% nút Ethereum dường như đã sẵn sàng để nâng cấp Dencun. Beiko cũng bày tỏ mong muốn về một công cụ dữ liệu có thể theo dõi mức độ sẵn sàng của các nút xác thực để nâng cấp, không chỉ tất cả các nút Ethereum.

Electra

Các nhà phát triển Ethereum thảo luận về bốn thay đổi mã liên quan đến nâng cấp Pectra.

EIP 7459

Đầu tiên là Đề xuất cải tiến Ethereum (EIP) 7549, cho phép khách hàng CL tổng hợp phiếu bầu cho các khối một cách hiệu quả hơn (còn được gọi là chứng thực). Sự đồng ý của nhà phát triển Trước đóĐề xuất rằng EIP 7549 sẽ được đưa vào Pectra. Nhà phát triển Teku, Mikhail Kalinin đã chia sẻ phân tích sâu hơn về cách EIP 7549 sẽ được triển khai trên Ethereum và đề xuất một số đánh đổi hoặc “tác động tiêu cực” có thể được đưa ra do thay đổi mã. Ryan đề nghị Kalinin tóm tắt trực tiếp những thay đổi được đề xuất của anh ấy đối với thông số CL trên GitHub để có thêm phản hồi và xem xét.

Nhà phát triển Prysm Terence Tsao nói rằng ông đồng ý với việc triển khai EIP 7549 do Kalinin đề xuất, nhưng đề xuất cung cấp thêm tài liệu và thông số kỹ thuật cho các thay đổi API Beacon, điều này nhất quán với EIP là bắt buộc. "Ngày nay, nếu bạn có 10 công cụ tổng hợp trong cùng một vị trí, bạn cần ký 10 chứng thực, thì với thay đổi này, bạn chỉ cần gửi một tin nhắn, vì vậy bạn có thể cần thực hiện một số API Beacon thay đổi," Tsao nói và nói thêm, "Tôi nghĩ phần này có lẽ cần suy nghĩ nhiều hơn về cách thay đổi API Beacon trình xác thực được tích hợp để giải quyết vấn đề này." Là nền tảng, API Beacon là thông số kỹ thuật dành cho CL cho phép các nút truy vấn mạng và lấy thông tin về trạng thái mạng.

Giảm phát hành

Sau đó, nhà nghiên cứu Ansgar Dietrichs của EF đã chia sẻ suy nghĩ của mình về cách giảm phát hành bằng cách giảm mạng Cập nhật nhanh về đề xuất nhằm giảm việc phát hành phần thưởng đặt cược. Anh ấy nói điều đó kể từ cuộc gọi hội nghị ACDC gần đây nhất. đề xuất, "phản hồi từ cộng đồng đã bị xáo trộn." Ông nhắc lại rằng đề xuất này sẽ là một thay đổi mã nhỏ có thể được đưa vào bản nâng cấp Electra vào phút cuối vào tháng 6 hoặc tháng 7, giả sử mạng chính trải qua đợt hard fork vào tháng 10. Tuy nhiên, Dietrichs cũng cho biết các cuộc thảo luận vẫn đang “đang diễn ra”, nghĩa là ý tưởng này cần được thảo luận thêm trước khi đưa ra quyết định.

EIP 7547

Thứ ba, nhà nghiên cứu Mike Neuder của EFĐề xuất EIP 7547, bao gồm danh sách để thảo luận thêm. Ông cho biết phiên họp đột phá thứ hai để thảo luận về "các đặc điểm chính xác" của thiết kế EIP sẽ hữu ích và ông đang cân nhắc tổ chức một phiên họp vào thứ Sáu tới, ngày 15 tháng 3. Ông cũng đề cập rằng EIP có một kênh Discord chuyên dụng có tên là "Danh sách bao gồm" mà những người muốn tìm hiểu thêm về đề xuất hoặc đặt câu hỏi nên sử dụng. Tsao cũng tuyên bố rằng kể từ ngày 16 tháng 2 lần đầu tiên nó được đưa vào Kể từ cuộc họp đột phá hàng tồn kho, các thông số kỹ thuật cho đề xuất phần lớn đã được bổ sung thêm. “Tôi nghĩ thông số kỹ thuật có lẽ đã hoàn thành khoảng 75%,” Tsao nói và nói thêm rằng có một số thành phần khác của thông số kỹ thuật cần cải thiện, chẳng hạn như các thay đổi đối với API thực thi và thông số kỹ thuật xung quanh các trình xác thực trung thực.

EIP 7251

Cuối cùng, nhà phát triển Lighthouse Mark Mackey đã bày tỏ sự ủng hộ của mình đối với EIP 7251, số dư hiệu quả tối đa (maxEB) được tăng lên. "Chúng tôi gần như đã tạo nguyên mẫu cho nó ở Lighthouse. Vẫn còn một số việc phải làm về thông số kỹ thuật, nhưng có vẻ như không có nhiều việc phải làm và việc xem xét kích thước của bộ trình xác thực giống như một quả bom hẹn giờ , chúng tôi đã đề xuất phát hành các đề xuất Tune, những thay đổi phát hành luôn gây tranh cãi nên không có gì đảm bảo rằng cộng đồng sẽ chấp nhận nó. Nếu họ không thích thì điều duy nhất chúng tôi thực sự có thể làm là maxEB," Mackey nói. Ryan cho biết trở ngại chính trong việc kết hợp maxEB vào Electra là do sự phức tạp của việc thay đổi mã, như đã thể hiện trong các cuộc gọi trước đây với nhóm Prysm. “Potuz,” một nhà phát triển ẩn danh trong nhóm Prysm, cho biết trong cuộc trò chuyện trong cuộc họp Zoom rằng nhóm của anh ấy sẽ xem xét lại EIP và đánh giá lại mức độ phức tạp của đề xuất. Ryan yêu cầu các nhóm tài khoản chuẩn bị cho cuộc gọi tiếp theo của ACDC sau hai tuần nữa để đưa ra "quyết định chắc chắn" về EIP 7547 và 7251.

Tiêu chuẩn hóa API trình quản lý khóa

Kỹ sư điều hành nhà phát triển (DevOps) của EF Barnabas Busa giải thích rằng tất cả các máy khách CL đều xuất hiện có các phương pháp tạo khóa trình xác thực hơi khác nhau, đó là các khóa mật mã cần thiết để vận hành và thu hồi trình xác thực. Có một số API tên là "API Keymanager" có thể trợ giúp các nhà khai thác nút Trình xác thực thực hiện quản lý khóa và tham gia và thoát trình xác nhận. Busa giải thích rằng sự khác biệt tinh tế giữa các máy khách khi trả về giá trị cho API này khiến việc kiểm tra điểm cuối API trở nên khó khăn. Anh ấy cũng đề cập rằng nhóm của anh ấy đã bắt đầu thử nghiệm cơ bản các trình xác thực kết hợp, nghĩa là người vận hành nút trình xác thực sử dụng một ứng dụng khách khác cho các nút đèn hiệu của họ thay vì ứng dụng khách của trình xác thực. Các nút báo hiệu là các máy khách duy trì trạng thái CL nhưng không quản lý các cặp khóa mà người xác thực yêu cầu để tham gia đồng thuận. Máy khách xác thực là máy khách sử dụng các cặp khóa để tạo khối và ký bằng chứng trên chuỗi. Ryan đề nghị Busa bắt đầu tạo tài liệu hoặc yêu cầu kéo với đề xuất chuẩn hóa API trình quản lý khóa. Các nhà phát triển trong cuộc gọi cũng hỗ trợ thử nghiệm thêm để đảm bảo trình xác thực kết hợp hoạt động trên tất cả các kết hợp máy khách CL.

Tiêu chuẩn hóa API Beacon giá trị khối

Một người tên là "Dustin" Các nhà phát triển Nimbus cũng đã tiêu chuẩn hóa Đại diện CL của điểm cuối API Beacon "productBlockV3" và "getBlockRewards" Lo lắng. Dustin giải thích rằng một số lĩnh vực của API Beacon không được xác định rõ ràng và "không được triển khai phổ biến" giữa các khách hàng. Cụ thể, khi nói đến các điểm cuối sẽ trả về giá trị khối, phép tính ít nhất phải bao gồm sự thay đổi về số dư của trình xác nhận trước và sau khối được đề xuất. Tuy nhiên, thông số kỹ thuật không nêu chi tiết liệu khách hàng có nên bao gồm phần thưởng và hình phạt đối với những thay đổi trong số dư của người xác nhận do hành động của người xác nhận khác hay không. Ví dụ, những điều này bao gồm các giải thưởng hoặc hình phạt đồng thời về nhiệm vụ của ủy ban, mức tự giảm trừ của người đề xuất hoặc người chứng nhận và các giải thưởng cho người tố giác. Ryan đồng ý rằng nên thêm hướng dẫn vào API Beacon. Tuy nhiên, các nhà phát triển khác trong cuộc gọi, bao gồm Radosław Kapka và Potuz từ nhóm Prysm, lại kém tự tin hơn. Potuz bày tỏ lo ngại rằng số lượng người sử dụng các điểm cuối này còn ít và có thể sử dụng các công cụ của riêng họ để bình thường hóa giá trị khối từ các máy khách CL khác nhau. Potuz nói: “Tôi thậm chí không hiểu tại sao chúng tôi lại đồng ý hỗ trợ điều này nếu người tiêu dùng bị hạn chế. Tôi sẽ cố gắng xem xét các thị trường này và xem liệu chúng tôi có thể thực sự gửi tác phẩm này đến những người sử dụng các thiết bị đầu cuối này thay vì chính chúng tôi hay không”.

Nhà phát triển Nimbus Jacek Sieka đã bác bỏ quan điểm này, nói rằng do sự tồn tại của điểm cuối "productBlockV3", các nhà phát triển cần giải quyết sự không nhất quán giữa các máy khách hoặc ngừng sử dụng nó. Điểm cuối, hãy sử dụng "V4 " thay vì. Hơn nữa, Sieka nói thêm: "Tôi nghĩ điểm cuối này chỉ là chức năng rất cơ bản. Nếu chúng ta hình dung ra một tương lai nơi chúng ta có nhiều nguồn khối và bạn cần so sánh chúng, thì điều này có ý nghĩa. Đơn giản thôi." Ryan khuyên Dustin Tạo một đề xuất để chuẩn hóa V3 và điểm cuối "getBlockRewards". Sau khi đề xuất được tạo, nhóm tài khoản sẽ xem xét lại xem có nên tiếp tục hỗ trợ chúng hay không.

Phần còn lại

Potuz đã gắn cờ hai dự án để nhà phát triển tiếp tục phản hồi và thảo luận. Phần đầu tiên nói về khối muộn hiện tại không được chỉ định trong API công cụ Hành vi của máy khách Lớp thực thi (EL), API này chỉ định giao tiếp giữa EL và CL. Potuz cho biết: “Nếu điều này có thể được chỉ định trong API công cụ, nó sẽ giúp chúng tôi dễ dàng hơn khi sắp xếp lại các khối sau này”. Mục thứ hai mà Potuz gắn cờ liên quan đến phân tích của anh ấy về bản nâng cấp tải trọng của Proposer Builder Separation (ePBS), một bản nâng cấp sẽ loại bỏ nhu cầu về rơle đáng tin cậy trên Ethereum. Potuz đã yêu cầu phân tích liên quan và Thêm phản hồi về các ràng buộc thiết kế ePBS khác.

Cuối cùng, Pooja Ranjan từ nhóm Ethereum Cat Herder đã công bố một dự án có tên "Nhóm làm việc mới của Phụ nữ trong Giao thức Ethereum (WiEP) được thành lập. WiEP là một tổ chức mới của Ethereum Foundation chuyên khuyến khích và phát triển nhiều nhà phát triển giao thức Ethereum nữ hơn. Ranjan cho biết nhóm sẽ tổ chức hội thảo trực tuyến kéo dài một giờ về Ngày 8 tháng 3 sẽ thảo luận với một số phụ nữ Những người đóng góp giao thức Ethereum.

Ryan sau đó cho biết anh sẽ nghỉ thi đấu ba tháng bắt đầu từ ngày 1 tháng 4. Khi anh ấy vắng mặt, Thành viên EF Alex Stokes sẽ kiểm duyệt cuộc gọi 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