Diving deep into the xCall

[pedro-lino]

Hi guys, I am part of the team working on integrating the algorand chain into the icon-bridge. We were asked to implement the xcall feature into our solution and we would like to clarify some doubts regarding it.

From its description, we understand it aims to be an interface to facilitate the integration of new services into the BSH.
But we are struggling to understand how to properly apply that concept into the current structure of the icon bridge.

To sum up the current icon bridge message exchanging flow:

1. user on chain A inits a service request from chain B, by interacting with chain A's bsh.
2. bsh A would then pass the message to bmc A, that would then encode it and forward to the relayer A.
3. The relayer A would decode it, verify it and then forward it to relayer B
4. relayer B would encode it again with chain B's protocol and pass it to bmc B.
5. bmc B would then decode it and obtain information about which service, was it requested to perform.
6. if that request would require bsh action the message would then be passed to bsh A, so that it could handle it.
7. afterwards, either a success or failure message response, would be sent back to chain A in a reverse way of the original path.

We would first like to understand, the advantages that introducing the xcall, would provide to this initial design of messaging exchanges.

Additionally, we would like to understand how should it be integrated into the current smart contract scheme.
Because some of the methods described on the IIP, seem very similar to what the current BMC already aims to do. E.g. handleCallMessage seems to aim the same as the current BMC's handleRelayMessage.
Is it, in any way trying to replace the current BMC contract by doing that? Or does it intend to act as a third smart contract that parses and forwards information between each chain's BMC and BSH?

When asking for any example implementations of the methods described on the description document of the xcall, we were pointed to this btp repo. After inspecting them, we still were not sure how should be integrated in the current icon bridge structure, but got some concerns, regarding algorand limitations to implement them, we would like to clarify as well:

These memory limits seem to indicate the, processed data by the xcall could surpass 3000 bytes:MAX_DATA_SIZE which is 2048 and MAX_ROLLBACK_SIZE with 1024. In algrand the limit size per transaction is 2048 and for logging events in smart contracts 1024. We might have ways to work around this, but could be a cause for concern if the required data to relay might need to be that large.
At last could you clarify the purpose of these 2 events (1 , 2)? Because they seem to require a larger output size than we could put in a single log.

Thanks!

[BennyOptions]

Hey @pedro-lino - thanks for reaching out here. One quick question - has your team used the e2e testing demo of the xCall service between ICON <> EVM (Hardhat)? I feel this should demonstrate exactly how the xCall interacts with the BMC and other components of BTP. It deploys a basic sample app, an xCall, all relevant components of BTP, then sends and processes sample messages.

From an architecture standpoint, the xCall service is itself a BSH. It is a service to pass arbitrary data between networks. I could see how this could have been done in the BMC potentially, but the BMC also has many additional tasks about message structure so I can also see why it was separated.

As a next step, let us know if you've already used this, and if not, please use the demo and let us know any followup questions from there.

https://github.com/icon-project/btp/tree/iconloop-v2/e2edemo

[pedro-lino]

Thanks for the clarification and suggestion @BennyOptions , one of our colleagues tried to execute it before, but got some build errors. In the end I guess we will be sticking with the original structure format after internal discussions.