Improve Stellar tier 1 structure updates

[TorstenStueber]

Currently we assume that we will use governance whenever the structure of the Stellar tier 1 validator set changes. For that reason Spacewalk will provide an extrinsic function where maintainers will be able to update the tier 1 set and that needs to be called whenever the community of Stellar tier 1 validators collectively decide to update their quorum slices.

Today it turned out that this situation can be more complicated and that SDF will for example add new validators to their quorum slice definition as a test run and other tier 1 validators will only change their definition accordingly once the test run was successful.

Hence, we need to have more flexibility when managing the tier 1 validator set. First for some transitional period not all tier 1 validators might use exactly the same quorum slices. We would need to store quorum slices per tier 1 validator. Second validators might change their quorum slice definition suddenly without announcing the proper point in time or block depth before.

I assume that Stellar validators also gossip any changes in their quorum slices through the network so that other nodes can validate whether a quorum has been reached when voting. These messages would also be signed so that hackers cannot spoof them. We would need to read it and auto update the Stellar oracle.

[vadaynujra]

Hey team! Please add your planning poker estimate with Zenhub @ebma @b-yap @ashneverdawn @TorstenStueber

[prayagd]

Year old ticket, moving it to icebox

[TorstenStueber]

I implemented a more appropriate algorithm in https://github.com/pendulum-chain/scp-messages

[ebma]

@TorstenStueber would you consider this ticket to be the one where we change the overall consensus derivation algorithm of the Stellar oracle pallet? Because it is not 100% clear to me from reading the title and description.

If so, then we need to describe in more detail how we can verify the inclusion of a Stellar transaction in the Stellar oracle and what the supplied parameters need to look like. Might make sense to write this down in a Notion page first. We could use something similar to the algorithm in https://github.com/pendulum-chain/scp-messages but this would further increase the (already very large) size of the data we need to pass to the extrinsic as we'd additionally need to supply some SCP messages about quorum sets.

[TorstenStueber]

This ticket is definitely not ready yet and you are right that it is not well specified.

It makes sense to do both at the same time: change the consensus mechanism to use the algorithm in https://github.com/pendulum-chain/scp-messages and also allow to automatically extract changing quorum sets this way.

However, there is still one element that is not sufficiently specified yet: if we allow every node to self report their quorum sets and we take this for granted, how do we protect ourselves against a single malicious node that just reports that they have just one quorum set that only consists of itself – in that case we would immediately consider this node to have consensus.

Instead even with the self reporting quorum sets we still need some checking mechanism that requires that certain well known nodes are part of the quorum, I would say it should be at least one SatoshiPay or one Stellar node. However, consensus could also exist without any SatoshiPay or Stellar nodes being involved, so this might be too strict.

This requires some more thought.