Báo cáo Devnet PeerDAS 7/14 của Sunnyside đã có mặt! Hãy cùng tìm hiểu tình trạng hiện tại của PeerDAS - chúng ta có thể xử lý bao nhiêu blob, và đâu là điểm nghẽn?

Trong số những nỗ lực đó, vai trò của Sunnyside là điều hành các devnet hàng tuần với nhiều cấu hình khác nhau và cung cấp cho các nhà phát triển cốt lõi những thông tin chi tiết thu được: •Giới hạn hiện tại của PeerDAS nằm ở đâu •Cụ thể các thành phần nào tạo ra nút thắt cổ chai •Các tối ưu hóa như Supernodes và GetBlobV2 hoạt động tốt như thế nào trong thực tế

Mục tiêu chính của chúng tôi là thử nghiệm nhanh chóng và linh hoạt theo những cách bổ sung cho những gì các đội khác như @ethPandaOps đang thực hiện tại fusaka-devents, cung cấp phản hồi kịp thời hỗ trợ cho việc triển khai PeerDAS đang diễn ra.

Trong tuần này, chúng tôi đã vận hành 12 devnet và chạy 3 bộ kiểm tra, sử dụng hình ảnh fusaka-devnet-2 mới nhất của @ethPandaOps: 1. Độ thông lượng Blob (số blob tối đa trên mỗi khối) 2. Băng thông mạng (kiểm tra tải liên tục) 3. Giới hạn băng thông (30 / 20 / 10 Mbps)

1 – Kiểm tra thông lượng Blob Kết quả kiểm tra cho thấy hầu hết các khách hàng CL có thể xử lý 84 blob mỗi khối hoặc nhiều hơn, và vẫn ổn định với ít nhất 40 blob. Một số khách hàng ghi nhận số lượng blob tối đa tương đối thấp hơn so với các devnet trước - nhưng điều này có thể là do số lượng validator trên mỗi nút trong devnet này đã giảm từ 100 xuống 8, điều này đã làm giảm tỷ lệ tham gia subnet của mỗi nút.

2 – Kiểm tra băng thông mạng Khác với các devnet trước đây, nơi mà mạng thường trở nên không ổn định khi số lượng blob cao, lần này tất cả các devnet đều hoạt động ổn định trong một khoảng thời gian dài (~16 giờ) ngay cả với 60 hoặc 72 blob mỗi khối. Mặc dù điều này không đảm bảo tính ổn định ở mức sản xuất, nhưng nó cho thấy rằng ít nhất một số sự kết hợp CL-EL đã đạt được mức độ bền vững cao hơn nhiều thông qua tối ưu hóa 🚀

3 – Kiểm tra Giới hạn Băng thông Để kiểm tra xem các staker thực sự tại nhà có thể tham gia một cách suôn sẻ khi PeerDAS hoạt động hay không, bài kiểm tra này đã áp dụng các giới hạn mạng và xem xét các yếu tố nào trở thành nút thắt cổ chai trong các kịch bản bị hạn chế khác nhau. Trong nhiều bài kiểm tra, chúng tôi phát hiện rằng việc sử dụng băng thông của nút thường xuyên tăng vọt - đặc biệt là gần đầu một slot khi các blob được phát tán - và những đợt tăng vọt này hạn chế hiệu suất mạng tổng thể. Lưu lượng đột biến xảy ra đồng đều trên các nút thay vì do một CL hoặc EL client cụ thể gây ra, và một khi các đợt tăng vọt bắt đầu, mạng không thể tăng thông lượng blob thêm nữa. Nói cách khác, lưu lượng đột biến là nút thắt lớn nhất trong các môi trường bị hạn chế băng thông, và chúng ta cần tìm cách giảm thiểu nó.

Ngoài ra, chúng tôi đã giao tiếp với nhiều nhóm khách hàng và khuyến khích cải tiến cho các vấn đề liên quan đến đồng bộ và đồng nghiệp.

Mạng devnet của Sunnyside vẫn đang hoạt động 🏗️; thực hiện các devnet tương tác với nhiều sự kết hợp khách hàng, các bài kiểm tra băng thông chi tiết hơn, các bài kiểm tra spam bao gồm các giao dịch bình thường, và các bài kiểm tra lấp đầy/sync, để xác định các điểm nghẽn trong các môi trường giống như điều kiện mainnet hơn.