- RFC: 02-006
- Authors: Krishnasuri Narayanam, Sandeep Nishad, Venkatraman Ramakrishna, Dhinakaran Vinayagamurthy
- Status: Proposed
- Since: 21-Oct-2022
Below figure depicts the different components of a Corda network. Primarily it consists of the infrastructure used for the creation of the network and the distributed applications (CorDapps) deployed on the network. Any such CorDapp is a combination of contracts, flows and a client component to interact with the network.
Below figure depicts the different components of a Corda network with Weaver-augmented capabilities, including infrastructural components like relays and drivers and CorDapps (contracts, flows, and client). However, not all of the Weaver-augmented capabilities are needed to implement asset exchange protocol. For example, changes to infrastructure layer (addition of Relays) and changes to client layer (addition of Identity Services and Drivers) are only needed to implement data sharing and asset transfer protocols.
Below we describe the approach for the implementation of asset exchange between Alice & Bob using HTLC that requires only non-validating notary.
- Lock transaction: Consumes an input Asset State and produces HTLC State as the output. Since the claim/unlock later happens in the same ledger, a reference to the consumed Asset State is maintained as a Corda StaticPointer instead of copying the entire Asset State object.
- both parties (Alice & Bob) are owners of the HTLC State (this prevents any of these parties to cheat the other)
All the above transactions collect the consents (signatures) from both parties (Alice & Bob). This helps:
- to ensure that the revealed preimage matches the hash in a claim transaction
- to guard against malicious lockers unlocking the assets illegally in a unlock transaction
A non-validating notary used in this approach doesn't check the validity of the transaction, but only prevents double spending by the parties. This ensures the privacy of the transaction data.
The onus on the changes required to be made lies both on the application developer (as Weaver is agnostic to the client application) and on Weaver as the platform provider.
- Asset contract must be augmented with the ability to verify lock, claim, and unlock requests (using Weaver libraries)
- Asset contract also should provide a function to create a state using StateAndRef with owner passed as argument.
- Create following flows to support lock, and claim of an asset (using Weaver SDK):
- UpdateOwnerFlow: Takes StatePointer, and returns Asset State with updated owner, where caller will be the new owner.
- RetrieveStateAndRef: Takes (assetType, id) for non-fungible assets or (assetType, quantity) for fungible assets as arguments, and returns the StateAndRef for the corresponding asset.
- Add client support:
- Endpoints: lock, claim, unlock, and query status of, an asset (using Weaver SDK)
- Endpoints: receive hash locks and secrets from corresponding app in the other network
- Send: hash locks and secrets to corresponding app in the other network
- HTLC states maintained in vaults
- Interoperation CorDapp to manage bulk of lock, claim, and unlock flows