About blockchain networks, Arpa BLS-TSS-Network supports one main chain and multiple relayed chains. After preparing for deploying contracts and updating node-client on Base(see #58), the steps to support a new Ethereum L2 can be described as follows:
- (Contract)Add
XXChainMessenger to handle L1->L2 group relay, then register it to ControllerRelayer on L1.
- (Contract)Update
ChainHelper to offer chain specified parameters, like block time and L1 fees.
- (Node)Add
xx_randomness_task and xx_randomness_result table.
- (Node)Impl
BLSTasksHandler<RandomnessTask> for XXBLSTasksDBClient<RandomnessTask> and impl SignatureResultCacheHandler<RandomnessResultCache> for XXSignatureResultDBClient<RandomnessResultCache>.
- (Node)Update factory method in crates/dal/sqlite/src/lib.rs for building
randomness_tasks_cache and randomness_result_cache.
- (Token bridge whitelist) Deploy a counterpart ARPA token, and submit it to the official whitelist of ERC-20 token bridge.
- Finally deploy contracts by python script, fund nodes on the new L2, and re-deploy node containers using auto published node-client docker package.
There are still some TODOs we need to work on. In my view automation consists of:
-
Package publish, of node-client and node-shell for node operators, and user-shell for stakers or Randcast users, which have already been set to publish after any push on main or when manually triggered.
-
Devnet test as well as CI/CD test framework, which is a bit tricky. When there are more than one L2, we are short of a way to form a relay mechanism between a simultaneous 1-to-n chain relationship. However we can learn from op devnet, then modify it to add more l2 component(ops-bedrock-l2-xx, ops-bedrock-xx-node, ops-bedrock-xx-batcher and ops-bedrock-xx-proposer). Two L2s should be enough representative. To save time, I also suggest we directly use testnet. Thanks to @Andlyn666 we have found a lot of and will discover more details, to make the system robuster in a more cost effective manner.
-
More consecutive L2 support. Basically we deploy some contarcts and login servers, modify config to add the chain and re-run nodes. The script we have is pretty useful. For contracts part I made some workaround to deploy according to env config. Further @wrinkledeth We can discuss about improving the variable name, the way to implement, making it more general to deploy contracts on different chains. Besides, if we can support running any number of nodes through script, it helps to test the gas cases under the upmost condition, but still, it is not of high priority. And about verification, it is kind of inconvenient. I tried to verify contracts we deployed on goerli like two months ago, but failed to find correct contract version, getting confused with things it should be like that and the actual transaction history from explorer and notes we had. So, it will make life much easier if we can verify contracts automatically after deployment. For nodes, since the most difficult part is to think and add diverse items to the config file of nodes, I think the existing way to trigger is alright.
-
(Single)Node deployment from day 1, for the permissionless manner in the future. We need to figure out recommended log monitor and alerting mechanism to get informed and find out what is going on when errors happen, and be careful about version discovery and compatible issues, like checking and restriction methods.
-
Upgrade on deployed contracts. These are relatively unusual and once we have to do that, it is more important to think over the rationale, and to conduct plenty of experiments to simulate consequences.
This is all I can think of so far. Comments and suggestions are welcome!
About blockchain networks, Arpa BLS-TSS-Network supports one main chain and multiple relayed chains. After preparing for deploying contracts and updating node-client on Base(see #58), the steps to support a new Ethereum L2 can be described as follows:
XXChainMessengerto handle L1->L2 group relay, then register it toControllerRelayeron L1.ChainHelperto offer chain specified parameters, like block time and L1 fees.xx_randomness_taskandxx_randomness_resulttable.BLSTasksHandler<RandomnessTask>forXXBLSTasksDBClient<RandomnessTask>and implSignatureResultCacheHandler<RandomnessResultCache>forXXSignatureResultDBClient<RandomnessResultCache>.randomness_tasks_cacheandrandomness_result_cache.There are still some TODOs we need to work on. In my view automation consists of:
Package publish, of node-client and node-shell for node operators, and user-shell for stakers or Randcast users, which have already been set to publish after any push on main or when manually triggered.
Devnet test as well as CI/CD test framework, which is a bit tricky. When there are more than one L2, we are short of a way to form a relay mechanism between a simultaneous 1-to-n chain relationship. However we can learn from op devnet, then modify it to add more l2 component(ops-bedrock-l2-xx, ops-bedrock-xx-node, ops-bedrock-xx-batcher and ops-bedrock-xx-proposer). Two L2s should be enough representative. To save time, I also suggest we directly use testnet. Thanks to @Andlyn666 we have found a lot of and will discover more details, to make the system robuster in a more cost effective manner.
More consecutive L2 support. Basically we deploy some contarcts and login servers, modify config to add the chain and re-run nodes. The script we have is pretty useful. For contracts part I made some workaround to deploy according to env config. Further @wrinkledeth We can discuss about improving the variable name, the way to implement, making it more general to deploy contracts on different chains. Besides, if we can support running any number of nodes through script, it helps to test the gas cases under the upmost condition, but still, it is not of high priority. And about verification, it is kind of inconvenient. I tried to verify contracts we deployed on goerli like two months ago, but failed to find correct contract version, getting confused with things it should be like that and the actual transaction history from explorer and notes we had. So, it will make life much easier if we can verify contracts automatically after deployment. For nodes, since the most difficult part is to think and add diverse items to the config file of nodes, I think the existing way to trigger is alright.
(Single)Node deployment from day 1, for the permissionless manner in the future. We need to figure out recommended log monitor and alerting mechanism to get informed and find out what is going on when errors happen, and be careful about version discovery and compatible issues, like checking and restriction methods.
Upgrade on deployed contracts. These are relatively unusual and once we have to do that, it is more important to think over the rationale, and to conduct plenty of experiments to simulate consequences.
This is all I can think of so far. Comments and suggestions are welcome!