-
Notifications
You must be signed in to change notification settings - Fork 27
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
Add teleporter messenger to genesis #474
Changes from all commits
d5c83f4
95242cd
f6a8086
8b5fde9
b00a9d8
371c392
071e119
5f2fc4e
3b1c93d
78a715f
57a9733
b0f5ec2
f492c8e
f0fa07f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,16 +1,12 @@ | ||
## Teleporter Messenger Contract | ||
This directory contains Solidity contracts implementing the Teleporter messaging protocol. | ||
## Contracts | ||
This directory contains Solidity contracts that leverage Avalanche Warp Messaging to implement unique cross-chain functions. | ||
|
||
This directory is set up as a [Foundry](https://github.com/foundry-rs/foundry) project. Use the `scripts/install_foundry.sh` to install the correct version of the ava-labs fork of foundry. Further documentation about given contracts can be found in`src/teleporter/`. | ||
This directory is set up as a [Foundry](https://github.com/foundry-rs/foundry) project. Use the `scripts/install_foundry.sh` to install the correct version of the ava-labs fork of foundry. | ||
|
||
## Building and Running | ||
- To compile the contracts run `forge build` from this directory. | ||
- Similarly, to run unit tests, run `forge test`. | ||
- See additional testing and deployment options [here](https://book.getfoundry.sh/forge/). | ||
|
||
## Deployment | ||
**Do not deploy using `forge create`**. See [this guide](https://github.com/ava-labs/teleporter/blob/main/utils/contract-deployment/README.md) on how to properly deploy the `TeleporterMessenger` contract to your Subnet. | ||
|
||
## Generate documentation | ||
- Documentation can be generated by running `forge doc --build` from this repository. By default, this will generate documentation to `contracts/docs/`, and an HTML book to `contracts/docs/book/`. It's also possible to serve this book locally by running `forge doc --serve <PORT>`. | ||
|
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -15,8 +15,7 @@ import ( | |
) | ||
|
||
const ( | ||
teleporterByteCodeFile = "./out/TeleporterMessenger.sol/TeleporterMessenger.json" | ||
|
||
teleporterByteCodeFile = "./out/TeleporterMessenger.sol/TeleporterMessenger.json" | ||
warpGenesisTemplateFile = "./tests/utils/warp-genesis-template.json" | ||
|
||
teleporterMessengerLabel = "TeleporterMessenger" | ||
|
@@ -40,51 +39,61 @@ func TestE2E(t *testing.T) { | |
|
||
// Define the Teleporter before and after suite functions. | ||
var _ = ginkgo.BeforeSuite(func() { | ||
// Generate the Teleporter deployment values | ||
teleporterDeployerTransaction, teleporterDeployedBytecode, teleporterDeployerAddress, teleporterContractAddress, err := | ||
deploymentUtils.ConstructKeylessTransaction( | ||
teleporterByteCodeFile, | ||
false, | ||
deploymentUtils.GetDefaultContractCreationGasPrice(), | ||
) | ||
Expect(err).Should(BeNil()) | ||
|
||
// Create the local network instance | ||
LocalNetworkInstance = NewLocalNetwork( | ||
"teleporter-test-local-network", | ||
warpGenesisTemplateFile, | ||
[]SubnetSpec{ | ||
{ | ||
Name: "A", | ||
EVMChainID: 12345, | ||
NodeCount: 2, | ||
Name: "A", | ||
EVMChainID: 12345, | ||
TeleporterContractAddress: teleporterContractAddress, | ||
TeleporterDeployedBytecode: teleporterDeployedBytecode, | ||
TeleporterDeployerAddress: teleporterDeployerAddress, | ||
NodeCount: 2, | ||
}, | ||
{ | ||
Name: "B", | ||
EVMChainID: 54321, | ||
NodeCount: 2, | ||
Name: "B", | ||
EVMChainID: 54321, | ||
TeleporterContractAddress: teleporterContractAddress, | ||
TeleporterDeployedBytecode: teleporterDeployedBytecode, | ||
TeleporterDeployerAddress: teleporterDeployerAddress, | ||
NodeCount: 2, | ||
}, | ||
}, | ||
2, | ||
) | ||
log.Info("Started local network") | ||
|
||
// Generate the Teleporter deployment values | ||
teleporterDeployerTransaction, teleporterDeployerAddress, teleporterContractAddress, err := | ||
deploymentUtils.ConstructKeylessTransaction( | ||
teleporterByteCodeFile, | ||
false, | ||
deploymentUtils.GetDefaultContractCreationGasPrice(), | ||
) | ||
Expect(err).Should(BeNil()) | ||
|
||
// Only need to deploy Teleporter on the C-Chain since it is included in the genesis of the subnet chains. | ||
_, fundedKey := LocalNetworkInstance.GetFundedAccountInfo() | ||
LocalNetworkInstance.DeployTeleporterContracts( | ||
LocalNetworkInstance.DeployTeleporterContractToCChain( | ||
teleporterDeployerTransaction, | ||
teleporterDeployerAddress, | ||
teleporterContractAddress, | ||
fundedKey, | ||
true, | ||
) | ||
LocalNetworkInstance.SetTeleporterContractAddress(teleporterContractAddress) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Previously this was encapsulated in the call to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it was a little odd previously actually. There was a boolean parameter in one exported function for whether or not another exported function should be called from it. Since they are both exported, I think it's cleaner to make them independent and left up to the caller. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, I had forgotten about that switch. Agreed, makes sense to keep them separate. |
||
|
||
// Deploy the Teleporter registry contracts to all subnets and the C-Chain. | ||
LocalNetworkInstance.DeployTeleporterRegistryContracts(teleporterContractAddress, fundedKey) | ||
log.Info("Set up ginkgo before suite") | ||
|
||
ginkgo.AddReportEntry( | ||
"network directory with node logs & configs; useful in the case of failures", | ||
LocalNetworkInstance.tmpnet.Dir, | ||
ginkgo.ReportEntryVisibilityFailureOrVerbose, | ||
) | ||
|
||
log.Info("Set up ginkgo before suite") | ||
}) | ||
|
||
var _ = ginkgo.AfterSuite(func() { | ||
|
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.
It might be helpful in some debugging scenarios to provide an easy way to deploy Teleporter to all subnets via
eth_sendRawTransaction
versus genesis. Some ideas that come to mind:bool
paramdeployViaGenesis
toNewLocalNetwork
. Then the only changes required aretrue
->false
andDeployTeleporterContractToCChain
-> DeployTeleporterContractToAllSubnets`DeployTeleporterContractToAllSubnets
can be made idempotent so that it can be called in all scenarios.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.
What are the benefits of having those two different options for the E2E test execution that you were thinking of?
For local E2E tests, I think this covers both deployment flows sufficiently.
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 was just anticipating any issues arising from the different deployment methods. In such a scenario, being able to toggle between the two could be helpful. For instance, if a future change comes with state initialization in the same way as
ReentrancyGuards
, switching to Nick's method would help narrow down any differences.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 we can punt on this for now personally. Have the default E2E cover both possible deployment flows should hopefully ensure we keep them both up-to-date and compatible with any future changes.
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.
Sounds good. Any test failures along these lines would require root cause analysis anyway, something the suggested change would likely not help much with.