360 support confirm scp messages in the stellar relay when proving transaction validity

[ebma]

I tried to adhere to the simplified approach described in this document.

The implementation deviates from the described approach as follows:

• Instead of checking if the n_h value lies within a certain range, the implementation takes the assumption that this value will be the same for all SCP messages.
• Instead of using the quorum hash and comparing it to hashes of existing quorum sets, we use the existing implementation that uses the stored in the on-chain storage to determine if the SCP messages originate from nodes that build a valid quorum set.

I had to change some of the test helper functions so that it's easier to build externalized and confirmed messages in one go, without having to duplicate code.

I recommend reading the Notion page and looking at the test cases to see if everything is covered.

Closes #360.

[ebma]

Instead of checking if the n_h value lies within a certain range, the implementation takes the assumption that this value will be the same for all SCP messages.

@TorstenStueber can I take this assumption or do I need to implement the range like you describe in the Notion page (and implemented here).

[TorstenStueber]

@ebma I will run my script and check whether this is generally the case.

The actual answer will only come with a deep dive into Stellar core code, but we can postpone this.

[TorstenStueber]

Turns out that it is not possible. Ledger 46647565 of the Stellar archive contains the following messages:

  Externalize message from FranklinTempleton3
    quorumSet: quorumHash1
    c = (1, value1), h.n = 1
  Externalize message from Lobster4
    quorumSet: quorumHash1
    c = (1, value1), h.n = 1
  Externalize message from BlockDaemon1
    quorumSet: quorumHash1
    c = (1, value1), h.n = 1
  Externalize message from Coinqvest2
    quorumSet: quorumHash1
    c = (1, value1), h.n = 1
  Externalize message from FranklinTempleton1
    quorumSet: quorumHash1
    c = (1, value1), h.n = 1
  Externalize message from Coinqvest3
    quorumSet: quorumHash1
    c = (1, value1), h.n = 1
  Externalize message from PublicNode1
    quorumSet: quorumHash1
    c = (1, value1), h.n = 1
  Externalize message from Lobster1
    quorumSet: quorumHash1
    c = (1, value1), h.n = 1
  Externalize message from SDF1
    quorumSet: quorumHash1
    c = (1, value1), h.n = 4294967295
  Externalize message from PublicNode3
    quorumSet: quorumHash1
    c = (1, value1), h.n = 1
  Externalize message from SDF2
    quorumSet: quorumHash1
    c = (1, value1), h.n = 1
  Externalize message from FranklinTempleton2
    quorumSet: quorumHash1
    c = (1, value1), h.n = 1
  Externalize message from Lobster3
    quorumSet: quorumHash1

Here n_h is 4294967295 for one of the nodes.

Luckily the same ledger looks different for the SatoshiPay archive:

  Confirm message from BlockDaemon1
    quorumSet: quorumHash1
    b = (1, value1), p.n = 1, c.n = 1, h.n = 1
  Confirm message from SDF3
    quorumSet: quorumHash1
    b = (1, value1), p.n = 1, c.n = 1, h.n = 1
  Confirm message from Coinqvest2
    quorumSet: quorumHash1
    b = (1, value1), p.n = 1, c.n = 1, h.n = 1
  Confirm message from SatoshiPay3
    quorumSet: quorumHash1
    b = (1, value1), p.n = 1, c.n = 1, h.n = 1
  Confirm message from FranklinTempleton1
    quorumSet: quorumHash1
    b = (1, value1), p.n = 1, c.n = 1, h.n = 1
  Confirm message from Coinqvest3
    quorumSet: quorumHash1
    b = (1, value1), p.n = 1, c.n = 1, h.n = 1
  Confirm message from PublicNode1
    quorumSet: quorumHash1
    b = (1, value1), p.n = 1, c.n = 1, h.n = 1
  Confirm message from SatoshiPay1
    quorumSet: quorumHash1
    b = (1, value1), p.n = 1, c.n = 1, h.n = 1
  Confirm message from Lobster1
    quorumSet: quorumHash1
    b = (1, value1), p.n = 1, c.n = 1, h.n = 1
  Confirm message from SDF2
    quorumSet: quorumHash1
    b = (1, value1), p.n = 1, c.n = 1, h.n = 1
  Confirm message from FranklinTempleton2
    quorumSet: quorumHash1
    b = (1, value1), p.n = 1, c.n = 1, h.n = 1
  Confirm message from PublicNode2
    quorumSet: quorumHash1
    b = (1, value1), p.n = 1, c.n = 1, h.n = 1
  Confirm message from Coinqvest1
    quorumSet: quorumHash1
    b = (1, value1), p.n = 1, c.n = 1, h.n = 1
  Confirm message from Lobster2
    quorumSet: quorumHash1
    b = (1, value1), p.n = 1, c.n = 1, h.n = 1
  Externalize message from GDGOUEQK5G6QINBH7277DC2MHVI4KXLAKEIB2OHN572AAONKLE5IMRRE
    quorumSet: quorumHash2
    c = (1, value1), h.n = 1

So we could fallback to another archive in this case again. Please check, though, whether the h.n messages really agree and then fallback.

[ebma]

@TorstenStueber thanks for investigating. Since the fallback you mentioned would have to happen in the vault client though, we don't need to consider it here probably and can live with taking the assumption of having the same n.h for all messages. It's very important though to keep it in mind for the vault client.

[TorstenStueber]

Okay, but the runtime should still check equality of the nH, not?

[TorstenStueber]

Looks good in principle but I am concerned about the requirement that all messages in the archive stem from nodes in the Tier 1 set. We need to discuss what we can do here.

[b-yap]

maybe revert back to sp_std ?

[ebma]

Do you think this matters? It changed because the latest template file uses core::

[ebma]

@b-yap @TorstenStueber what do you say, can this be merged?

[ebma]

Ping @b-yap @TorstenStueber

[TorstenStueber]

I approve of the changes. There is a small nit I mentioned in one comment but I don't find it important enough to slow down this PR any further.

[TorstenStueber]

This case cannot happen as externalized_envelope is define in line 567 to be an ScpStExternalize message.