Description of each module

Interface module: dApp developers use GraphQL to define the messages they want to transfer among chains. All user-defined rules will form a set. The users can update the set by defining GraphQL rules. 

Consensus module: Using the DPoS consensus mechanism combined with HotStuff, MEP performs consensus on four types of data: 

• User-defined message rules. These need to be propagated to all MEP nodes by consensus, thus updating the data collection ruleset. 

• Messages collected by the collection layer. Consensus and authentication of the data collected from each blockchain is required to ensure the authenticity and validity of the data. • Blockchain governance. Unified management by the MEP community to upgrade the set of blockchains that can be supported so that more chains can be supported and unneeded chains can be shut down. 

• Signature service. When performing message transfer, users need to apply for a signature from MEP, and each node will sign or refuse to sign the requested content after checking its own storage. After reaching consensus, the user (dApp) can take the signature to the destination chain to verify and then start subsequent operations. 

Threshold signature module: This module is responsible for signing the data requested by the user. We will use the algorithm described in the paper “Secure distributed key generation for discrete log based cryptosystems” [10]. The generation, distribution, and signing of threshold signatures is integrated into the consensus mechanism. The counterparts to the signature module in each MEP node are the verification services that will be deployed as smart contracts on each chain, which can verify the signatures granted to users. 

Message collection module: This module collects messages from each blockchain based on user defined requirements. This is the contact layer between MEP and each blockchain. The basis for collection is the consensus set of collection rules. Each MEP node will collect messages from multiple nodes of an underlying blockchain; these messages will be filtered and aggregated and run through the consensus module. This message collection layer is similar to an oracle machine but differs in a few important ways: First, all the data that MEP collects is on-chain, which means it’s already consensus data. In contrast, oracle machines often rely on off-chain data. All data that MEP collects is externally verifiable so that users can easily prove the correctness of MEP node data based on the blockchain’s Merkel proof. We will provide users with convenient tools to compare their data on the blockchain with their data on MEP before MEP goes live. MEP nodes will run light nodes of some underlying chains internally. 

Message processing module: This is the message processing engine. The collected messages need to be processed before they are uploaded to the chain in a specific storage format to meet the user specified requirements. 

Storage module: This is where the collected messages are stored and acts as the equivalent of a data cache for the underlying blockchain. 

Network module: Each MEP node communicates with the others through a P2P network. The data transmission and synchronization between the nodes is guaranteed by Gossip protocol.