Message Verification Requirements

[pedro-lino]

Hello, regarding the Icon Bridge, I would like to better understand what exactly does the relayer need to verify, when it receives a new message from the bmc.
What are the requirements to consider a new message verified?
Thanks!

[manishbista28]

The relayer receives message by scanning event logs from source chain for BTP Message and submits it to BMC in target chain

The relayer verifies the event log from source chain by:

1. ensuring that they form a chain by comparing hash of successive blocks
2. further ensure integrity of header, transaction and receipts (this differs based on the consensus engine)
3. if BTP Message is present, it should have expected value of serial number.
4. ensure BTP Message is from the source (BMC address) that the unidirectional relayer is supposed to forward.

When the relayer submits a transaction on destination chain's BMC, it does not verify the transaction receipt.

Please let me know if this helps.

[pedro-lino]

Yes it helps, thank you!

[pedro-lino]

@manishbista28 one thing I'm still struggling to understand is in point 2, why and how do you check the validity of a new block.

If a block was already added to its blockchain, it must already have passed its consensus criteria, right?
In this case I am looking into verifying blocks from the Algorand chain, that has a consensus protocol that's a variation of PoS. What could I check to verify the integrity of a new block, that wasn't already required for it to be added to the blockchain in the first place?

Or am I missing something and verifying a message could be a different process than verifying a block?
Thanks again!

[manishbista28]

The endpoint that the relayer receives the blocks from is not supposed to be a "trusted" node. As such, we have to assume that the blocks we received could have been forged with a faulty BTP Message.

To verify that the received blocks are correct:

1. We first initialize the relayer with a value (e.g. block hash of some block number) that we know to be true through the relayer config.
2. Then for each block that is received from the endpoint, we ensure that this block has what it needs to form a chain.

For example, in case of BSC, we check

1. To verify that n-th block forms a part of chain, n+1-th block should be verified and its ParentHash should point to n-th blocks hash
2. While verifying a block, we extract necessary info from block header to ensure that the block was validated by a set of validators, which we know to be correct. This is followed by some other checks..

So, we aren't verifying anything new. We're just ensuring that what the endpoint says is verified is actually so.

[pedro-lino]

But if we assume that the blocks could have been forged, since they come from a non trusted endpoint, why do we trust that their block height, parent hash or list of validators are valid? I mean, couldn't a malicious entity that forged a block, also forge its validators list for example?

[manishbista28]

We do not trust anything received from endpoint including block-height, parent hash and validator list.

That is why we first verify it. The only way to verify without relying on an endpoint (external source) is by ensuring that this newly received information is consistent with the state information we have so far.

As long as this state information was initialized correctly (e.g. like a genesis block in a chain) and it was update correctly (by verifying newer blocks) up until now, this state can be used to verify data received from endpoint.

While initializing this state information, we include in it a manually verified block's number, parent hash, validator info, etc.

[pedro-lino]

Ok I understand, so we always initialise with a known heigh, current hash, validators list and next validators list and for each new block we need to verify, the height was incremented, the hash points to the previous and the validators list is the one mentioned by the previous block's next validators list.

[manishbista28]

yes

relayer's verifier is equivalent to a full node that still needs to verify the blocks it receives from other nodes after starting off from a trusted genesis block configuration.

[pedro-lino]

hey @manishbista28, I've been going on this issue and came up with these follow-up questions, that I hope you can clarify.

The endpoint that the relayer receives the blocks from is not supposed to be a "trusted" node. As such, we have to assume that the blocks we received could have been forged with a faulty BTP Message.

Wouldn't it be a more efficient option to just run a trusted node instead? Why couldn't this be an option?

2. further ensure integrity of header, transaction and receipts (this differs based on the consensus engine)

Does it really make sense, to do a full consensus verification, for code running on an off-chain untrusted environment? I understand it would make sense on the previous BTP solution, where it would be verified inside the smart contract. But from a user of the bridge's point of view, it doesn't give you extra trust, since the code is not running inside a smart contract and therefor the relayer operator could always change the code and needs to be trusted

[CyrusVorwald2]

@manishbista28 please correct me if I'm wrong.

Full consensus verification is not necessary. We implemented it for the other chains because it's fairly trivial, prevents MITM attacks between the RPC endpoint and relay, and is a first step towards on-chain verification with BTP. There may also be some additional benefit, such as message sequencing, but I'm not sure. In any case, Algorand's consensus is significantly harder to verify because it must keep track of the full history of validators. Simply checking the parent hash is good enough in this case.