As blockchain technology continues to gain traction, companies have quickly become dependent on multiple distributed ledgers. Until recently, if a company wanted to have a smart contract run on multiple blockchains, they would have to write smart contract for each separate blockchain, with each contract written in a different language unique to that blockchain. This is expensive, laborious, and time-consuming for a business. Enterprises using multiple blockchains are better off standardizing on technologies to achieve efficiency, but this has not been possible to date.
To address these issues, DAML was created as a language for developing concise and secure smart contracts that are executed in a standardized format across different private distributed ledgers. DAML is designed to simplify and remove some of the complexities involved in smart contract development, allowing developers to focus on implementing the behavior and logic of created contracts.
DAML Diamond Asset-Backed Tokens Use Case
To show how a company can utilize DAML to create and transact with asset-backed tokens, OpenCrowd has developed a DAML implementation based on our ongoing work with Diamond Standard Co. to create fungible asset tokens that are backed by real physical assets (diamonds). Diamond Standard is creating a novel, new commodity asset class that is a store of value, like gold. This has never been done before.
Our solution consists of an underlying master registry of diamond assets and a fungible token (a BitCarbon). The diamond assets are stored offline in secure units called “bars”. The contents of each bar are algorithmically selected to ensure each has the same gemological value of underlying physical diamonds, thus enabling the fungibility of the coins. The implementation includes key operational workflows such as the registration and verification of assets, creation/minting of fungible tokens, and custody management. Minting of fungible tokens is done by approved minters that create new coins.
Key Implementation Concepts
Our demo consists of the following contracts:
Registry: The smart contract that diamonds are registered onto by the Registrant
Contract Template: A smart contract stored in DAML. Contract Templates in DAML are by default skeletal contracts with no data. The instantiation of contract templates is what is used to create contract instances on the DAML project.
Registrant: An authorized party that can register diamonds onto the Diamond Registry contract
Minter: An authorized party that can mint fungible tokens using diamonds registered by the Registrar
Admin: An authorized user that is responsible for onboarding Registrars and Minters onto the platform
Token Owner: The owner of the newly minted tokens
Fungible Asset: A token that can be exchanged for other tokens of the same type with equal value
Transfers: An exchange of fungible assets between two parties
Registry: This contract registers diamonds
RegistryInvite: An Invite Contract for a Diamond Registrant to register diamond properties
Minters: Manages minters and issues out invite to mint diamonds
MintersInvite: An invite that would mint diamond pucks upon acceptance
Token: A contract would check if diamond IDs are valid and would generate fungible tokens that are tied to minted diamond pucks
Lien: Option to create a lien for a minted puck with a lien expiration date
LienProposal: An invite to enter into a lien agreement with the lien expiration date specified
Design Pattern Used
For our use case, we used the Multiple Party Agreement design pattern. This pattern uses pending contracts as wrapper agreements before the final agreement contract so that any one of the counterparties to the contract can initiate the workflow by creating a pending contract. The final contract agreement is not created on the ledger until all the counterparties involved in the pending contract sign all pending contracts.
As an example in our use case, the Admin creates the RegistryInvite contract, the Registrant1 accepts the invite, and the pending RegistryInvite contract is signed. Likewise, in the Minters contract, the Admin creates the MinterInvite contract, the Minter accepts this invite, and the MinterInvite pending contract is signed.
Building and Running the System
Your daml.yaml and Registry.daml files are included in this project. Compile the daml file to get your Registry.dar file: $ daml build
After compiling, start your local sandbox to load all your contract templates from $ daml start, and run the Navigator UI by launching your web browser and inserting the url: localhost:7500/
Operating the System/ System Workflow
- Select the Admin role. Once on the Admin profile, select the “Templates” menu and then the Diamond Register contract template. On selection, enter the “Admin” as the Party. Now, select this contract and invite the Registrant, entering Registrant1 as the new Registrant.
- Switch roles to Registrant1 and you would be able to see the contract with the same transaction Id, as noted when the Registry contract was created. Select this transaction and accept the invite by clicking the choice button – AcceptRegistryInvite.
- Now the Registrant1 selects the Registry contract, adds the diamond properties and signs off the transaction with Registrant1 counterparty.
- Switch roles back to Admin and open the Minters contract template. Enter the Admin name and submit the transaction, while noting the Registry and Minters contract Id numbers.
- Open the new Minters contract, select the InviteMinter choice button, and enter Minter1 for newMinter and the appropriate registry contractId.
- Now switch roles to Minter1 and you would automatically see the Minter contract that was created. Select this contract and accept the MinterInvite.
- Switch roles back to the Admin and select the MintersInvite contract. Open the contract and finalize the contract with the last updated Registry contract. The Minter is then automatically added as an observer to the finalized contract
- Switch roles to Minter1 and view the Minters Contract to mint a token
- Select the Token contract template, and assign a unique Id. Enter TokenOwner as the owner, Minter1 as the Minter party and the diamond Id used to add diamond properties in step 6.
- Once the Token contract has been created, go to the latest minters contract and Mint a Token. Enter a unique TokenId, enter the registryId of the diamond, enter TokenOwner as the owner party, lastly, enter the last known registry contract Id and submit - a Diamond token would be successfully issued at this stage.
- Once the Token have been issued, open the token contract and place a lien on the diamond, specifying the diamond expiration date.
Process Flow Diagram
Final Thoughts
Not only does DAML provide a simple way to create flexible, broadly functional smart contracts, it does so without sacrificing the privacy or scale required by larger enterprises. The universality of DAML smart contracts has beneficial implications for any use case with multi-step processes involving multiple party interactions. Developers would only need to focus on implementing the core logic when building smart contracts, as opposed to creating unique signatures, key structures, and other fundamental blockchain transaction components from scratch. The effect of this focus becomes apparent when comparing the amount of code needed for a contract: equivalent smart contracts are 710 lines of code, while DAML smart contracts are only 200 lines, a very significant difference. Enterprises should take note of DAML’s many benefits and consider its use for permissioned blockchain solutions.
© 2005-2020 OpenCrowd Inc. New York