Subject: [Blockchain-interop] Escrow Interface & Trustless ODAP

From: Luke Riley <[email-masked]>
Date: Thu, 15 Jul 2021 16:41:07 +0000

Hi all,

Hope you are having a good summer.

I've added a proposed on chain escrow smart contract interface for Accounts based DLTs here: https://github.com/CxSci/blockchain-gateway/blob/escrowAndTrustless/docs/escrow/AccountsDLTEscrowInterface.md and I've written a description on how it connects to ODAP here: https://github.com/CxSci/blockchain-gateway/blob/escrowAndTrustless/docs/escrow/EscrowInterfaceToODAPnotes.md .

Also in the second link I was theorising how to move ODAP in a more trustless style direction. Any feedback on that will be very welcome.

Regards,

Luke

Luke Riley
Head of Research and Development
[email-masked]
+44 (0) 333 305 6860
www.quant.network
The content of this email is confidential and intended for the recipient specified in message only. It is ​strictly forbidden to share any part of this message with any third party, without a written consent of ​the sender. If you received this message by mistake, please reply to this message and follow with its ​deletion, so that we can ensure such a mistake does not occur in the future.
​
​

---

From: Rafael Belchior <[email-masked]>
Date: Fri, 16 Jul 2021 17:35:15 +0100

Hello Luke, All, 

Your work is very insightful, thank you for sharing. This provides a
first step for solving the problem of lock interface standardization. I
have some comments: 

-On the addToken method, do we need to specify the type of the token?
This detail could be handled by the gateway/connector 

-I suppose addToken works as a type of top-up to the gateway, but it
still has not been added to the escrow (I'm not sure you can add assets
to the escrow without locking them). If so, probably we could merge
addToken with lockFungibleToken? 

-On the lockFungibleToken (and nonFungible version), a timelock is
needed. Typically, within a blockchain, there is the notion of a
globally synchronized clock that is not 100% accurate (this happens
because the nodes of the blockchain have unsynchronized clocks). This
clock is used as a reference to the timelock (e.g., block number in
Ethereum/Fabric; time windows in Corda).  

However, modeling a global clock that references several chains is an
open research problem. A possible solution is to admit the existence of
a global clock that synchronizes with all the chains and tries to
maintain a notion of relative time among them. For example, a gateway
could perceive each round of consensus as an epoch for each chain; where
each chain has different relative clock speeds. This would allow us to
model a cross-blockchain timelock.  

-Regarding, updateTimeLock, in which situation would this method be
necessary? 

-getSecret can only be called by the escrow creator, I suppose? 

-The different states of an escrow are the ones you presented last time
(CREATE, LOCK, CLAIM, CANCEL)? 

-In the future we probably want reusable escrows 

The rest of the specification looks like an excellent start! 

Regarding the second document: 

-I think the crash recovery part is on point. Using self-healing or
primary backup, along with the timelock would make it difficult for
funds to be lost or indefinitely locked. 

-HLTCs are widely used for users to exchange assets in different
blockchains where both are present in both blockchains. Is the practical
advantage of these changes to enable an atomic swap/asset transfer
across blockchains where not all the participants are present in all the
blockchains? 

Another advantage is that gateways could automatically exchange
verification transactions (those used for recovering assets in case of a
timeout). 

Hope that all of you have a great weekend, 

Rafael 

A 2021-07-15 17:41, Luke Riley escreveu:

> Luke Riley​
> [1]
> [2]
> [3]

-- 
-- Rafael Belchior 

Ph.D. student in Computer Science and Engineering, Blockchain - Técnico
Lisboa
https://rafaelapb.github.io/
https://www.linkedin.com/in/rafaelpbelchior/ 

Links:
------
[1] https://www.quant.network/
[2] https://twitter.com/quant_network
[3] https://www.linkedin.com/company/quantnetwork/