PRA BMV: verify Substrate event

[danielvo11]

Verify Event in substrate chain:

• Substrate store list of events of each block in Merkle Patricia Trie (MPT) node. In order to verify specify event, relay push MPT proofs to BMV. BMV will take state root from block header and proofs from relay to verify list of events of block.

• After verify MPT success, BMV get encoded of list events. Because substrate has more than 100 event types and each of that has it own data structure, we proposed relay to decode list event data and send it to BMV. BMV will encode it again and compare with data result from MPT verification. It kind of duplicate data from relay send to BMV.

Problem that may happen:

• Because of substrate store all events of one block in one MPT node, in order to verify event, relay must push encoded data of all event in one transaction. In case that block has large number of event, it could be impossible to push it in one transaction.
• For example: Assume that block has 1000 events, each event size 100 bytes, total size for all events is 1000*100 = 100'000 bytes = 90 kb.

What you think about that? Do you have any better idea to verify BTP event inside PRA BMV?

/cc @quocle108

[dhlee-icon]

Does it really need to push all events data to BMV to verify the block? If user sends 1 message or so in one traction, then the relevant leaf node of MPT would also 1 node or so. Then, from the event message to MPT root, we can sends only the relevant path to the root. You can reference bitcoin SPV protocol if needed, https://wiki.bitcoinsv.io/index.php/Simplified_Payment_Verification . Just as similar as SPV, you can design verification process to streamline and prune the verification data which is only used. Further questions will be welcomed.

[danielvo11]

When I look at your opinion, it seems impossible, right?

I means it impossible to prove event log by getProof.

[flowersinthesand]

We concluded that there's no way for PRA BMV on ICON to avoid an issue of handling all events in one block at the moment so would like to approach to this issue as follows:

1. PRA to ICON BMR decodes events and sends it to BMV and BMV encodes and compares it with the result from MPT validation. As described in the body it may not work as expected if there are a lot of events with big data in one block. However, considering the current number of events in Edgeware we think it should be okay.
2. To circumvent a lot of events with big data issue we'll design and implement a protocol between PRA BMV on ICON and PRA to ICON BMR to leverage multi-transactions as suggested in PRA BMV: verify Substrate event #30 (reply in thread)

@leeheonseung Due to the time limitation we don't think we can finish the second approach in BTP 1.1. We would like to suggest to work on it in developing BTP 2.0 as an improvement as also BMC in BTP 2.0 seems to have a similar design. Feel free to share your thought.

[cow-hs]

comment 1

The opinion of the ICON team is that BMV should not rely on BMR, so BMV should work based on the original data.

comment 2

If there is big data in one Block, it is not a simple performance problem, but a critical problem that can cause BTP to stop for the following reasons.

• we may not be able to send proofs to one tx at a time.
• The leaf size of MPT can be larger than TX limit and cannot be limited.

comment 3

According to the comment 2, the ICON team will develop and provide fragmentation and assembly functions to ICON BMC.
Since you only need to work on the ICON BMC side, there is no need to check the interface change and protocol change on the ICONDAO side.
Therefore, ICONDAO does not have to worry about the above.

[quocle108]

@leeheonseung

The opinion of the ICON team is that BMV should not rely on BMR, so BMV should work based on the original data.

Of course, our solution should not rely on BRM. This is the reason we need the review from your team. Let's me explain more detail about it:

The normal way:

After successful MPT verification, ICON BMV gets serialized data of Vec<EventRecord>. To deserialize this data we need to store all event's structures inside the BMV smart contract. But it's too expensive and bad performance to decode that data due to a large number of event structures (As I see there are more than 100 event structures).

For example:

Here is sample deserialized data

[
  {
    "phase": {
      "applyExtrinsic": 0
    },
    "event": {
      "index": "0x0000",
      "data": [
        {
          "weight": 186153000,
          "class": "Mandatory",
          "paysFee": "Yes"
        }
      ]
    },
    "topics": []
  },
  {
    "phase": {
      "applyExtrinsic": 1
    },
    "event": {
      "index": "0x0003",
      "data": [
        "13sSDfzDzkJiJRSSC9CkJU2Dsfas8BnpUm13TfSaWkHjszNf"
      ]
    },
    "topics": []
  },
  {
    "phase": {
      "applyExtrinsic": 1
    },
    "event": {
      "index": "0x0500",
      "data": [
        "13sSDfzDzkJiJRSSC9CkJU2Dsfas8BnpUm13TfSaWkHjszNf",
        1870250734013
      ]
    },
    "topics": []
  }
]

To decode the event[0], it needs structure with index 0x0000
To decode the event[1], it needs structures with index 0x0000 and 0x0003
To decode the event[2], it needs structures with index 0x0000, 0x0003 and 0x0500

Our propose:

We need the BMR to decode a part of the serialized data of Vec<EventRecord> and then send it to ICON BMV. To verify this data, ICON BMV will encode it and compare it with original serialized data (Which is already successful MPT verification). The main purpose of this: we don't need to decode all event's data, we only need to decode the BTP Message Event's data.

Here is sample data that will be sent to ICON BMV

[
  {
    "phase": {
      "applyExtrinsic": 0
    },
    "event": {
      "index": "0x0000",
      "data": "serialized_data1"
    },
    "topics": []
  },
  {
    "phase": {
      "applyExtrinsic": 1
    },
    "event": {
      "index": "0x0003",
      "data": "serialized_data2"
    },
    "topics": []
  },
  {
    "phase": {
      "applyExtrinsic": 1
    },
    "event": {
      "index": "0x0500",
      "data": "serialized_data3"
    },
    "topics": []
  }
]

[trmaphi]

We only need the Receipt stored in BMC, not the entire Receipt of the block.
Parachain is not a general substrate, but rather a frontier implementation.

Every substrate-based chains contain a different list of FRAMEs - supports the list of features in runtime, it means that every substrate-based chains can possibly have a different set of features. And, EVM and Ethereum FRAME, the most used implementation is from frontier.

The implementation of BMC, BMV, BSH on Edgeware Network depends on both EVM and Ethereum FRAME, so the RelayMessage structures must adapt based on the Parachain we'll target.

[flowersinthesand]

As we found a security vulnerability in the way we've suggested we'll implement the original way that BMV deserializes the event vector. Thanks for your help.