Phân đoạn tải trọng
Tóm tắt: Chia một Block EL ( =payload ) thành nhiều khối nhỏ (“ chunk ”) có ngân sách gas cố định (ví dụ: 2**24 = 16.77M ) lan truyền độc lập dưới dạng sidecar. Mỗi khối mang trạng thái trước mà nó cần thực thi không trạng thái và cam kết với diff sau trạng thái của nó. Các khối được sắp xếp theo thứ tự nhưng có thể được thực thi hoàn toàn độc lập song song . CL cam kết với tập hợp các tiêu đề khối; sidecar mang thân khối và bằng chứng bao hàm.
Quá trình xác thực trở thành một luồng liên tục.
Động lực
Ngày nay, các khối là những đối tượng lớn, nguyên khối và sẽ ngày càng lớn hơn trong tương lai. Việc xác thực yêu cầu phải nhận được toàn bộ Block trước khi có thể bắt đầu thực thi. Điều này tạo ra các nút thắt về độ trễ trong quá trình truyền và thực thi Block .
Sau khi Block được nhận qua mạng ngang hàng (p2p), các giao dịch được thực hiện tuần tự. Chúng tôi không thể bắt đầu xác thực trong khi tải xuống hoặc thực thi song song.
Tin nhắn trên lớp p2p thường được nén bằng Snappy. Định dạng khối của Snappy được sử dụng trên Ethereum không thể truyền phát được. Do đó, chúng ta cần cắt Block thành nhiều phần trước khi nén.
Với Đề xuất cải tiến Ethereum (EIP)-7928: Danh sách Truy cập Cấp khối , tình hình được cải thiện, nhưng chúng tôi vẫn đang chờ quá trình tải xuống hoàn tất trước khi bắt đầu xác thực Block . Với 4 lõi, chúng tôi nhận được biểu đồ Gantt sau:
Thay vào đó, chúng ta có thể truyền phát các khối dưới dạng các đoạn :
- Mỗi khối chứa ≤
2**24gas giao dịch.- Ta cũng có thể tăng kích thước khối theo cấp số nhân (
2**22,2**23, …,2**25) trong gas. Điều này sẽ cung cấp cho chúng ta độ trễ khác nhau cho các khối, cho phép song song hóa tốt hơn - nhưng tôi không chắc liệu điều đó có đáng để phức tạp hóa hay không.
- Ta cũng có thể tăng kích thước khối theo cấp số nhân (
- Các giao dịch vẫn được sắp xếp theo thứ tự . Các khối được lập chỉ mục và sắp xếp, nhưng độc lập với nhau, do đó chúng có thể được xác thực song song. Tuy nhiên, trạng thái sau của khối 0 vẫn là trạng thái trước của khối 1.
- (tùy chọn) Mỗi khối mang trạng thái cần thiết để thực thi mà không cần trạng thái .
Điều này chuyển xác thực từ “ tải xuống toàn bộ Block, sau đó xử lý” → “xử lý trong khi nhận phần còn lại”.
Thay đổi lớp thực thi
Chúng tôi mở rộng định dạng Block EL để hỗ trợ phân đoạn:
class ELHeader :parent_hash: Hash32fee_recipient: Addressblock_number: uint64gas_limit: uint64timestamp: uint64extra_data: ByteList[MAX_EXTRA_DATA_BYTES]prev_randao: Bytes32base_fee_per_gas: uint256parent_beacon_block_root: Rootblob_gas_used: uint64excess_blob_gas: uint64transactions_root: Rootstate_root: Rootreceipts_root: Rootlogs_bloom: Bloomgas_used: Uintwithdrawals_root: Rootblock_access_list_hash: Bytes32 # New fields chunk_count: int # >= 0 Không có cam kết nào đối với từng khối riêng lẻ trong tiêu đề EL. Chúng tôi chỉ thêm số lượng khối vào đó. Các đầu ra thực thi ( state_root , logs_bloom , receipts_root , gas_used ) phải giống với giá trị trong khối cuối cùng (áp dụng cho trạng thái gốc và rút tiền gốc), hoặc gốc sau khi tổng hợp các giá trị của khối (áp dụng cho giao dịch, biên lai, nhật ký, gas đã sử dụng và danh sách truy cập Block ).
Khối thực thi
Các khối không bao giờ được đưa on-chain; chỉ có phần gốc của chúng được cam kết.
Các khối chứa các trường mà chúng ta thường mong đợi trong thân Block EL. Các giao dịch được chia thành các khối với giới hạn 2**24 gas cho mỗi khối. Việc rút tiền chỉ được phép thực hiện trong khối cuối cùng. Tương tự như danh sách truy cập cấp khối, các khối có danh sách truy cập khối riêng, và người ta cũng có thể thêm các giá trị tiền trạng thái vào các khối, mở khóa tính năng không trạng thái.
class Chunk :header: ChunkHeadertransactions: List [Tx]withdrawals: List [Withdrawal] # only in chunk at index -1 chunk_access_list: List [ChunkAccessList]pre_state_values: List [(Key, Value)] # optional Mỗi khối đi kèm với một tiêu đề bao gồm chỉ mục khối. Các giao dịch được sắp xếp theo chunk.header.index và chỉ mục của chúng trong khối. Các cam kết đối với đầu ra thực thi của mỗi khối được bao gồm trong tiêu đề.
class ChunkHeader :index: int txs_root: Rootpost_state_root: Rootreceipts_root: Rootlogs_bloom: Bloomgas_used: uint64withdrawals_root: Rootchunk_access_list_root: Rootpre_state_values_root: Root # optional Để ngăn chặn những người đề xuất chia khối của họ thành quá nhiều phần, giao thức có thể thực thi rằng các phần phải đầy ít nhất một nửa ( \geq\frac{chunk\_gas\_limit}{2} ≥ c h u n k _ g a s _ l i m i t 2 ) HOẶC chunk.header.index == len(beaconBlock.chunk_roots) ( = khối cuối cùng trong Block đó ).
Thay đổi lớp Consensus
Khối Beacon theo dõi các khối có trường mới:
class BeaconBlockBody :...chunk_roots: List [ChunkRoot, MAX_CHUNKS_PER_BLOCK] # SSZ roots of chunks class ExecutionPayloadHeader :...chunk_count: int CL nhận các khối thực thi từ EL thông qua một vùng chứa ChunkBundle mới bao gồm tiêu đề EL và các khối ( =tương tự như blob ).
CL tính toán gốc khối bằng cách sử dụng hash_tree_root của SSZ và đưa chúng vào thân Block beacon.
Thiết kế xe gắn máy
Các khối được vận chuyển bằng xe đẩy có thùng bên :
class ExecutionChunkSidecar :index: uint64 # chunk index chunk: ByteList[MAX_CHUNK_SIZE] # Opaque chunk data signed_block_header: SignedBeaconBlockHeaderchunk_root_inclusion_proof: Vector[Bytes32, PROOF_DEPTH] Lớp Consensus đảm bảo tất cả các khối đều có sẵn và được liên kết đúng cách với thân Block beacon thông qua bằng chứng Merkle đối với chunk_roots ( =tương tự như blob ).
Mạng lưới
Người đề xuất chỉ truyền Block beacon nhẹ với các cam kết ( chunk_count , chunk_headers_root ) trên chủ đề beacon_block thông thường, trong khi dữ liệu thực thi nặng được truyền riêng dưới dạng ExecutionChunkSidecar trên X mạng con song song ( beacon_chunk_sidecar_{0..X} ), loại bỏ trùng lặp bởi (block_root, index) .
Ban đầu, tất cả các nút phải đăng ký tất cả các mạng con và lưu trữ tất cả các khối. Mặc dù điều này chưa làm giảm yêu cầu về băng thông/lưu trữ, nhưng nó cho phép tận dụng lợi ích tức thời của việc song song hóa. Việc lưu trữ một phần có thể được bổ sung trong bản nâng cấp trong tương lai khi cơ chế cơ bản được chứng minh và/hoặc việc chứng minh zk trở nên khả thi.
Fork chọn nĩa
Lựa chọn Fork yêu cầu tất cả các nhánh phụ đều khả dụng và được xác thực thành công trước khi một Block được coi là hợp lệ. Block beacon với chunk_roots lan truyền nhanh chóng, nhưng Block chỉ đủ điều kiện lựa chọn nhánh sau khi mọi nhánh đã được nhận và được chứng minh bao gồm với gốc. Block beacon vẫn chứa tiêu đề EL với tất cả các cam kết cần thiết (= cam kết với Block cha và đầu ra thực thi ). Phần thân Block mà chúng ta biết trên EL vẫn trống trong thiết kế này.
Những lợi ích
- Xác thực luồng : quá trình thực thi có thể bắt đầu trong khi các phần khác của Block vẫn đang tải xuống hoặc đang tải từ đĩa. Các khối độc lập (nếu được cung cấp trạng thái trước), hoặc dựa vào danh sách truy cập khối ( với sự khác biệt trạng thái ở cấp độ khối ) và trạng thái trước khối; nhiều CPU/lõi có thể xác thực các khối đồng thời; phân phối việc sử dụng băng thông trên các khe thay vì các đợt bùng phát đầu khe.
- Chứng minh hợp lý : ZK Provers có thể song song hóa việc chứng minh nhiều khối cùng một lúc, tận dụng tính độc lập của các khối.
- Tính thân thiện với trạng thái không trạng thái : vì một khối riêng lẻ nhỏ hơn một Block, chúng ta có thể cân nhắc thêm các giá trị tiền trạng thái để không cần truy cập trạng thái cục bộ. Một giải pháp trung gian thực tế là chỉ bao gồm các giá trị tiền trạng thái trong khối
0, đảm bảo rằng ít nhất một khối luôn có thể được thực thi trong khi nút tải trạng thái cần thiết cho các khối khác từ đĩa vào bộ nhớ đệm. - Khả năng mở rộng trong tương lai : con đường rõ ràng để tích hợp zk-proof trên các khối hoặc thực hiện phân mảnh.
Không gian thiết kế
Kích thước khối
Gas 2**24 (~16,7M) xuất hiện dưới dạng khối có kích thước tự nhiên:
- Kích thước giao dịch tối đa : Theo Fusaka (Đề xuất cải tiến Ethereum (EIP)-7825),
2**24là kích thước giao dịch tối đa có thể. - Các khối hiện tại: Các khối gas 45M tự nhiên chia thành ~3 khối, cung cấp tính song song ngay lập tức
- Các khối trong tương lai: Có khả năng mở rộng tốt - các khối gas 100M sẽ có ~6 khối
Trình xác thực
- Công cụ thực thi chia Block thành các phần bên trong (không hiển thị với CL) và chuyển chúng đến CL thông qua
ExecutionChunkBundle. - Người đề xuất gói từng khối trong một sidecar với bằng chứng bao hàm. Người đề xuất cũng tính toán gốc cây Hash của từng khối và đưa chúng vào thân Block beacon.
- Việc xuất bản diễn ra song song trên tất cả các mạng con
- Người chứng thực chờ tất cả các phần và xác thực chúng trước khi bỏ phiếu
Người xây dựng
Người đề xuất có thể xuất bản các khối khi chúng hoàn tất việc xây dựng, và người xác thực có thể bắt đầu xác thực chúng ngay cả trước khi nhận được Block beacon. Vì các khối chứa Block Header beacon đã ký và bằng chứng bao hàm dựa trên nó, nên người ta có thể xác thực ( =execute ) các khối khi chúng được gửi đến, tin tưởng vào nguồn của chúng ( =proposer ).
Câu hỏi mở & Công việc tương lai
Kích thước khối tiến triển?
Ý tưởng tăng kích thước khối theo cấp số nhân ( 2**22 , 2**23 , …, 2**25 ) có vẻ hữu ích nhưng lại làm tăng độ phức tạp. Khối đầu tiên có thể nhỏ hơn (5M gas) với các giá trị tiền trạng thái để thực thi ngay lập tức, trong khi các khối sau lớn hơn. Đây vẫn là một lĩnh vực cần thử nghiệm.
Con đường nuôi con một phần
Trong khi việc triển khai ban đầu yêu cầu quyền giám sát toàn bộ, kiến trúc này tự nhiên hỗ trợ quyền giám sát một phần:
- Các nút chỉ có thể quản lý các mạng con Y trong số X
- Cơ chế tái tạo (tương tự như DAS) có thể phục hồi các phần bị mất
Tương thích với ePBS và Delayed Execution
Thoạt nhìn, thiết kế đề xuất có vẻ tương thích với cả Đề xuất cải tiến Ethereum (EIP)-7732 và Đề xuất cải tiến Ethereum (EIP)-7886 . Trong ePBS, gốc khối có thể sẽ di chuyển vào ExecutionPayloadEnvelope , và chúng tôi sẽ đặt thêm một gốc trên gốc khối vào ExecutionPayloadHeader . PTC sẽ không chỉ phải kiểm tra xem một tải trọng EL duy nhất có khả dụng hay không, mà còn phải kiểm tra xem tất cả các khối đều khả dụng hay không. Điều này không khác mấy so với blob.
Ưu điểm của việc phân chia Block và quy mô xác thực độc lập với giới hạn gas cao hơn có thể góp phần làm giảm sự đột biến trong mức tiêu thụ băng thông của nút.
