# 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,
},
}
```