Content of an Icon Bridge Message

[pedro-lino]

Hey guys, I'd like some help trying to better understand the structure of an Icon bridge Message.

According to the file types.go, the Message struct that the relayer sends to the BMC, contains an array of Receipt and in each one there is an array of Event, being that each contains an individual byte array representing the Event's field named Message.

I would like to ask for clarification on what does represent a Receipt, an Event and what could be the content of the Event's Message. It would be very helpful if you could provide a practical example as well.

From my understanding, in each Message sent across the bridge, we would make a request for a particular service (like token transfer from chain A to B).
So I don't understand why would a message need multiple receipts each containing multiple events. What's the need of having all these arrays?
Wouldn't it be enough to have the contents of a message being, a struct with the type of service to perform and the required parameters to perform it?

Thanks in advance.

[MuhammedIrfan]

@pedro-lino Receipts are block header item. BMC emits BTP Message as Events which are part of Receipts. Initially while developing decentralized version, it was required to maintain this structure, while migrating to centralized version we decided to maintain this structure.

[pedro-lino]

Thanks for the reply @MuhammedIrfan , there is still one thing I dont get yet though.

Why does a message need to contain multiple receipts anyway?
Shouldn't a single btp message represent only one service request, to be passed to the smart contracts to execute ? (Like transfer x amount of token y, from address a to address b)

I still don't understand why does the message needs to be so complex. Shouldn't the relayer from chain A be listening to all its new blocks and inspect their receipts, to then filter only the ones that contain a valid btp message, and then parse that message in a proper way to send it to chain B ? Why does the current structure sends all the receipts and events instead of filtering them in the relayer first and send the bmc only the data it will need to proceed with the token transfer request?

If that reason was somehow to minimize contract calls in the decentralized solution, could we change that approach to make a more efficient solution that would work in this centralized version?

Also, what is the structure of a Message inside of an event? could you provide an example please?

[pedro-lino]

@manishbista28 perhaps you could have some insight on this issue as well?

[manishbista28]

Why does a message need to contain multiple receipts anyway?

If a single block has multiple transaction receipts each of which contain BTP Message (which is likely when blocks are generated slowly but BTS contract is called multiple times), then each of these transaction receipts' event logs' will be checked to find event logs with the required BTP Message. Using these data, we form a chain.Receipt for each transaction receipt.
Computation for the above is mentioned here
So a chain.Message holds information of transaction receipts for a block. Since block can have multiple txn receipts, so should the chain.Message hold multiple chain.Receipt

Shouldn't the relayer from chain A be listening to all its new blocks and inspect their receipts, to then filter only the ones that contain a valid btp message, and then parse that message in a proper way to send it to chain B ?

Yes, it should. That is what's done in function getRelayReceipts and also here

Also, what is the structure of a Message inside of an event?

For ICON, Message is represented in clean text form. This link includes an event log which holds a BTP Message. The data field of this event log is stored in Event->Message object.

Example of Event->Message from the link above

0xf8fbb8396274703a2f2f3078312e69636f6e2f637832336139316565336464323930343836613931313361366134323432393832356438313364653533b83b6274703a2f2f30783232382e736e6f772f3078663830384662623535434644446133374430353142393632623739313861384433393831666544358362747382024cb87af87800b875f873aa687835666135336432396230303539646562316166303366386564623964623130396636343936373966aa307835433039463435453944316563334441653632323431383862613730613566363631393745443139dcdb906274702d3078312e69636f6e2d4943588953401e65833f620000

For evm chains, the message has to be parsed like this to obtain string equivalent as log.Data is rlp encoded. Example txn

[manishbista28]

Multiple Event in Receipt is useful only if a single transaction generates multiple BTP Messages.
I am not sure if there are any such contract methods so far that generate multiple BTP Message.
I am also not sure if the BTP Protocol prohibits a single transaction from generating multiple BTP Message.
If there is no prohibition, perhaps it makes sense to accommodate it in relay.

[pedro-lino]

Thank you very much @manishbista28 that was really insightful.

[pedro-lino]

@manishbista28 got one follow up question here, that is currently blocking me.

When receiving a new message from icon, we are going to get it here , in the format of a chain.Message
It is already composed by the chain.Receipt struct which is itself composed by the chain.Event struct.
These two structs already come decoded. But the Message field of the Event does not, it comes in the byte array format.

My question here is, how can I decode this Message here on the relayer? What is the target structure to decode to and which protocol did Icon use to encode it to a byte array?

I see that on the BSC's BMC , it gets decoded into this BMCMessage using this decoding function.

For our case, we need to do the entire decoding inside the relayer and only pass the key elements to the smart contracts, as these are heavily restricted. So please help me understand how to properly decode the messages received from Icon.

[manishbista28]

What is the target structure to decode to and which protocol did Icon use to encode it to a byte array?

Message is emitted by ICON's BMC this way
Here the BMC Message struct is serialized and saved to block chain's event log.

This serializedMsg is saved as rlp encoded byte array by ICON
In the example given previously, the following rlp encoded value is what was present on transaction receipt
0xf8fbb8396274703a2f2f3078312e69636f6e2f637832336139316565336464323930343836613931313361366134323432393832356438313364653533b83b6274703a2f2f30783232382e736e6f772f3078663830384662623535434644446133374430353142393632623739313861384433393831666544358362747382024cb87af87800b875f873aa687835666135336432396230303539646562316166303366386564623964623130396636343936373966aa307835433039463435453944316563334441653632323431383862613730613566363631393745443139dcdb906274702d3078312e69636f6e2d4943588953401e65833f620000

To show that this rlp encoded value can be decoded, a simple way to check would be with this online decoder (Screenshot attached)

To help verify convert hex to string.

This rlp decoding can also be done using go-ethereum library's rlp function. I had once needed to do something very similar while working on e2e tests. This is how I did it then if it can be helpful.

[pedro-lino]

Thanks again for helping @manishbista28!

From my interpretation of you suggestion, this would be how to decode that event's message, to the BMCMessage structure presented on the solidity contracts:

note: I replaced the sn type from solidity's uint256 to big.Int, since I didnt find a native uint256 type in go, could that be a problem?

Any hints on what could I be doing wrong?

[manishbista28]

No, it won't be a problem
big.Int is large enough to hold uint256

However, we've never found the need to decode the BMC Message. The purpose of the relayer is to relay the BMCMessage as it is. So I'm curious as to why it was needed for algorand integration.

[pedro-lino]

Because Algorand's smart contracts are built on a very low level machine like language, in which is very difficult to handle encoding operations. Additionally it has very tight memory restrictions. For that reason, we would like to do most of the data processing on the relayer and only pass to the contracts the absolutely necessary data, in a ready to process format.

[manishbista28]

hmm
i'll loop in @bbist in case he has any additional info he wants to share in this context.

[pedro-lino]

I was able to make some changes and decode the message in the relayer. Thanks mostly to the example you shared above from parser.go. Now I'll pass the decoded addresses and service type to the contracts, for them to handle the request/response flow.
As for the sending message part, the intention is also that the contracts return the decoded service request, to be encoded in the relayer, also in the rlp format that Icon expects to receive, as pyteal does not have any RLP protocol implemented and it would not be viable to attempt to implement one from scratch, due to its syntax.