Xác minh bằng chứng bản địa

Tóm tắt

Mục tiêu tổng thể của đề xuất này là giảm thiểu rủi ro và đơn giản hóa đáng kể các cầu nối L2, và nói chung là bất kỳ ứng dụng onchain nào xác minh bằng chứng ZK, bằng cách giới thiệu một nguyên tắc cơ bản L1 tiêu chuẩn mà bất kỳ dự án nào cũng có thể áp dụng thay cho ngăn xếp xác minh onchain tùy chỉnh của mình. Điều này đạt được thông qua hai thay đổi:

1. Tổng quát hóa Đề xuất cải tiến Ethereum (EIP)-8025 để cơ sở hạ tầng xác minh bằng chứng lớp đồng thuận trở nên độc lập với chương trình, không bị ràng buộc bởi các bằng chứng thực thi Máy ảo Ethereum (EVM) .
2. Một Đề xuất cải tiến Ethereum (EIP) mới cho phép truy cập vào hợp đồng thông minh thông qua một loại giao dịch mang bằng chứng và ba mã lệnh ( PROGRAMHASH , PUBVALUESHASH , PROOFCOUNT ).

Cả hai cùng nhau cho phép bất kỳ dự án nào kế thừa trực tiếp cơ sở hạ tầng xác minh bằng chứng của L1, với các bản vá lỗi zkVM được phân phối thông qua các bản phát hành dành cho khách hàng thay vì các bản nâng cấp quản trị cho từng dự án.

Động lực

Hiện nay, mỗi dự án Ethereum rollup đều duy trì cơ sở hạ tầng xác minh bằng chứng trên chuỗi riêng biệt. Các dự án ZK rollup triển khai các hợp đồng xác minh zkVM, hợp đồng bộ hóa, bộ điều phối đa bằng chứng và logic danh sách trắng chương trình. Các dự án Optimistic rollup cung cấp các máy ảo chống gian lận trên chuỗi riêng của họ (WAVM của Arbitrum, máy Cannon MIPS của Optimism) cùng với logic giải quyết tranh chấp xung quanh. Trong cả hai trường hợp, mỗi hợp đồng được bảo trì, vá lỗi và nâng cấp độc lập để đáp ứng các lỗi trong hệ thống bằng chứng hoặc máy ảo cụ thể của nó, với mỗi lần nâng cấp được kiểm soát bởi một chứng chỉ đa chữ ký hoặc Các tổ chức tự trị phi tập trung (DAO) tùy chỉnh. Điều này chậm, rủi ro và trùng lặp trên toàn hệ sinh thái.

Đề xuất cải tiến Ethereum (EIP)-8025 giới thiệu cơ chế xác minh bằng chứng zkVM trên lớp Consensus của Ethereum, nhưng chỉ dành cho mục đích riêng của L1: xác minh tải trọng thực thi để cho phép xác thực phi trạng thái và phi tuyến tính. Các gói Rollup vẫn cần các hợp đồng xác minh trên chuỗi riêng của chúng.

Tuy nhiên, cơ sở hạ tầng mà Đề xuất cải tiến Ethereum (EIP)-8025 mang đến cho CL, bao ProofEngine , cơ chế lan truyền bằng chứng và logic xác minh, không nhất thiết chỉ dành riêng cho L1. Nếu được khái quát hóa để không phụ thuộc vào chương trình và được cung cấp cho các hợp đồng thông minh thông qua một loại giao dịch mới, bất kỳ rollup nào, ngay cả những rollup không phải EVM, cũng có thể chuyển việc xác minh bằng chứng sang CL. Khi cần vá lỗi cho một triển khai zkVM, các nhóm phát triển client của Ethereum phát hành phần mềm cập nhật theo cùng một cách mà các lỗi trong geth hoặc Nethermind được khắc phục hiện nay: thông qua các bản phát hành client, mà không cần Hard fork. Đây là nguyên tắc tương tự đằng sau các rollup gốc , nhưng được khái quát hóa hơn: cũng giống như các rollup gốc kế thừa môi trường thực thi của L1, việc xác minh bằng chứng gốc cho phép bất kỳ rollup nào kế thừa cơ sở hạ tầng xác minh bằng chứng của L1.

Mặc dù tài liệu này trình bày đề xuất xoay quanh các rollup, nhưng cùng một nguyên tắc cơ bản này có thể áp dụng cho bất kỳ hợp đồng nào xác minh bằng chứng ZK trên chuỗi: hệ thống bảo mật, bộ xử lý phụ ZK, định danh, ZK ML và các hệ thống khác.

Cách Rollup xác minh bằng chứng hiện nay

Mỗi nhà cung cấp zkVM đều cung cấp một hợp đồng xác minh Solidity phổ quát (thường là kiểm tra Groth16 hoặc Plonk trên BN254). Định danh chương trình và các giá trị công khai (bất kỳ đầu vào và đầu ra nào mà mạch cam kết) được truyền cùng với bằng chứng. Đối với SP1:

 interface ISP1Verifier {function verifyProof(bytes32 programVKey, // program hashbytes calldata publicValues, // public values (inputs and/or outputs)bytes calldata proofBytes // the proof) external view;}

Lưu ý về thuật ngữ. SP1 gọi programVKey là “khóa xác minh”, nhưng điều này trùng với khóa xác minh mạch riêng của zkVM. Tài liệu này giữ chúng tách biệt:

• Hash chương trình (được gọi là programVKey bởi SP1, imageId bởi Risc0): một chuỗi bytes32 dùng để xác định chương trình khách đã được biên dịch. Vì mỗi zkVM biên dịch khác nhau (ví dụ: RV32IMA so với RV64IMA), nên nó là mã băm cho mỗi cặp (source, zkVM) . ERE thể hiện điều này dưới dạng kiểu liên kết zkVMVerifier::ProgramVk của mỗi backend (bao bọc SP1VerifyingKey , Digest của Risc0, ETC).
• Khóa xác minh : mạch VK của zkVM (cam kết đa thức, tham số miền). Được mã hóa cứng dưới dạng hằng số trong các trình xác minh trên chuỗi, một hằng số cho mỗi phiên bản zkVM, được chia sẻ giữa tất cả các chương trình.

Ví dụ: Taiko (người xác nhận đa năng)

Taiko minh họa sự phức tạp phát sinh khi một rollup sử dụng nhiều hệ thống bằng chứng. Kiến trúc xác minh của nó bao gồm sáu hợp đồng trên ba cấp độ (hai bộ xác minh thô, hai bộ điều hợp, một bộ điều phối, một bộ xác minh SGX), mỗi bộ được duy trì và nâng cấp độc lập thông qua một chữ ký đa chữ ký tùy chỉnh.

1. Trình xác thực zkVM thô. Taiko triển khai cả trình xác thực SP1 Plonk ( SP1Verifier.sol ) và trình xác thực Risc0 Groth16 ( RiscZeroGroth16Verifier.sol ). Đây là các hợp đồng xác thực phổ quát do nhà cung cấp cung cấp.

2. Bộ điều hợp dành riêng cho Taiko. Mỗi trình xác thực thô được gói gọn trong một hợp đồng bộ điều hợp thực hiện giao diện IVerifier của Taiko:

 // TaikoSP1Verifier: adapter for SP1contract TaikoSP1Verifier is IVerifier {address public sp1RemoteVerifier; // raw SP1 verifiermapping(bytes32 => bool) public isProgramTrusted; // whitelisted programsfunction verifyProof(Context[] calldata _ctxs, bytes calldata _proof) external view {bytes32 aggregationProgram = bytes32(_proof[:32]);bytes32 blockProvingProgram = bytes32(_proof[32:64]);require(isProgramTrusted[aggregationProgram]);require(isProgramTrusted[blockProvingProgram]);bytes memory publicInputs = buildPublicInputs(_ctxs);ISP1Verifier(sp1RemoteVerifier).verifyProof(aggregationProgram, publicInputs, _proof[64:]);}}

Một Risc0Verifier song song có hình dạng tương tự, với isImageTrusted thay thế isProgramTrusted và sha256(buildPublicInputs(...)) làm bản tóm tắt nhật ký.

3. Bộ điều phối đa xác minh. Hợp đồng ComposeVerifier điều phối nhiều người xác minh và đảm bảo rằng một tập hợp đủ người xác minh đã kiểm tra từng bằng chứng:

 contract MainnetVerifier is ComposeVerifier {address public immutable sgxGethVerifier; // SGX verifier (required)address public immutable risc0RethVerifier; // Risc0 optionaddress public immutable sp1RethVerifier; // SP1 optionfunction verifyProof(Context[] calldata _ctxs, bytes calldata _proof) external {SubProof[] memory subProofs = abi.decode(_proof, (SubProof[]));for (uint256 i = 0; i < subProofs.length; ++i) {IVerifier(subProofs[i].verifier).verifyProof(_ctxs, subProofs[i].proof);}require(areVerifiersSufficient(verifiers));}function areVerifiersSufficient(address[] memory _verifiers) internal view override {// Must have exactly 2: sgxGethVerifier + (risc0 or sp1)}}

Những thay đổi đối với Đề xuất cải tiến Ethereum (EIP)-8025

Đề xuất cải tiến Ethereum (EIP)-8025 giới thiệu các bằng chứng thực thi tùy chọn cho việc xác thực Block L1. Cơ sở hạ tầng mà nó mang đến cho lớp Consensus ( ProofEngine , gossip, logic xác minh) chỉ dành riêng cho L1 vì các kiểu dữ liệu của nó là: ExecutionProof.public_input mang một new_payload_request_root: Root , và ProofType là một uint8 liệt kê một tập hợp nhỏ cố định các bản dựng được chấp nhận (client, zkVM) (xem triển khai Lighthouse ):

Phương pháp này hoạt động tốt khi tập hợp các chương trình khách nhỏ và được biết trước, nhưng không thể đáp ứng được các chương trình tổng hợp tùy ý.

Đề xuất cải tiến Ethereum (EIP) này bổ sung thêm một nguyên thủy xác minh chung, giữ nguyên bề mặt hiện có của Đề xuất cải tiến Ethereum (EIP)-8025 ( ExecutionProof , ProofType , verify_execution_proof , notify_new_payload , notify_forkchoice_updated , process_execution_proof , request_proofs , ProofAttributes ). Sự tổng quát hóa này phản ánh ERE , trong đó đặc tính zkVMVerifier không phụ thuộc vào chương trình và các chương trình khách cụ thể được xây dựng dựa trên đó. Theo thiết kế của ERE, trong đó Trình Compiler và phần phụ trợ zkVMVerifier là các đặc tính độc lập, vùng chứa Proof mới chia ProofType được hợp nhất thành hai trục: một BackendType: uint8 chỉ xác định phần phụ trợ zkVM và một program_hash: Bytes32 xác định chương trình khách (cụ thể cho một cặp (guest program, zkVM) , xem ghi chú thuật ngữ ). Công cụ sử dụng backend_type để chọn mạch VK; program_hash là một đầu vào công khai cho mạch, được kiểm tra cùng với public_values ​​trong quá trình xác minh:

 class ProofPublicInput ( Container ):program_hash: Bytes32public_values: ByteList[MAX_PUBLIC_VALUES_SIZE] class Proof ( Container ):proof_data: ByteList[MAX_PROOF_SIZE]backend_type: BackendTypepublic_input: ProofPublicInput def verify_proof ( self: ProofEngine, proof: Proof ) -> bool : ...

verify_execution_proof của Đề xuất cải tiến Ethereum (EIP)-8025 có thể được triển khai lại như một lớp bao bọc mỏng trên verify_proof để chia sẻ mã, mà không có thay đổi nào có thể quan sát được ở lớp gossip:

 def verify_execution_proof ( self: ProofEngine, ep: ExecutionProof ) -> bool :backend_type, program_hash = self .resolve_proof_type(ep.proof_type)expected_public_values = serialize_stateless_output(StatelessValidationResult(new_payload_request_root=ep.public_input.new_payload_request_root,successful_validation= True ,chain_config= self .chain_config,)) return self .verify_proof(Proof(proof_data=ep.proof_data,backend_type=backend_type,public_input=ProofPublicInput(program_hash=program_hash,public_values=expected_public_values,),))

Cấu trúc byte của serialize_stateless_output trên StatelessValidationResult được hiển thị trong phần Tác động lên các rollup gốc , vì các hợp đồng rollup gốc tái tạo nó trên chuỗi. Tính hợp lệ Block vẫn được tách rời khỏi việc xác minh bằng chứng; hướng dẫn người chứng minh trung thực không thay đổi. Các bằng chứng đến từ sidecar (các giao dịch mang bằng chứng, xem phần Truyền bằng chứng ) đi qua verify_proof trực tiếp, không cần trình bao bọc L1.

Tính ổn định Hash chương trình (vấn đề chưa được giải quyết)

Thuộc tính “các bản sửa lỗi được triển khai thông qua các bản phát hành cho máy khách, không có gì thay đổi trên chuỗi” của quá trình xác minh bằng chứng gốc phụ thuộc vào một yêu cầu không hề đơn giản: mã băm program_hash được ghim trên chuỗi phải duy trì ổn định qua các bản vá zkVM. Nếu bất kỳ bản vá nào thay đổi Hash, các bản cập nhật đã ghim giá trị cũ sẽ bị vô hiệu hóa trừ khi chúng được nâng cấp, và câu chuyện nâng cấp lại phụ thuộc vào quản trị trên chuỗi.

Hiện tại không có phiên bản zkVM nào cung cấp trực tiếp tính năng này. Cả hai ứng cử viên hàng đầu đều nhận diện các thành phần thay đổi trong quá trình cập nhật SDK/phụ thuộc/chuỗi công cụ thông thường, chứ không chỉ là các bản vá ở lớp mạch:

• imageId của Risc0 là một SHA-256 trên SystemState { pc: 0, merkle_root } với merkle_root là một merkle root Poseidon2 của ảnh bộ nhớ ban đầu, chứa cả ELF người dùng và ELF hạt nhân ( binfmt/src/elf.rs#L435 ). Ảnh bộ nhớ ghi lại chính xác các byte đã biên dịch, vì vậy việc tăng phụ thuộc, cập nhật chuỗi công cụ hoặc vá lỗi hạt nhân đều làm thay đổi imageId ngay cả khi ngữ nghĩa STF không thay đổi.
• programVKey của SP1 là một Poseidon2 trên (preprocessed_commit, pc_start, ...) ( hypercube/src/verifier/hashable_key.rs#L107 ). Không giống như imageId của Risc0 (một Hash thuần túy của các byte đã biên dịch), vk của SP1 là sản phẩm phụ của việc chạy thiết lập mạch trên ELF: preprocessed_commit là cam kết tiền xử lý của AIR và pc_start đến từ trình liên kết, vì vậy các thay đổi mạch, cập nhật SDK và thay đổi chuỗi công cụ đều di chuyển nó, ngay cả khi mã nguồn khách của người dùng giống hệt nhau về byte.

Việc sử dụng trực tiếp một trong hai program_hash trên chuỗi sẽ khiến mọi bản phát hành zkVM trở thành một sự kiện có thể xem được trong rollup.

Phương án khả thi là một lớp gián tiếp : program_hash trên chuỗi là một định danh ổn định, được chọn bởi rollup và là đầu vào công khai cho bằng chứng, trong khi định danh nội bộ của zkVM là một đầu vào riêng tư, được duy trì bởi các máy khách và có thể thay đổi tự do với mỗi bản phát hành. Bằng chứng phải chứng thực rằng hai định danh này được liên kết với nhau, sao cho program_hash ổn định thực sự cam kết với những gì đã được thực thi. Cơ chế chính xác vẫn là một câu hỏi thiết kế mở.

Các bản cập nhật gốc sử dụng sentinel NATIVE_PROGRAM hoàn toàn bỏ qua điều này: sentinel chỉ đơn giản nói "bất cứ thứ gì L1 hiện đang chấp nhận", và tập hợp được chấp nhận bản thân nó là một thành phần phía máy khách được cập nhật cùng với các bản phát hành zkVM.

Đề xuất cải tiến Ethereum (EIP) mới: Giao dịch chứng minh

Định dạng giao dịch

 TransactionType: PROOF_TX_TYPETransactionPayloadBody:[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit,to, value, data, access_list, max_fee_per_blob_gas,blob_versioned_hashes, proofs, public_values_hash,y_parity, r, s]

Ở đâu:

• proofs : một danh sách các cặp (program_hash, backend_type) . Mỗi program_hash là một bytes32 xác định chương trình khách cho backend zkVM cụ thể đó (xem ghi chú thuật ngữ ). Mỗi backend_type là một số nguyên không dấu uint8 và PHẢI là duy nhất trong danh sách, vì hai bằng chứng từ cùng một backend sẽ không tăng thêm tính bảo mật. Độ dài của danh sách này xác định proof_count .
• public_values_hash : một Hash bytes32 của đầu ra công khai của chương trình (được chia sẻ giữa tất cả các bằng chứng, vì tất cả các phần phụ trợ đều chứng minh cùng một tuyên bố).

Bằng Proof cấp CL mang các byte public_values ​​thô; phần thân giao dịch (và mã lệnh PUBVALUESHASH ) chỉ hiển thị Hash của chúng. Hợp đồng tái tạo các byte dự kiến ​​và so sánh các mã băm. Hai bất biến liên kết hai góc nhìn này với nhau (được kiểm tra bởi bất kỳ nút nào xử lý sidecar, khi lan truyền mempool và một lần nữa bởi trình xây dựng khi lắp ráp Block):

• sidecar[i].public_input.program_hash == proofs[i].program_hash and sidecar[i].backend_type == proofs[i].backend_type .
• sha256(sidecar[i].public_input.public_values) == public_values_hash .

Những điều này liên kết các định danh hiển thị cho EVM ( proofs[i].program_hash , public_values_hash ) với các đối tượng Proof cơ bản được truyền cho verify_proof . Xem phần Lan truyền bằng chứng để biết cách các bằng chứng đến được trình tạo và cách bằng chứng Block L1 bao phủ chúng.

Mã lệnh

Các mã lệnh mới đọc các trường của giao dịch có bằng chứng và trả về giá trị 0 cho các giao dịch không có bằng chứng.

Một rollup tùy chỉnh lặp lại với PROOFCOUNT() và kiểm tra từng PROGRAMHASH(i) so với Danh sách trắng của chính nó.

Đối với các bản tổng hợp gốc, PROGRAMHASH(i) trả về một giá trị đánh dấu được biết đến (ví dụ: bytes32(1) ) khi bằng chứng thứ i sử dụng một chương trình mà L1 hiện chấp nhận cho các bằng chứng thực thi Máy ảo Ethereum (EVM) của riêng nó. Bằng cách này, hợp đồng kiểm tra PROGRAMHASH(i) == NATIVE_PROGRAM mà không lưu trữ các hàm băm cụ thể cho mỗi zkVM và tự động theo dõi các bản nâng cấp L1 được phát hành trong các bản phát hành máy khách.

Chống nhiều loại

Danh sách proofs cho phép mỗi rollup chọn sự cân bằng giữa bảo mật/chi phí của riêng mình: [(hash, SP1)] là một bằng chứng duy nhất, [(hash_sp1, SP1), (hash_risc0, Risc0)] yêu cầu cùng một tuyên bố phải được chứng minh độc lập bởi cả hai bên trước khi CL chấp nhận giao dịch. Hợp đồng đọc PROOFCOUNT() và thực thi mức tối thiểu của riêng nó.

Điều này thay thế cơ chế điều phối đa bằng chứng ở cấp độ hợp đồng (như ComposeVerifier của Taiko yêu cầu cả SGX và trình xác minh ZK) bằng một cơ chế ở cấp độ giao thức. Vì proofs nằm trong phần thân giao dịch đã ký, nên nó không thể bị giả mạo.

Sự lan truyền bằng chứng

Bằng chứng phải được chuyển đến trình xây dựng thông qua mempool, nhưng không cần khả dụng lâu dài. Phương pháp được đề xuất là một sidecar tạm thời : bằng chứng di chuyển cùng với giao dịch giống như một sidecar blob Đề xuất cải tiến Ethereum (EIP)-4844 . Các nút mempool và trình xây dựng chạy từng mục sidecar thông qua verify_proof (và kiểm tra các bất biến từ định dạng Giao dịch ) trước khi chuyển tiếp hoặc bao gồm giao dịch. Sau đó, trình xây dựng loại bỏ sidecar trước khi đưa vào Block , gấp nó vào bằng chứng Block L1 đệ quy và loại bỏ nó. Các trình xác thực chỉ thấy phần thân giao dịch (danh sách proofs và public_values_hash ) cộng với bằng chứng Block L1; chúng không bao giờ cần các byte bằng chứng thô. Do đó, bằng chứng Block L1 bao phủ một cách đệ quy mọi giao dịch mang bằng chứng trong Block (các bằng chứng hậu lượng tử có thể đủ lớn đến mức L1 bị giới hạn ở một bằng chứng trên mỗi vị trí).

Kích thước. Đề xuất cải tiến Ethereum (EIP)-8025 đặt MAX_PROOF_SIZE = 400 KiB cho mỗi bằng chứng. Đặc tả không giới hạn len(proofs) , nhưng giới hạn kích thước của máy khách mempool khiến 2-3 là mức trần thực tế.

Tác động đến các đợt hợp nhất hiện có

Bảng dưới đây trình bày số dòng mã Solidity (không phải dòng trống, không phải dòng chú thích) cho các hợp đồng onchain của mỗi dự án, được chia thành logic tổng hợp "cốt lõi" và ngăn xếp xác minh bằng chứng mà cơ chế xác minh bằng chứng gốc sẽ loại bỏ.

Những con số này chỉ là ước tính sơ bộ. Chúng chỉ bao gồm mã Solidity on-chain và không bao gồm các trình chứng minh Ngoài chuỗi , trình sắp xếp chuỗi và chương trình khách đằng sau mỗi program_hash . Các bề mặt quản trị (chữ ký đa chữ ký, khóa thời gian, hợp đồng Các tổ chức tự trị phi tập trung (DAO) , quản trị viên proxy), cầu nối dành riêng cho đối tác và mã mẫu proxy được loại trừ khỏi cả hai cột.

Hệ thống sáu hợp đồng đa xác minh của Taiko được thu gọn thành một hợp đồng duy nhất trong hộp thư đến:

 contract TaikoInbox {mapping(bytes32 => bool) public isTrustedProgram; // whitelisted per-zkVM program hashesuint256 public minProofCount; // multi-proof threshold (eg 2)function proveBatches(BatchMetadata[] calldata metas,Transition[] calldata trans// _proof parameter removed: verified by the CL) external {// Verify all proofs used trusted programs.require(PROOFCOUNT() >= minProofCount, "insufficient proofs");for (uint256 i = 0; i < PROOFCOUNT(); i++) {require(isTrustedProgram[PROGRAMHASH(i)], "untrusted program");}bytes memory publicInputs = buildPublicInputs(metas, trans);require(PUBVALUESHASH() == sha256(publicInputs), "wrong public values");// Accept the batches....}}

Một Danh sách trắng isTrustedProgram duy nhất thay thế cả isProgramTrusted (SP1) và isImageTrusted (Risc0); minProofCount thay thế areVerifiersSufficient .

Tác động đến các gói tổng hợp gốc

Hợp đồng NativeRollup từđặc tả ZK của native rollup sử dụng cùng một mẫu. Thay vì PROOFROOT so với validation_result_root , nó kiểm tra PROGRAMHASH , PUBVALUESHASH và PROOFCOUNT :

 bytes32 constant NATIVE_PROGRAM = bytes32(uint256(1));uint256 public minProofCount;function advance(BlockParams calldata params) external {bytes32 l1Anchor = blockhash(block.number - 1);bytes32 npRoot = computeNewPayloadRequestRoot(blockHash, params.feeRecipient, params.stateRoot,// ... remaining fields ...getVersionedHashes(params.payloadBlobCount),l1Anchor, bytes32(0));// SSZ-encode the StatelessValidationResult container:// new_payload_request_root (32 bytes) || successful_validation (1 byte)// || chain_id (8 bytes, little-endian).// Must match serialize_stateless_output() in execution-specs.bytes memory expectedPublicValues = SSZ.encodeStatelessValidationResult(npRoot, true, chainId);bytes32 expectedPubValuesHash = sha256(expectedPublicValues);require(PROOFCOUNT() >= minProofCount, "insufficient proofs");for (uint256 i = 0; i < PROOFCOUNT(); i++) {require(PROGRAMHASH(i) == NATIVE_PROGRAM, "not a native program");}require(PUBVALUESHASH() == expectedPubValuesHash, "wrong public values");blockHash = params.blockHash;stateRoot = params.stateRoot;blockNumber = blockNumber + 1;stateRootHistory[blockNumber] = params.stateRoot;}

Một bản cập nhật gốc (native rollup) đơn giản là bản có programHash khớp với những gì L1 chấp nhận; một bản nâng cấp L1 (ví dụ: một Fork thay đổi verify_stateless_new_payload ) sẽ được lan truyền tự động. Các bản cập nhật với máy ảo tùy chỉnh (custom VMs) sử dụng cùng một mẫu với programHash khác.