Tiêu đề ban đầu: "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#120Writeup"

Tác giả gốc: Christine Kim

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

Cuộc họp cuối cùng

Vào ngày 19 tháng 10, các nhà phát triển Ethereum đã tập trung trên Zoom cho cuộc họp Cuộc gọi số 120 của All Core Developers Execution (ACDE). Cuộc gọi hội nghị ACDE là chuỗi 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 đang tập trung vào tiến độ của các chủ đề sau:

1. Phiên bản 1.4.0-beta.3 của thông số CL;

2. Điều kiện khởi động Devnet-10;

3. Phân tích độ trễ blob của Gajinder Singh, một nhà phát triển phần mềm duy trì các ứng dụng khách Lodestar và EthereumJS.

Sự triệu tập

Danny Ryan đã công bố phát hành đặc tả mã CL mới cho bản nâng cấp Cancun/Deneb (Dencun), được gọi là "Triệu hồi". Phiên bản này được đánh dấu chính thức là phiên bản 1.4.0-beta.3 trong kho CL GitHub và có hai thay đổi chính:

1. Cấu hình Mainnet KZG: Đã hoàn thành công việc định dạng cần thiết cho đầu ra của Lễ thiết lập đáng tin cậy Ethereum và đưa nó vào bản phát hành thông số kỹ thuật CL mới nhất.

2. Quy tắc tin đồn mới: Nhà phát triển Teku Enrico Del Fante đã tạo quy tắc tin đồn mới để đảm bảo rằng các nút CL không truyền nhiều hơn số lượng đốm màu tối đa trên mỗi khối, hiện được xác định trong thông số kỹ thuật. Số lượng là sáu. Điều này sẽ đảm bảo rằng người xác thực không thể spam mạng với các tin nhắn không hợp lệ vượt quá sáu đốm màu trên mỗi khối.

Devnet-10

Những thay đổi trong phiên bản 1.4.0-beta.3 của thông số CL sẽ được thử nghiệm trên mạng phát triển tiếp theo, Devnet-10. Tuy nhiên, có một số trở ngại để đưa Devnet-10 lên khỏi mặt đất. Barnabas Busa, kỹ sư DevOps tại Ethereum Foundation, cho biết anh vẫn đang chờ nhóm khách hàng phát hành phiên bản phần mềm mới. Khi những điều này đã sẵn sàng, Busa hy vọng sẽ ra mắt mạng phát triển tiếp theo vào thứ Ba, ngày 20 tháng 10.

Một nhà phát triển ứng dụng khách Prysm sử dụng bút danh "Potuz" đã chỉ ra rằng cấu hình KZG mạng chính có trong thông số kỹ thuật CL mới nhất không thể được hợp nhất vào Geth và Prysm cho đến khi các thay đổi được thực hiện đối với "go-kzg". "go-kzg" là một kho lưu trữ mã riêng biệt triển khai sơ đồ cam kết KZG sang ngôn ngữ lập trình Go. Các nhà phát triển bày tỏ sự thất vọng về quyết định phụ thuộc giữa các kho lưu trữ go-kzg, Geth và Prysm. Đây không phải là lần đầu tiên Potuz và các nhà phát triển khác đưa ra thách thức liên quan đến việc sử dụng thư viện KZG cho EIP 4844.

Parithosh Jayanthi, kỹ sư DevOps tại Ethereum Foundation, cho biết các nhà phát triển có thể khởi chạy Devnet-10 mà không cần cấu hình KZG mạng chính và bản phát hành ứng dụng khách mới, nhưng điều này có nghĩa là các nhà phát triển sẽ không thử nghiệm bất kỳ mã mới nào trên Devnet-10, thay vào đó, hãy kiểm tra lại mã đã phát hành. mã trên Devnet-9.

Tuần này trên Devnet-9, các nhà phát triển đã phát hiện ra sự cố trong quá trình triển khai ứng dụng khách CL. Mario Vega thuộc nhóm thử nghiệm của Ethereum Foundation giải thích rằng các trình xác thực đã không xử lý đúng cách các khối dữ liệu không hợp lệ (blobs). Vega cho biết nếu trình xác thực phát tán độc hại các khối dữ liệu hợp lệ tới một số nút và khối dữ liệu không hợp lệ đến các nút khác, thì các nút nhận khối dữ liệu không hợp lệ sẽ không thể theo dõi phần đầu của chuỗi. Để giải quyết vấn đề này, một thử nghiệm tổ ong đã được tạo để dễ dàng sao chép các điều kiện này và thử nghiệm đối với các bản phát hành máy khách mới. Điều này sẽ cho phép các nhà phát triển ngay lập tức xem liệu bản sửa lỗi của họ có hoạt động hay không.

Về vấn đề này, Enrico Del Fante đã đề cập rằng trong một số trường hợp nhất định khi một khối chứa một hoặc nhiều đốm màu có chỉ mục không khớp với các cam kết blob hiện có trong khối, ứng dụng khách Teku sẽ không nhập khối đó. Dankrad Feist, một nhà nghiên cứu tại Ethereum Foundation, đã chỉ ra rằng những người xác nhận cố tình đề xuất các khối chứa các đốm màu không hợp lệ không có lợi ích nào khác ngoài khả năng làm tăng gánh nặng tính toán trên mạng ngang hàng Ethereum và khiến một số người xác nhận nhận các khối mất đồng bộ hóa với mạng. Feist nhấn mạnh rằng không có lợi ích tài chính nào từ hành vi như vậy và ngay cả khi người xác thực làm điều đó, gánh nặng tính toán bổ sung trên lớp ngang hàng của Ethereum sẽ bị giới hạn bởi số lượng đốm màu tối đa trên mỗi khối.

Tuy nhiên, để ngăn người xác thực thực hiện hành động này, các nhà phát triển đang thảo luận về khả năng thêm một điều kiện cắt giảm mới. Điều kiện cắt giảm mới sẽ cố gắng giám sát các khối để bao gồm các đốm màu không hợp lệ nhằm ngăn chặn người xác thực cố tình gây áp lực lên lớp ngang hàng. Tuy nhiên, do chi phí nghiên cứu và phân tích cần thiết để thay đổi tính kinh tế của trình xác thực Ethereum, Ryan đề nghị thảo luận thêm về đề xuất này trong bối cảnh Praha/Electra, bản nâng cấp tiếp theo sau Dencun.

Ryan nói thêm rằng các nhà phát triển có thể thiết lập hành vi phù hợp cho tình huống này trong đặc tả CL của Dencun và người xác nhận vẫn phải nhập các khối ngay cả khi chỉ mục blob không khớp với cam kết khối. Ông lập luận rằng vì những người xác thực không có động cơ tài chính để truyền bá các khối chứa các đốm màu không hợp lệ theo cách được Del Fante mô tả, nên gánh nặng mạng tiềm ẩn từ hành vi phi lý như vậy bị giới hạn tối đa bởi số lượng đốm màu tối đa trên mỗi khối. Do đó, những sửa đổi nhỏ đối với đặc tả CL sẽ đủ để giải quyết vấn đề trong thời gian ngắn, trong khi các nhà phát triển có thể xem xét các giải pháp lâu dài hơn cho các bản nâng cấp trong tương lai, chẳng hạn như các điều kiện cắt giảm mới.

Jayanthi và Ryan xác nhận lại rằng ít nhất Devnet-10 sẽ không được khởi chạy trên máy khách Prysm cho đến khi nhà phát triển thiết lập cấu hình KZG mạng chính trên máy khách và giải quyết vấn đề do Mario Vega nêu ra. Ryan nhấn mạnh rằng các cuộc thảo luận về điều kiện cắt giảm mới chỉ diễn ra trong bối cảnh nâng cấp Praha/Electra chứ không phải Dencun và những thay đổi đối với thông số CL để nhập các khối chứa các đốm màu không hợp lệ sẽ không phải là rào cản đối với việc khởi chạy Devnet-10. Đại diện từ nhóm khách hàng Prysm và Lighthouse cho biết họ sẽ phát hành bản cập nhật cho phần mềm của mình vào ngày mai, 20 tháng 10.

Phân tích độ trễ khối

Trong một chia sẻ vào thứ Bảy, ngày 14 tháng 10, Gajinder Singh, người duy trì các khách hàng Ethereum Lodestar và EthereumJS, đã chia sẻ phân tích mới về mối quan hệ giữa số lượng đốm màu và độ trễ nhập khối dựa trên sự lan truyền tin đồn. Singh lưu ý rằng trong các thử nghiệm của mình với Devnet-9, độ trễ khối tăng đáng kể khi số lượng đốm màu mà trình xác thực nhận được càng cao.

Bảng dưới đây tóm tắt những phát hiện của Singh. Cột đầu tiên liệt kê tỷ lệ phần trăm khối hoàn chỉnh đến, trong khi các giá trị trong bảng biểu thị số giây cần thiết để nhập khối.

Độ trễ nhập khối tính bằng giây so với số lượng đốm màu có trong khối. Nguồn: Gajinder Singh, Twitter

Singh đã tweet rằng mặc dù chỉ có một đốm màu trên mỗi khối sẽ tạo ra độ trễ không đáng kể, nhưng bất kỳ con số nào cao hơn hai sẽ tạo ra độ trễ đáng kể. Dankrad Feist cho biết dữ liệu phân tích của Singh rất khác so với kết quả thử nghiệm của anh ấy về việc truyền bá các khối lớn trên mạng chính Ethereum. “Có vẻ như không có cách nào dữ liệu này chính xác”, Feist khẳng định và nói thêm rằng vì các đốm màu được xử lý song song với các khối, việc thêm độ trễ xử lý blob vào thời gian khối là một cách không chính xác để dự đoán thời gian lan truyền khối Mainnet. Dự đoán của Singh về việc truyền khối bằng các đốm màu có thể được tìm thấy tại

Singh cho biết trên Twitter rằng mặc dù chỉ có một đốm màu trên mỗi khối sẽ tạo ra độ trễ không đáng kể, nhưng bất kỳ con số nào cao hơn hai sẽ tạo ra độ trễ đáng kể. Tuy nhiên, Dankrad Feist chỉ ra rằng dữ liệu phân tích của Singh khác biệt đáng kể so với kết quả thử nghiệm của ông về việc truyền bá các khối lớn trên mạng chính Ethereum. “Không thể nào dữ liệu này trông chính xác được,” Feist khẳng định và nói thêm rằng vì các đốm màu được xử lý song song với các khối nên việc thêm độ trễ của quá trình xử lý blob vào thời gian khối để dự đoán thời gian lan truyền khối mạng chính là một vấn đề. Dự đoán của Singh về việc truyền khối bằng các đốm màu có thể được tìm thấy ở đây. Feist gọi phân tích của Singh là "quá bi quan".

Bất chấp sự khác biệt của họ, cả Feist và Ryan đều đồng ý rằng phân tích của Singh thực sự là điều mà các nhóm khách hàng khác có thể học hỏi. Ryan khuyến khích các nhóm CL khác cố gắng tái tạo các thí nghiệm của Singh trên Devnet-9 để xem liệu họ có thể thu được dữ liệu và kết quả tương tự hay không. Nếu có dữ liệu mới về độ trễ khối sau khi giới thiệu các đốm màu, Ryan đề nghị xem lại chủ đề trong cuộc gọi ACDE vào tuần tới.

"Liên kết gốc"