Skip to content
MCH dev docs

Moonchain Supernode

Version 2.0.4

Moonchain Supernode V2

Section titled “Moonchain Supernode V2”

In our zkEVM SupernodeV2, there are two important parts to a Moonchain Supernode, which are connected over the engine API:

  • MCH-geth
  • MCH-client

MCH geth

Section titled “MCH geth”

The MCH-geth repository is a customized version of taiko-geth tailored to integrate Moonchain’s specifications. Functioning as an IoT Web3 platform, it interfaces with an zk node previously. Similar to Ethereum’s L1/L2 execution engines, MCH-geth monitors and processes new IoT transactions within the network. These transactions are ececuted on the EVM, maintaining the latest state and comprehensive database of current IoT data. Subsequently, it submits proofs using Zero-Knowledge cryptography for enhanced security and privacy.

MCH client

Section titled “MCH client”

The compiled binary bin/MCH-client serves as the primary interface, offering three essential sub-commands:

  1. driver: Ensures synchronization between the IoT execution engine’s chain and the MCHL1 contract. This command directs the IoT execution engine to maintain alignment with the designated MCHL1 contract.
  2. proposer: Facilitates the proposal of new transactions from the IoT execution engine’s transaction pool to the MCHL1 contrct. This sub-command is responsible for initiating new transaction proposals within the ecosystem.
  3. prover: Manages the verification process by requesting Zero-Knowledge (ZK) proofs from the zkEVM. Additionally, it submits transactions to validate proposed blocks, confirming their integrity and validity within the blockchain network.

Driver

Section titled “Driver”

The Driver component within the MCH client software functions as an IoT consensus client. It actively monitors the MCH layer 1 protocol contract for incoming IoT blocks. Upon detecting new blocks, the Driver directs the connected IoT execution engine to incorporate these blocks into its local chain using the Engine API.

Engine API

Section titled “Engine API”

The Engine API serves as the interface through which the Driver communicates with the IoT execution engine. It enables the Driver to instruct the execution engine to perform tasks such as inserting new blocks into its local chain or handling chain reorganizations when necessary. This API facilitates seamless coordination between the MCH client’s Driver and the underlying IoT execution engine, ensuring synchronization and consistency across the network.

Chain synchronization process

Section titled “Chain synchronization process”

NOTE

In MCH, a block’s timestamp can be equal to its parent block’s timestamp, which differs from the original Ethereum protocol. Therefore, it is permissible for there to be two MCHL1.proposeBlock transactions included in one L1 block. This flexibility in timestamp handling supports Moonchain’s specific blockchain architecture and operational requirements.

The driver component in MCH plays a crucial role in coordinating with the IoT execution engine. It begins by informing the IoT execution engine about the latest verified IoT head from the MCH contract and attempts initial synchronization through peer-to-peer (P2P) communication. The driver monitors the sync progress of the execution engine, transitioning to inserting verified blocks into its local chain via the Engine API if no new sync progress is detected over time.

Once the IoT execution engine is synchronized with the latest verified IoT head, the driver subscribes to MCHL1.BlockProposed events. Upon receiving notification of a new pending block proposal, the following chronological order can be perceived.

  1. Retrieve the MCHL1.proposeBlock L1 transaction associated with the event.
  2. Decode the transaction’s calldata to extract the txList (transaction list) and block metadata.
  3. Validate the txList against the predefined rules specified in MCH to ensure its compliance and integrity within the blockchain network.

If the txList is valid:

  1. Construct a deterministic MCHL2.anchor transaction based on the protocol’s rules, placing it as the first transaction in the proposed txList.
  2. Utilize the validated txList and decoded block metadata to compose a deterministic IoT block.
  3. Instruct the IoT execution engine to insert this assembled block and designate it as the current canonical chain’s head using the Engine API.

If the txList is invalid:

  1. Generate a MCHL2.invalidateBlock transaction and assemble an IoT block containing only this transaction.
  2. Direct the IoT execution engine to insert this block without setting it as the chain’s head via the Engine API.