You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/adhara/atomic_settlement.md
+13-11
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,7 @@
1
1
# Atomic Settlement - Two phase commit protocol
2
2
3
3
## Introduction
4
+
4
5
Atomic settlement across two different platforms is well described below by [Paul Krzyzanowski](https://people.cs.rutgers.edu/~pxk/417/notes/transactions.html)
5
6
6
7
> A key facet of a transaction is that it keeps data consistent even in
@@ -23,21 +24,22 @@ This is used in the case where a sender wants to `approve` an amount to be trans
23
24
### ERC 2020
24
25
This concept was further refined in the [ERC 2020](https://eips.ethereum.org/EIPS/eip-2020) contract definition which is otherwise called the E-Money Standard Token. This token allows the wallet owner to place a hold on funds for a specific beneficiary.
25
26
26
-
> **Holds**: token balances can be put on hold, which will make the held amount unavailable for further use until the hold is resolved (i.e. either executed or released). Holds have a payer, a payee, and a notary who is in charge of resolving the hold. Holds also implement expiration periods, after which anyone can release the hold Holds are similar to escrows in that are firm and lead to final settlement. Holds can also be used to implement collateralization.
27
+
> **Holds**: token balances can be put on hold, which will make the held amount unavailable for further use until the hold is resolved (i.e. either executed or released). Holds have a payer, a payee, and a notary who is in charge of resolving the hold. Holds also implement expiration periods, after which anyone can release the hold Holds are similar to escrows in that they are firm and lead to final settlement. Holds can also be used to implement collateralization.
27
28
28
-
In simple terms if Counterparty A wants to transfer an asset on one chain to Counterparty B in exchange of a different asset on a different chain, then the process would be:
29
-
1.Counterparty A places a hold on asset 1 on chain 1 with Counterparty B as the beneficiary and Notary A as the notary
30
-
2.Counterparty B places a hold on asset 2 on chain 2 with Counterparty A as the beneficiary and Notary A as the notary
31
-
3. Notary A checks both holds are in place and are correct and then executes both holds
32
-
4. If Notary A decides that anything is wrong in the process, then Notary A releases both holds which cancels the holds, allowing the assets to be used for other transactions
29
+
In simple terms if Party A wants to transfer an asset, on one network to Party B, in exchange for a different asset on a different network, then the process would be:
30
+
1.Party A places a hold on asset 1 on network 1 with Party B as the beneficiary and Notary A as the notary.
31
+
2.Party B places a hold on asset 2 on network 2 with Party A as the beneficiary and Notary A as the notary.
32
+
3. Notary A checks both holds are in place and are correct and then executes both holds.
33
+
4. If Notary A decides that anything is wrong in the process, then Notary A cancels the holds, thereby releasing the assets to be used in other transactions.
33
34
34
35
### Proof based Atomic transactions
35
-
Using the process above, there is an obvious dependency on the Notary to effect the atomic settlement which introduces risk into the system.
36
36
37
-
One of the ways of mitigating this risk is to change the process slightly. The change is that each chain has some logic on it that simply verifies a proof that an event occurred on the other chain. That logic (could be embedded in a smart contract) is the designated notary on the transaction and can therefore ensure settlement happens on one chain if and only if settlement can be guaranteed on the other chain.
37
+
The process above shows how the atomic settlement depends on the actions of a notary, which introduces risk into the system.
38
+
39
+
A way of mitigating this risk is to alter the process by allowing each network to contain some logic, embedded in a smart contract, that can prove the occurrence of an event on the other network. That logic assumes the role of the designated notary on the transaction and can therefore ensure settlement happens on one network if and only if settlement can be guaranteed on the other network.
38
40
39
-
These proofs are covered in more detail [here]("./cross_chain_proofs.md").
41
+
These proofs are covered in more detail [here]("./crosschain_proofs.md").
40
42
41
-
Once settlement has occurred on one chain, a proof of settlement can be sent back to the other chain which completed the settlement process on the other chain.
43
+
Once settlement has occurred on one network, a proof of settlement can be sent back to the other network, which completes the settlement process on that network.
42
44
43
-
The beauty of this construct is that there is no requirement to have a trusted intermediary that could block settlement occurring on one or both chains. Any entity can generate and transfer proofs between the two chains.
45
+
The beauty of this construct is that there is no requirement to have a trusted intermediary that could block settlement occurring on one or both networks. Any entity can generate and transfer proofs between the two networks.
Banks are looking for consistency and standardisation when it comes to connecting to different digital platforms and managing interoperability between different settlement legs.
5
6
6
7
At a simplistic level, banks will be running gateways to different platforms. These gateways could be using different technologies. Below is an image showing the generic components that banks will need to manage. The image is showing a corda gateway and an enterprise ethereum gateway, but this pattern can be extended to other technology stacks.
7
8
8
-
9
+
10
+
11
+
## Risk as platforms scale
9
12
10
-
## Risk as platforms scale
11
-
The risk to banks as the platforms scale is that they need to manage a plethora of gateways, interfaces, data formats and interop mechanisms. By establishing some standard patterns, we can provide guardrails to platform providers to ensure that the connections to their platforms and the interop mechanisms are well understood by the banks and easy to deploy.
13
+
As the platforms scale, banks will need to manage multiple gateways, interfaces, data formats and interop mechanisms. By establishing some standard patterns, we can provide guardrails to platform providers to ensure that the connections to their platforms, and the interop mechanisms involved, are well understood by the banks and easy to deploy.
12
14
13
-
15
+
14
16
15
-
## Aspiration
16
-
The Aspiration of Harmonia is to provide those guardrails in order to be able to generate common/open source interfaces and protocols across apps and DLT protocols
17
+
## Aspiration
17
18
18
-
19
+
Harmonia aspires to provide those guardrails in order to be able to generate common/open source interfaces and protocols across apps and DLT protocols.
20
+
21
+
19
22
20
23
## Interfaces
21
-
There are in fact only 4 interfaces to consider. By focusing on these 4 interfaces the ecosystem of banks and platforms have a real opportunity to establish a simple and standard way for different components to communicate with each other. The 4 interfaces are:
24
+
25
+
The interfaces to consider depends on the ecosystem of banks, but consists mainly of the following 4:
22
26
23
27
- The HSM interface (already largely standardised to use PKCS#11)
24
28
- The Bank Side API
25
29
- The Interop interface
26
30
- The Network interface (well documented across the major DLT protocols)
The following documents have been contributed by Adhara
3
+
4
+
-[Interop principles](interop_principles.md) Some basic interop principles that have been agreed by a number of banks who are invested in this emerging ecosystem.
5
+
-[Bank Side patterns](bank_side_patterns.md) This is a document that explores the impact that standardising, a few generic interfaces, can have on the adoptability by banks, to be able to connect to and manage the new emerging platforms.
6
+
-[Atomic Settlement](atomic_settlement.md) A review of the process of ensuring that in a settlement that consists of more than one leg, all the settlement legs succeed or none succeed.
7
+
-[Crosschain Protocols](crosschain_protocols) Extending the concepts in the above document, this document looks at different crosschain protocols that can enable atomic settlement.
8
+
-[Crosschain Interoperability](crosschain_interoperability.md) Technical design and protocol level discussions regarding implementation of crosschain PvP and DvP.
0 commit comments