Deploy Scripts & Refactorings #56
Conversation
wottpal
changed the title
wottpal
force-pushed
the
feat/deploy-script
branch
2 times, most recently
from
9b2f135
to
4809778
Compare
| const isInBlock = result?.status?.isInBlock | ||
| if (!isInBlock) return |
There was a problem hiding this comment.
I think there is also a stat isFinalized. Should it be preferred over of isInBlock? as being included in the block doesn't guarantee that it will end up in the canonical chain.
There was a problem hiding this comment.
I'm aware of that, but in my experience (I don't know why) substrate-contracts-node is never returning the finalized state, so for local development the UI/scripts would hang indefinitely. Example:
➜ contracts git:(feat/deploy-script) ✗ CHAIN=alephzero-testnet pnpm ts-node scripts/merkle_whitelist.ts
Initialized API on Aleph Zero Testnet (0.9.1-3074280b4ca)
Initialized Accounts: 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
Merkle root: 0xdf102b13c62da2b7b39fdfc3d02bdbf045a86162f2a96a9545e2563b139b0537
Contract 'azns_name_checker' deployed at 5F21CGaUXAUSBcXvLgCr7keh8xzZ1q2dnDdC79QC314gBgvS
Contract 'azns_fee_calculator' deployed at 5GL6DEqSp5BkASPCNX3GiMAqxwUoKYWWngcVETU1H17HdUYT
Contract 'merkle_verifier' deployed at 5DXvCLDLxgmcesnQdxdZGgARS4eYDxaEwc4D317DfPNmyowp
Contract 'azns_registry' deployed at 5H9HRJFquTDTtzW71uTYaS5zXfYqT5SnSKQFPswNG5cEuvvo
Off-chain verification: true
On-chain verification: true
Ready
Broadcast
InBlock
Finalized
Registered domain 'alice.azero' successfully
➜ contracts git:(feat/deploy-script) ✗ pnpm ts-node scripts/merkle_whitelist.ts
Initialized API on Development (0.24.0-fbc28a7ad4b)
Initialized Accounts: 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
Merkle root: 0xdf102b13c62da2b7b39fdfc3d02bdbf045a86162f2a96a9545e2563b139b0537
Contract 'azns_name_checker' deployed at 5GeCN6UFQdtAwKbdXL9ZdPoyXUCzqCFAPLztxshtH1fviX7H
Contract 'azns_fee_calculator' deployed at 5CQt44DaKjpM8PJisobeHajks7bpcn4FXRpNbFBKLSNpxz9v
Contract 'merkle_verifier' deployed at 5HZ7EFudYckLFZsRn3Zv1UNmxzYuGZ5EZB8EuH7gC5dBQD1j
Contract 'azns_registry' deployed at 5DaCvqL6KAXF1NNLHZsVPk1bQm5a4sKPZcH1d6Zb7pVZ9MwL
Off-chain verification: true
On-chain verification: true
Ready
InBlock
There was a problem hiding this comment.
Is your local node producing finalized blocks?
There was a problem hiding this comment.
I did a little research, as substrate-contracts-node somehow has "instant finality" in the same block, it does not seem to be recognized as a finalized block by polkadot.js/api… At least that's my theory.
The consensus algorithm has been switched to manual-seal in paritytech/substrate-contracts-node#42. Hereby blocks are authored immediately at every transaction, so there is none of the typical six seconds block time associated with grandpa or aura.
As we'll face this situation everywhere in the frontend in the upcoming weeks, I would like to find a solution. But I don't really have an idea, I def. don't want to build two different frontend behaviors (one for local nodes, one for live nodes). This will cause even more problems IMO. Having something like this implemented paritytech/substrate-contracts-node#160 could solve the issue though. I'll comment there and tend to leave it with isInBlock for now.
scripts/merkle_whitelist.ts
Outdated
| const tree = await constructMerkleTree(account) | ||
| const root_encoded = bufferToU8a(tree.getRoot()) | ||
|
|
||
| // 2. Deploy all contracts |
There was a problem hiding this comment.
We should probably not deploy all contracts here. It'll become difficult to maintain. In the first iteration, We deployed the azns_registry to test the integration b/w the two contracts.
We should either modularize each contract deployment for integration test or just do functional test here.
What are your thoughts?
There was a problem hiding this comment.
Yeah I was also somehow unhappy with both merkle-scripts but only wanted to "keep them alive" with the current changes. I now did a few things in 8a29819 & c285c8d:
- Refactored some merkle/verification/whitelist helpers into
scripts/whitelist - Added actual whitelist loading from file and made it part of the main deployment script (can be invoked via
WHITELIST=../whitelist/whitelist.txt pr deploy) - Only kept & rewritten one top-level
testMerkleVerifier.tsthat instantiates only a single merkle-verifier contract and does some super simple test-case verification. It also re-uses the deployment function fromdeploy/deployMerkleVerifier.ts.
Lmk what you think.
wottpal
force-pushed
the
feat/deploy-script
branch
2 times, most recently
from
c285c8d
to
dac6095
Compare
wottpal
force-pushed
the
feat/deploy-script
branch
from
dac6095
to
f4fb3c5
Compare
No description provided.