Vostok’s approach addresses many of the shortcomings of public-blockchain smart contracts when applied to a private network.
Difference between smart contracts on public and private networks
The blockchain is evolving from payment systems, to enabling the platforms that allow underpin decentralised 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 finished. Consequently, with further technological development blockchain users realised that more than transferring is possible and started to build various useful and even funny decentralised applications. As far as the public blockchain goes 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. Now, given our experience with the 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 tokenisation)
- Auctions of any type or complexity
- Predictive analytics over 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 which are either trusted or can store very limited data objects directly on the blockchain. In both cases, there are serious limitations for the private case.
- 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 business customers expect from smart contract functionality in 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:
1. Q: What language should contracts use and how safe it should be?
As you might know, Waves has the RIDE language, which is really convenient and well-integrated to the blockchain – but it is useful only when the logic of the application is confined to the chain. For applications which need to operate with a lot of different documents, RIDE is inconvenient and we should use something more friendly for developers.
2. 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 blockchain specifics and languages for smart contract development, and the relevant languages aren’t able to work with off-chain data.
3. 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 into the blockchain too closely, which is inherited from public networks where another integration poses a direct threat to system security.
4. 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 from smart contracts, which introduces additional costs for businesses when adopting blockchain within their project.
In the next section, we will describe how we approached all these problems and what our complete solution is.
Vostok Smart Contracts.
So, what smart contracts are available for Vostok Platform?
As you already know, Vostok support RIDE and relatively soon will adopt RIDE 4 dAps. But RIDE, like almost any other smart contract language that was developed for the public platform initially, lacks the ability to work with off-chain data. Given that RIDE is very fast and well-integrated to 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, public insurance could all be implemented using the RIDE language. Otherwise, we recommend using our new feature – Docker smart contracts.
Docker smart contracts
Vostok Docker smart contracts are actually programs wrapped into the 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 the 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 on 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 Vostok 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 or RPC 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 Vostok’s Docker smart contracts are:
- Flexibility of programming languages. Developers can choose any programming language, with any frameworks and packages 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 of 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 block time, or can be lower if user wants.
- Contract parameters can be encrypted to prevent users from knowing what data you are processing.
What happens when you call a contract?
As explained in the previous section we have some code in the docker container. But what actually happens, when someone puts a call transaction in the Node transaction pull? The procedure is as follows:
- If the container does not exist, it will be created with the necessary environment variables.
- It loads exec, a firewall if an Internet connection for this contract is prohibited, and the domain Node is initialised with environmental variables.
- Then 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 which 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 ‘mine’, and also apply the tx to the state.
If you are interested in seeing examples and the necessary steps of deploymen,t you can check this guide in our official documentation.
Brief comparison with the best on the market.
The advantages do we gain from these technological solutions are important, so here we will discuss how our Docker 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 Vostok Docker contracts do not have.
- 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 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 will be completed.
- Off-chain data. You can put some data in the Ethereum smart contracts, but the storage is quite limited and expensive. You can not, for example, write a contract for example, that requests current prices from an exchange, and uses them for other operations. In other words, you can not create a small web server using Solidity, but you can do it with Vostok – 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 working on improving our technology and have already started work on some of the key features we will release in the coming months. To start 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 Docker smart contracts and ordinary transactions, along with mining multiple Docker contracts in parallel.
Written by George Ugulava