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 #122"
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ứ 122. Tại cuộc họp, người ta chỉ ra rằng hầu hết các nhóm khách hàng CL đều có kế hoạch hoàn thành việc triển khai cập nhật thông số kỹ thuật Deneb trong tương lai gần và thảo luận về kế hoạch ra mắt mạng phát triển mới. Ngoài ra, các nhà phát triển còn tập trung vào việc cải thiện các điều kiện lan truyền blob để đơn giản hóa các vấn đề phức tạp liên quan và thảo luận về các điều kiện để truy xuất các đoạn và blob bị thiếu trong các yêu cầu RPC.
Mặt khác, cuộc họp đề cập rằng nhà phát triển Geth Szilágyi đã đưa ra đề xuất giải quyết vấn đề đa dạng khách hàng trên lớp thực thi (EL). Đề xuất này nhằm giải quyết các lỗi phía máy khách thông qua xác thực chéo, dẫn đến một cuộc thảo luận chuyên sâu về việc xây dựng các máy khách Ethereum không trạng thái và quy trình tạo khối. Cuộc thảo luận đề cập đến các vị trí khác nhau của nhóm khách hàng EL và tác động mà các đề xuất có thể có đối với tình trạng mạng và động lực của người dùng. Sự phức tạp của vấn đề đòi hỏi phải nghiên cứu và tạo nguyên mẫu sâu hơn, đồng thời đề xuất này sẽ được Geth và các nhóm khách hàng EL khác nghiên cứu chuyên sâu.
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 16 tháng 11 năm 2023, 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ố 122. 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 tập trung thảo luận về tiến trình cải tiến CL cho bản nâng cấp Cancun/Deneb.
Hầu hết các nhóm khách hàng CL đều cho biết rằng họ đang hướng tới việc hoàn thành việc triển khai cập nhật đặc tả Deneb trong tuần này hoặc tuần tới. Các nhà phát triển đã đồng ý bắt đầu thảo luận về việc khởi chạy Devnet #12 trong cuộc gọi All Core Developer Execution (ACDE) vào thứ Năm tới. Sau đó, các nhà phát triển đã thảo luận chi tiết về đề xuất của nhà phát triển Geth Péter Szilágyi nhằm giải quyết các vấn đề về đa dạng máy khách ở lớp thực thi (EL).
Chẳng hạn như ACDC#121, nhóm khách hàng CL đang nỗ lực cải thiện các điều kiện lan truyền blob để giảm đáng kể Độ phức tạp và các vấn đề liên quan đến việc truyền bá blob được quan sát thấy trong 11 mạng phát triển trước đây. Dưới đây là thông tin cập nhật về tiến độ của các nhóm khách hàng CL khác nhau kể từ ACDC vừa qua:
Lighthouse: Quá trình phát triển gần như đã hoàn tất. Mã mới cần được xem xét và thử nghiệm vào cuối tuần tới.
Teku: Đã triển khai xác nhận tính năng truyền bá mới. Quá trình phát triển quy trình xây dựng đang diễn ra.
Lodestar: Dự kiến hoàn thành triển khai vào cuối tuần này.
Prysm: Việc triển khai dự kiến sẽ hoàn thành vào cuối tuần tới. Sau đó, phải mất một tuần nữa để sắp xếp quy trình xây dựng.
Dựa trên các cập nhật của ứng dụng khách CL, Ryan đã đề xuất lập kế hoạch ra mắt Devnet #12 trong cuộc gọi ACD tiếp theo. Barnabas Busa, kỹ sư DevOps tại Ethereum Foundation (EF), cho biết ngày ra mắt mục tiêu “hợp lý” cho mạng phát triển Cancun/Deneb tiếp theo có thể là ngày 29 hoặc 30 tháng 11. Parithosh Jayanthi, một kỹ sư DevOps khác tại EF, đã yêu cầu cập nhật về thử nghiệm tổ ong. Mario Vega từ nhóm thử nghiệm EF xác nhận rằng thử nghiệm tổ ong cơ bản cho bản nâng cấp đã sẵn sàng. Nhóm của anh ấy sẽ bổ sung thêm các trường hợp thử nghiệm mới cho quy trình xây dựng và quy trình làm việc "blobber" vào bộ thử nghiệm Hive trong những tuần tới.
Tiếp theo, nhà phát triển Teku Enrico Del Fante đã đặt câu hỏi về các máy khách CL sử dụng các yêu cầu RPC "byRoot" để truy xuất các đoạn bị thiếu và các điều kiện thích hợp cho một blob là gì, Del Fante giải thích chi tiết. Các nhà phát triển khác trong cuộc gọi hỗ trợ nêu rõ trong đặc tả CL khi nào máy khách sẽ nhận được các khối và đốm màu khi yêu cầu nhập qua RPC, nếu máy khách không nhận được chúng qua giao thức tin đồn. Các nhà phát triển cũng thảo luận về các điều kiện bổ sung mà khách hàng cần đáp ứng để trả lời các yêu cầu RPC cho các khối và các đốm màu. Nhà phát triển Prysm Terence Tsao chỉ ra rằng về cơ bản có "ba cấp độ" để giải quyết các điều kiện này. Khách hàng có thể nhận được blob hoặc khối thông qua lớp mạng ngang hàng của Ethereum. Cấp độ thứ hai là khách hàng nhận được đốm màu hoặc đoạn này thông qua tin đồn và xác thực thông báo thông qua chức năng chuyển đổi trạng thái. Cấp độ thứ ba và cuối cùng là nơi khách hàng nhận được tất cả thông tin cần thiết về chunk và các đốm màu liên quan của nó. Các nhà phát triển đã tranh luận về mức độ nào của thông số kỹ thuật Cancun cần đáp ứng đối với Del Fante.
Ryan đề nghị Del Fante tạo một pull request trên GitHub để chính thức hóa ngôn ngữ cho vấn đề này và hoàn thiện nó vào tuần tới.
Thảo luận lần cuối tại ACDC #122 Chủ đề là " Đề xuất tạo ra EL Đa dạng Moot" do Szilágyi đề xuất. Nhà phát triển Geth Marius van der Wijden đã chia sẻ bản tóm tắt về đề xuất trong cuộc gọi, giải thích rằng “trường hợp xấu nhất” mà đề xuất cố gắng giải quyết là nếu phần lớn khách hàng gặp lỗi dẫn đến phần lớn trình xác thực trên Ethereum bị cắt và buộc phải đăng xuất khỏi mạng. Đề xuất của Szilágyi gợi ý một cách tiếp cận trong đó thay vì khuyến khích người dùng đang chạy ứng dụng khách đa số chuyển sang ứng dụng khách thiểu số, người dùng được khuyến khích giải quyết vấn đề bằng cách xác thực chéo với các ứng dụng khách thiểu số khác.
“Thay vì yêu cầu mọi người điều hành một số ít khách hàng (điều này có thể bất tiện) hoặc yêu cầu họ điều hành nhiều khách hàng (có thể tốn kém); Bất kỳ khách hàng mà họ thích và chỉ yêu cầu họ thực hiện xác thực chéo không trạng thái với các khách hàng khác,” Szilágyi đề xuất. Để đề xuất này có hiệu quả, Geth và các nhóm khách hàng EL khác sẽ phải nỗ lực xây dựng các phiên bản nhẹ của ứng dụng khách của họ để xác thực chéo các khối Ethereum. Phiên bản của ứng dụng khách được sử dụng để xác thực chéo các khối sẽ không thể đồng bộ hóa với mạng, đề xuất các khối hoặc thực hiện đầy đủ chức năng của ứng dụng khách EL. Van der Wijden đã đề cập rằng công việc xây dựng ứng dụng khách Ethereum “không trạng thái” sẽ hữu ích cho việc nâng cấp Verkle Trie của Ethereum trong tương lai.
Nhà phát triển Nethermind Łukasz Rozmej nói rằng ông phản đối đề xuất này vì khách hàng EL cần thêm công việc để xác thực chéo với các khách hàng khác. Điều này sẽ gây ra sự chậm trễ vào quá trình tạo khối. Ngoài ra, Rozmej tuyên bố rằng anh ấy muốn đợi cho đến khi quá trình nâng cấp Verkle Trie hoàn tất trước khi bắt tay vào xây dựng một ứng dụng khách Ethereum không trạng thái sẵn sàng sản xuất. Rozmej cũng hỏi khách hàng sẽ xử lý việc tạo khối như thế nào nếu xác thực chéo với các khách hàng khác không thành công. Để giải quyết vấn đề này, Ryan đề xuất áp dụng cách tiếp cận "n trên m". Nếu việc xác thực chéo khối thành công đối với ít nhất 3 trong số 6 khách hàng, trình xác thực sẽ tiếp tục xác thực khối, nếu không nó sẽ ngừng xác thực.
Ryan cũng nêu lên mối lo ngại rằng đề xuất này có thể làm giảm thêm động lực khuyến khích người dùng chuyển từ sử dụng khách hàng đa số như Geth sang khách hàng thiểu số, đặc biệt là nếu nguy cơ bị cắt giảm do lỗi trong Geth được giảm bớt thông qua đề xuất xác thực chéo của Szilágyi. “Tôi nghĩ đó là điều đúng đắn cho sức khỏe của mạng lưới,” Van Der Wijden trả lời những lo ngại của Ryan. "Điều quan trọng nhất là chúng tôi sẽ không hoàn thiện bất kỳ trạng thái không hợp lệ nào. Điều này quan trọng hơn việc Geth chiếm 50% hay 60% mạng lưới." Van Der Wijden cũng chỉ ra rằng đề xuất này không cần sự ủng hộ của tất cả EL nhóm khách hàng để có thể tiếp tục thúc đẩy. Ít nhất, Van Der Wijden cho biết nhóm Geth sẽ điều tra nguyên mẫu đề xuất này và cung cấp dữ liệu chuẩn về độ trễ xác thực khối.
「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