Clarify Block & Call Confirmation

[haerdib]

Currently, we have the following use cases:

• Unshielding: Every executed unshielding extrinsic triggers a CALL_CONFIRMED
• Indirect block confirmation Every iterated parent chain block trigges a BLOCK_CONFIRMED
• Direct block confirmation Every produced sidechain block triggers a BLOCK_CONFIRMED

@brenzi: Are all these use cases still valid as such?

I have to admit, having indirect & direct block confirmation combined in one extrinsic created a heavy misunderstanding in my head, even though I have implemented it myself. Is there an advantage of combining these?

Snippets from Team conversation long time ago ( I have not found out how to actually show the whole conversation from this time.. but if relevant I could dig that up)

01.03.2021: Decision to use block confirmation instead of call confirmation:

brenzi: block_confirmations: ja, genau wie bisher, nur einmal pro block. (wir könnten uns ggf. ein "rollup" überlegen, wobei jeder tx hash des blocks angefügt wird, aber aktuell möchte ich das nicht

30.03.2021: Decision how to substitute direct block confirmation with indirect block confirmation:

haerdib: Für die indirect block confirmation verwende ich jetzt folgende substitutionen:
shard -> genesis hash
block hash -> layer 1 block header hash
state hash -> parent hash layer 1 block

[clangenb]

Yes, I agree. It was quite obfuscated. The minimum we should do, is to distinguish between a ParentchainBlockConfirmed and a SidechainBlockConfirmed to prevent further confusion. These should also be implemented as two separate pallet-calls

Additionally, this provides more flexibility to adjust them independently in the future.

[haerdib]

I wholeheartedly agree. The thing I'm unsure about it the use case of the Call confirmation. Currently only unshielding call execution triggers this confirmation. Do we need both - CallConfirmed & ParentchainBlockConfirmed ?

[brenzi]

if we can provide requesters with a merkle proof, we don't need CallConfirmed anymore

furthermore I suggest to distinguish

ParentchainBlockProcessed

and

SidechainBlockProposed

its not yet a confirmation in the latter case. We may still need to solve forks

[haerdib]

What parameters should these calls include?
SidechainBlockProposed : Just like the old block confirmation:

• shard
• sidechain block hash
• updated state hash

ParentchainBlockProcessed:

• block hash of processed parent chain block.. what else?

[clangenb]

I think it could look like this:

• ParentchainBlockProcessed. Contains:
  • parentchain_block_hash,
  • processed_trusted_calls_merkle_root
  • no post_mutation_state_hash. It does not contain useful information, and several shards could have been mutated anyhow.
• SidechainBlockProposed:
  • shard_id
  • sidechain_block_hash
  • I don't think we need the post_mutation_state_hash? The sidechain_block_hash contains the full information already.

[haerdib]

I don't think we need the post_mutation_state_hash? The sidechain_block_hash contains the full information already.

I can't think of any use case of this as well right now.

[haerdib]

Up 'till now the state hash has been used as IPFS hash: https://github.com/integritee-network/pallets/blob/c5fc10f0cf5f767b0ee716b5f928793687fd9648/teerex/src/lib.rs#L203

So I guess that was the use case. Is that still an arugment to keep it?

[clangenb]

Hmm, possibly. Although, I think that using IPFS has disadvantages. We can't update the state in IPFS incrementally because it is encrypted. Furthermore, I don't see the benefit of fetching the state from IPFS compared to fetching it (incrementally) from a worker directly. @brenzi ?

[brenzi]

true. ipfs was meant to simplify the onboarding of new workers and ensure this can happen unpermissioned. But actually I fail to see a reason to keep it now