非EVM兼容链的跨链互通
Mapo Protocol的跨链过程涉及多个步骤，从锁定资产到验证数据，确保资产在不同区块链之间的安全传输和互通,这里我们仅讨论非EMV兼容链的接入过程。完成以下几个模块的开发和部署即可接入到mapo protocol.
Light-client层
接入mapo Protocol协议的双方链都需要部署对方的light-client，这里我们仅讨论如何在支持智能合约的目标链上实现mapo-relay-chain的light-client，由于目标链支持链上的智能合约(wasm或其他)，所以mapo-relay-chain的light-client都将以目标链支持的智能合约语音来实现，这里我们主要介绍mapo-relay-chain的light-client的一些数据结构和验证方法，以方便用户使用特定语音去实现该light-client。
由于目标链上部署的map-relay-chain的light-client只需要满足一个需求，就是对来自于map-relay-chain的跨链消息的验证。为了实现该需求，map-relay-chain的light-client需要满足两个功能:
维持和更新
light-client的状态,即保存一定数量的区块头及持续更新校验新的区块头。可以根据
light-client的当前状态，验证源链上的合约事件功能，通常是交易的收据的验证（MPT的验证信息）。
light-client状态
light-client中可以保存一定数量连续的区块头用于维持当前light-client的状态，用户向light-client提交新的区块头，light-client可以验证该区块头的签名来判断该区块头的合法性。
// Header represents a block header in the Ethereum blockchain.
type Header struct {
ParentHash common.Hash `json:"parentHash" gencodec:"required"`
Coinbase common.Address `json:"miner" gencodec:"required"`
Root common.Hash `json:"stateRoot" gencodec:"required"`
TxHash common.Hash `json:"transactionsRoot" gencodec:"required"`
ReceiptHash common.Hash `json:"receiptsRoot" gencodec:"required"`
Bloom Bloom `json:"logsBloom" gencodec:"required"`
Number *big.Int `json:"number" gencodec:"required"`
GasLimit uint64 `json:"gasLimit" gencodec:"required"`
GasUsed uint64 `json:"gasUsed" gencodec:"required"`
Time uint64 `json:"timestamp" gencodec:"required"`
Extra []byte `json:"extraData" gencodec:"required"`
MixDigest common.Hash `json:"mixHash"`
Nonce BlockNonce `json:"nonce"`
// BaseFee was added by EIP-1559 and is ignored in legacy headers.
BaseFee *big.Int `json:"baseFeePerGas" rlp:"optional"`
}在map-relay-chain的主网上的验证者会对每一个区块都签名，并且该签名会保存在区块头里（header.Extra）,light-client可以通过验证该签名，同时map-relay-chain的验证者集合的变化结果也不会保存在区块头（header.Extra）里，所以light-client可以根据更新的验证者集合来验证区块头.
签名数据Msg包含了区块头的hash,达成共识的round以及一个MsgCommit:
// hash: header.Hash()
func PrepareCommittedSeal(hash common.Hash, round *big.Int) []byte {
var buf bytes.Buffer
buf.Write(hash.Bytes())
buf.Write(round.Bytes())
buf.Write([]byte{byte(istanbul.MsgCommit)})
return buf.Bytes()
}IstanbulExtra结构的数据经过rlp编码后存入header.Extra字段，其中就包含了达成共识的round数据，bls的签名数据AggregatedSeal.Signature以及变化的验证者,light-client可以根据这些数据更新其状态及验证者集合. 更多信息
type IstanbulExtra struct {
// AddedValidators are the validators that have been added in the block
AddedValidators []common.Address
// AddedValidatorsPublicKeys are the BLS public keys for the validators added in the block
AddedValidatorsPublicKeys []blscrypto.SerializedPublicKey
// AddedValidatorsG1PublicKeys are the BLS public keys for the validators added in the block
AddedValidatorsG1PublicKeys []blscrypto.SerializedG1PublicKey
// RemovedValidators is a bitmap having an active bit for each removed validator in the block
RemovedValidators *big.Int
// Seal is an ECDSA signature by the proposer
Seal []byte
// AggregatedSeal contains the aggregated BLS signature created via IBFT consensus.
AggregatedSeal IstanbulAggregatedSeal
// ParentAggregatedSeal contains and aggregated BLS signature for the previous block.
ParentAggregatedSeal IstanbulAggregatedSeal
}
type IstanbulAggregatedSeal struct {
// Bitmap is a bitmap having an active bit for each validator that signed this block
Bitmap *big.Int
// Signature is an aggregated BLS signature resulting from signatures by each validator that signed this block
Signature []byte
// Round is the round in which the signature was created.
Round *big.Int
}light-client验证消息
一旦light-client更新到最新状态了就可以用于验证跨链消息了，通常使用链上交易中输出的日志来表示一个跨链消息，所以我们只需要验证消息所在的交易收据的合法性，即可证明该跨链消息的有效性.
证明交易收据的合法性只需要验证该交易收据所在的MPT树的root与对应的区块头里的ReceiptHash一致即可，则用户可以获取某交易的证明数据，并将收据及证明数据传递到已部署的light-client即可完成一个跨链消息的验证.
如下获取一条交易收据的证明数据:
func getTxProve() []byte {
// get receipts from the node
conn := dialConn()
txsHash := getTransactionsHashByBlockNumber(conn, blockNumber)
receipts := getReceiptsByTxsHash(conn, txsHash)
// get receipts from json
//receipts := GetReceiptsFromJSON()
tr, err := trie.New(common.Hash{}, trie.NewDatabase(memorydb.New()))
if err != nil {
panic(err)
}
tr = atlastypes.DeriveTire(receipts, tr)
proof := light.NewNodeSet()
key, err := rlp.EncodeToBytes(txIndex)
if err != nil {
panic(err)
}
if err = tr.Prove(key, 0, proof); err != nil {
panic(err)
}
txProve := TxProve{
Tx: &TxParams{
From: fromAddr.Bytes(),
To: toAddr.Bytes(),
Value: SendValue,
},
Receipt: receipts[txIndex],
Prove: proof.NodeList(),
BlockNumber: blockNumber.Uint64(),
TxIndex: txIndex,
}
input, err := rlp.EncodeToBytes(txProve)
if err != nil {
panic(err)
}
return input
}Maintainer开发
Maintainer服务是一个独立的程序,用于更新同步light-client的状态,向源链和目标链上的light-client提交对应链上的区块头数据. 由于Maintainer服务已经支持了map-relay-chain,所以目标链的开发者只需要在Maintainer服务中增加对自己链的支持即可. 接入链的开发者可以fork一个mapo protocol提供的Maintainer做二次开发以增加对自己链的支持.
获取当前
light-client的状态根据当前
light-client的状态获取对应链的区块头数据并提交到light-client
Mos层
Mos层定义了mapo protocol通用消息跨链的框架结构及实现逻辑，Mos层需要在跨链双方的链上都部署，由于mapo-relay-chain上已经实现了该模块，所以目标链的开发者需要参考一下的数据和接口来实现该模块。
主要数据结构和接口:
enum MessageType {
CALLDATA,
MESSAGE
}
// @notice This is the configuration you need across the chain.
// @param relay - When it is true, the relay chain is required to perform a special execution to continue across the chain.
// @param msgType - Different execution patterns of messages across chains.
// @param target - The contract address of the target chain.
// @param payload - Cross-chain content.
// @param gasLimit - The gasLimit allowed to be consumed by an operation performed on the target chain.
// @param value - Collateral value cross-chain, currently not supported, default is 0.
struct MessageData {
bool relay;
MessageType msgType;
bytes target;
bytes payload;
uint256 gasLimit;
uint256 value;
}
// @notice Gets the fee to cross to the target chain.
// @param toChain - Target chain chainID.
// @param feeToken - Token address that supports payment fee,if it's native, it's address(0).
// @param gasLimit - The gasLimit allowed to be consumed by an operation performed on the target chain.
function getMessageFee(uint256 toChain, address feeToken, uint256 gasLimit) external view returns(uint256, address);
// @notice Initiate cross-chain transactions. Generate cross-chain logs.
// @param toChain - Target chain chainID.
// @param messageData - Structure MessageData encoding.
// @param feeToken - In what Token would you like to pay the fee.
function transferOut(uint256 toChain, bytes memory messageData, address feeToken) external payable returns(bytes32);
// @notice Add the fromaddress permission.
// @param fromChain - The chainID of the source chain.
// @param fromAddress - The call address of the source chain.
// @param tag - Permission,false: revoke permission.
function addRemoteCaller(uint256 fromChain, bytes memory fromAddress, bool tag) external;
// @notice Query whether the contract has execution permission.
// @param mosAddress - This is the mos query address.
// @param fromChainId - The call chain id of the source chain.
// @param fromAddress - The call address of the source chain.
function getExecutePermission(address mosAddress,uint256 fromChainId,bytes memory fromAddress) external view returns(bool);
event mapMessageOut(uint256 indexed fromChain, uint256 indexed toChain, bytes32 orderId, bytes fromAddrss, bytes callData);
event mapMessageIn(uint256 indexed fromChain, uint256 indexed toChain, bytes32 orderId, bytes fromAddrss, bytes callData, bool result, bytes reason);Messenger程序开发
Messenger服务是一个独立的程序，旨在监控并路由源链和目标链上mos的特定事件。这些事件包括常见的消息事件，如mapMessageOut和mapMessageIn。Messenger服务为这些事件构建相应的证明数据，并最终将跨链消息以及证明数据提交到目标链。由于Messenger服务已经支持map-relay-chain，集成链的开发者只需要在Messenger服务中添加对自己链的支持。开发者可以fork一个Mapo Protoco提供的Messenger服务，并自定义以添加对自己链的支持。
在这个过程中，Messenger服务在促进跨链消息及其相关证明的传输中扮演关键角色，确保信息在源链和目标链之间安全可靠地传输。它抽象了与智能合约交互和处理事件的复杂性，使开发者更容易将自己的链集成到Mapo Protocol框架中。
应用层
应用层代表了跨链框架的真正业务逻辑。用户在该层定义具体的业务逻辑，如资产管理以及锁定、解锁、铸造、销毁等操作。实际的跨链操作发生在应用层中，其中会调用Mos层的transferOut接口，将具体的跨链消息写入链上。
以下是应用层内的跨链过程流程：
用户交互：用户与应用层进行交互，启动跨链操作，如在链之间锁定、解锁或转移资产。
调用transferOut：当用户启动跨链操作时，应用层会调用
Mos层的transferOut接口。该接口构建和格式化跨链消息，包括在目标链上执行的操作的细节。路由消息：一旦跨链消息构建完成，Messenger服务会被通知(监听)。Messenger服务收集必要的证明数据，并将跨链消息与证明一起提交到目标链。
目标链验证：在目标链上，使用为源链部署的
light-client来验证接收到的跨链消息的真实性和合法性。light-client确保数据与源链的数据一致，确认消息的有效性。执行和操作：在成功验证后，目标链上的应用层解码接收到的消息并执行相应的操作，如铸造新代币、解锁锁定的资产等。
应用层充当用户意图与跨链通信的技术复杂性之间的桥梁。它提供了用户友好的界面，让用户触发跨链操作，并确保这些操作在涉及的链之间安全执行和验证。
Last updated