-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standalone getting started guide #155
Merged
Merged
Changes from all commits
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
65e87aa
standalone getting started guide
cam-schultz 19dd4d6
Update contracts/src/CrossChainApplications/GETTING_STARTED.md
cam-schultz 74df9f7
Update contracts/src/CrossChainApplications/GETTING_STARTED.md
cam-schultz 240a475
Update contracts/src/CrossChainApplications/GETTING_STARTED.md
cam-schultz 94b6368
Update contracts/src/CrossChainApplications/GETTING_STARTED.md
cam-schultz a788cc7
Update contracts/src/CrossChainApplications/GETTING_STARTED.md
cam-schultz ee7f264
Update contracts/src/CrossChainApplications/GETTING_STARTED.md
cam-schultz a8806ec
cleanup
cam-schultz 751617c
Merge branch 'main' into standalone-getting-started
cam-schultz dfb04c4
rephrase
cam-schultz 03bd439
Merge branch 'main' into standalone-getting-started
cam-schultz ecd38ea
update go bindings
cam-schultz f60da78
Merge branch 'main' into standalone-getting-started
cam-schultz File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
2 changes: 1 addition & 1 deletion
2
abi-bindings/go/CrossChainApplications/ERC20Bridge/ERC20Bridge/ERC20Bridge.go
Large diffs are not rendered by default.
Oops, something went wrong.
2 changes: 1 addition & 1 deletion
2
...ainApplications/ExampleMessenger/ExampleCrossChainMessenger/ExampleCrossChainMessenger.go
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
214 changes: 214 additions & 0 deletions
214
contracts/src/CrossChainApplications/GETTING_STARTED.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,214 @@ | ||
# Getting Started with an Example Teleporter Application | ||
|
||
This section walks through how to build an example cross-chain application on top of the Teleporter protocol, recreating the `ExampleCrossChainMessenger` contract that sends arbitrary string data from one chain to another. Note that this tutorial is meant for education purposes only. The resulting code is not intended for use in production environments. | ||
|
||
## Step 1: Create Initial Contract | ||
|
||
Create a new file called `MyExampleCrossChainMessenger.sol` in the directory that will hold the application. | ||
|
||
At the top of the file define the Solidity version to work with, and import the necessary types and interfaces. | ||
|
||
```solidity | ||
pragma solidity 0.8.18; | ||
|
||
import {ITeleporterMessenger, TeleporterMessageInput, TeleporterFeeInfo} from "../../Teleporter/ITeleporterMessenger.sol"; | ||
import {ITeleporterReceiver} from "../../Teleporter/ITeleporterReceiver.sol"; | ||
``` | ||
|
||
Next, define the initial empty contract. | ||
|
||
```solidity | ||
contract MyExampleCrossChainMessenger {} | ||
``` | ||
|
||
## Step 2: Integrating Teleporter Messenger | ||
|
||
Now that the initial empty `MyExampleCrossChainMessenger` is defined, it's time to integrate the `ITeleporterMessenger` that will provide the functionality to deliver cross chain messages. | ||
|
||
Create a state variable of `ITeleporterMessenger` type called `teleporterMessenger`. Then create a constructor for our contract that takes in an address where the Teleporter Messenger would be deployed on this chain, and set our state variable with it. | ||
|
||
```solidity | ||
contract ExampleCrossChainMessenger { | ||
ITeleporterMessenger public immutable teleporterMessenger; | ||
|
||
constructor(address teleporterMessengerAddress) { | ||
teleporterMessenger = ITeleporterMessenger(teleporterMessengerAddress); | ||
} | ||
} | ||
``` | ||
|
||
## Step 3: Send and Receive | ||
|
||
Now that `MyExampleCrossChainMessenger` has an instantiation of `ITeleporterMessenger`, the next step is to add in functionality of sending and receiving arbitrary string data between chains. | ||
|
||
To start, create the function declarations for `sendMessage`, which will send string data cross-chain to the specified destination address' receiver. This function allows callers to specify the destination chain ID, destination address to send to, relayer fees, required gas limit for message execution at the destination address' `receiveTeleporterMessage` function, and the actual message data. | ||
|
||
```solidity | ||
// Send a new message to another chain. | ||
function sendMessage( | ||
bytes32 destinationBlockchainID, | ||
address destinationAddress, | ||
address feeTokenAddress, | ||
uint256 feeAmount, | ||
uint256 requiredGasLimit, | ||
string calldata message | ||
) external returns (uint256 messageID) {} | ||
``` | ||
|
||
`MyExampleCrossChainMessenger` also needs to implement `ITeleporterReceiver` by adding the method `receiveTeleporterMessage` that receives the cross-chain messages from Teleporter. | ||
|
||
```solidity | ||
// Receive a new message from another chain. | ||
function receiveTeleporterMessage( | ||
bytes32 originBlockchainID, | ||
address originSenderAddress, | ||
bytes calldata message | ||
) external {} | ||
``` | ||
|
||
Now it's time to implement the methods, starting with `sendMessage`. First, add the import for OpenZeppelin's `IERC20` contract to the top of your contract. | ||
|
||
```solidity | ||
import {IERC20} from "@openzeppelin/contracts/token/ERC20/IERC20.sol"; | ||
``` | ||
|
||
Then in `sendMessage` check whether `feeAmount` is greater than zero. If it is, transfer and approve the amount of IERC20 asset at `feeTokenAddress` to the Teleporter Messenger saved as a state variable. | ||
|
||
```solidity | ||
function sendMessage( | ||
bytes32 destinationBlockchainID, | ||
address destinationAddress, | ||
address feeTokenAddress, | ||
uint256 feeAmount, | ||
uint256 requiredGasLimit, | ||
string calldata message | ||
) external returns (uint256 messageID) { | ||
// For non-zero fee amounts, first transfer the fee to this contract, and then | ||
// allow the Teleporter contract to spend it. | ||
if (feeAmount > 0) { | ||
IERC20 feeToken = IERC20(feeTokenAddress); | ||
require( | ||
feeToken.transferFrom(msg.sender, address(this), feeAmount), | ||
"Failed to transfer fee amount" | ||
); | ||
require( | ||
feeToken.approve(address(teleporterMessenger), feeAmount), | ||
"Failed to approve fee amount" | ||
); | ||
} | ||
} | ||
``` | ||
|
||
Note: Relayer fees are an optional way to incentive relayers to deliver a Teleporter message to its destination. They are not strictly necessary, and may be omitted if a relayer is willing to relay messages with no fee, such as with a self-hosted relayer. | ||
|
||
Next, add the call to the `TeleporterMessenger` contract with the message data to be executed when delivered to the destination address. In `sendMessage`, form a `TeleporterMessageInput` and call `sendCrossChainMessage` on the `TeleporterMessenger` instance to start the cross chain messaging process. | ||
|
||
> `allowedRelayerAddresses` is empty in this example, meaning any relayer can try to deliver this cross chain message. Specific relayer addresses can be specified to ensure only those relayers can deliver the message. | ||
> The `message` must be ABI encoded so that it can be properly decoded on the receiving end. | ||
|
||
```solidity | ||
return | ||
teleporterMessenger.sendCrossChainMessage( | ||
TeleporterMessageInput({ | ||
destinationBlockchainID: destinationBlockchainID, | ||
destinationAddress: destinationAddress, | ||
feeInfo: TeleporterFeeInfo({ | ||
feeTokenAddress: feeTokenAddress, | ||
amount: feeAmount | ||
}), | ||
requiredGasLimit: requiredGasLimit, | ||
allowedRelayerAddresses: new address[](0), | ||
message: abi.encode(message) | ||
}) | ||
); | ||
``` | ||
|
||
With the sending side complete, the next step is to implement `ITeleporterReceiver.receiveTeleporterMessage`. The receiver in this example will just receive the arbitrary string data, and check that the message is sent through Teleporter. | ||
|
||
```solidity | ||
// Receive a new message from another chain. | ||
function receiveTeleporterMessage( | ||
bytes32 originBlockchainID, | ||
address originSenderAddress, | ||
bytes calldata message | ||
) external { | ||
// Only the Teleporter receiver can deliver a message. | ||
require(msg.sender == address(teleporterMessenger), "Unauthorized."); | ||
|
||
// do something with message. | ||
return true; | ||
} | ||
``` | ||
|
||
The base of sending and receiving messages cross chain is complete. `MyExampleCrossChainMessenger` can now be expanded with functionality that saves the received messages, and allows users to query for the latest message received from a specified chain. | ||
|
||
## Step 4: Storing the Message | ||
|
||
Start by defining the `struct` for how to save our messages. It saves the string message itself and the address of the sender. | ||
|
||
A map will also be added where the key is the `originBlockchainID`, and the value is the latest `message` sent from that chain. | ||
|
||
```solidity | ||
// Messages sent to this contract. | ||
struct Message { | ||
address sender; | ||
string message; | ||
} | ||
|
||
mapping(bytes32 originBlockchainID => Message message) private _messages; | ||
``` | ||
|
||
Next, update `receiveTeleporterMessage` to save the message into our mapping after we receive and verify that it's sent from Teleporter. ABI decode the `message` bytes into a string. | ||
|
||
```solidity | ||
// Receive a new message from another chain. | ||
function receiveTeleporterMessage( | ||
bytes32 originBlockchainID, | ||
address originSenderAddress, | ||
bytes calldata message | ||
) external { | ||
// Only the Teleporter receiver can deliver a message. | ||
require(msg.sender == address(teleporterMessenger), "Unauthorized."); | ||
|
||
// Store the message. | ||
messages[originBlockchainID] = Message(originSenderAddress, abi.decode(message, (string))); | ||
} | ||
``` | ||
|
||
Next, add a function called `getCurrentMessage` that allows users or contracts to easily query our contract for the latest message sent by a specified chain. | ||
|
||
```solidity | ||
// Check the current message from another chain. | ||
function getCurrentMessage( | ||
bytes32 originBlockchainID | ||
) external view returns (address, string memory) { | ||
Message memory messageInfo = messages[originBlockchainID]; | ||
return (messageInfo.sender, messageInfo.message); | ||
} | ||
``` | ||
|
||
There we have it, a simple cross chain messenger built on top of Teleporter! Full example [here](./ExampleMessenger/ExampleCrossChainMessenger.sol). | ||
|
||
## Step 5: Testing | ||
|
||
For testing, `scripts/local/test.sh` sets up a local Avalanche network with three subnets deployed with Teleporter, and a relayer to deliver Teleporter messages. To add an integration test simply add a new test script under `integration-tests`. An integration test for `ExampleCrossChainMessenger` is already included (`scripts/local/integration_tests/example_messenger.sh`), which performs the following steps: | ||
|
||
1. Deploys the [ExampleERC20](../Mocks/ExampleERC20.sol) token to subnet A. | ||
2. Deploys `ExampleCrossChainMessenger` to both subnets A and B. | ||
3. Approves the cross-chain messenger on subnet A to spend ERC20 tokens from the default address. | ||
4. Sends `"hello world"` from subnet A to subnet B's cross-chain messenger to receive. | ||
5. Calls `getCurrentMessage` on subnet B to make sure the right message and sender are received. | ||
|
||
Running `./test.sh example_messenger` at the root of the repo should yield at the end of the test: | ||
|
||
```bash | ||
test_runner | Raw result is: "0x5DB9A7629912EBF95876228C24A848de0bfB43A9 | ||
test_runner | hello world!" | ||
test_runner | The latest message from chain ID GoTmTVw77eGauaL17e1xPrtWEa72SQnvf9G8ackU6KZVGVYpz was: | ||
test_runner | Message Sender: 0x5DB9A7629912EBF95876228C24A848de0bfB43A9 | ||
test_runner | Message: "hello world!" | ||
test_runner | Successfully called getCurrentMessage. | ||
test_runner | Done running test example_messenger. | ||
test_runner | | ||
test_runner exited with code 0 | ||
``` |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ran
scripts/local/test.sh
in teleporter base directory and it failed.I believe it is because while running
/code/docker/run_setup.sh
, subnet-evm is not cloned to the docker container before sourcing the latest avalanchego version from./scripts/versions.sh
in subnet-evm.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
might conflict with #152
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is
teleporter/subnet-evm
populated? After cloningteleporter
, rungit submodule update --init --recursive
to do so.That being said, we're planning on removing the Docker-based integration tests, as well as reworking our
subnet-evm
dependency, so this part of the README will be removed soon.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did this and it ran, but seems that once the subnets were up and running the script exited due to foundry not being installed.
Might not be worth troubleshooting this further if this testing portion is going to be rewritten. If this test is removed, this tutorial should definitely still include a test script or equivalent instructions for beginners.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this was an issue with how our foundry fork was setup. If you were running this on Mac M1, then this should be resolved now. In any case, agreed not worth debugging here.