Skip to main content

Bundles and Domain Blocks

Bundles​

Operators produce bundles, which add new extrinsics to the execution inbox, and output the execution result of all prior bundles. Bundles are produced probabilistically based on the stake-weighted operator VRF election. The bundle consists of a header and a body.

Bundle Header​

  • ProofOfElection: the proof for the stake-weighted VRF election.
    • domain_id: the index of the domain for this bundle. Must exist within the DomainRegistry.
    • operator_id: the id for this operator in the registry. We do not need to include the public key since it already resides within the operator registry.
    • slot_number: the time slot number for the randomness beacon.
    • proof_of_time: random output for that slot from the Proof-of-Time beacon.
    • vrf_signature: the signature of the slot randomness using the operator’s private key. Used to verify the VRF election based on the operator's proportion of stake for this domain.
  • ExecutionReceipt of the last domain block executed.
  • estimated_bundle_weight: the total (estimated) weight of all extrinsics in the bundle. Used to prevent overloading the bundle with compute.
  • bundle_extrinsics_root: the Merkle root of all new extrinsics included in this bundle, will be added to the execution_inbox for this domain must be included in the next domain block for it to be valid.
  • signature: the Schnorr signature of the hash of the bundle header.

Bundle Body​

The bundle body is largely an “opaque blob” for consensus nodes. They only check to ensure the total size, weight, and Merkle roots are correct, but they should not need to interpret the semantics of individual transactions.

  • extrinsics an ordered list of all new extrinsics being proposed by this operator for the next domain block. All the extrinsic is verified against the last domain block according to the ExecutionReceipt in the bundle header.

Bundle Limits​

The size of bundle body in bytes and it's estimated_bundle_weight are limited by the max_bundle_size and max_bundle_weight domain configuration items as well as the consensus block size and weight limits based on the expected number of bundles bundle_slot_probability/SLOT_PROBABILITY in a single block.

The max_bundle_size item should be defined such that the average bundle size by expected number of bundles fits within the consensus block size limit. The max_bundle_weight item should be defined based on hardware expectations for this domain. The operators would on average have to handle execution of domain blocks with bundle_slot_probability/SLOT_PROBABILITY bundles.

For example, given the consensus SLOT_PROBABILITY=1/6 if bundle_slot_probability = 1, each domain block is expected to have 6 bundles on average with 95.74% of blocks having 11 or fewer bundles. In this case, max_bundle_weight should be defined so that the operator can execute the total weight of 6 full bundles within the target block weight limit of 1500 ms. Similarly, max_bundle_size should be defined to fit 6 full bundles within the consensus block size limit of 3.75 MiB for normal extrinsics. The domain config would then have:

  • bundle_slot_probability = 1
  • max_bundle_weight = 250 ms
  • max_bundle_size = 655 360 bytes

The weight limit of any individual extrinsic is equal to max_bundle_weight as even the biggest extrinsic should fit within the bundle to be included by operators.

The creators of a domain may set up different limits based on their execution needs, as long as they are within the system limits defined in the Domain Genesis Config section. For example, a domain may choose a higher max_bundle_weight and lower bundle_slot_probability.

Domain Blocks​

Domain block follows the standard Substrate block format. It consists of a Header and a list of extrinsics that are compiled from the bundles contained within the consensus block.

  • Header:

    • parent_hash

    • number

    • state_root

    • extrinsics_root

  • Extrinsics

Execution Receipt​

Execution Receipt (ER) is a deterministic receipt for the execution of a domain block. It provides a way to prove or disprove valid execution of the ordered set of extrinsics in the domain block body.

  • domain_block_number: the index of the current domain block that forms the basis of this ER.

  • domain_block_hash: the block hash corresponding to domain_block_number.

  • domain_block_extrinsics_root: extrinsics root field of the header of the domain block referenced by this ER.

  • parent_domain_block_receipt_hash: a pointer to the hash of the ER for the last domain block. The parent must have already been included in this domain’s blocktree by the consensus chain for this bundle to be valid. Note that this does not have to be the tip of the domain blocktree (on the consensus chain), as this bundle could be confirming an existing tip or forking away from a fraudulent branch.

  • consensus_block_number: a pointer to the consensus block index which contains all of the bundles that were used to derive and order all extrinsics executed by the current domain block for this ER.

  • consensus_block_hash: a pointer to the consensus block hash which contains all of the bundles that were used to derive and order all extrinsics executed by the current domain block for this ER.

  • inboxed_bundles: list of all bundles included in and excluded from execution by this domain block, contains a list of hashes and invalidity reasons for bundles (Valid or Invalid(InvalidBundleType), extrinsics_root). The bundles marked Invalid were initially included in the consensus block, but later deemed invalid and excluded from execution.

  • bundle_extrinsics_roots: all extrinsic_roots for all bundles being executed by this block. Used to ensure these are contained within the state of the execution_inbox.

  • final_state_root: the final state root for the current domain block reflected by this ER. Used for verifying storage proofs for domains.

  • execution_trace: an ordered list of the post-state root values after each transaction in the current domain block was executed, as computed locally by this operator.

  • execution_trace_root: the Merkle root of the execution trace for the current domain block. Used for verifying fraud proofs.

  • block_fees: all SSC fees for this ER to be shared across operators. These include the total execution and storage fees for executing the previous domain block and fees for relaying the XDM messages to other domains.

  • transfers: amounts transferred via XDM to/from other domains or consensus chain or otherwise burned/minted on this domain

    • transfers_in into the current domain
    • transfers_out out of the current domain