No-Code blockchain smart contracts
Updated: Apr 28, 2020
This blog explains how the nSymbol No-Code Toolkit supports blockchain smart contracts.
Image credit: blockgeeks.com
In recent years, blockchain technology has grown at impressive speed. More individuals and organizations are using it every week, while the breadth and depth of available functionality continues to grow. This post discusses how a No-Code approach can make blockchain technology, and specifically smart contracts, easier to use and less costly to deploy.
Blockchains are a type of network that you access over the Internet. Their most defining characteristic is a decentralized design. Unlike social networks owned by a technology company which are centralized (e.g. Facebook, LinkedIn), blockchain networks are decentralized which provides several key benefits:
Provide permanent record of events that is extremely difficult to defraud
Not owned by anyone, always available
Greater reliability as there is no single point of failure
Improved security as there is no central database to hack
Other blockchain advantages include:
Able to securely store and transfer monetary and other forms of value
Use of encryption with a strong focus on identity protection
Ability to host secure chunks of software that can interact with other entities
“There are a lot of really fabulous things that get done with digital assets and blockchain technologies to reduce friction, to reduce costs, and enable things that weren't possible before.”
There are two main types of blockchain network at this time: a single public Ethereum network and a large community of private Hyperledger networks. These are discussed further below.
Blockchain smart contracts
The No-Code Toolkit is a desktop application (nSymbol Tag) that connects to blockchain networks. The remainder of this post uses the terms No-Code Toolkit and Tag interchangeably.
Tag is used to create and prepare software programs that run on a blockchain network. The software is called smart contracts in the Ethereum world and chaincode in the Hyperledger world. While there are technical differences between the two, they are comparable and treated much the same in Tag.
The following terms are used in this post:
Smart contract module: a collection of files that together support software that runs on a blockchain network
Chaincode: the source code for software that runs on a blockchain
Smart contract: a convenience term that refers to both the above
Smart contract modules include chaincode (written in Solidity for Ethereum or Java for Hyperledger) and other files related to blockchain deployment. They also include data setup files which define data fields used to create forms and prepare chaincode. They can also include static or dynamic legal text which provides a human-readable version of the contract.
Chaincode is a small program that provides some degree of interaction. It can interact with humans, other chaincode or other blockchain entities (e.g. oracles that provide current prices or exchange rates). When chaincode is uploaded to a blockchain the smart contract is considered open. After parties have accepted terms or cancelled the smart contract is considered closed.
Open smart contracts can hold a balance of funds (defined below) that's related to a transaction. For example, a buyer can transfer funds to a smart contract before completing a purchase. This assures the seller that funds are available before delivery of goods (product or service). If the buyer is not happy with delivery the funds are refunded; if the buyer is happy the funds are transferred to the seller and the contract closes.
This example illustrates a smart contract acting as an escrow agent, which takes possession of funds until successful completion of the contract. This is similar to the traditional use of human escrow agents, except there is no additional fee for a middleman or agent.
Funds in this discussion are defined as something of value which can be quantified on the host blockchain. This can be, but need not be, directly related to money or currency. On the Ethereum network chaincode stores ETH tokens, which are easily converted to/from traditional currencies (e.g. US dollar) at the current exchange rate.
On Hyperledger networks the funds can be tokens of any kind supported by that private blockchain. The tokens can represent currency or something else of value. For example, a retail organization might track customer loyalty points on their private blockchain. Smart contracts would be able to store or transfer loyalty point tokens to other entities. On a different private blockchain tokens might represent cases of apples or computer parts.
Smart contract types
Tag defines the concept of smart contract type. This type is used to define the behavior and capabilities of a smart contract module.
Smart contract types are currently static and the chaincode is pre-written. The first type supported is Bill of Sale which is flexible and extensible as discussed in the linked-to blog post. More static types can be added by customer request.
The No-Code design also anticipates allowing end users to define new dynamic smart contract types. More details on how this will work will be in a future blog post.
Other potential smart contract types include: notary services (an impartial witness to the signing of important documents); supply chain (when goods are delivered to a port of call the contract pays out); safe shipping (if IOT sensors packaged with shipped goods detect large bumps, the purchase price can be discounted); luxury item tracking (record every person in possession of a gemstone as it moves from mine to consumer to guarantee authentic origin); and many more. There is tons of innovation happening in this area and so the scope of possible smart contract types is large and growing.
“The potential uses of smart contracts extend far beyond the movement of digital cash. Indeed, smart contracts can be used to effectuate business activities involving purchases and exchanges of virtually any tangible or intangible goods, services and rights (e.g.,sales of securities, commodities, personal property, real estate, digital rights, etc.).”
Oliver Herzfeld - forbes.com
Uploading to the blockchain
Smart contract types are a concept defined by Tag, not the blockchain network. Blockchain networks only care about the uploaded chaincode which is associated with a given smart contract type.
This distinction is made possible by using the nSymbol web server. The server can store files (including chaincode) for each supported smart contract type as depicted below.
Smart contract types are created in Tag. They are represented by a smart contract module (collection of files) which is uploaded to the server.
To use a smart contract module on a blockchain network, the chaincode must first be uploaded to the blockchain. This can be done using desktop or (planned) mobile views of Tag. Note that on Ethereum there is a small fee to upload chaincode. To upload chaincode, initial data must be provided.
Once created, the chaincode will interact with parties (e.g. buyer and seller) until such time as the contract is closed or cancelled. This can also be done using desktop or mobile views. Note that on Ethereum, there is a small fee for interactions that modify running chaincode.
After the contract is closed or cancelled, a record of it remains on the blockchain as a permanent archive.
Attaching data to a smart contract
For the Bill of Sale example, the minimum initial data required for a smart contract is buyer address, seller address, product/service name and price.
This data is described using data setup files in Tag. These files auto-generate forms which the user fills out when creating a contract. Only after all required data is provided is it possible to upload a smart contract to the blockchain network.
If more data than the minimum is desired it can be added to custom data setup file(s). Custom data can be anything related to the contract that both parties are interested in. This is described in more detail in the Bill of Sale blog post.
One advantage of splitting the data between minimal and custom, is to minimize the amount of data stored in chaincode. On the Ethereum blockchain each piece of data stored increases the fee payable to upload chaincode.
Similarly, it is cost effective to minimize the logic included in chaincode. Blockchain programmers are hard to find and can be expensive. The No-Code philosophy is to pull data and logic out of the chaincode (if possible) and provide other ways to store and/or interact with it during the contract life cycle.
There are several options for storing custom data including a private file network, the nSymbol server and IPFS (InterPlanetary File System). Further discussion of these options is beyond the scope of this post, other than to say that the nSymbol server is responsible for keeping track of where custom data is stored for a given smart contract module.
Integration of legal text
An important feature of the No-Code Toolkit is the ability to merge content, logic and data. This allows a smart contract author to generate a Word document which merges legal text for the contract with current values from minimum and/or custom data fields.
This is important, because the legal text can inform a judge of the contract terms in the event that court action is required. It also clearly communicates terms to the parties of a contract.
This is where No-Code flexibility really starts to pay off. The minimum data fields necessary for a Bill of Sale are buyer, seller, productOrService and price. They can be used to sell any product or service as long as the parties agree on a contract structure.
Consider three options for preparing a Bill of Sale smart contract for cucumbers:
Gather the minimum data fields with no legal text
Gather the minimum data fields with minimal legal text
Gather the minimum and custom data fields with descriptive legal text
All three options will look the same from a blockchain network's perspective - only the minimum data fields are used by the chaincode. The second option might include static legal text that indicates cucumbers are being sold, but no item-specific data. The third option could include descriptive legal text including a product code and organic farm certification.
A lawyer might prefer the third option because it provides the most detail and clarity, however every situation is different and in many cases the first or second options will be completely acceptable to both parties.
The legal text is optional - if it exists it is stored in a similar way to custom data files.
Using legal text and custom data in this way allows the same chaincode to be used for a wide variety of smart contract types. Simply replace the custom data fields above with whatever information is relevant for a particular sale. Using the same chaincode for many scenarios means there is no need to create and test multiple custom programs written in Solidity or Java. This helps keep cost and complexity to a minimum.
This post discussed how No-Code smart contracts are designed to work and some of the options available to customize for different products or services. More information is available in the Smart Contracts technology page.