Open AntonAndell opened 10 months ago
https://github.com/icon-project/IBC-Integration/blob/main/docs/ibc-setup-using-dive-cli.md Can be used to setup test.
@AntonAndell thanks for the information, ill setup a local environment for testing, run some tests with the provided example dapps and ill contact you with any question before starting writing a draft for the new docs.
Hi @AntonAndell as I commented in previous calls here is the summary of things ive encountered during my tests of xcall v2
ResponseMessage
on v1 is different than v2 (see reference table).RollbackExecuted
on v1 is different than v2 (see reference table).CallMessageSent
on v1 is different than v2 (see reference table).Event Name | Signature V1 | Signature V2 | Params V1 | Params V2 |
---|---|---|---|---|
CallMessage | CallMessage(str,str,int,int,bytes) |
CallMessage(str,str,int,int,bytes) |
(_from, _to, _sn, _reqId, _data) |
(_from, _to, _sn, _reqId, _data) |
CallExecuted | CallExecuted(int,int,str) |
CallExecuted(int,int,str) |
(_reqId, _code, _msg) |
(_reqId, _code, _msg) |
ResponseMessage | ResponseMessage(int,int,str) |
ResponseMessage(int,int) |
(_sn, _code, _msg) |
(_sn, _code) |
RollbackMessage | RollbackMessage(int) |
RollbackMessage(int) |
(_sn) |
(_sn) |
RollbackExecuted | RollbackExecuted(int,int,str) |
RollbackExecuted(int) |
(_sn, _code, _msg) |
(_sn) |
CallMessageSent | CallMessageSent(Address,str,int,int) |
CallMessageSent(Address,str,int) |
(_from, _to, _sn, _nsn) |
(_from, _to, _sn) |
The following section describes the differences in the main interfaces (contract methods) between xcall V1 and xcall V2.
public BigInteger sendCallMessage(String _to, byte[] _data, @Optional byte[] _rollback)
public BigInteger sendCallMessage(String _to, byte[] _data, @Optional byte[] _rollback, @Optional String[] _sources, @Optional String[] _destinations)
Same interface on both versions.
public void executeCall(BigInteger _reqId, byte[] _data)
public void executeCall(BigInteger _reqId, byte[] _data)
public void handleCallMessage(String _from, byte[] _data)
public void handleCallMessage(String _from, byte[] _data, String[] protocols)
Same interface on both versions.
public void executeRollback(BigInteger _sn)
public void executeRollback(BigInteger _sn)
Taking into consideration the differences described in the previous points and the comment by @AntonAndell, I believe there are several items that are needed to fully document xcall-v2, each item has a different priority which I would like to discuss here before making changes to the documentation. The following is a list of the items with my personal assessment of the priority in each of them:
_sources
and destinations
in the sendCallmessage
method. Is this currently possible? for this example to work we need to have (unless im misundestanding) a network connection that currently has both BTP and other (IBC?) type of underlying protocol, that way we can use one set of networks and showcase two different examples of sending a cross-chain message using two different protocols.getNetworkAddress
will return the network Id of the current chain, calling getVerifiers
will return the network Id and contract addresses (are these the xcall or BMC addresses?) of the connected networks.CallExecuted
event. When making the executeCall
transaction on the destination chain (this example destination is Havah), I can see the CallExecuted
event as this {"scoreAddress":"cxf35c6158382096ea8cf7c54ee338ddfcaf2869a3","indexed":["CallExecuted(int,int,str)","0x25"],"data":["0x0","UserReverted(0)"]}
. the signature of this events is described as CallExecuted(_reqId, _code, _msg)
. for this event _reqId
is the id of the message, _code
I assume is the error code which can only be 0x0
or 0x1
(on which I assume 0x1
is a success?), for _msg
is this the error message?CallExecuted
event. is the transaction to the dapp contract executed in the case that _code
is 0x0
and 0x1
or only on 0x1
?" Describe an example for sending a message using the optional params _sources and destinations" You already did this with the multi protocol sample dapp but you only used 1 protocol but nothing much changes as you add more
retrieving the "success receipt" for a "two-way communication". Not very high priority since it is only a pure addition to xCall v1 No core fucntionality changes due to this.
"Show an example on how to get the list of network IDs from the xcall contract" This data will be kept offchain. To find available connections and networkIds one should check some type of off chain wiki. The docs mabye should contain this titself.
PR #31 closes this issue
The library to be used now for xcall development is: xyz.venture23:xcall-lib:0.1.1' for java cw-xcall-lib={package="cw-xcall-lib", git="https://github.com/icon-project/xcall-multi.git", branch="main", features = ["library"]} for cosmwam Solidity lib: to be published?
Differences from IIP52 xCall
Multi protocol xCall is based on the initial spec defined in IIP52.
Two new optional parameters are added in sendCallMessage:
_sources
anddestinations
. These parameters can be specified to choose the protocols to deliver the xCall message. If, for example, a dapp wanted to use BTP, they specify the address of BMC as the source and the address of BMC on a destination chain as destinations.Rollback guarantees. In IIP52, xCall rollback executions can only be tried once before removed, which can cause loss of data in case of failure. In xCall multi protocol, it can be retried until successful.
Two-way message success verification. For all two-way messages, a response has to be relayed back since the fee has already been paid. This means that in most cases, a response with the result success is being relayed back. In xCall multi protocol, we store this success receipt so that it can be verified by dapps.
BTP address has been replaced completely by Network Address. A BTP address is a Network Address as defined here with a
btp://
prefix. A Network Address in IIP52 refers to the Network ID in this document which might cause some confusion.The source of truth for a Network ID is now in xCall and not BMC.
_nsn
is removed fromCallMessageSent
event.Error messages are no longer relayed across chains in a response.
_msg
has been removed from ResponseMessage event. This is due to the removal of relaying the error messages.A message can now only be success or failure (1 or 0). In IIP52 a message can have many different error codes but was not used by dapps and the same behavior is not necessarily supported by all chains.
MaxDataSize is defined on the whole payload rather than only user data This change was necessary to limit the size of the
_sources
anddestinations
parameters.What this means for dapps using v1:
The use of BTP address needs to be changed to NetworkAddress. Example remove btp prefix from
btp://${NETWORK_LABEL_DESTINATION}/${CONTRACT_DESTINATION}
; Network Address implmentation will work the same as BTP address and no extra changes should be needed.If event listeners are used some parameters have changed.
Less priority:
Example dapps: Solidity: https://github.com/icon-project/xcall-multi/blob/main/contracts/evm/contracts/mocks/dapp/DAppProxySample.sol https://github.com/icon-project/xcall-multi/blob/main/contracts/evm/contracts/mocks/multi-protocol-dapp/MultiProtocolSampleDapp.sol
Java: https://github.com/icon-project/xcall-multi/blob/main/contracts/javascore/example-dapps/dapp-multi-protocol/src/main/java/xcall/sample/dapp/MultiProtocolSampleDapp.java https://github.com/icon-project/xcall-multi/blob/main/contracts/javascore/example-dapps/dapp-simple/src/main/java/xcall/sample/dapp/SimpleDapp.java
Cosmwasm: https://github.com/icon-project/xcall-multi/tree/main/contracts/cosmwasm-vm/cw-mock-dapp-multi https://github.com/icon-project/xcall-multi/tree/main/contracts/cosmwasm-vm/cw-mock-dapp
@FidelVe Lets keep discussion and questions in this issue during the development