🚨 Báo cáo devnet Sunnyside (30/09) vừa được phát hành — về devnet-5 chạy ở quy mô mainnet ~11% (~1.7K nút đầy đủ). Nếu bạn quan tâm đến việc mở rộng blob & giới hạn mạng, đây là tài liệu cần đọc. Một chuỗi 🧵

Thông lượng blob tại devnet-5 duy trì 22/33 blob, và đã được kéo dài đến 48/72, với mức sử dụng gas đạt đỉnh gần ~45M. Giới hạn lớn nhất là khả năng mạng: các fullnode với giới hạn tải lên 50Mbps liên tục chạm trần ở 48/72 blob.

Khác với các devnet nhỏ trước đây của chúng tôi, các đỉnh EL P2P cho các nút đầy đủ đã hoàn toàn vượt qua gossip, tạo ra sự không ổn định mới ở quy mô lớn. Phía EL của mạng lưới hiện là nguồn biến động chính. Các đỉnh tải lên gossip của cột đã giảm bớt, có lẽ vì lưu lượng EL đã bão hòa băng thông và các nút có nhiều bạn CL hơn để chia sẻ các yêu cầu cột.

Về khả dụng, độ tin cậy của GetBlobsV2 rõ ràng cho thấy một số suy giảm với tải cao hơn. Geth và Nethermind cho thấy khả dụng blob cao hơn tỷ lệ hit, cho thấy họ thường chỉ giữ các blob một phần — gợi ý rằng việc cho phép trả về một phần từ API GetBlobs có thể giúp hiệu suất CL ở số lượng blob cao hơn. Trong khi đó, hiệu suất GetBlobAPI của Reth đã được cải thiện rất nhiều, gấp đôi số lượng peer (~120 so với ~40–60) và cuối cùng đã khắc phục được các vấn đề đồng bộ/tràn bộ nhớ trong quá khứ.

Kết luận: Fusaka sẽ mở khóa hỗ trợ cho nhiều blob hơn cho L2s, trong khi các BPO hiện tại đã được lên lịch sẽ mở rộng lên mục tiêu 14 blob mỗi khối (với tối đa là 21). Để vượt qua giới hạn này, cần chú ý cẩn thận đến các nút thắt cổ chai quan trọng được nêu trong báo cáo này — cụ thể là băng thông tải lên, độ ổn định mạng P2P và các ngoại lệ cụ thể của khách hàng. Ưu tiên ngay lập tức nên là cải thiện hiệu quả băng thông và tinh chỉnh việc xử lý blob của khách hàng, chẳng hạn như cho phép trả lại một phần thông qua API GetBlobs. Sunnyside Labs vẫn cam kết thúc đẩy các lĩnh vực này và sẽ tiếp tục làm việc để đẩy công suất blob đến giới hạn của nó — nhưng luôn theo cách đảm bảo mạng hoạt động an toàn và đáng tin cậy.