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: Chuẩn bị và sửa chữa Pectra, tiến trình PeerDAS

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 #139 Writeup"

Tác giả gốc: Christine Kim

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

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

Cuộc kêu 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) là một chuỗi các cuộc họp được tổ chức hai tuần một lần tập trung vào thảo luận và điều phối những thay đổi đối với Lớp đồng thuận Ethereum (CL), còn được gọi là Chuỗi Beacon. Được tổ chức bởi nhà nghiên cứu Alex Stokes của Ethereum Foundation (EF), cuộc gọi ACDC lần thứ 139 đề cập đến các bản sửa lỗi Pectra Devnet 2, sự chuẩn bị cho Devnet 3, tiến trình triển khai PeerDAS và dữ liệu mới về phân phối nút Ethereum.

Trong cuộc họp, các nhà phát triển đã xem xét tính ổn định và các vấn đề hiện có của Pectra Devnet 2, thảo luận về việc chuẩn bị cho Devnet 3 sắp tới và thảo luận về tiến trình triển khai PeerDAS được thảo luận chiều sâu. Ngoài ra, đề xuất của EIP 7688, nhằm mục đích giới thiệu cấu trúc dữ liệu tương thích về phía trước để hỗ trợ những thay đổi tiềm năng trong phương pháp tuần tự hóa dữ liệu Ethereum, cũng gây ra cuộc thảo luận rộng rãi giữa những người tham dự. Christine Kim, Phó Chủ tịch Nghiên cứu của Galaxy Digital, đã ghi lại cuộc họp này một cách chi tiết và BlockBeats đã biên soạn văn bản gốc như sau:

Ngày 8 tháng 8 năm 2024, Nhà phát triển Ethereum Chúng tôi đã tổ chức Cuộc gọi hội nghị đồng thuận dành cho các nhà phát triển cốt lõi (ACDC) lần thứ 139 thông qua Zoom. Cuộc gọi hội nghị ACDC là một chuỗi cuộc họp hai tuần một lần, 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), còn được gọi là Chuỗi Beacon. Cuộc gọi tuần này được tổ chức bởi nhà nghiên cứu Alex Stokes của Ethereum Foundation (EF). Các nhà phát triển thảo luận về các bản sửa lỗi Pectra Devnet 2, sự chuẩn bị cho Devnet 3, tiến trình triển khai PeerDAS và dữ liệu mới về phân phối nút Ethereum.

Cập nhật Pectra

Stokes thông báo rằng nhà nghiên cứu Hsiao Wei Wang của EF sẽ sớm ra mắt đồng thuận Pectra lớp Phiên bản cập nhật chính thức của thông số kỹ thuật (CL) alpha.4, chứa trước Một số cải tiến đã được thực hiện cho phiên bản 1 và dự kiến phát hành trong tương lai gần.

Về chủ đề Pectra Devnet 2, Kỹ sư vận hành nhà phát triển EF Barnabas Busa cho biết mạng ổn định và đã đạt 85% tỷ lệ tham gia mạng. Vẫn còn một số vấn đề nhỏ cần được giải quyết trong các máy khách lớp thực thi (EL), chủ yếu là EthereumJS và Erigon. Hầu hết các máy khách CL đều ổn định trên Devnet 2. Tuy nhiên, Busa đã đề cập đến các vấn đề nhỏ với ứng dụng khách Prysm cần được điều tra thêm. Kỹ sư Parithosh Jayanthi của EF DevOps nói thêm rằng các nhóm khách hàng cũng được yêu cầu điều tra các vấn đề giữa các nút Lighthouse, Teku và Besu.

Sau đó, các nhà phát triển đã thảo luận về cách cải thiện quy trình giao tiếp của các công ty khởi nghiệp devnet. Nhà phát triển Prysm Kasey Kirkham đã chỉ ra sự thiếu hiểu biết của cô ấy về thời gian ra mắt Devnet 2 trong cuộc trò chuyện trên Zoom. Để đảm bảo thông tin khởi chạy Devnet 3 được truyền đạt chính xác đến tất cả các nhóm khách hàng, các nhà phát triển đã quyết định tổ chức một cuộc họp định kỳ hàng tuần để cập nhật tiến trình thử nghiệm của Pectra. Mặc dù thời gian chính xác vẫn chưa được xác định nhưng các cuộc họp này dự kiến sẽ diễn ra vào thứ Hai hàng tuần, tương tự như các cuộc gọi thử nghiệm trước khi nâng cấp của Dencun. Jayanthi đề xuất rằng các cuộc họp này sẽ ngắn gọn và hiệu quả, kéo dài từ 15 đến 30 phút, tập trung thảo luận về các cập nhật thử nghiệm mạng phát triển liên quan đến Pectra, bao gồm các chủ đề như mạng phát triển PeerDAS và EOF.

Khi thảo luận về vấn đề của Pectra Devnet 3, các nhà phát triển đã nhắc lại rằng họ sẽ tiếp tục sử dụng cấu hình EIP giống như Devnet 2. Ngoài ra, Devnet 3 sẽ lần đầu tiên tích hợp thiết kế mới nhất của EIP 7702, nhóm sẽ tiến hành thử nghiệm cẩn thận để đảm bảo khả năng tương thích của nó với các EIP lõi Pectra. Gajinder Singh từ nhóm Lodestar đã đề cập rằng EIP 7251, vấn đề trong đề xuất MaxEB, đã được phát hiện trong Devnet 2. Mặc dù nó đã được sửa lỗi nhưng vẫn cần thử nghiệm chuyên sâu hơn trên mạng phát triển Pectra tiếp theo để xác minh giải pháp.

Như đã nêu trong ACDE #193, có đặc tả API Engine mới cho phép máy khách CL lấy các đốm màu từ nhóm bộ nhớ giao dịch EL blob. Phương thức này được gọi là "getBlobsV1". Để tránh lạm dụng, nhà phát triển Teku Enrico del Fante đã đề xuất một số một số giải thích rõ ràng về đặc tả CL. Stokes khuyến nghị các nhà phát triển nên xem lại những giải thích rõ ràng này và lên kế hoạch thử nghiệm việc sử dụng phương pháp này trên Pectra Devnet 3.

Các nhà phát triển phát triển giao thức mplex không dùng nữa được thảo luận. Mplex là một giao thức được các máy khách CL sử dụng để truyền đa luồng qua một liên kết truyền thông duy nhất, nhưng nó đã không được các nhà bảo trì của nó chấp nhận. Nhóm khách hàng đang có kế hoạch chuyển sang các công nghệ tái sử dụng luồng mới như yamux. Phil Ngo của Lodestar thông báo rằng họ đã hoàn tất quá trình tích hợp và thử nghiệm yamux và đang hướng tới Chuyển đổi trực tiếp sang giao thức mới thay vì duy trì cả hai giao thức trong thời gian dài, vì điều này sẽ làm tăng chi phí hoạt động của khách hàng. Etan Kissling của Nimbus cũng tiết lộ rằng nhóm của anh ấy đang thử nghiệm yamux. Các nhà phát triển đã đồng ý rằng họ sẽ tiếp tục theo dõi tiến trình của các nhóm khách hàng CL khác trong quá trình chuyển đổi giao thức và lên kế hoạch đánh giá lại chiến lược di chuyển từ bộ ghép kênh sang bộ ghép kênh mới trong những tháng tới.

Etan Kissling nêu chủ đề trên Pectra EIP 7688, một đề xuất nhằm giới thiệu cấu trúc dữ liệu tương thích về phía trước để cho phép các nhà phát triển hợp đồng thông minh chuyển từ RLP sang SSZ khi phương thức tuần tự hóa dữ liệu của Lớp thực thi Ethereum (EL) tiếp tục sử dụng nó. Mặc dù bản nâng cấp Pectra sẽ không triển khai đầy đủ SSZ, nhưng EIP 7688 được đề xuất để đảm bảo khả năng tương thích về phía trước của Pectra EIP đối với các thay đổi dữ liệu.

Alex Stokes thận trọng khi đưa EIP 7688 vào bản nâng cấp Pectra vì tin rằng quy mô nâng cấp đã khá lớn. Parithosh Jayanthi đã đề cập trong hội nghị rằng EIP 7688 có thể được thử nghiệm trong Devnet 5 càng sớm càng tốt. Đại diện từ các đội bao gồm Lodestar, Prysm, Teku và Lighthouse bày tỏ sự ủng hộ đối với đề xuất này. Stokes và Beiko khuyến nghị nên tránh thêm EIP mới vào Pectra cho đến khi tất cả các EIP Pectra hiện tại đạt đến trạng thái ổn định. Kissling chấp nhận lời đề nghị và hỏi khi nào là thời điểm tốt nhất để xem lại vấn đề. Mặc dù không nhận được câu trả lời cụ thể nhưng nhìn chung nhóm đều đồng ý rằng EIP 7688 nên được đánh giá lại trước khi Pectra Devnet 5 ra mắt.

Cập nhật PeerDAS

Các đại diện của nhóm khách hàng Prysm đã báo cáo tiến trình mới nhất của họ trong việc triển khai PeerDAS tại cuộc họp và làm dấy lên cuộc thảo luận về nhu cầu yêu cầu API công cụ "blobsidecar". Alex Stokes đề xuất rằng cuộc họp nhóm PeerDAS tiếp theo yêu cầu thảo luận chuyên sâu về những điều chỉnh mà PeerDAS cần thực hiện đối với API Engine. Ông cũng chỉ ra rằng một nhà nghiên cứu của EF đã soạn thảo một thông số kỹ thuật chính thức, đề xuất sử dụng nó từ PeerDAS Cơ chế lấy mẫu bị loại bỏ để giảm độ phức tạp của quá trình nâng cấp. Tuy nhiên, tại cuộc họp nhóm PeerDAS gần đây, những người tham gia bày tỏ lo ngại rằng động thái này có thể gây khó khăn hơn cho việc giới thiệu lại việc lấy mẫu thông qua hard fork trong tương lai. Ngoài ra, tác động của việc loại bỏ cơ chế lấy mẫu đối với việc tăng giới hạn khí blob một cách an toàn ở Pectra là không rõ ràng. Đề xuất tách giới hạn khí blob trong lớp thực thi (EL) và lớp đồng thuận (CL), EIP 7742, đã được đưa ra một lần nữa trong cuộc gọi hội nghị tuần này. Stokes cho biết anh ấy sẽ cập nhật EIP và có kế hoạch thảo luận về khả năng đưa nó vào cuộc gọi CL tiếp theo, cũng như các chủ đề liên quan đến điều chỉnh giới hạn gas blob trong Pectra.

Cập nhật nghiên cứu

Trong cuộc gọi hội nghị tuần này, các nhà phát triển đã tập trung vào Ba chủ đề nghiên cứu. Đầu tiên, họ khám phá các trường hợp đặc biệt mà người xác thực có thể gặp phải khi hợp nhất số dư ETH đã đặt cọc theo EIP 7251. Etan Kissling đề xuất rằng số dư của trình xác thực có thể không được cập nhật trong thời gian dài trong quá trình hợp nhất, điều này có thể khiến giao thức phân bổ không chính xác trách nhiệm của ủy ban đồng bộ hóa. Đáp lại, Alex Stokes trả lời rằng vấn đề này tương tự như cách xử lý giao thức thoát khỏi trình xác thực và đề xuất ghi lại trường hợp biên này trong đặc tả lớp đồng thuận (CL) mà không thay đổi thiết kế hợp nhất hiện có.

Sau đó, các nhà phát triển đã thảo luận về những thay đổi đối với lớp mạng Ethereum, đặc biệt là việc giới thiệu "nhập ENR nhanh". Quic là viết tắt của Quick UDP Internet Connection, giúp các nút gửi và nhận dữ liệu. Stokes đề xuất tạo yêu cầu kéo (PR) trên GitHub để biết thêm chi tiết về các thay đổi cụ thể đối với mục nhập ENR nhanh.

Cuối cùng, ProbeLab đã chia sẻ phân tích liên tục của họ về hoạt động của nút trên mạng Ethereum. Báo cáo cho thấy hiện có 8.335 nút đang chạy trên mạng Ethereum, 42% trong số đó sử dụng là khách hàng của Lighthouse. Các nút hoạt động tại Hoa Kỳ chiếm 36% tổng số và khoảng một nửa số nút được triển khai trong các trung tâm dữ liệu. Nhà phát triển Prysm “Potuz” bày tỏ sự tò mò về thực tế là số lượng nút Lighthouse được lưu trữ trong trung tâm dữ liệu vượt quá số lượng nút tự lưu trữ. Stokes suy đoán rằng điều này có thể là do cơ sở người dùng chính của ứng dụng khách Lighthouse bao gồm các tổ chức và nhà khai thác nút chuyên nghiệp.

Vào cuối cuộc họp, Potuz kêu gọi nhóm xem lại bản PR mà anh ấy đã gửi về việc điều chỉnh cấu trúc trọng tải thực thi. Đề xuấttrong cuộc gọi ACDC gần đây nhất đã được đề xuất lần đầu tiên. Potuz nhấn mạnh tầm quan trọng của việc ra quyết định nhanh chóng, đồng thời lưu ý rằng mặc dù những thay đổi này đơn giản và dễ hiểu về mặt khái niệm, nhưng việc tích hợp chúng vào đặc tả Lớp đồng thuận (CL) có thể là một thách thức. Ông khuyên các nhà phát triển nên bắt đầu làm việc này càng sớm càng tốt.

「 Liên kết gốc‖