XCall for arbitrary message delivery
XCall is a BTP service for arbitrary message delivery without any authentication.
To add the service to the BTP network, besides implementing service logic, it also requires verification of the codes to prevent forging messages and consuming too much fee for processing messages. These verification processes create problems that slow launches and limit creativity. To expand users and convenience, we need to improve our protocol.
To remove the verification of codes and solve fee payment problems, the user pays the fee for executing service logic. The followings are proposed designs for it.
There are two kinds of work required to relay messages. One is delivering messages with proof from the block. The other is delivering block updates. If it delivers a message after a long silence, then it needs to deliver a lot of block updates. And this causes big differences in costs for delivering a message ignoring other latency problems. It would be a very bad experience to pay a lot for delivering a single message besides the following user pays a small.
So, it's not usable.
Block updates are delivered by relays, but a message with proof is delivered by a user. Of course, a user may pay a fee for block updates. But it could be spread by an operator. This could be ideal for a payment mechanism. But for handling messages, it comes with lots of other problems.
Prevent multiple deliveries for a message
If someone delivers a message multiple times, Only one delivery must be successful. It would be painful for DApp developer to handle it. And also this logic is common to all normal services. So, it should be implemented in the BTP framework. This means that the contract in the destination should record all results of message delivery.
Handle random order deliveries by DApp
Some services don't need to receive the messages in order. The other services expect ordered message delivery. Later services need to handle it by themselves. The most developer expects ordered message delivery. It increases the implementation cost.
Prepare complex proof data by DApp
Although all block updates are handled by relay with complicated codes, a user also needs to gather proof for messages. Gathering proof is too complex to be done by users. To ease this work, codes for gathering proof for each chain must be shared. But as you can imagine, it would be enlarged more and more whenever new blockchains are integrated. Sometimes, it may not fit the platform that the user uses.
So, it's too expensive.
Compared to prior solutions, it's a balanced solution. Relays deliver messages to the intermediate contract of the target chain. Then a user handles service delivery from the intermediate contract to the service contract.
The role of an intermediate contract is the followings.
- Confirm that the message is not forged and delivered at once
- Notify the actual sender of the message
- Sends result back on the actual delivery
A user sends a message to the destination paying a fee for message delivery to the intermediate contract. Then it waits for the arrival of the message, then it dispatches the message to the service contract. With this design, a user doesn't need to know about cryptographical stuff but uses normal smart contract features.
Sending a two-way message to B network from A. C1: service contract in network A C2: service contract in network B
The user sends a transaction to send specific messages with the fee specified by BTP Network Operator.
If the contract calls sendCallMessage, then it gets the serial number of the messages on return.
Otherwise, it should check the "CallMessageSent" event to get the serial number.
Then it waits for the event of message arrival with the serial number at the target blockchain.
Actual message delivery would be handled by the relays after the transaction finalization.
When the message arrives at the destination chain, then the XCall emits a "CallMessage" event. The event includes BTP Addresses of the source and destination and the serial number of the message from the source. When it executes the call, it should use the request ID and data in the event.
If the delivered message is a two-way message, then it would send a response. And the XCall from the source chain should emit "ResponseMessage" if it receives the result. If it fails, then it also emits "RollbackMessage" to let the user knows that he needs to handle rollback data.
When the delivery has failed, then XCall of the source chain emits a "RollbackMessage" event with the serial number of the message. Then anybody can process this rollback with the serial number. It delivers a rollback message to the original sender like other messages. The only difference is that the sender is "XCALL" in the source chain.
