diff --git a/src/SUMMARY.md b/src/SUMMARY.md index df386fe..9c80bf9 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -74,10 +74,12 @@ - [EVM](./development/messages/sending/evm.md) - [Solana]() - [Algorand]() + - [CosmWasm]() - [Registering xDapps](./development/messages/registration/overview.md) - [EVM](./development/messages/registration/evm.md) - [Solana]() - [Algorand]() + - [CosmWasm]() - [Relaying Messages](./development/messages/relaying/overview.md) - [Manual Relays]() - [Rest Relayers]() @@ -87,6 +89,7 @@ - [EVM]() - [Solana]() - [Algorand]() + - [CosmWasm]() - [Projects](./projects/summary.md) - [Messenger](./projects/messenger/introduction.md) - [Prerequistes]() diff --git a/src/development/messages/receiving/evm.md b/src/development/messages/receiving/evm.md new file mode 100644 index 0000000..4103c3e --- /dev/null +++ b/src/development/messages/receiving/evm.md @@ -0,0 +1,28 @@ +# Receving Messages on EVM + +To receive messages in EVM we need to implement a function `receiveMsg`. The name of this function is arbitrary, any function name works as long as the your relayer knows what to call on the application contract when submitting messages. + +This function will take in and encoded set of `bytes` as the VAA and then call the `parseAndVerifyVM` function on the Core Bridge to validate the message. + +```solidity + + function receiveEncodedMsg(bytes memory encodedMsg) public { + (IWormhole.VM memory vm, bool valid, string memory reason) = core_bridge.parseAndVerifyVM(encodedMsg); + + //1. Check Wormhole Guardian Signatures + // If the VM is NOT valid, will return the reason it's not valid + // If the VM IS valid, reason will be blank + require(valid, reason); + + //2. Check if the Emitter Chain contract is registered + require(_applicationContracts[vm.emitterChainId] == vm.emitterAddress, "Invalid Emitter Address!"); + + //3. Check that the message hasn't already been processed + require(!_completedMessages[vm.hash], "Message already processed"); + _completedMessages[vm.hash] = true; + + //Process the message. In this case, we just store the string in the VAA to storage + current_msg = string(vm.payload); + } + +``` \ No newline at end of file diff --git a/src/development/messages/receiving/overview.md b/src/development/messages/receiving/overview.md new file mode 100644 index 0000000..d00ab1b --- /dev/null +++ b/src/development/messages/receiving/overview.md @@ -0,0 +1,9 @@ +# Overview of Receving Messages + +The basic flow of receving messages requires you (or a relayer!) to submit the VAA to your application contract. This contract then calls the Core Bridge on the receving chain to check the message signatures against the stored guardian set signatures. + +If those checks pass, then the application can check to see if it's a message that's already been processed before by checking it's sequence number against a store list of processed message sequence numbers. + +The final optional check is to make sure that the message came from an application from the source chain that we were expecting. Usually this is our own application, and should be registered during initialization steps (see [registration](../registration/overview.md)). + +After we have ensured all those things are correct, we can go ahead and process the message according to the business logic in our application. \ No newline at end of file diff --git a/src/development/scaffold/overview.md b/src/development/scaffold/overview.md index 58d7d8d..00fceeb 100644 --- a/src/development/scaffold/overview.md +++ b/src/development/scaffold/overview.md @@ -14,7 +14,7 @@ The handlers folder contains the js client code to deal with each chain's specif They all take in a context object that's made up of the -### starter.js +### orchestrator.js This file parses command line args and filters calls to chain management handlers. ### xdapp.config.json