|
1 | 1 | # Test/Demo network configuration
|
2 | 2 |
|
3 | 3 | The overall workflow works as follows:
|
4 |
| -- each individual node run `mkconfig` to generate a local config files, containing private keys, public keys, network addresses, chain configs, and nitro config. See [`node_0.toml`](./c0/node_0.toml) for an example. This `mkconfig` will additionally append (without duplication) to a [`committee.toml`](./c0/committee.toml) config file which is meant for the key manager role. |
5 |
| - - `committee.toml` simulates the (unspecified) offchain process of OCL DAO process eventually produced. |
6 |
| -- one run `just test-chain-deploy --keep-anvil` which internally invoked two binaries: [`deploy`](../timeboost-contract/src/binaries/deploy.rs) to deploy contracts to parent chain, and [`register`](../timeboost-contract/src/binaries/register.rs) to take a `committee.toml` file and invoke `setNextCommittee()` on the [`KeyManager` contract](../contracts/src/KeyManager.sol). |
7 |
| - - this process is part of `./scripts/run_demo_[sailfish|timeboost]`. |
8 |
| - - for test blockchain, the deployed `KeyManager` contract is deterministic thus we included it ahead of time as part of `chain_config` in `node_i.toml` node config in the first step. |
9 |
| -- a timeboost/sailfish node starts with a `--config node_i.toml` flag. On startup, it will fetch other peers' network address (the primary `sailfish_address`, all other are derived) and public keys from the contract since `.chain_config` did specify the deployed `KeyManager.sol` contract address. After getting all these info, timeboost node can construct struct like `Committee`, `Network` etc locally, and spawn off as usual. |
10 | 4 |
|
| 5 | +- Each individual node runs `mkconfig` to generate local config files, containing private keys, |
| 6 | + public keys, network addresses, chain configs, and nitro config. |
| 7 | + See [`node_0.toml`](./c0/node_0.toml) for an example. `mkconfig` will additionally append (without |
| 8 | + duplication) to a [`committee.toml`](./c0/committee.toml) config file which is meant for the key |
| 9 | + manager role. |
| 10 | +- `committee.toml` simulates the (unspecified) offchain process of OCL DAO process eventually |
| 11 | + produced. |
| 12 | +- Run `just test-chain-deploy --keep-anvil`, which internally invokes two binaries: |
| 13 | + [`deploy`](../timeboost-contract/src/binaries/deploy.rs) to deploy contracts to parent chain, and |
| 14 | + [`register`](../timeboost-contract/src/binaries/register.rs) to take a `committee.toml` file and |
| 15 | + invokes `setNextCommittee()` on the [`KeyManager` contract](../contracts/src/KeyManager.sol). |
| 16 | + - This process is part of `./scripts/run_demo_[sailfish|timeboost]`. |
| 17 | + - For a test blockchain, the deployed `KeyManager` contract is deterministic thus we included it |
| 18 | + ahead of time as part of `chain_config` in `node_i.toml` node config in the first step. |
| 19 | +- A timeboost/sailfish node starts with a `--config node_i.toml` flag. On startup, it will fetch |
| 20 | + other peers' network addresses (the primary `sailfish_address`, all other are derived) and public |
| 21 | + keys from the contract since `.chain_config` did specify the deployed `KeyManager.sol` contract |
| 22 | + address. After getting all these info, a timeboost node can construct structs like `Committee`, |
| 23 | + `Network` etc. locally, and start as usual. |
11 | 24 |
|
12 | 25 | To generate configs for all nodes in a new committee:
|
13 | 26 |
|
14 | 27 | ``` sh
|
15 | 28 | # see mkconfig.rs Args or `mkconfig --help` for more options
|
16 |
| -just mkconfig 5 --seed 42 |
17 |
| -just mkconfig 13 --nitro-addr "localhost:55000" |
| 29 | +just mkconfig 5 2025-01-09T02:00:00Z --seed 42 |
| 30 | +just mkconfig 13 2025-01-09T02:00:00Z --nitro-addr "localhost:55000" |
18 | 31 |
|
19 | 32 | # recipe for docker env is fixed at 5 nodes
|
20 |
| -just mkconfig_docker --seed 42 |
| 33 | +just mkconfig_docker 2025-01-09T02:00:00Z --seed 42 |
21 | 34 |
|
22 | 35 | # recipe for nitro CI test, fixed at 2 nodes with nitro chain config
|
23 |
| -just mkconfig_nitro --seed 42 |
| 36 | +just mkconfig_nitro 2025-01-09T02:00:00Z --seed 42 |
24 | 37 | ```
|
25 | 38 |
|
26 |
| -### On test wallet mnemonic |
| 39 | +### On test wallet mnemonic |
27 | 40 |
|
28 |
| -The official test wallet is using `test ... test junk` as its mnemonic and most testnet will pre-fund accounts under this wallet. But the nonce of these wallet, especially the public testnets, is unpredictable making the deployed contract address unpredictable. |
29 |
| -Even though in test environments, we spawn off test blockchain from a fresh state, thus deployed KeyManager contract will always live in `0xe7f1725e7734ce288f8367e1bb143e90bb3f0512`, when we integrate with live Arbitrum testnet, this won't be the case. |
30 |
| -To avoid future confusion, we choose a newly generated mnemonic phrase `"attend year erase basket blind adapt stove broccoli isolate unveil acquire category"`, not preoccupied w.h.p. and our deployed contract address should be the same across testnet (local or live). The only additional work is to fund this wallet using the default faucet which is step in [`test-contract-deploy` script](../../scripts/test-contract-deploy). |
31 |
| -Now you can see in `--key-manager-addr "0x2bbf15bc655c4cc157b769cfcb1ea9924b9e1a35"` in `justfile`, which can verified by running `just test-contract-deploy`. |
| 41 | +The official test wallet is using `test ... test junk` as its mnemonic and most testnet will |
| 42 | +pre-fund accounts under this wallet. But the nonce of these wallet, especially the public testnets, |
| 43 | +is unpredictable making the deployed contract address unpredictable. |
| 44 | + |
| 45 | +Even though in test environments, we spawn off test blockchain from a fresh state, thus deployed |
| 46 | +KeyManager contract will always live in `0xe7f1725e7734ce288f8367e1bb143e90bb3f0512`, when we |
| 47 | +integrate with live Arbitrum testnet, this won't be the case. |
| 48 | + |
| 49 | +To avoid future confusion, we choose a newly generated mnemonic phrase |
| 50 | +`"attend year erase basket blind adapt stove broccoli isolate unveil acquire category"`, not |
| 51 | +preoccupied w.h.p. and our deployed contract address should be the same across testnet (local or |
| 52 | +live). The only additional work is to fund this wallet using the default faucet which is step in |
| 53 | +[`test-contract-deploy` script](../../scripts/test-contract-deploy). |
| 54 | + |
| 55 | +Now you can see in `--key-manager-addr "0x2bbf15bc655c4cc157b769cfcb1ea9924b9e1a35"` in `justfile`, |
| 56 | +which can verified by running `just test-contract-deploy`. |
32 | 57 |
|
33 | 58 | ```
|
34 | 59 | $ cast wallet new-mnemonic
|
|
0 commit comments