added receing messages
This commit is contained in:
parent
e51fc5a4a8
commit
b32159e8b4
|
@ -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]()
|
||||
|
|
|
@ -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);
|
||||
}
|
||||
|
||||
```
|
|
@ -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.
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue