Một bản mẫu ethereum chia nhiệm vụ khôi phục blob giữa các nút mạng cho thấy sự giảm 11–18 lần trong ước tính khối lượng tính toán tái tạo trong các mô phỏng 1.000 nút. Kết quả cho thấy các nhà vận hành có thể giảm công việc trùng lặp thông qua một thay đổi nhỏ hơn so với đề xuất toàn bộ RowDAS.
Báo cáo ngày 3 tháng 9 của nhà nghiên cứu Csaba Kiraly Sept. 3 report mô tả thiết kế được giảm nhẹ như một bước đầu tiên có thể hướng tới RowDAS. Nó giao nhiệm vụ khôi phục mà không giới thiệu các kênh mạng hàng mới trong đề xuất đầy đủ.
Blobs chứa dữ liệu được sử dụng bởi các layer-2 rollups. PeerDAS, hệ thống của Ethereum để kiểm tra tính khả dụng của dữ liệu blob, cho phép các nút mạng tải xuống chỉ một phần dữ liệu đó. Các nút có mức độ lưu trữ cao giữ ít nhất 64 trong số 128 cột dữ liệu, đủ để khôi phục dữ liệu blob bị thiếu; các siêu nút giữ toàn bộ 128 cột.
Nhiều nút mạng lưu ký cao có thể lặp lại cùng một quá trình tái tạo. Thiết kế được tối giản gán các blob cụ thể cho chúng trước, cho phép các nút khác nhận dữ liệu đã được khôi phục thay vì tự tái tạo ngay lập tức.
Những gì các mô phỏng khôi phục blob của ethereum cho thấy
Trong một cấu hình với bốn blob, 10% supernode và không giữ lại cột nào, chi phí ước tính để tái tạo toàn mạng giảm từ 48,6 giây CPU theo mô hình PeerDAS xuống còn 2,75 giây CPU theo thiết kế được giảm nhẹ. Tại tỷ lệ supernode 20%, các con số tương ứng là 91 và 6,6 giây CPU.
Các tổng số này mô tả lượng công việc tính toán tích lũy trên mạng mô phỏng, chứ không phải thời gian phục hồi đã trôi qua. Việc kế toán áp dụng chi phí đo lường là 162 miligiây mỗi lần phục hồi blob trên bộ xử lý Ryzen 9 8945HS. Tốc độ giao dịch và tiết kiệm phí nằm ngoài các phép đo được báo cáo.
Cơ sở PeerDAS đã bao gồm việc chờ ngẫu nhiên và các kiểm tra ngăn tái tạo trùng lặp. Do đó, phép so sánh này ghi nhận hành vi hiện tại của khách hàng cho công việc mà những khoảng trễ đó tiết kiệm.
Dưới biến thể được giảm nhẹ, các nút mạng được phân công chia sẻ các ô đã khôi phục thông qua các kênh phân phối cột hiện có. Các nút mạng có mức độ lưu giữ cao giữ vai trò khôi phục chậm trễ cho bất kỳ dữ liệu nào còn thiếu, duy trì cơ chế dự phòng kiểu PeerDAS.
Full RowDAS, được quy định trong bản nháp EIP-8371, sẽ thêm một tuyến khôi phục khác: các kênh hàng cho phép các nút mạng nhỏ hơn gộp dữ liệu của họ và khôi phục tập thể khi tổng lượng dữ liệu nắm giữ vượt ngưỡng khôi phục. Thiết kế đơn giản hóa vẫn duy trì sự phụ thuộc vào các nút mạng có mức lưu ký cao và không thể cung cấp độ bền vững bổ sung đó.
Các phép đo vẫn chỉ giới hạn ở các mạng mô phỏng, đang trong quá trình sử dụng mật mã thực. Kiraly không báo cáo kết quả nào từ devnet, và cấu hình 128 hàng-subnet của thiết kế đầy đủ vẫn là một sự suy diễn từ số lượng subnet nhỏ hơn. Các mô phỏng lớn hơn và các bài kiểm tra trên mạng thực vẫn còn ở phía trước.
EIP-8371 giữ nguyên giới hạn blob, và sự phân chia được đề xuất giữa gán nhiệm vụ và mạng hàng chưa được tích hợp vào bản nháp của nó. Cơ hội ngay lập tức là hẹp hơn: giảm công việc xử lý cần thiết để khôi phục, với các lợi ích về độ bền rộng hơn phụ thuộc vào lớp hàng sau này.
Bài viết Ethereum có thể có cách đơn giản hơn để giảm gánh nặng tính toán của hệ sinh thái rollup đang phát triển của nó xuất hiện đầu tiên trên CryptoSlate.