Cuộc gọi lớp đồng thuận Ethereum #99 Viết lên

https://www.galaxy.com/research/insights/ethereum-consensus-layer-call-99-writeup/

Vào ngày 1 tháng 12 năm 2022, các nhà phát triển Ethereum đã tập hợp đểLớp đồng thuận thứ 99 (CL) cuộc gọi. Được chủ trì bởi Danny Ryan của Ethereum Foundation, các cuộc gọi CL là một trong hai chuỗi cuộc họp hai tuần một lần, nơi các nhà phát triển Ethereum thảo luận và điều phối các thay đổi đối với giao thức của Ethereum. Tuần này, các nhà phát triển đã xác nhận lại các quyết định được đưa ra trong cuộc gọi Tất cả các nhà phát triển cốt lõi (ACD) vào tuần trước. Cụ thể, các nhà phát triển đã đồng ý làm việc để cho phép rút ETH đã đặt cược cho bản nâng cấp tiếp theo của Ethereum, Thượng Hải, tách biệt với công việc của họ về proto-danksharding (EIP 4844), có khả năng sẽ được kích hoạt trong một bản nâng cấp riêng sau Thượng Hải. Các nhà phát triển cũng đã thảo luận về một loạt các chủ đề và sáng kiến nghiên cứu đang diễn ra liên quan đến các thông số kỹ thuật của Lớp đồng thuận của Ethereum. Cuối cùng, gần cuối cuộc gọi, các nhà phát triển đã tổ chức lễ kỷ niệm 2 năm Chuỗi Ethereum Beacon, ra mắt vào ngày 1 tháng 12 năm 2020.

Rút ETH đã đặt cọc và EIP 4844

Để bắt đầu cuộc gọi, Danny Ryan đã nhắc lại cuộc thảo luận từ Cuộc gọi ACD #150, nơi các nhóm khách hàng của CL đã đi đến thống nhất về việc tập trung hoàn toàn vào việc rút ETH đã đặt cọc cho Thượng Hải. “Tôi nghĩ điều quan trọng mà các nhóm Lớp đồng thuận đã làm rõ là họ tin rằng EIP 4844 gần như không sẵn sàng giống như việc rút tiền [Stake ETH] và việc kết hợp chúng sẽ làm chậm đáng kể việc rút tiền. Chúng tôi sẽ không ghép đôi chúng. Chúng tôi sẽ làm việc hết mình trước Capella ở dạng hiện tại,” Ryan cho biết trong cuộc gọi. Capella là tên của mạng thử nghiệm chuyên dụng, nơi các nhà phát triển cốt lõi đang thử nghiệm các thay đổi mã đối với việc rút ETH đã đặt cọc.

Barnabas Busa, một kỹ sư devops tại Ethereum Foundation, đã đưa ra một bản cập nhật về tiến trình cho phép rút ETH đã đặt cược. Busa đã đề cập rằng có hai mạng dành cho nhà phát triển đa khách hàng đang thử nghiệm rút tiền, một mô phỏng môi trường trước Hợp nhất và một mô phỏng môi trường sau Hợp nhất. Cả hai nhà phát triển này hiện không hỗ trợ tất cả các máy khách EL và CL. Tính năng rút tiền thử nghiệm mới hơn trong môi trường hậu Hợp nhất hỗ trợ ứng dụng khách Prysm, Lighthouse và Teku CL, cũng như ứng dụng khách Geth và Nethermind EL. Khi việc triển khai từ các máy khách khác như Nethermind (EL) và Besu (EL) đã sẵn sàng, các nhà phát triển sẽ tạo ra một mạng thử nghiệm nhiều máy khách, tồn tại lâu hơn để rút tiền.

Sau đó, Alex Stokes, một nhà nghiên cứu tại Ethereum Foundation, đã đưa ra một bản cập nhật ngắn về yêu cầu kéo của anh ấy khi thực hiện các cuộc quét có giới hạn. Nói tóm lại, đây là một cơ chế để ngăn chặn tình huống trường hợp cạnh trong đó giao thức được yêu cầu quét qua toàn bộ bộ xác thực để rút tiền một phần và toàn bộ. Đề xuất của Stokes giới hạn quá trình quét đối vớitối đa 1.024 trình xác nhận . Không có sự phản đối nào đối với đề xuất của Stokes và các nhà phát triển đã đồng ý tiếp tục với nhiều trường hợp thử nghiệm rút tiền hơn xung quanh cuộc càn quét có giới hạn vào cuối tuần tới.

Mặc dù quá trình phát triển cho EIP 4844 sẽ diễn ra tách biệt với công việc phát triển ở Thượng Hải và rút tiền đặt cược ETH, nhưng các nhà phát triển vẫn thảo luận về một số mục thảo luận mở liên quan đến việc triển khai proto-danksharding. Sean Anderson, một kỹ sư phần mềm Sigma Prime, người xây dựng ứng dụng khách Lighthouse (CL), đã đề cập rằng có một câu hỏi mở về cách mạng sẽ xử lý các đốm màu đồng bộ hóa. Blobs là một loại giao dịch mới sẽ được giới thiệu trong EIP 4844, chuyên chuyển giao dữ liệu giao dịch từ các bản tổng hợp Lớp 2 sang lớp cơ sở của Ethereum. Ryan khuyến nghị nên thảo luận thêm xung quanh các trường hợp cạnh để đồng bộ hóa blob tạivấn đề mở GitHub.

Trent Van Epps, một người phụ trách hệ sinh thái của Ethereum Foundation, đã đưa ra một bản cập nhật về tiến độ của buổi lễ thiết lập đáng tin cậy cần thiết để triển khai EIP 4844. Buổi lễ, được thiết kế để tạo ra một đoạn mã an toàn sẽ được sử dụng trong EIP 4844, sắp sẵn sàng cho giai đoạn đóng góp công khai. Van Epps nói rằng ông hy vọng buổi lễ sẽ là một trong những buổi lễ lớn nhất từng được tiến hành trong không gian tiền điện tử, thu hút từ 8.000 đến 10.000 đóng góp. Thời gian đóng góp của công chúng cho buổi lễ sẽ kéo dài khoảng 2 tháng và bắt đầu vào khoảng tháng 12. Để biết thêm thông tin, hãy đọcTrang web này và tham giaphiên Twitter Spaces này vào ngày 2 tháng 12 năm 2022.

thảo luận nghiên cứu

Các nhà phát triển đã chạy qua một số mục thảo luận liên quan đến tối ưu hóa tiềm năng và những thay đổi đối với thông số kỹ thuật của Ethereum CL. Đầu tiên, Adrian Manning, đồng sáng lập Sigma Prime, đã nêu bật hai đề xuất, cả hai đều tương thích ngược, nghĩa là chúng sẽ không yêu cầu nâng cấp hard fork trên toàn hệ thống để triển khai. Chi tiết đầu tiênnơi đây nhằm mục đích cải thiện khả năng khám phá ngang hàng giữa các nút đặt cược trên Ethereum. Thứ hai cho phép hỗ trợ cho các nút CL đang chạy giao thức truyền thông internet mới nhất được gọi là IPv6. Mục thảo luận sau này đã được nhóm Sigma Prime nêu ra vào tháng Năm. Ghi chú cuộc gọi từ cuộc gọi CL trước đó có thể được tìm thấynơi đây .

Đồng bộ hóa điểm kiểm tra đề cập đến một hoạt động cho phép các nút mới kết nối với Chuỗi Beacon nhanh chóng đồng bộ hóa với phần đầu của chuỗi bằng cách tìm nạp trạng thái khối mới nhất từ một nút đáng tin cậy. Checkpointz là một công cụ mà nhóm DevOps của Ethereum Foundation đã xây dựng để giúp các nút đáng tin cậy dễ dàng hiển thị điểm cuối đồng bộ hóa điểm kiểm tra. Trong cuộc gọi, Mikhail Kalinin, Trưởng nhóm nghiên cứu tại ConsenSys, giải thích rằng có một số lo ngại xung quanh việc Checkpointz trở thành tâm điểm gây ra lỗi cho các nút và chỉ ramột vài đề xuất để giúp đa dạng hóa sự phụ thuộc từ Checkpointz sang các công cụ khác.

Sau đó, Oisin Kyne, đồng sáng lập của Obol Technologies, một công ty xây dựng các giải pháp công nghệ trình xác thực phân tán (DVT), đã nêu bật một vấn đề với việc phân công nhiệm vụ tổng hợp của trình xác thực. Kyne giải thích rằng các nhiệm vụ không được thiết kế để thực thi bởi một bộ xác thực phân tán. Do đó, anh ấy đã đề xuất hai điểm cuối mới cho máy khách CL để hỗ trợ tốt hơn hoạt động của trình xác thực phân tán. Thông tin thêm về đề xuất của Kynesnơi đây và nền tảng cấp cao về DVTnơi đây .

Cuối cùng, Kalinin đưa ra hai câu hỏi xung quanh các thông số kỹ thuật của Ethereum Engine API. Đầu tiên là một mục nội trợ giúp đơn giản hóa các thông số kỹ thuật API của Engine bằng cách loại bỏ một phương pháp lỗi thời để truy xuất các khả năng được ứng dụng khách EL hỗ trợ có tên là “engine_getCapabilities .” Các nhà phát triển đã đồng ý đưa ra phản hồi về đề xuất này một cách không đồng bộ trên GitHub. Câu hỏi thứ hai của Kalinin là xung quanh việc sử dụng cấu trúc nào cho các tài liệu đặc tả API của Engine. Một trong những cách tiếp cận ghi lại các thay đổi đối với API Engine bằng fork, nghĩa là bằng cách nâng cấp hard fork ở cấp hệ thống. Các tài liệu cấu trúc khác thay đổi theo chức năng Engine API. Những ưu và nhược điểm của từng phương pháp được giải thích chi tiết hơnnơi đây . Không có nhà phát triển nào trong cuộc gọi có thành kiến mạnh mẽ đối với cả hai, nhưng Ryan đã đề cập rằng anh ấy cảm thấy thoải mái hơn với cách tiếp cận rẽ nhánh và Kalinin đề cập rằng anh ấy nghĩ rằng ưu điểm của việc sử dụng cách tiếp cận chức năng là rất mạnh.

Những thứ linh tinh

Các nhà phát triển đã đồng ý xem xét cuộc thảo luận trên GitHub xung quanhengine_getCapabilities và suy nghĩ thêm về cấu trúc ghi lại các thay đổi của API Công cụ trước thềm Thượng Hải. Trước khi kết thúc cuộc gọi, nhà phát triển Ethereum độc lập Micah Zoltu đã đặt một câu hỏi nhanh xung quanh dữ liệu đằng sau trang webclientdiversity.org . Zoltu giải thích rằng trang web lấy dữ liệu của họ từ hai nguồn khác nhau và điều này dẫn đến kết quả cực kỳ khác nhau. Ryan đã trả lời rằng một trong những phương pháp này tính toán việc phân phối khách hàng bằng ETH đã đặt cọc. Phần còn lại ghi lại dữ liệu về việc phân phối máy khách bằng cách sử dụng trình thu thập dữ liệu xác định các nút và đồng nghiệp của chúng. Theo hiểu biết của Ryan, dữ liệu do trình thu thập thông tin nút thu thập là không chính xác và phương pháp dựa vào in khối và phân phối ETH đã đặt cược, mặc dù không hoàn hảo, nhưng đáng tin cậy hơn đáng kể.

Jacek Sieka, còn được gọi là “Arnetheduck”, Trưởng phòng Phát triển Nghiên cứu tại Status, người đang xây dựng ứng dụng khách Nimbus (CL), đã đề cập rằng nhóm của anh ấy đã đưa ra một bản phát hành ứng dụng khách mới. Bản phát hành chính thức chuyển ứng dụng khách Nimbus từ bản beta sang trạng thái sẵn sàng sản xuất. Thông tin chi tiết về những cải tiến trong phiên bản này có thể được tìm thấynơi đây . Trước khi kết thúc cuộc gọi, Ryan lưu ý rằng cuộc gọi CL tiếp theo vào ngày 15 tháng 12 năm 2022 sẽ là cuộc gọi cuối cùng trong năm. Các nhà phát triển sẽ tiếp tục cuộc gọi vào khoảng tháng 1 của năm mới.