Khoảng một năm trước, chúng tôi đã xuất bản thiết kế FullDAS của mình, dựa trên mã xóa nhòa 2D, nhắm đến 32MB dữ liệu (256 blob) mỗi slot, với các thành phần sau: 1. Một giao thức hiệu quả để phân tán và giám sát, sử dụng: - Nhắn tin cấp ô - Gossip ID hàng/cột/ô dựa trên bitmap - Khôi phục mã xóa nhòa trực tuyến trong mạng - Chuyển tiếp chéo giữa các hàng và cột để tăng cường tính sẵn có - Xuất bản theo lô để giảm hoặc loại bỏ chi phí băng thông của nhà xuất bản - Chuyển đổi pha đẩy-kéo để giảm hoặc loại bỏ chi phí băng thông trong mạng ngang hàng, đồng thời vẫn giữ độ trễ thấp và phân phối tải 2. Một giao thức nhanh và nhẹ để lấy mẫu từ giám sát, sử dụng: - Nhắn tin cấp ô - Tính ngẫu nhiên cục bộ để tăng cường bảo mật lấy mẫu - Phân phối mẫu nhanh từ giám sát - Lấy mẫu cải tiến và thích ứng 3. Một cấu trúc khám phá ngang hàng mới dựa trên ID hàng và cột để loại bỏ độ trễ kết nối Thực tế, một số phần của thiết kế đã được thai nghệ từ năm 2022, lần đầu tiên được giới thiệu tại EthereumZurich'2023. Kể từ bài đăng của chúng tôi, một số kỹ thuật đã được triển khai, một số đang được phổ biến, trong khi những kỹ thuật khác vẫn cần được thảo luận và chứng minh tính hữu ích. Mục tiêu của bài viết này là cung cấp một bản cập nhật, hy vọng góp phần đẩy nhanh tiến trình mở rộng blob.

Một vấn đề khác là với các hệ số ngẫu nhiên được phân bổ trên toàn bộ không gian ID ô, sẽ không có sửa chữa từng phần. Một nút sẽ cần thu thập (ít nhất) nhiều tổ hợp tuyến tính của các ô gốc như số lượng ô trong cấu trúc. Đây là lý do tại sao nhiều mã dựa trên các tổ hợp tuyến tính (hoặc thậm chí các phép XOR đơn giản) hạn chế số lượng và phạm vi các phần tử gốc (ô) mà từ đó các tổ hợp được xây dựng. Người ta có thể hình dung điều này như hầu hết các hệ số bị buộc về 0, và chỉ một số ít được phép chọn ngẫu nhiên. Điều này cho phép sửa chữa từng phần với chi phí giảm nhẹ hiệu quả mã hóa. Như một ví dụ, các mã LT sử dụng thủ thuật này để cho phép giải mã hiệu quả. Chúng tôi gọi khái niệm này là Hạn chế RLC (R-RLC). Tương tự, chúng ta có thể hạn chế RLC theo cột (hoặc theo hàng), sử dụng các tổ hợp tuyến tính chỉ từ các ô của cột đã cho, và gửi các tổ hợp như vậy đến các nút có cột đó trong quyền quản lý. Điều đó sẽ cho phép các nút thực hiện phục hồi ngay khi có đủ ô từ cột, một dạng phục hồi từng phần. Tuy nhiên, chúng ta vẫn sẽ không thể chuyển tiếp chéo giữa các hàng và cột, bởi vì một tổ hợp tuyến tính của các ô cột không giúp ích cho việc phân phối hàng. Thậm chí sau khi giải mã cột, việc chuyển tiếp chéo vẫn bị giới hạn: các nút giải mã cùng một cột sẽ có cùng một phần tử của một hàng, chứ không phải các tổ hợp tuyến tính khác nhau. Một lựa chọn khác có thể nảy ra trong đầu là sử dụng các tổ hợp tuyến tính tương tự như mã RS 2D, có hệ số mở rộng được xác định trước và làm cho các hệ số phụ thuộc vào các ID hàng và cột... tuy nhiên với điều này, chúng ta về cơ bản sẽ sao chép những gì mã Reed-Solomon của chúng ta đã làm. Vậy chúng ta có thể làm gì với RLC? Ở đây chúng tôi liệt kê một số tùy chọn từ không gian thiết kế, với ưu và nhược điểm của chúng. Lưu ý rằng đây vẫn là công việc đang tiếp diễn, vì vậy đừng mong đợi một giải pháp rõ ràng tốt hơn đường cơ sở của chúng tôi, mã hóa RS 2D. (Phần còn lại của văn bản được dịch tương tự, giữ nguyên các thẻ HTML và nội dung bên trong các thẻ)

Tất nhiên, có chi phí chung của GossipSub, nhưng các kỹ thuật đẩy-kéo, như được thảo luận tại đây và tại đây, có thể giảm chi phí chung này đi một nửa hoặc thậm chí nhiều hơn, mà không làm tăng đáng kể độ trễ.

Vậy nút nghẽn ở đâu?

Nút nghẽn có khả năng nhất với mô hình dựa trên ô là ở chi phí chung trên mỗi thông điệp. Điều này bao gồm chi phí xử lý, như xác thực thông điệp và mã hóa xóa, cũng như chi phí mạng, như tiêu đề và gossip ID thông điệp.

Đối với phần sau, chúng tôi đã đề xuất việc sử dụng các ID thông điệp có cấu trúc và bitmap IHAVE/IWANT. Điều này vẫn chưa được chỉ định và triển khai.

Đối với chi phí xử lý, chúng ta nên xem xét lại các ngăn xếp mạng của mình và cải thiện các thứ như xác minh hàng loạt. Chúng ta cũng có thể phải sử dụng các thông điệp đa ô thay vì các ô đơn lẻ như một sự thỏa hiệp. Các mô hình kết hợp, nơi cả thông điệp cấp cột và cấp ô được sử dụng, cũng đang được thảo luận.

Kết luận

FullDAS vẫn đang phát triển, và thiết kế có khả năng sẽ thay đổi, nhưng chúng ta đã có một loạt các kỹ thuật có thể được giới thiệu dần dần để tăng dần số lượng blob. Nhiều thay đổi này là độc lập, cho phép tăng nhân số lượng blob mà chúng ta có thể hỗ trợ, cho phép chúng ta nhanh chóng mở rộng số lượng blob của Ethereum.