# 3rd network discussion ## Substrate Node Rough points need change: 1. Admin? 2. OP logic? Q: 1. which user/scretkey in deployment/config is used by L1 monitors to communicate with SubstrateNode? ``` 卓:只使用了bsctestnet的"//Alice//stash",我想是因为无论是supply,retrive还是swap都涉及了bsctestnet和ropsten,不像在layer 1上的操作是独立的,所以不需要运行两个monitor 宗:根据monitor/src/substrate/index.ts文件的main(),程序默认使用EthConfig中第一个账号与substrate交信(即bsctestnet的Alice//stash)。经测试,改用第二个账号(ropsten的Alice)后我们的system仍能正常运作,这里account的选择应该是任意的。 ``` 2. How substrate node confirm it is from L1 monitor (is_admin)? ``` 卓:是通过is_admin,runtime里admins函数设置了两个admin accountId(这两个accountId怎么得到看下面回答),swap pallet用aux.rs里的is_admin函数去遍历只有accountId匹配才能继续进行deposit,deposit_nft等操作 宗:admins函数里的字符串为sudo Id,由monitor通过EthConfig中的l2Account字符串加密而来(即“//Alice”与“//Alice//stash”),加密涉及sr25519,ss58与hex_literal。substrate/runtime会将请求的origin(l2 account name)与admins函数里的字符串进行匹配。 EthConfig的l2Account参数,我觉得可以理解为:和L2通信时使用的name public async getSudo() { if (!this.sudo) { await cryptoWaitReady(); const keyring = new Keyring({ type: "sr25519" }); this.sudo = keyring.addFromUri(this.account); console.log("sudo is " + this.sudo.address); console.log("sudo Id is " + ss58.addressToAddressId(this.sudo.address)); } return this.sudo; } The "this.account" is the "//Alice//stash" string. ss58.addressToAddressId(this.sudo.address) is "be5ddb1579b72e84524fc29e78609e3caf42e85aa118ebfe0b0ad404b5bdd25f", which is one of the hard code hex in substrateNode runtime/lib.rs: fn admins() -> Vec<AccountId> { vec![ AccountId::from(hex_literal::hex!["d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d"]), AccountId::from(hex_literal::hex!["be5ddb1579b72e84524fc29e78609e3caf42e85aa118ebfe0b0ad404b5bdd25f"]) ] } ``` 3. For the 3rd new L1 monitor, which codes need change to accept the 3rd L1 monitor user as admin? ``` 卓:runtime/src/lib.rs里,admins函数加一个accountId,可以通过sudo得到,runtime里的就是sudoId(直接在monitor/src/substrate/client.js里init函数加console.log(sudo),node运行就好了),depolyment的ethconfig新的config对象l2Account要和之前的不一样(见下方question 3的回答) 宗:我的理解是,admin就是monitor身份,用来确保L2链收到的指令一定发自monitor而不是其它origin。 因为L1链与L2链彼此间会直接通信,为了记录,L1链与monitor建议使用不同的l2name。经测试,monitor使用与L1链不同的name,与L2进行通信是OK的 如果加入第三条链,新的L1链也应该有独特的与L2通信时使用的name,记录在substrate runtime里。 至于L1链为什么要直接与L2链通信,而不是通过monitor,我还没有完全厘清。建议整理并记录每一种Op的发信链,方便以后查阅与修改。 ``` ## Monitor Rough points need change: 1. Admin accounts? 2. monitor structure? Q: 1. L1 monitors are using which config as its user to communicate with L1 network? ``` 卓:For ropsten monitor,it uses deviceId, rpcSource, monitorAccount, mongodbUrl(deployment/config/eth-config.js) ``` 2. L1 monitors are using which config as its user to communicate with L1 network? ``` 卓:For bsctestnet monitor,it uses deviceId, rpcSource, monitorAccount, mongodbUrl(deployment/config/eth-config.js) ``` 3. L2 monitors are using which config as its user to communicate with L2 (substrateNode)? Or no user? ``` 卓:Use l2Account,用来产生privateKey,拿来签名/获取nonce,如果l2account相同,就无法获取正确的nonce,所以不一样 ``` 4. We need start the 3rd L1 monitor for 3rd network. ``` 卓:添加一个ethconfig,添加新的deviceId, rpcsource,继续使用原来的monitorAccount和mongodbUrl; L2account生成的sudoId就是传给substrate-node被is_admin检查的accountId,substrate-node/runtime/src/lib.rs里写死的accountId我想是通过和上方类似办法console.log得到的); getChargeAddress获取这条链上的rio地址; monitorAccount调用合约代码的地址(就是本地geth客户端的账户地址,目前写死了); deviceId指哪条链; rpcsource是web3连接node的https地址; mongodb获取数据库里l1合约的event log和参数等数据 ``` ## Solidity Rough points need change: 宗:config-contracts-info? Yes, need add the 3rd network's data. And also need deploy 1_utils_migration.js and 3_token_migration.js one time for the new network. Need add new testnet config in truffle-config.js ## deployment Rough points need change: 1. Deploy contracts on the 3rd network. * For the first deployment, need truffle migrate 1 and 3 too, not only 2 2. Add new config for the new 3rd L1 monitor. 3. Deployment steps change for the new 3rd L1 monitor. 1.lerna/init_bridge.sh: ``` npx truffle migrate --f 2 --to 2 --network chainName node init.js chainName ``` 2.deployment/config/eth-config.ts: add new config into Ethconfig ``` { chainName: "", mongodbUrl: "mongodb://localhost:27017", rpcSource: "", wsSource: "", privateKey: secrets.accounts.deployer.priv, monitorAccount: "0x6f6ef6dfe681b6593ddf27da3bfde22083aef88b", deviceId: "", l2Account: "//Alice//stash", enabled: testnet, isSnap: false, }, } ```