skip indirect invocations for initial sync of integritee parentchain

[brenzi]

closes #1514, #1519

• postpone state provisioning to after registering self onchain (prerequisite for allow enclave updates: migrate state to updated mrenclave #85 and deprecating direct MU-RA)
  • enhance fetching peer for provisioning to use most active on own shard by shard_status now and avoid fetching from self
  • OCW: also provision entire state, not only light client
• fast-sync for Integritee parentchain: introduce concept of shard_creation_header, the integritee parentchain header of the first registered enclave for own shard:
  • do not fetch events & proofs from rpc &
  • ignore indirect invocations
  • ...for all blocks up to the one where the primary worker registered its enclave for the first time
  • doing the same for target_a/b needs more thinking, because headers don't include timestamps which are the only thing the parentchains have as a common reference (unless they are on the same relaychain)

[brenzi]

hmmm. the OCW M6 test fails during the second run. AliceIncognito Balance is wrong.
I guess that case isn't handled well yet

I think we need to pass the shard birth header along with the provisioning payload for the non-primary worker

still strange is this:
[2023-12-07T16:20:12Z ERROR itc_parentchain_indirect_calls_executor::executor] Error adding indirect trusted call to TOP pool: Error { code: ServerError(1001), message: "Trusted operation could not be deciphered", data: None }

[clangenb]

TBH, it is hard to grasp if we have been thinking about all things here, or if this is very brittle.

[clangenb]

I think we need to pass the shard birth header along with the provisioning payload for the non-primary worker

I think so, what does worker2 otherwise do? Fast sync until his own birth header? This would be wrong obviously.

still strange is this: [2023-12-07T16:20:12Z ERROR itc_parentchain_indirect_calls_executor::executor] Error adding indirect trusted call to TOP pool: Error { code: ServerError(1001), message: "Trusted operation could not be deciphered", data: None }

It could be that we provision the shielding key too late. If there is no shielding key provisioned, the worker2 might use one that it initialized itself, which results in the error.

[brenzi]

I think we need to pass the shard birth header along with the provisioning payload for the non-primary worker

I think so, what does worker2 otherwise do? Fast sync until his own birth header? This would be wrong obviously.

Alternatively, worker2 could sync the chain and scan for register enclave events from the primary worker. Or we introduce the "birth header" storage onchain for each shard.
That would be entirely trustless. However, sync would be slower in the former case and I think provisioning is deemed trustworthy in our scope anyway, so this may just be good enough

[brenzi]

It could be that we provision the shielding key too late. If there is no shielding key provisioned, the worker2 might use one that it initialized itself, which results in the error.

I did change the order of things, yes. will keep an eye on this

[brenzi]

hmm, my thinking was wrong. status quo is that the second OCW receives the light client state from the first one and therefore does not sync the blocks between birth header and the last synced block of the peer. (due to my reordering of provisioning?)

I decided to provision Everything in the case of OCW as well, which solves that issue. I think this is more convenient anyway and has the advantage that we may find a simpler way for forward secrecy by rotating shielding keys. This would be very complex (infeasible?) if every new OCW always needs to sync the entire history