BTC
$96,000
5.73%
ETH
$3,521.91
3.97%
HTX
$0.{5}2273
5.23%
SOL
$198.17
3.05%
BNB
$710
3.05%
lang
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
Trang chủ
AI AI
Tin nhanh
Bài viết
Sự kiện
BlockBeats Pro
Thêm
Thông tin tài chính
Chuyên đề
Hệ sinh thái chuỗi khối
Mục nhập
Podcast
Data
OPRR
Partnered With:

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: Kích hoạt PeerDAS và tăng giới hạn gas blob

Đọc bài viết này mất 22 phút
Vào ngày 13 tháng 6, tất cả các nhà phát triển cốt lõi của Ethereum đã tham gia cuộc gọi hội nghị Đồng thuận tất cả các nhà phát triển cốt lõi (ACDC) lần thứ 135.
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 #135 Writeup"
Tác giả gốc: Christine Kim
Bản tổng hợp gốc: Luccy, 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ứ 135. Hội nghị này chủ yếu tập trung vào việc chuẩn bị mạng thử nghiệm của Pectra Devnet 1, PeerDAS Devnet 1 và Đề xuất cải tiến Ethereum (EIP) nối tiếp đơn giản (SSZ).


Các nhà phát triển đã tổ chức các cuộc thảo luận chuyên sâu về bảo trì gói phần mềm, quy trình đưa vào EIP và đặt tên cho vòng nâng cấp lớp đồng thuận Ethereum mới. Ngoài ra, phiên này còn đề cập đến tiến trình triển khai theo đặc tả Electra, tác động của những thay đổi của mạng PeerDAS đối với cách các nút Ethereum xử lý và xác thực dữ liệu cũng như các vấn đề kỹ thuật phức tạp xung quanh việc tăng giới hạn khí blob.

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 13 tháng 6 năm 2024, các nhà phát triển Ethereum đã tập trung trên Zoom để tham gia Tất cả các nhà phát triển cốt lõi Đồng thuận (ACDC) Cuộc họp số 135. Cuộc gọi ACDC là chuỗi sự kiện hai tuần một lần do nhà nghiên cứu Alex Stokes 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, còn được gọi là Chuỗi Beacon). Tuần này, các nhà phát triển đã thảo luận về việc chuẩn bị cho Pectra Devnet 1, PeerDAS Devnet 1 và mạng thử nghiệm chuyên dụng thứ ba cho Đề xuất cải tiến Ethereum (EIP) nối tiếp đơn giản (SSZ).


Thông báo


Các nhà phát triển bắt đầu cuộc họp với hai thông báo. Kỹ sư Parithosh Jayanthi của Ethereum Foundation cho biết nhóm ethPandaOps, một nhóm kỹ sư làm việc trong Ethereum Foundation DevOps (EF DevOps), sẽ tiếp quản bảo trì và phát triển mô-đun Kurtosis gói ethereum. Gói này trước đây đã được các nhà phát triển sử dụng để khởi chạy các mạng thử nghiệm Ethereum và các công cụ liên quan, chẳng hạn như bảng điều khiển dữ liệu Grafana để theo dõi và thử nghiệm các hoạt động triển khai ứng dụng khách khác nhau. Việc di chuyển gói này từ nhóm kỹ thuật Kurtosis sang nhóm ethPandaOps có thể ảnh hưởng đến người dùng vì một số liên kết sẽ chuyển hướng đến kho GitHub do nhóm ethPandaOps quản lý chứ không phải nhóm Kurtosis nữa. Jayanthi khuyên người dùng nên cập nhật các liên kết phần mềm của họ và theo dõi các bản phát hành mới từ nhóm ethPandaOps.


Thông báo thứ hai được đưa ra bởi Tim Beiko, Trưởng bộ phận Hỗ trợ Giao thức tại Ethereum Foundation. Beiko cho biết anh đang nỗ lực giới thiệu một quy trình mới để đưa EIP vào nâng cấp Ethereum theo từng giai đoạn. Anh ấy đã tạo một EIP dự thảo xác định thẻ "Đề xuất đưa vào": Đề xuất để đưa vào, được xem xét để đưa vào và được lên lịch để đưa vào. Ông hy vọng các nhà phát triển sẽ xem xét tài liệu và đưa ra phản hồi. Ông hy vọng tài liệu sẽ được hoàn thành trước cuộc họp ACD tiếp theo.


Electra


Phiên bản chính tiếp theo của Electra v1.5.0-alpha.3 sắp hoàn thành. Các nhà phát triển đồng ý đặt thông số đồng thuận trong yêu cầu kéo (PR) #3768Hợp nhất vào phiên bản tiếp theo. Yêu cầu kéo được tạo bởi nhà phát triển Nimbus Etan Kissling, người đã chỉ ra rằng trường "committee_bits" nên được thêm vào cuối "Chứng thực" thay vì ở giữa dữ liệu để tránh các vấn đề về tuần tự hóa dữ liệu. Ngoài PR #3768, Stokes đã hỏi liệu có bất kỳ vấn đề mở nào khác cần được giải quyết trước khi phát hành phiên bản chính tiếp theo của thông số kỹ thuật Electra hay không. Jayanthi đã đề cập trong cuộc trò chuyện trên Zoom rằng có một số vấn đề nổi bật với việc tích hợp trình xác thực được kích hoạt thông qua lớp thực thi (EL). Stokes đã lưu ý theo dõi trạng thái tích hợp trình xác thực do EL kích hoạt sau cuộc họp.


Về tiến độ triển khai đặc tả Electra mới nhất, hầu hết các nhóm khách hàng lớp đồng thuận (CL) tại cuộc họp đều tuyên bố rằng họ có thể triển khai v1.5.0-alpha.3 Chuẩn bị sẵn phiên bản mới để thử nghiệm trong vòng một đến hai tuần sau khi hoàn thiện . Các nhà phát triển đã đồng ý xem lại thời gian của mạng phát triển Pectra tiếp theo, Pectra Devnet 1, sau vài tuần nữa.


PeerDAS


Tiếp theo, các nhà phát triển đã thảo luận về tiến độ triển khai PeerDAS. PeerDAS là một cải tiến mạng cho Ethereum nhằm nâng cao khả năng xử lý và xác minh lượng lớn dữ liệu tùy ý do người dùng gửi thông qua các giao dịch blob của các nút. Stokes nhớ lại quyết định tại cuộc họp ACDC cuối cùng rằng các nhà phát triển sẽ làm việc với các Pectra EIP khác, Phát triển song song của PeerDAS đạt được bằng cách kích hoạt một chu kỳ kích hoạt riêng biệt của PeerDAS trên mạng phát triển.


Nhà phát triển Lodestar Gajinder Singh cho biết dựa trên các cuộc thảo luận tại phiên đột phá gần đây về PeerDAS, nhà phát triển sẽ xây dựng bản nâng cấp Deneb và làm việc với các Pectra EIP khác để kích hoạt PeerDAS trên các mạng phát triển riêng biệt. Nhà phát triển Teku Enrico Del Fante cho biết các nhà phát triển sẽ dễ dàng xây dựng PeerDAS hơn trên các đặc tả mã ổn định đã được thiết lập trong bản nâng cấp Ethereum Deneb trước đó, thay vì dựa trên các đặc tả mã Pectra luôn thay đổi. Jayanthi đồng ý rằng việc hợp nhất triển khai PeerDAS với các triển khai Pectra EIP khác hiện có thể gây ra sự phức tạp trong quá trình thử nghiệm, đặc biệt là khi cố gắng xác định nguồn gốc lỗi. Ông đề nghị tách riêng hai quy trình công việc và sau đó hợp nhất chúng khi quá trình triển khai ổn định hơn. Stokes đồng ý và nói rằng các nhà phát triển có thể xem xét lại việc hợp nhất PeerDAS và các triển khai Pectra EIP khác trong khoảng một tháng.


Về chủ đề ra mắt PeerDAS Devnet 1, nhóm khách hàng chưa có ước tính rõ ràng về thời điểm mạng thử nghiệm sẵn sàng ra mắt. Ước tính cá nhân tại các phiên dao động trong khoảng từ 2 tuần đến 1 tháng. Stokes đề xuất xem lại lịch trình phát triển mạng trong vài tuần nữa, khi nhóm khách hàng có nhiều thời gian hơn để triển khai PeerDAS.


Beiko sau đó chỉ ra rằng mặc dù PeerDAS là một cải tiến mạng chứ không phải là sự thay đổi đối với giao thức lõi Ethereum, nhưng ông vẫn hy vọng rằng những thay đổi mã sẽ được đưa vào Nâng cấp Pectra. Tài liệu meta-EIP là tài liệu công khai liệt kê tất cả các thay đổi giao thức cốt lõi có trong bản nâng cấp Ethereum. Beiko đã chỉ ra rằng PeerDAS là “tính năng lớn nhất” trong Pectra và mặc dù nó không yêu cầu kích hoạt hard fork, nhưng nó vẫn nên được đưa vào tài liệu để cho thấy rằng các nhà phát triển nghiêm túc về việc chuẩn bị sẵn sàng kịp thời cho việc kích hoạt mạng chính Pectra. Không phản đối điều này.


Tăng giới hạn khí blob


PeerDAS thay đổi cách các nút xử lý và truyền dữ liệu thông qua mạng ngang hàng Ethereum lớp mạng ngang hàng Way. Để người dùng, đặc biệt là các bản tổng hợp Lớp 2, được hưởng lợi từ những thay đổi này, nhà phát triển phải tăng giới hạn hiện tại là sáu đốm màu trên mỗi khối lên ngưỡng cao hơn, điều này sẽ cho phép thông lượng blob (dữ liệu tùy ý) cao hơn. Việc thay đổi giới hạn blob sẽ yêu cầu thay đổi giao thức lõi Ethereum, như các nhà phát triển đã thảo luận tại hội nghị tuần này, có thể liên quan đến công việc kỹ thuật phức tạp hơn là chỉ điều chỉnh một giá trị không đổi trong ngăn xếp giao thức.


StokesĐề xuất, Tách rời các phần phụ thuộc giữa lớp thực thi (EL) và lớp đồng thuận (CL) khi thay đổi giới hạn khí blob. Hiện tại, bất kỳ thay đổi nào về giới hạn khí blob đều yêu cầu thay đổi giao thức EL và CL. Stokes đã đề xuất các cách để phá vỡ những sự phụ thuộc này, cho phép các nhà phát triển loại bỏ các giới hạn khí blob được mã hóa cứng khỏi EL một cách an toàn và để chúng hoàn toàn phụ thuộc vào CL. Nhà nghiên cứu Dankrad Feist của Ethereum Foundation (EF) đã chỉ ra rằng ngoài vấn đề phụ thuộc giữa EL và CL, tác động dây chuyền của việc thay đổi giới hạn gas blob trong tính toán gas của khối cũng rất quan trọng. Feist cho biết: "Cách tốt nhất là thay đổi cách tính toán. Có lẽ việc tính giá xăng xảy ra ở EL là một lỗi. Điều đó lẽ ra phải có ở CL, nhưng bây giờ khó thay đổi hơn. ... Không dễ dàng gì." "


Các nhà phát triển đã đồng ý tiếp tục nghiên cứu cách tốt nhất để thực hiện các thay đổi đối với giới hạn khí blob và tính toán khí trong khối. Các nhà phát triển cũng đồng ý tiếp tục thảo luận về việc liệu việc kích hoạt PeerDAS trong Pectra có đi kèm với việc tăng giới hạn khí blob hay không. Các nhà phát triển đang bị chia rẽ về việc liệu những thay đổi này nên được triển khai cùng nhau hay thực hiện theo từng giai đoạn trên nhiều hard fork.


Jayanthi nói rằng việc kết hợp những thay đổi này là một quyết định "rủi ro" vì các nhà phát triển sẽ không biết PeerDAS sẽ hoạt động như thế nào cho đến khi nó được kích hoạt trên mạng chính. Kỹ sư DevOps của Ethereum Foundation (EF) Barnabas Busa nói thêm rằng phạm vi của hard fork Pectra đã rất lớn và không yêu cầu thay đổi mã bổ sung. Busa nói: “Điều quan trọng là chúng tôi đã có rất nhiều EIP và tôi cảm thấy như chúng tôi tiếp tục bổ sung thêm và nó không bao giờ kết thúc”. không thể phát hành PeerDAS và tăng số lượng đốm màu trong năm rưỡi thử nghiệm tiếp theo."


Một nhà phát triển có tên hiển thị là "Francesco" đề xuất rằng nếu các thay đổi về mạng không đi kèm với sự gia tăng số lượng đốm màu, thì PeerDAS có thể bị xóa để "giảm rủi ro của Pectra". ." Francesco hỏi: "Lợi ích của PeerDAS của Pectra là gì nếu không tăng số lượng đốm màu?"


Để minh họa thêm về khó khăn khi thử nghiệm PeerDAS, Jayanthi đã chỉ ra rằng thử nghiệm giới thiệu các đốm màu EIP 4844 cho Ethereum không mô phỏng đầy đủ hiệu suất thực tế và tác động của các đốm màu trên mạng chính Ethereum. Jayanthi cho biết: “Vấn đề là rất khó để kiểm tra mạng. Chúng tôi đã thực hiện rất nhiều thử nghiệm tuyệt vời liên quan đến 4844, nhưng các đốm màu không hoạt động giống hệt như chúng tôi đã làm trong các thử nghiệm. các nút yếu hơn xuất hiện Câu hỏi. Chúng tôi nhận thấy những thách thức về thời gian và những thứ tương tự, đó là lý do tại sao mặc dù chúng tôi có thể mô phỏng một tình huống hoàn hảo trong mạng phát triển nơi PeerDAS và tăng số lượng đốm màu hoạt động, nhưng nó không có bất kỳ ý nghĩa thực tế nào đối với chúng. ý nghĩa của mạng chính, đây là lý do chính tại sao tôi nghĩ chúng ta nên làm từng bước thay vì tất cả cùng một lúc." Nhà nghiên cứu Ansgar Dietrichs của EF nhận xét rằng việc tăng số lượng đốm màu và liên kết PeerDAS là sai vì chỉ riêng PeerDAS đã yêu cầu nhà phát triển để chọn giá trị số lượng blob. Mặc dù các nhà phát triển có thể chọn số tương tự như trên mạng chính Ethereum, nhưng phải đưa ra quyết định về số PeerDAS nên sử dụng. Lý do duy nhất để chọn cùng một số là các nhà phát triển đã tăng độ phức tạp của PeerDAS để cho phép nó quay trở lại cơ chế lan truyền blob trong đặc tả Deneb hiện tại trong trường hợp xảy ra lỗi. Dietrichs nói thêm rằng những lo ngại về độ phức tạp của thử nghiệm càng củng cố thêm quan điểm của ông rằng Pectra nên được kích hoạt thông qua hai hard fork thay vì một, nhưng điều đó không có nghĩa là ông nghĩ PeerDAS nên được tách rời khỏi những thay đổi về số lượng blob.


Cập nhật SSZ


Kissling đã chia sẻ Cập nhật về tiến trình của ba EIP liên quan đến SSZ. Ông lưu ý rằng việc triển khai các EIP này đã được tiến hành trên nhiều khách hàng, bao gồm Teku, Grandine và Lighthouse. Ông nói, các nhà phát triển có thể bắt đầu thảo luận về tiến trình mạng phát triển cho các EIP SSZ này và có thể đưa chúng vào phạm vi nâng cấp Pectra tại cuộc họp ACDC tiếp theo.


Đặt tên F-Star


Có một bài viết trong Đăng trên Ethereum Magicians thảo luận về lớp đồng thuận Ethereum tiếp theo sau Electra (CL) tên nâng cấp. Các nhà phát triển đã quyết định đặt tên cho bản nâng cấp lớp điều hành (EL) sau Praha: Osaka. Tên nâng cấp CL của ứng cử viên là: Fulu, Felis, Formosa và Funi. Những tên này tuân theo quy ước đặt tên ngôi sao chính bắt đầu bằng "F" và phù hợp cho lần nâng cấp toàn mạng lần thứ sáu của Beacon Chain. Stokes đã yêu cầu các nhà phát triển trong cuộc gọi cân nhắc về chủ đề trên chủ đề Pháp sư.


「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

Chọn thư viện
Thêm mới thư viện
Hủy
Hoàn thành
Thêm mới thư viện
Chỉ mình tôi có thể nhìn thấy
Công khai
Lưu
Báo lỗi/Báo cáo
Gửi