ICON BTP Arbitrary Call Service Standard

[sink772]

iip: 52
title: ICON BTP Arbitrary Call Service Standard
author: Jaechang Namgoong (@sink772)
discussions-to: https://github.com/icon-project/IIPs/issues/52
status: Draft
type: Standards Track
category: IRC
created: 2022-07-11

Abstract

A standard interface to make an arbitrary call service (a.k.a. xcall) between different blockchain networks via ICON BTP protocols.

Motivation

Adding a new service to an existing BTP infrastructure requires an audit of the code to ensure that the service does not have any malicious behavior, because the relay bears the gas cost of executing the service transaction. To improve scalability and flexibility and to overcome the restriction mentioned above, we propose a new interface for invoking arbitrary cross-chain contract calls that can appropriately charge the gas cost to users triggering cross-chain transactions.

[han-so1omon]

Is fee handling describe here applicable to all BTP services? If so, then I do not believe that it belongs in this IIP, as this IIP is for a specific service

[sink772]

The core fee handling mechanism (for the relay fee) would be carried out in the BMC module, and this will be addressed in the updated #25 standard. xcall receives total fees (relay fee + protocol fee) on behalf of the BMC module, since this is the outermost interface to communicate with the user contract. Then the relay fee goes to BMC module, and the remaining protocol fee goes to the Fee Handler.

[han-so1omon]

As BTP is an open framework, there are no rules that enforce that someone else who implements BTP could not define a separate service. For example, a different arbitrary call service (e.g. arbCall) with different rules, but with the same fee structure

These two pieces of information are sufficiently separate that I believe it should be a separate IIP. Something like the following:

IIP: BTP Service Fee Handling IIP: BTP Arbitrary Call Service Standard (references the service fee handling IIP)

[sink772]

You're overlooking the underlying rationale of the xcall specification. Please see the Motivation section first to see why this specification was proposed. Also, BTP is not an open network (in operational viewpoint) and actually there is a rule to register a new service to BMC, see the addService API in the BTP spec.

That's why we (Scott and our devs) are thinking xcall would be the only service for the BTP in the end. So it is natural for xcall to collect fees from user contracts, and that is why the fee-related APIs reside in xcall spec (for protocol-fee handling).

Regarding relay-fee handling, as I said above, that is a part of BMC module, but it could be separated to another IIP spec as you suggested. It's a different topic than xcall and should be decided how to handle it later.

[han-so1omon]

What I mean is that BTP is an open specification. At any time, anyone is able to implement it on their own, either by adapting existing implementations or creating their own new implementations, and then deploying new infrastructure. Anyone can also propose a new BTP IIP on their own and guide it into acceptance.

Especially with the eventual launch of ICON SDK, there will inevitably be adaptations of the BTP infrastructure into new contracts or relays with new mechanisms and new use cases. I think that the foresight of this is extremely important to building something that can grow and be owned in a decentralized manner

I believe that it is foresight like this that caused IBC, for example, to become successful, and to allow for a variety of new standards and implementations, all of which the community are incentivized to create

[AntonAndell]

@sink772 Could you explain the reasoning of only allowing contract calls? Rollbacks would not be possible if called directly but for simple calls i don't see why it would be disallowed.

[BennyOptions]

@sink772 to @AntonAndell 's point, when planning Balanced architecture, there are some scenarios where we would like users to be able to call xCall directly. This would provide a safe way to get message.sender from the xCall message, rather than building our own proxy that could have some bug.

Can we allow EOAs to call xCall instead of limiting to contracts only? If so, what would be the best next step?

[sink772]

@AntonAndell @BennyOptions From the beginning, xCall interface assumed contract-to-contract message passing, which requires for service providers to deploy new contracts on both source and destination chains to provide their functionality. This assumption makes xCall implementation simple and straight-forward.

However, if there is a need to call xCall directly from EOAs (without providing rollback data, i.e. only for one-way message), it would also logically make sense and no reason to disallow it.

So the next step would be updating the xCall standard doc and modifying the RI code accordingly. This may take some time to be finished.

[BennyOptions]

@sink772 thank you and sounds good. Is there anything else we can do to track the issue / help or will you submit a PR when it's ready?

[sink772]

@AntonAndell @BennyOptions FYI, the xCall RI has also been updated to reflect the spec change. https://github.com/icon-project/btp/commit/959681d7cf95b86492d1e54ca25f9f9916b82b9a