-
Notifications
You must be signed in to change notification settings - Fork 4
Add interface for CrosschainDeployAdapter #5
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
Changes from all commits
307845a
716c3de
6b217ae
8e33f39
fd7434c
4c2d7a6
bd519d5
3636d7a
40f2c07
88bc0b1
ea929d5
70206c9
fe7a0da
06773c5
367fbb9
be4c339
60dedd4
444eba6
8b12528
456569e
fd883f4
f219167
7df5ba6
b4685f3
25a70c2
4c62035
1919e87
3ce7924
b6998f8
b4b6ca5
f82c1e5
b124e3c
e57869d
ed494e0
b926e2c
05912cd
5105657
63bbcb4
45ccc31
59eafcf
749ef6a
73fdcda
2581da3
e2ef7f5
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 |
|---|---|---|
| @@ -0,0 +1,3 @@ | ||
| # copy this to a `.env` file and set these values. | ||
| INTEGRATION_FORK_URL= | ||
| INTEGRATION_PRIVATE_KEY= |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,34 @@ | ||
| name: test | ||
|
|
||
| on: workflow_dispatch | ||
|
|
||
| env: | ||
| FOUNDRY_PROFILE: ci | ||
|
|
||
| jobs: | ||
| check: | ||
| strategy: | ||
| fail-fast: true | ||
|
|
||
| name: Foundry project | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@v4 | ||
| with: | ||
| submodules: recursive | ||
|
|
||
| - name: Install Foundry | ||
| uses: foundry-rs/foundry-toolchain@v1 | ||
| with: | ||
| version: nightly | ||
|
|
||
| - name: Run Forge build | ||
| run: | | ||
| forge --version | ||
| forge build --sizes | ||
| id: build | ||
|
|
||
| - name: Run Forge tests | ||
| run: | | ||
| forge test -vvv | ||
| id: test |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,3 @@ | ||
| [submodule "lib/forge-std"] | ||
| path = lib/forge-std | ||
| url = https://github.com/foundry-rs/forge-std |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1 +1,83 @@ | ||
| # foundry-multichain-deploy | ||
| # foundry-multichain-deploy | ||
|
|
||
| > **Warning** | ||
| > | ||
| > Only testnet multichain deployment is available. Mainnet deployment will be enabled soon! | ||
|
|
||
| Provides `foundry` tooling for the multichain deployment contract built atop Sygma. See | ||
| [ChainSafe/hardhat-plugin-multichain-deploy]("https://github.com/ChainSafe/hardhat-plugin-multichain-deploy") | ||
| for the Hardhat plugin version. | ||
|
|
||
| ## Installation | ||
|
|
||
| Run `forge install chainsafe/foundry-multichain-deploy` to install this plugin to your own foundry project. You might need to use `--no-commit` so as to properly configure your git working directory and commit the dependency yourself. For further instructions, check [the official documentation.](https://book.getfoundry.sh/projects/dependencies) | ||
|
|
||
| ## Usage | ||
|
|
||
| The `CrosschainDeployScript` contract is a foundry "script", which means that it | ||
| is not really deployed onto the blockchain. It provides a few helper methods | ||
| that make it easier to deal with the `CrosschainDeployAdapter` from the hardhat | ||
| repository. | ||
|
|
||
| To use it, first import the `CrosschainDeployScript` and inherit from it. | ||
|
|
||
| ```solidity | ||
| // SPDX-License-Identifier: LGPL-3.0-only | ||
| pragma solidity 0.8.20 | ||
| import {CrosschainDeployScript} from "foundry-multichain-deploy/src/CrosschainDeployScript.sol"; | ||
|
|
||
| contract SampleDeployScript is CrosschainDeployScript { | ||
|
|
||
| function run { | ||
| // Remember that forge "builds" the contracts and stores them and their | ||
| // ABI in the root level of the `out` folder so you'd just need to use the contract | ||
| // file name and the contract name and forge gets it from the ABI. | ||
| bytes memory constructorArgs = abi.encode(uint256("10")); | ||
| bytes memory initData = abi.encode("add(uint256)", uint256(10)); | ||
| addDeploymentTarget("sepolia", constructorArgs, initData); | ||
| addDeploymentTarget("holesky", constructorArgs, initData); | ||
| deploy{value: msg.value}("SimpleContract.sol:SimpleContract", 50000, false); | ||
|
Contributor
Author
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 thought about this but would it make sense to setup the constructorargs and initdatas before the contract itself? Because these are tied to the contract so it doesn't make sense that the contract name is something users have to supply in the (Sorry, was on the flight and saw these commits, wanted to understand more)
Member
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. Honestly, contructor thing was wierd. You could have script that deploy more than one contract multichain, this ensures that you can do that
Contributor
Author
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. But it's still weird, isn't it? You add deployment targets against a particular contract, but it would make sense to "fix" the contract before queuing up the arguments to its later functions. Now if someone messes up the contract name, it's a waste. How about we give a step saying
Member
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. But you can now do: contract SampleScript is CrosschainDeployScript {
run() {
addDeploymentTarget("sepolia", constructorArgs, initData);
addDeploymentTarget("holesky", constructorArgs, initData);
deploy("SampleContract:Contract1")
addDeploymentTarget("sepolia", constructorArgs2, initData2);
addDeploymentTarget("holesky", constructorArgs2, initData2);
deploy("SampleContract:SomeOtherContract")
}
}why would this be weird? |
||
| } | ||
| } | ||
| ``` | ||
|
|
||
| Now, you can run this with `forge script script/SampleDeployScript.sol:SampleDeployScript --rpc-url $CHAIN_RPC_URL --broadcast -vvv --verify`. | ||
|
|
||
| This script is not deployed, but it instead constructs the calls to the upstream | ||
| contract and broadcasts them (thanks to the `--broadcast` flag). | ||
|
|
||
| A good example of how to use this project is demonstrated in the | ||
| [`test/unit/CrosschainDeployScript.t.sol`](test/unit/CrosschainDeployScriptTest.t.sol) | ||
| file. | ||
|
|
||
| ### Encoding Arguments | ||
|
|
||
| The `constructorArgs` and `initData` arguments use the encoded format for the | ||
| values that get passed to the adapter for deployment. Notice how in the example | ||
| above, these are encoded using `encode` and `encodePacked`. | ||
|
|
||
| The `SimpleContract` example has a constructor that takes a `uint256` value. So | ||
| it requires a value to be passed as `constructorArgs`. We use `bytes memory | ||
| constructorArgs = abi.encode(uint256(10));` to do so. | ||
|
|
||
| If a contract constructor doesn't have any input arguments, you can just use | ||
| `bytes memory constructorArgs = '';` for that particular constructor. | ||
|
|
||
| Now, the `add` function of the `SimpleContract` takes a `uint256` argument as | ||
| well, but to pass this to `initDatas`, you need to pass the function signature | ||
| as well. So you'd have to use `bytes memory initData = | ||
| abi.encodeWithSignature("add(uint256)", uint256(10));`. If you're calling a | ||
| function like `inc()` which takes no arguments, just say `bytes memory initData | ||
| = abi.encodeWithSignature("inc()");` instead. | ||
|
|
||
| To learn more, check out the ways you can use `abi.encode` and | ||
| `abi.encodeWithSignature` in the foundry book. | ||
|
|
||
|
|
||
| ## Development | ||
|
|
||
| [Install foundry](https://book.getfoundry.sh/getting-started/installation) and [`just`](https://github.com/casey/just). | ||
|
|
||
| Check the `justfile` for more instructions on how to run this project. Run `just --list` to see all the options. | ||
|
|
||
| Note that all integration tests *should* have `Integration` in the test function name for them to work, unless you'd like to use `--match-test` specifically for those tests. However, to keep things simple, it's best to follow this practice. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,6 @@ | ||
| [profile.default] | ||
| src = "src" | ||
| out = "out" | ||
| libs = ["lib"] | ||
|
|
||
| # See more config options https://github.com/foundry-rs/foundry/blob/master/crates/config/README.md#all-options |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,40 @@ | ||
| set shell:=["bash", "-uc"] | ||
| set dotenv-load | ||
|
|
||
| # build the contracts | ||
| build: | ||
| forge build | ||
|
|
||
| # format source | ||
| fmt: | ||
| forge fmt | ||
|
|
||
| # run unit tests | ||
| test: | ||
| forge test --no-match-test Integration | ||
|
|
||
| # run integration tests, needs --fork-url | ||
| integration-test: | ||
| set -x | ||
| forge test --mt Integration --fork-url $INTEGRATION_FORK_URL -vvv | ||
|
|
||
| # watches the directory for changes and rebuilds. | ||
| watch-build: | ||
| forge build --watch | ||
|
|
||
| deploy-anvil: build | ||
| echo "Unimplemented" >&2 | ||
| exit 1 | ||
|
|
||
| deploy-sepolia: build | ||
| echo "Unimplemented" >&2 | ||
| exit 1 | ||
|
|
||
| # Builds locally using docker (useful for debugging dependency issues) | ||
| docker-build: | ||
| echo "Unimplemented" >&2 | ||
| exit 1 | ||
|
|
||
| docker-test: docker-build | ||
| echo "Unimplemented" >&2 | ||
| exit 1 |
Uh oh!
There was an error while loading. Please reload this page.