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 #138 Writeup"
Tác giả gốc: Christine Kim
Bản tổng hợp gốc: Ladyfinger, BlockBeats

Ghi chú của biên tập viên:
Cuộc 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) được tổ chức hai tuần một lần để thảo luận và điều phối các thay đổi đối với Lớp đồng thuận Ethereum (CL). Đây là cuộc gọi hội nghị ACDC lần thứ 138. Hội nghị này đề cập đến việc ra mắt Pectra Devnet 1, các thay đổi đối với cấu trúc API công cụ và thân khối báo hiệu, đồng thời đưa Đề xuất cải tiến Ethereum (EIP) vùng chứa ổn định vào Pectra, cụ thể là EIP 7688 và EIP 7495. và các bản cập nhật PeerDAS cũng như các chủ đề khác. Trong cuộc họp, các nhà phát triển đã xem xét mức độ sẵn sàng nâng cấp Pectra và thảo luận về một số câu hỏi và đề xuất mở liên quan đến việc triển khai PeerDAS. Ngoài ra, nhà phát triển Nimbus Etan Kissling cũng chia sẻ tiến độ triển khai EIP 7688 và EIP 7495, nhấn mạnh tầm quan trọng của những đề xuất này nhằm nâng cấp phương pháp tuần tự hóa dữ liệu Ethereum. 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. BlockBeats đã biên soạn văn bản gốc như sau:

Ngày 25 tháng 7 năm 2024. Những người tham gia phát triển Ethereum đã tổ chức cuộc họp Đồng thuận dành cho nhà phát triển toàn lõi (ACDC) lần thứ 138 thông qua Zoom. Hội nghị ACDC là 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. Phiên họp tuần này được điều hành bởi Alex Stokes, một nhà nghiên cứu tại Ethereum Foundation (EF). Các nhà phát triển đã thảo luận những vấn đề sau:

· Ra mắt Pectra Devnet 1

· Thư thay đổi đối với Cấu trúc API động cơ và thân khối tiêu chuẩn

· Kết hợp các đề xuất cải tiến Ethereum container ổn định (EIP) vào Pectra, cụ thể là EIP 7688 và EIP 7495

· Cập nhật về PeerDAS và lịch triển khai nó trên mạng chính

Pectra Devnet 1 Pectra

Devnet 1 đã hoạt động vào thứ Ba, ngày 23 tháng 7. Tuy nhiên mạng không ổn định. Parithosh Jayanthi, kỹ sư DevOps tại Ethereum Foundation, cho biết ứng dụng khách Erigon đã gặp sự cố ngay sau khi devnet được ra mắt. Sau đó, một giao dịch EIP 7702 được phát trên devnet khiến mạng chia thành ba trạng thái. Các nhà phát triển đang gỡ lỗi ứng dụng khách và giải quyết các vấn đề phân tách chuỗi.

Giới thiệu "ExecutionPayloadEnvelope"

Nhà phát triển Potuz của Prysm đã đề xuất một phương pháp thực thi cấu trúc tải của beacon chain khối Những cải tiến chính và điều chỉnh tương ứng đối với API công cụ. Đề xuất này nhằm mục đích đơn giản hóa quá trình lưu trữ và xử lý dữ liệu chuyển đổi trạng thái của các máy khách Lớp Đồng thuận (CL). Với việc triển khai nâng cấp Pectra, máy khách CL cần quyền truy cập vào các phần cụ thể của tải thực thi để thực hiện chuyển đổi trạng thái một cách chính xác. Tuy nhiên, thiết kế hiện tại khiến các máy khách này bỏ qua một số thông tin không cần thiết trong quá trình tải thực thi.

Nâng cấp Pectra sẽ yêu cầu máy khách CL yêu cầu dữ liệu chuyển đổi trạng thái cần thiết từ Lớp thực thi (EL) hoặc lưu trữ cục bộ các phần quan trọng của khối. Để nâng cao hiệu quả của máy khách CL sau khi nâng cấp Pectra, Potuz đề xuất giới thiệu cấu trúc mới có tên "binded_execution_payload_envelope" để lưu trữ tập trung thông tin chính cần thiết cho quá trình chuyển đổi trạng thái thực thi. Những cải tiến như vậy sẽ làm tăng đáng kể tốc độ và hiệu quả của máy khách CL trong việc tính toán chuyển đổi trạng thái. Ông cũng nhấn mạnh rằng những điều chỉnh này sẽ đảm bảo khả năng tương thích với các nâng cấp mạng trong tương lai như định dạng Simple Serialization (SSZ).

Mark Mackey, nhà phát triển dự án Lighthouse, cảnh báo rằng nếu những thay đổi này không được thực hiện, hiệu suất của máy khách CL trên mạng thử nghiệm Pectra có thể bị ảnh hưởng. Mikhail Kalinin, một nhà phát triển của dự án Teku, bày tỏ sự thận trọng và đặt câu hỏi liệu những thay đổi về giao thức có thực sự cần thiết để giải quyết sự phức tạp của việc triển khai EIP ở Pectra hay không. Potuz khẳng định rằng có những vấn đề cơ bản với thiết kế giao thức hiện tại và cần phải được sửa chữa. Ông chỉ ra: "Thiết kế hiện tại có sai sót về mặt khái niệm. Nó kết hợp dữ liệu quan trọng đối với quá trình chuyển đổi trạng thái CL với dữ liệu hoàn toàn không liên quan ở cùng cấp độ và trong cùng một thông báo. Do đó, tôi nghĩ thiết kế hiện tại đã sai. Chúng tôi đang làm việc chăm chỉ." để sửa lỗi này."

Stokes khuyến khích các nhà phát triển GitHub.

Cập nhật API công cụ Devnet 2

Liên quan đến cuộc thảo luận ở trên, nhà phát triển Geth "Lightclient ” đề xuất một thay đổi khác đối với API công cụ. Thay đổi này nhằm mục đích giúp việc chuyển đổi khối trở nên dễ dàng hơn đối với khách hàng EL. Máy khách EL xác định phiên bản khối bằng cách diễn giải các trường null và void trong khối. Tuy nhiên, do EIP 7685 của Praha, khách hàng EL sẽ không thể phân biệt các phiên bản khối dựa trên các trường này nếu không có lịch phân nhánh. Để tránh tốn chi phí tham chiếu lịch trình của các bản nâng cấp trước đây, Lightclient đề xuất hợp nhất tất cả các yêu cầu thành một loại duy nhất trong API công cụ mà EL có thể chuyển tới CL để giải thích.

Lightclient lưu ý rằng cách giải thích các khối khác nhau giữa EL và CL và trong trường hợp này CL phù hợp hơn để thể hiện dữ liệu yêu cầu. "Khi chúng ta xử lý các khối, không có khái niệm 'Đây là khối Bellatrix', như trên CL. Tôi nghĩ các bạn đã làm rất tốt việc phân biệt giữa các loại khối phân nhánh khác nhau. Nhưng trong On EL, Tôi nghĩ đây là cách hầu hết tất cả các ứng dụng khách được triển khai, chúng tôi có một khối đại diện cho tất cả các loại khối và chúng tôi sử dụng sự hiện diện của một giá trị null để xác định xem [fork] đó có hoạt động hay không."

Nhà phát triển Nimbus "Dustin" phản đối đề xuất này, nói rằng đề xuất của Lightclient không giải quyết đầy đủ sự phức tạp của việc giải thích khối trên EL và CL. Dustin nói: “Nó chỉ chuyển sự phức tạp và nhầm lẫn từ EL sang CL và cả hai nơi đều khả thi. Chuyển nó sang CL không giải quyết được vấn đề. ... Nó chỉ chuyển vấn đề mà thôi”.

Stokes khẳng định rằng CL phù hợp hơn để xử lý việc diễn giải yêu cầu và khuyến nghị các nhà phát triển xem xét kỹ hơn Potuz và Lightclient tại GitHub.

EIP 7688 và 7495 trong Pectra

Nhà phát triển Nimbus Etan Kissling đã và đang thúc đẩy việc tuần tự hóa Ethereum phương thức được cập nhật lên SSZ. Vì mục đích của Pectra, ông đã xác định hai EIP trung gian là 7688 và 7495 để giới thiệu cấu trúc dữ liệu mà các nhà phát triển hợp đồng thông minh có thể dựa vào để tương thích với những thay đổi liên quan đến SSZ trong tương lai. Kissling lưu ý rằng anh ấy đã nhận được sự hỗ trợ từ các nhóm đặt cược thanh khoản như Rocketpool, cũng như các nhóm khách hàng khác như Teku và Lodestar.

Stokes đã cảnh báo nhóm khách hàng CL không thêm EIP mới vào Pectra. “Pectra vốn đã rất lớn, đặc biệt nếu chúng tôi kết thúc với PeerDAS trong fork. Tại một thời điểm nào đó, chúng tôi cần phải rất thực tế về quy mô của fork và những rủi ro mà nó gây ra. Một lần nữa, tôi đồng ý với Etan. Có nhiều lý do cho điều này. tính năng này có giá trị trong chân không, nhưng tôi nghĩ đây là một trong những hard fork lớn nhất mà chúng tôi từng thực hiện hoặc lớn nhất và không nên xem nhẹ điều đó,” ông nói.

Các nhà phát triển đã nêu lên một số lo ngại về thời điểm các EIP này thực sự có thể được thêm vào mạng phát triển Pectra, vì các nhà phát triển Pectra vẫn chưa kết hợp nhiều EIP như PeerDAS và EOF. Về vấn đề này, Jayanthi khuyến nghị trước tiên hãy quyết định rõ ràng xem liệu các nhà phát triển có nên đưa các EIP này vào bản nâng cấp hay không. Jayanthi cũng cảnh báo rằng có một nút thắt cổ chai khi thử nghiệm CL và EL EIP cùng nhau trên một devnet. Ông viết trong một cuộc trò chuyện trên Zoom: “Việc vận chuyển 10 EIP trực tiếp cùng nhau sẽ khiến việc phân tách và thử nghiệm kết hợp trở nên rất phức tạp. “Và chúng tôi không chỉ có các EIP trực tiếp”. p>

Mackey chia sẻ rằng các nhà phát triển ứng dụng như nhóm EigenLayer đang cố gắng tìm hiểu xem dự định kích hoạt những gì trong Pectra và việc tiếp tục thiếu rõ ràng về hai EIP này là một trở ngại cho nỗ lực của họ. Nhà phát triển Lighthouse Sean Anderson khuyên bạn nên thu thập thêm thông tin đầu vào từ các nhà phát triển ứng dụng trên Ethereum về các EIP này để xác định mức độ quan trọng của chúng đối với các ứng dụng.

Stokes đề nghị xem lại cuộc thảo luận này sau để các nhà phát triển có thể tập trung giải quyết các vấn đề của Pectra Devnet 1.

Cập nhật PeerDAS

Các nhà phát triển đã có cuộc thảo luận chuyên sâu về những phát triển mới nhất của PeerDAS. Anderson báo cáo rằng nhóm khách hàng lớp đồng thuận (CL) đang tích cực khắc phục các sự cố được phát hiện trong vòng cuối cùng của mạng phát triển PeerDAS và đảm bảo tính ổn định của quá trình triển khai trước khi khởi chạy mạng phát triển mới. Nhà phát triển Lodestar và EthereumJS Gajinder Singh cho biết dựa trên phản hồi từ cuộc họp những người triển khai PeerDAS gần đây, cộng đồng quan tâm đến việc tích hợp PeerDAS trong mạng phát triển Pectra tiếp theo.

Stokes đề xuất rằng dựa trên các cuộc thảo luận với nhóm nghiên cứu của Ethereum Foundation (EF) và các nhà phát triển khác, chức năng lấy mẫu có thể cần phải được bỏ qua khi kích hoạt PeerDAS lần đầu trên mainnet. , để giảm độ phức tạp khi triển khai. Ông giải thích rằng việc triển khai đầy đủ PeerDAS bao gồm ba chức năng chính: phân phối, lấy mẫu và tái thiết. "Hiện tại, đặc tả PeerDAS trong Pectra bao gồm ba nhiệm vụ này. Trực giác mách bảo tôi rằng chức năng lấy mẫu có lẽ là điểm phức tạp nhất trong quá trình triển khai. Nếu việc lấy mẫu đặt ra một thách thức không thể vượt qua, chúng tôi có thể xem xét triển khai nó trong Pectra. Tăng số lượng các đốm màu trong khi giảm hoặc điều chỉnh phạm vi của PeerDAS,” Stokes giải thích.

Stokes hứa rằng ông sẽ phát triển một đề xuất chính thức cho ý tưởng này và cùng cộng đồng nhà phát triển khám phá nó sâu hơn. Singh ủng hộ điều này. Stokes cũng khuyến nghị nên chính thức đưa PeerDAS vào bản nâng cấp Pectra. Đáp lại, Jayanthi hỏi liệu điều này có nghĩa là phải xác định lại đặc tả PeerDAS dựa trên đặc tả Pectra hay không, lưu ý rằng việc hợp nhất các nhà phát triển PeerDAS và Pectra có thể làm phức tạp các nỗ lực gỡ lỗi vì cả hai đều không ổn định. Ông gợi ý rằng nên duy trì tính độc lập của hai quy trình công việc cho đến khi thông số kỹ thuật ổn định. Nhà phát triển Teku Enrico Del Fante đồng ý với Jayanthi.

Stokes lưu ý rằng nhiều nhà phát triển tập trung vào việc triển khai PeerDAS đã không thể tham dự cuộc họp. Ông đề xuất tiếp tục thảo luận về các bước tương lai cho PeerDAS tại cuộc họp những người triển khai PeerDAS tiếp theo.

Thêm BeaconBlocksByRange V3

Nhà phát triển dự án Lighthouse "Dapplion" đã đề xuất một cải tiến giải pháp được thiết kế để giúp khách hàng đồng bộ hóa với chuỗi chính hiệu quả hơn trong trường hợp chia tách chuỗi dài hạn. Ông chỉ ra rằng giao thức RPC [BeaconBlocksByRange V2] hiện có có một số hạn chế nhất định: “Khi bạn cần đồng bộ hóa một khối phân nhánh dài và không chắc chắn nhánh nào là chuỗi chính, theo giao thức hiện tại, bạn chỉ cần gửi A trong phạm vi khe, nút sẽ trả về khối mà nó cho là chính xác. Mặc dù bạn có thể truy vấn thông tin này thông qua các thông báo trạng thái, nhưng quá trình này không đồng bộ và có thể gây ra một số vấn đề. Mặc dù hiện tại không có tình huống phân nhánh nghiêm trọng nào trên mạng chính. sự cố tương tự xảy ra trong tương lai, đây sẽ là một vấn đề cần được giải quyết". Dapplion giải thích thêm rằng giải pháp mà ông đề xuất tương đối đơn giản, thậm chí có thể được đưa vào các bản nâng cấp Pectra sắp tới. Mặc dù những cải tiến này chưa xảy ra nhưng Stokes vẫn khuyến khích các nhà phát triển tham dự xem xét cẩn thận đề xuất này và Chia sẻ suy nghĩ của họ và đề xuất trên GitHub.

「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