added receing messages

This commit is contained in:
spacemandev 2022-06-17 08:54:29 -05:00
parent e51fc5a4a8
commit b32159e8b4
4 changed files with 41 additions and 1 deletions

View File

@ -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]()

View File

@ -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);
}
```

View File

@ -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.

View File

@ -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