Differences between smart contracts on public and private networks
The blockchain is evolving from offering payment systems to powering the platforms that underpin decentralized applications. Charles Hoskinson provides a good explanation: when Ethereum was developing their platform they realised that the transfer of assets has a story behind it, which can consist of different terms and conditions to be fulfilled for transfer to be completed. Consequently, with further technological development blockchain users realised that more than asset transfer was possible — and started to build various useful and even funny decentralized applications. As far as public blockchains go, the main use cases are:
With the growth of adoption and popularity of public blockchain platforms, enterprise companies understood that blockchain technology could actually be very efficient for some of their business processes. That progress and focus on business needs had an influence on smart contract development as well. Given our experience with corporate customers, we can provide popular use cases in which smart contracts can shine in the private blockchain arena:
- Corporate document flow
- Supply chain business processes
- Secure voting systems
- Clearing of mutual settlements with suppliers
- Leasing and rental equipment
- Creation of derivative financial instruments, backed by tangible or intangible assets (e.g. debt tokenization)
- Auctions of any type or complexity
- Predictive analytics for blockchain data
As you might imagine, there is a difference between smart contracts for public and private blockchains. On a private blockchain the key differences are:
- Data operated by smart contracts is much more sensitive compared to public networks.
- A common case is that smart contracts should be able to operate with documents and data stored outside of the blockchain, which is not possible for public blockchain platforms. In a public network, there are oracles that are either trusted or can store very limited data objects directly on the blockchain. In both cases, there are serious limitations for private use.
- Sometimes, transactions which invoke smart contracts should be encrypted, if we are dealing with private smart contracts in such a way that only authorized parties can decrypt and execute the contract.
What do enterprise customers expect from smart contract functionality for business applications?
The answer to this question is relatively simple — they want to translate their complex business processes into blockchain logic with a minimum amount of pain. In order to satisfy the needs of our customers, we conducted research and formulated questions to understand what has to be done with our smart contracts:
Q: What language should contracts use and how safe it should be?
As you might know, Waves includes the Ride language, which is really convenient and well integrated with the blockchain — but it is useful only when the logic of the application is confined to the blockchain. For applications which need to operate with a lot of different documents, Ride is inconvenient and we should use something more friendly for developers.
Q: Can the system easily express complex business rules?
For most languages the answer is, unfortunately, no. There are many reasons for this. Corporate developers do not know the specifics of blockchain technology and languages for smart contract development, and the relevant languages aren’t able to work with off-chain data.
Q: Can we upgrade contracts in the future without rewriting all blockchain structures?
Again, no for most approaches on the market (except Hyperledger Fabric). The main reason is that contracts are integrated with the blockchain too closely, which is inherited from public networks where another integration poses a direct threat to system security.
Q: How easy is it to integrate smart contracts into existing customer infrastructure and work with other business applications?
Unfortunately, most of the business applications or their APIs have to be redesigned and it is hard to use them for smart contracts, which introduces additional costs for businesses when adopting blockchain for their project.
In the next section, we will describe how we approached all these problems and what our complete solution is.
Waves Enterprise Smart Contracts
So, what smart contracts are available for Waves Enterprise?
As you already know, Waves Enterprise supports Ride, but like almost any other smart contract language that was originally developed for a public platform, it lacks the ability to work with off-chain data. Given that Ride is very fast and well integrated with the blockchain, we propose to use Ride for implementation of simple logic that doesn’t involve data processing from external sources. So, for example, public auctions, public voting, and public insurance could all be implemented using the Ride language. Otherwise, we recommend using our new feature — containerized smart contracts.
Containerized smart contracts
Waves Enterprise’s containerized smart contracts are actually programs wrapped in a Docker container. The Docker container is placed in the Docker registry (one or many). Each container has an address on the blockchain and an image hash associated with it (obviously, to ensure that we are using a valid container we publish the image hash beforehand with the DockerCreate transaction; more on this can be found in our documentation). To execute a contract, a blockchain transaction is made with the required call parameters, and the contract will also write the results to the blockchain. Since we are using Docker containers, any programming languages and frameworks can be used — unlike Hyperledger Fabric, where developers are limited by the SDK. Note that Docker isolates the application from the Waves Enterprise node and we do not have access to the node at the Code level, but we do have a network connection so are able to execute HTTP requests when we need to. This means we are able to request not only our node but almost any other service we know. To summarise our previous statements, the key advantages of Waves Enterprise’s containerized smart contracts are:
- Flexibility of programming languages. Developers can choose any programming language, with any frameworks and libraries they are comfortable with.
- As a result, we can run neural networks and other machine learning models inside contracts to bring the power of AI to blockchain applications.
- We can connect our smart contracts to external data sources, accessing real-time data and working with applications outside the blockchain.
- Complexity of smart contracts is bounded only by the computing power of the virtual machine on which the contract is deployed. Execution time is bounded only by microblock time, or can be lower if the user wants.
- Contract parameters and state can be encrypted so that other network members cannot access them.
What happens when you call a contract?
As explained in the previous section we have some software in the containerized container. But what actually happens when someone puts a call transaction in the node transaction pool? The procedure is as follows:
- If there is no active container, it will be deployed from the image that is stored in the Docker registry.
- It loads exec, a firewall if an Internet connection for this contract is prohibited, and the domain node is initialized with environment variables.
- The run.sh script is executed, which will install dependencies if the container did not exist.
- The contract can obtain information about the node and transaction through the OS environment variables.
- The contract will be killed on timeout if takes too long to compute (the exact timeouts can be configured by the user).
- The result of the contract’s execution should be printed to STDOUT and formatted as List [DataEntry]. For more details on the format and output you can check the documentation.
- If the contract executed successfully, the miner will create ExecutedContractTransaction and sign it. The transaction contains the call transaction that invoked the contract, and the result. Then, like any other transaction, it is included in the block and applied to the state.
- All participants receiving the block can validate that the transaction signature was produced by the participant with role miner, and also apply the tx to the state.
If you are interested in seeing examples and the necessary steps of deployment, you can check this guide in our official documentation.
Brief comparison with the ‘best’ on the market
The advantages we gain from these technological solutions are important, so here we will discuss how our containerized smart contracts compare with other popular smart contracts.
1. Ethereum has a strong community and has dominated for a long period of time as the number one dApp development platform in the public blockchain arena. It has also been modified for private blockchain use (for example Quorum and Masterchain). But Solidity and EVM languages in general, for the sake of execution on a public network, have serious limitations which Waves Enterprise’s containerized contracts avoid.
- Gas. EVM languages are Turing complete, but in order to be stable in case of an attack, which would paralyse the system by executing infinite calculations, there is a limit to how many operations the EVM can perform per contract execution and how complex operations can be. As a result, if we have a complex contract we may get an Out of Gas Error. This is impractical for a private network, because we require that business processes must be completed.
- Off-chain data. You can put some data in Ethereum smart contracts, but storage is quite limited and expensive. You cannot, for example, write a contract that requests current prices from an exchange, and uses them for other operations. In other words, you cannot create a small web server using Solidity, but you can do it with Waves Enterprise — and even with your favourite programming language and framework.
2. Hyperledger Fabric is currently the best-known platform for private blockchain solutions, and also brings to the table smart contracts in Docker containers. However, they are limited by the SDK and only available for Go, JS, etc. Developers have to handle a lot of low-level operations like dispatch and argument discovery, making even the simplest ‘hello world’ programme on Go 90 lines of code. This might be impractical for many developers.
We are constantly improving our technology and have already started work on some of the key features we will release in the coming months. To begin with, we are working on security enhancements for the current protocol. In the future, smart contracts may require a multi-signature by miners involved in contract execution. We are also enhancing our mining process to support parallel mining of containerized smart contracts and ordinary transactions, along with mining multiple containerized contracts in parallel.