Help understanding how the relayer gets new messages on receiver.go

[pedro-lino]

Hi guys, I've been trying to follow the BSC integration to try to understand how to implement a similar relayer for Algorand.
I am having some trouble trying to understand how new messages sent from the BMC, arrive on the receiver.go module of the relayer.

I know that when the BMC has a new msg to send to the relayer, it will emit this event. I thought the relayer should be lsitening to this event at all times, but it is currently only doing so, in a way that doesn't make sense to me.

So from what I understood, when the relayer detects that the heigh on the BSC blockchain increased, it will try to scan the latest block added there and obtain its receipts.

After getting the receipts of the latest bsc block, the relayer will aim to use them to try to generate the RelayReceipts. During that process ,it will wait for the above mentioned BMC event to be triggered, by calling this method. However, what is totally unclear to me here, is what's the role of the first Receipts here, being that they are being used as inputs to get the information sent from the bmc emitted event, but I don't understand what's going on. By inspecting, it leads to some JSON encoding that I am not being able to follow.

So to sum up, I am mainly looking for answers to these 2 questions:

1. Why do we need to monitor the BSC chain for new blocks and only try to read information from the BMC in case of a new one? I'd assume, we should be listening for bmc events at all times, because people may want to send a new btp message at any time, I dont get how are new btp messages being generated, related with a new block being added to the bsc blockchain.
2. Why do we need to gather the Receipts of a new block, in order to fetch the message from the BMC smart contract? What's their use within this method?

Thank you and sorry for the long text!

[manishbista28]

When a user interacts with BTP Token Service smart contract deployed on a chain (e.g a user invokes transfer method of BTS contract on icon chain), an event log of type Message is generated by BMC contract and stored on that chain.

Following is the example of such transaction done on ICON contract:
https://tracker.icon.foundation/transaction/0xee9c950ab5e83c647eb51b8240b6333241ddab7081ae773d669385c9fc279c33#events
There you can see a Message event generated by BMC contract: cx23a91ee3dd290486a9113a6a42429825d813de53

This Message event has the actual BTP Message that needs to be passed to the other chain. To do this:

1. icon receiver module of relay scans recently generated blocks to find events generated by BMC Contract
2. Once it verifies that there is a BTP Message, it forwards the message to sender module of relay.
3. This sender module will use the BTP Message to call handleRelayMessage() method of BMC Contract deployed on target chain
4. BMC Contract of target chain has now received the message generated on source chain and will now process accordingly

This procedure is the same for BSC chain's receiver as well. It will scan blocks generated on BSC chain and look for Message event type generated by BMC Periphery Contract. The bmcperiphery_gen.go is an auto-generated interface that makes it easier to work with type Message event.

In conclusion, BTP Message is present in transaction events, which the relayer needs to find (by scanning blocks) and forward it to target chain.

[pedro-lino]

First of all thanks for the quick and detailed answer!

I still have some doubts though, here is how I currently see the icon bridge messaging flow :

1. Whenever someone initiates a token transfer, the bmc on the chain A will hold the funds to be transfered (until the message gets to the other side of the chain and the funds are converted to chain B's native token) and emit a Message event signalling this transfer request.

2. When the chain B gets the relay message it will mint the respective amount of their tokens and send back a message of success to chain A. At this point, chain B will create a transaction receiving tokens B, from chain A and add it to a new block on chain B. This block would contain one event log of minting new tokens.

3. When the src chain gets back the success message, it will effectively burns the initial held tokens it sent to B and conclude the transfer. At this point, chain A will create a transaction sending tokens A, to chain B and add it to a new block on chain A.(this should represent the example you sent). This block would contain the two event logs of the first transfer request and the second of the burning success.

Please help me figure out what I am thinking wrong because, according to this logic:

• A Message event (transfer start) is only added to a new block after the transfer is finished. So the receiver could not access it as soon as it received a new btp message asking to start the process.
• Even if the event would be added to a new block on chain A, at the moment a new btp message is sent (when a new transfer is requested) , if the transfer somehow ends up failing (by not being validated in the relayer or on chain B), there would be a need for a new block being added to chain A to revert the transfer inserted on the previous block

[manishbista28]

1. Whenever someone initiates a token transfer, the BTS contract on chainA will hold the funds to be transferred (until it gets an acknowledgment from chainB that the transfr was successful) . The Message event is generated first on ChainA, which includes the transfer Request. This is picked up and forwarded by relayer running in one direction (chainA-> chainB).

This message is received, processed and another Message event is generated by ChainB. This acknowledgement Message is picked up and forwarded by relayer running in the opposite direction (chainB-> chainA). Finally the chainA receives the acknowledgement and unlocks the locked fund. So, for successful transfer there are a pair of Message Events generated.

The number of such Message event exchanges depends upon how a Service Handler (e.g. BTS) operates.

2. ChainB will create a transaction receiving tokens from chainA. This transaction will also contain an event log of type Message that states that the token transfer request was handled.

3. When src chain gets back the message, it will burn the initially held token but it does not need to emit a Message event any more if the token transfer process is complete because there is no point in communicating to the other chain anymore. The example that I had sent was for the first Message event generated by src chain (ICON) for dst chain (BSC).

• For Token Transfer case, a Message event is generated by srcChain first which is processed by dstChain, then another acknowledgement Message event is generated by dstChain which is received and processed by srcChain.

• When the Message is sent (when a transfer is requested), if the transfer ends up failing on chainB, then chainB will emit a Message event mentioning that it could not process the incoming request. This Message event is processed by contract on src Chain accordingly (by unlocking funds, or running necessary revert logic). For both success and failure case, a transaction will have to be done on the source chain to unlock locked funds (and other stuff).

Logic for handling successful or failed token transfers is entirely up to the Service Handler (Token Service smart contract) to decide and implement Service Handler only needs to work with BMC contract to generate a Message event if it needs to communicate with other chain.
Relay is only responsible for relaying transactions. If a relay can not validate a transaction, then it will not forward the BTP Message at all and will keep on retrying block verification (or become stuck). This shows the need for relay to strictly follow receipts, header and protocol verification logic.

[manishbista28]

Also on docs:

https://github.com/icon-project/icon-bridge/blob/main/docs/token-transfer-flow.md
https://github.com/icon-project/icon-bridge/blob/main/docs/img/token_transfer_flow.svg

[pedro-lino]

Awesome explanation, thank you so much