Bài đăng này sẽ mô tả một cách tiếp cận khá đơn giản và tích hợp tốt để lưu trữ phân tán lịch sử Ethereum và mở rộng việc lưu trữ trạng thái.
Bước 1: đưa nội dung Block vào các blob
Chúng tôi đưa lịch sử Ethereum vào các blob. Cách tự nhiên để thực hiện việc này là sử dụng hàm get_blobs(block_body) -> List[Blob] để tuần tự hóa phần thân Block và chia nó thành các blob. Sau đó, chúng tôi yêu cầu các giá trị băm phiên bản blob đầu tiên trong danh sách Hash phiên bản blob của tiêu đề Block phải bằng [get_versioned_hash(blob) for blob in get_blobs(block.body)] .
Để thuận tiện, chúng ta có thể tách các blob cho phần thân CL khỏi các blob cho phần thân EL (ví dụ: ExecutionPayload ), sau đó chúng ta có thể để các bằng chứng ZK-EVM chỉ bao gồm các băm có phiên bản đó làm bằng chứng công khai. Điều này cho phép xác minh một Block hoàn toàn bằng cách (i) tải xuống các tiêu đề, (ii) thực hiện kiểm tra DAS cho các blob, (iii) tải xuống và xác minh trực tiếp chỉ phần CL, (iv) xác minh bằng chứng ZK-EVM. Khi các tính năng Consensus Tinh gọn đầy đủ được giới thiệu, phần CL cũng sẽ nhận được bằng chứng ZK, và chúng ta sẽ có một chuỗi"tiêu đề, DAS và bằng chứng" đầy đủ.
Chúng ta có thể làm cho đoạn mã trên sạch hơn bằng cách thực hiện phân đoạn payload và điều chỉnh một vài hằng số. Cụ thể, nếu chúng ta (i) thực hiện Đề xuất cải tiến Ethereum (EIP)-7976 với cùng gasprice cho các byte bằng 0 và khác 0, và (ii) tăng kích thước blob khi nâng cấp blob lên quantum-resistant (hoặc thậm chí sớm hơn), thì chúng ta có thể đạt được sự đảm bảo rằng mỗi phân đoạn payload có thể vừa với một blob (!!). Ví dụ: nếu chúng ta đặt chi phí calldata là 64 gas mỗi byte, thì nhờ Đề xuất cải tiến Ethereum (EIP)-7825 , chúng ta có Hard Cap là một giao dịch tuần tự phải dưới 256 kB, vì vậy nếu chúng ta đặt kích thước blob thành 256 kB, chúng ta sẽ đạt được sự đảm bảo này.
Chúng ta cũng cần thực hiện tương tự đối với danh sách truy cập cấp khối, bao gồm đảm bảo rằng bất biến "64 gas trên mỗi byte" được phản ánh cho từng thành phần và cho toàn bộ tổ hợp.
Bước 2: lưu trữ lịch sử blob ngẫu nhiên
Chúng tôi thêm một quy tắc rằng mỗi máy khách phải lưu trữ một mẫu được chọn ngẫu nhiên của mỗi blob mà nó nhìn thấy. Nếu chúng tôi:
- Đặt kích thước mẫu thành 512 byte (giảm từ 2048 byte hiện tại) để tối đa hóa băng thông PeerDAS
- Giả sử trung bình tích cực có 64 khối dữ liệu kích thước 256 kB trên mỗi khe cắm (16 MB), đủ để tăng không gian khối dữ liệu L2 lên ~20 lần so với hiện trạng hoặc tăng Gas Limit hiện tại lên ~128 lần hoặc kết hợp cả hai
Sau đó, chúng ta có:
- Mỗi máy khách lưu trữ 1/512 của mỗi blob, do đó bạn cần ~710 nút trung thực (trên 512 do chồng chéo) để lưu trữ >= 50% các blob để có thể khôi phục tất cả chúng.
- Tải của mỗi máy khách sẽ là (ở mức 128 blob tích cực cho mỗi khe)
512 * 62 * 31556926 / 12byte = 80 GB mỗi năm, tương đương với tải bổ sung hợp lý áp dụng cho các nút Consensus
Có thể truy vấn blob bằng cách sử dụng lại cơ chế DAS hiện có hoặc bằng cách tạo một giao thức chuyên dụng được tối ưu hóa hơn cho quá trình đồng bộ hóa.
Bước 3: thêm dung lượng lưu trữ
Thực ra, việc này không cần bất kỳ công sức nào. Nếu danh sách truy cập cấp khối được bao gồm trong blob, thì bạn đã có thể đồng bộ hóa blob từ trạng thái mới nhất mà bạn biết (nếu cần, Snapshot thời gian hợp nhất) và phát lại các bản cập nhật để tính toán trạng thái hiện tại. Nếu muốn, chúng ta cũng có thể thêm cơ chế "lặp lại quá trình duyệt cây từ trái sang phải", mặc dù chưa rõ liệu điều này có đáng để phức tạp hay không.
