Cypherium | Evolution of Smart Contracts
Abstract: This article takes a broad look at the evolution of smart contracts, from traditional industry contracts to decentralized smart contracts, and the possibilities that current blockchain technology makes available. We analyze a number of problems facing today’s smart contract platforms, as well as the shortcomings of the various technological solutions. Finally, we focus on the elements and unique application scenarios required of the next generation, 3.0 platform for smart contracts.
Paper contracts, the ones currently inked below letterheads and signed above corporate seals, almost always engender conflict. Due to the inherent ambiguity of language, the parties can develop (willfully or not) different interpretations of the contract’s terms. Entire industries have been born of these disputes. However, if the contract not in ambiguous language, but rather programmed in code, these problems become much simpler, as the code cannot equivocate. We have called such code-written contracts “smart contracts.”
But while unambiguous, computer code can be modified. So in order to solve effectively the problem of multi-party trust, smart contracts have become viable only through the advent of blockchain technology, and its characteristic advantages of decentralization, tamper-resistance, and high reliability. On-chain smart contracts go through a three-tiered workflow, which enables permissionless transactions between any network participants: construction, storage, and execution. First, the agreement clarifies the rights and obligations of both parties; the developer then programs these rights and obligations electronically; and finally, various conditions contained in its terms may trigger the automatic execution of the contract.
We’re now going to go through in more technical detail the practical evolution of smart contracts, where we’ve been, where we are, and where we are going from here.
I. Smart Contract 1.0 — Bitcoin script and its limitations
“Script” is essentially a combination of instructions. The scripting system used by Bitcoin in trading is somewhat akin to assembly language. But the script is based on a coding vocabulary that most people cannot understand: its stack-based, with no LOOP statement, no state machine, opcodes divided into constants, processes, control, stack operations, arithmetic operations, bit operations, cryptographic operations, reserved words, three internally used pseudo instructions, etc.
Without delving into the particulars, suffice it to say that due to language limitations, the development of Bitcoin’s smart contract capabilities are quite limited. In fact, its own white paper states some specific limitations:
1) Lack of Turing completeness. Lacking LOOP statements, the design avoids infinite loops, but it also poses obstacles to smart contract programming.
2) UTXO scripts do not provide fine-grained control over the number of withdrawals from the account. This is due to the indivisibility of UTXO. For example, if Alice has 1 Bitcoin, and she wants to send Bob 0.5 Bitcoin, she must create two transactions: the first sends 0.5 Bitcoin to Bob and the second refunds 0.5 Bitcoin to herself
3) Lack of state. Bitcoin only has two states: the spent and the unpaid. This leaves no room for other internal states of contracts, making it difficult to implement multi-stage option contracts.
4) Unable to see the data of the blockchain through the script For example, block hashes, random numbers, etc., this flaw makes the scripting language not communicate well with transactions.
II. Smart contract 2.0 — Ethereum smart contract virtual machine and its defects
Since Ethereum emerged much later than Bitcoin, it has made leaps of improvement towards the functionality, positioning, and design architecture of smart contract platforms, while avoiding the defects of Bitcoin script. Vitalik and company have brought our vision of a scalable, enterprise-ready smart contract platform much nearer to reality — especially with their creation of the Ethereum Virtual Machine (EVM). Virtual machines play an integral role in the successful implementation of smart contracts, as they allow any network participant to access and run a smart contract’s code while securing the integrity of that contract. In other words, anyone can execute the contract, but no one can violate its design or change its intended outcomes.
According to Ethereum’s public platform, the design goals of EVM include the following:
1) Simplicity. The opcode and data types are as few as possible, and the virtual machine structure is as simple as possible.
2) Clear result. There is no room for ambiguity in the specification statement, and the result should be completely deterministic. In addition, the computation steps should be accurate so that the consumption of Gas can be measured.
3) Space saving. EVM components should be as compact as possible.
4) Designed for blockchain. Applications built on EVM should be able to handle 20-byte addresses, as well as 32-bit custom encrypted values, with modulo operations for custom encryption, read blocks, transaction data, state interaction and other capabilities;
5) Safe and friendly. Not easy to be exploited by hackers, yet easy to build a set of Gas consumption cost models and also easy to optimize.
These are all advantageous principles that serve as a solid foundation for the real world implementation of smart contract platforms. There are a few other salient features of the EVM worth mentioning before we go onto imagine its fuller capacities:
1) A distinction between temporary storage and permanent storage. Memory exists in each instance of the VM and disappears after the execution of the VM, while storage exists in the permanent blockchain state layer.
2) Adopts a stack-based architecture (like Bitcoin).
3) The machine code length is 256 bits (or 32 bytes).
4) Use of variable, scalable memory size.
5) No limit to the size of the stack.
6) 1024 call stack depth limit.
7) Instruction execution charging mechanism.
However, like any technology the EVM has growing pains. Beyond reworkable kinks, the EVM has a few defects that limit both its present functionality and its future-facing potential:
8) Using 256-bit integers results in serious performance degradation. Most current processors primarily support 32-bit or 64-bit integer arithmetic. As a result, most devices, unable to support 256-bit operations, slow down the network speed dramatically.
9) Missing standard libraries and tool libraries. In the development of their smart contract platform, Ethereum developers realize that no standard library presents in their language, Solidity. They can only copy and paste the code from some open source software. Firstly, the security of these codes is not guaranteed, and people may modify the code unwisely for smaller Gas consumption, which may introduce more serious security issues to their contracts.
10) Difficult to debug and test. This problem not only presents a design flaw of EVM, but also relates to its difficulty of implementation. The only exception that EVM can throw is OutOfGas, and there is no debug log or external code available.
11) Floating point operations are not supported.
12) Poor security. Since the overflow of mathematical operations is not well handled, there are often “one hundred million dollar code losses.” And because there is no sandbox-style security isolation, it has recently been said that the EVM has completely broken by a “nuclear bomb” of security exploitation.
13) Unreasonable billing, the high cost of application. EVM not only makes writing good code difficult, it also makes it very expensive. For example, storing data on a blockchain requires a lot of Gas. This means that the cost of caching data in a smart contract can be very high, so data is often recalculated each time the contract runs. As the contract is continuously executed, more and more gas and time are spent on repeatedly calculating the same data, and after all that, the cost of the code cannot be simulated adequately offline.
14) Only limited storage. No consideration for secure docking of external resources such as IPFS, etc.
Due to the above-mentioned limitations and the slow consensus, so far Ethereum has not seen any truly killer apps, beyond erc-20 ICO tokens, which have operated by and large as vacuums of money and time.
III. Smart contract “3.0”
The consistent execution of smart contracts must derive from the deterministic nature of its main blockchain’s execution results, which means that all transactions must be handled strictly by their chronological order (total order).
Many of the public chains that have been launched now support smart contracts, but after careful analysis of their structure, most of them have not overcome the above-mentioned defects of Ethereum, let alone true innovation.
Some projects that claim to be “blockchain 3.0” have smart contract platform that can’t measure up, even to the defects of Ethereum.
These projects (such as DAGs or sharding projects) mainly want to solve the problem of transactions per second (TPS), but their smart contract platforms only superficially address the complicated technological problems we face in this space, and they do not solve the profound and diverse needs of smart contracts.
A Directed Acyclic Graph (DAG) cannot serve as a suitable smart contract platform because of the technology’s uncontrollable duration of transactions, as well as its lack of a global ordering mechanism, which makes it difficult to establish the necessary consistency of an account status model.
Sharding technology, too, focuses on solving TPS performance problems, but in doing so sacrifices a number of much needed performance aspects, and ultimately neglects the security and consistency that are the core elements of decentralized technology. Sharding tech is still in its infancy. Vitalik proposed the concept of sharding very early in his own thinking. Yet even with the support of the powerful Ethereum Foundation, no sharding implementation has been released so far. This is because state inconsistency, synchronization, and storage are as problematic for sharding as they are for DAGs.
At present, many agree that Zilliqa offers a good approach to sharding. However, it is not a good solution to the consistency problem: it cannot support state sharding. Zilliqa’s white paper has stated that its smart contract language is not Turing complete. The language they use is called Scilla, which is unknown and without a backing ecosystem. Moreover, Zilliqa can only perform particular kinds of payment transaction, like Bitcoin. In face, one could argue that Zilliqa does not support smart contracts whatsoever.
Since blockchain applications are mainly built around smart contracts, the next (“3.0”) generation of smart contract engines must adapt to real-life needs, such as multi-scenario terms, multi-level governance, scalability, transparency, security, consistency, community-accountable, and so on.
Cypherium is the only decentralized technology that meets these real-world requirements of a third generation smart contract platform.
IV. Cypherium’s Innovations
By way of introduction, here are some features of the Cypherium Virtual Machine (CVM):
1) Based on Java. The Java language has the largest developer community in the world. There are a large number of third-party libraries on the network for quick development and use. There are already many powerful IDEs available, such as IntelliJ Idea, Eclipse, VS Code, etc. Running on javascript allows for high portability, support for floating point operations, and easy CPU optimization. And, of course, there’s all those killer apps.
2) Hierarchical calculation. At present, all known blockchains handle smart contracts in unified deployment, with unified computing and unified consensus processing. In real life, because of the different application scopes, the power capacities of all of our computing devices are quite varied. Cypherium allows all of these computing devices to run the CVM, without affecting the consensus processing of the blockchain’s computation results. Cypherium separates the calculation of the smart contract from the consensus of calculation results, which allows the network to categorize computation according to the power of the particular device. Nodes are only responsible for PBFT consensus on all computation results to ensure consistency. This design allows the Cypherium chain to adapt to a wide range of application scenarios, and apply smart contracts at multiple layers. For example, the mainframe can develop complex contracts with huge amounts of computing; PC nodes can develop contracts suitable for PC computing; mobile devices can run smart contracts for mobile devices; and so on.
3) Native 64-bit integer support and fixed-point representation. The CVM has been implementing native acceleration processing on 64-bit integer and fixed-point operations according to different CPU types, thereby improving the computing speeds of all smart contracts.
4) Support for runtime and compile-time security checks. The risks of Ethereum smart contracts come mainly from one of two sources: the vulnerability caused by the flaws in the design of the smart contract language itself, or more importantly, the code loophole caused by the coders’ unfamiliarity with the smart contract language. To avoid these problems, the CVM provides an automatic security check mechanism during both compile and execute phases, checking for buffer overflows, stack overflows, excessive computation, excessive memory consumption, and unsafe external requests. Therefore, the reliability and security of the execution of the smart contract are guaranteed, and the robustness of the whole system is ensured to a large extent.
5) Transparent billing mechanism. Cypherium only charges the computing workload, memory consumption, and storage capacity, and can provide external tools for calculation. Users can clearly calculate the GAS cost without accessing the network. If the network is congested, the user can pay a fixed rating priority fee. The priority fee (temporarily set to an exponent of 2, depending on the appropriate level,1, 2, 3, 4, 5, or 6) is prioritized for queuing, and the fee structure is fixed and transparent.
6) Smart contracts can be updated. In the case where all relevant accounts vote to agree, the smart contract containing breached vulnerability can be deprecated, and the newly deployed contract can inherit the relevant status and data of the prior contract.
7) Fully compatible with all smart contracts in Ethereum. There may be nearly a million smart contracts that have matured on Ethereum. In order to attract these and future users, the CVM provides a fully compatible Ethereum smart contract mechanism that allows users to deploy directly to the Cypherium chain without any code changes. The logic and results are exactly the same.
8) Enhanced security. All operations Cypherium virtual machines are executed under sandbox isolation, and internal procedures will always provide its own operating status to an external monitor. If unforeseen circumstances are found, such as attacks, infinite loops, the occurrence of astronomically high numbers (often caused by memory overflow), the CVM will immediately halt its operation. This design guarantees the normal operation of a given node and protects the user’s on-chain assets from accidental loss. At the same time, we perform CoSi collective signature processing on the execution result, so that the execution result state data cannot be tampered with during the network communication process, thereby effectively preventing data forgery and ensuring the consistency of our results.
9) Self-contained cross-chain atomic operation package. With the diversification of blockchain applications, there are more and more public chains, consortium chains, and private chains. However powerful a chain may be, if it cannot communicate with other chains, it will become isolated, and the application community will not flourish. Cypherium will provide interfaces to COSMOS and ILP ecosystems. Users can easily use those interfaces in smart contracts, and even can perform decentralized multi-currency trading in the contract, so that Cypherium ecosystem will grow and thrive with and active, diverse user community.
10) Secure docking and external storage package. Storage in the blockchain is very expensive, but the current IPFS solution can solve this problem well. IPFS is a peer-to-peer distributed file system that attempts to connect to the same file system for all computing devices. The system utilizes the advantages of blockchain protocol and network infrastructure to store immutable data, while automatically removing duplicate files from the network. When we talk about the underlying blockchain technology of IPFS, we have to mention FileCoin, which provides a market for host and uploader to transact, built on IPFS. The cost of storage can adjust according to the market, and the uploader can select the speed by redundancy and cost. It divides nodes into two types: storage and retrieval. Anyone can become a storage node through leasing out the extra storage space on their own disk on their own extra storage space leased out. Retrieval nodes, which need to be as close the storage nodes as possible, also require a higher bandwidth and lower latency, anasd the user will pay for the retrieval node that returns the file fastest. Cypherium-IPFS docking mainly refers to docking the above-mentioned retrieval nodes and providing query functions, so that Cypherium smart contracts can check in a timely manner the various states of software, audio, and video on IPFS, thus facilitating related transactions.
11) Nodes can upgrade new virtual machine functionality without downtime. When designing a virtual machine, the Cypherium team built the core functionalities internally, such as our instruction set, consensus mechanism, signature system, and consistency checks. Most of the functional modules, however, are externally linked. When running, the CVM will dynamically search for related modules as needed. This feature makes it easy to upgrade non-core features of the CVM, which becomes especially important for large collaborative computing scenarios. Cypherium provides a call stack depth adjustment mechanism that allows miners to make appropriate adjustments based on node performance and user-facing population.
12) Functionality modularization. Most of the current blockchain designs use unified computing of all smart contracts. In hard-copy contracts, different contracts often correspond to different application user groups. For example, gambling contracts often only correspond to fans and gamblers, and option contracts often only correspond to enterprises employee groups. Accordingly, different contracts should correspond to components with different computing capabilities. The Cypherium team separates the calculation and consensus consistency by design. Nodes are responsible for the results of the operation. This makes it unnecessary to require all nodes’ code modules to be the same. The nodes can select relevant functional modules according to their own user groups. These functional modules can run without permission on the test network, but in order to run on the official network, they must obtain the official certification of the Cypherium organization. However, the verification node must be fully functional to ensure consistent execution results. In this way, users can participate extensively in the development of the virtual machine and its smart contracts, and they can release smart contracts on the test network, which can form a functional component to be bought and sold within the community ecosystem, so that our functions grow more and more powerful, offering the best possible experience of a smart contract platform.
V. Unique Use Cases and Outlooks for the Cypherium Smart Contract Platform
There are many application scenarios in the blockchain. We don’t want to list them one by one here; if you have reached the end of this article you’ve been through enough lists already. Cypherium supports common applications, of course. But before closing there are a few use cases and scenarios that Cypherium innovations enable uniquely:
1) Decentralized exchanges. Taking full advantage of our smart contract cross-chain features, plus our order record database, a cutting-edge decentralized exchange can be developed through the APP interface.
2) Software, audio, and video copyright transactions. As mentioned above, Cypherium can query the content information in IPFS, which lays a solid foundation for external copyright transactions. It can be used easily and effectively in smart contracts for timely state management, query, and transaction.
3) Medium and large-scale collaborative computing (such as Bitcoin joint mining, meteorological calculation, artificial intelligence collaborative computing, etc.) This part (which we consider to be the most exciting) has not been tried in the smart contract space. Cypherium provides a new opportunity for everyone to use their own computers to work together, and automatically calculate the cost and distribute profit to participants.
4) Bill transaction. The blockchain can solve the problem of the authenticity of bills, deeds of sale, and other forms of provenance. From the issuance of a bill, all the business participants of the whole network are broadcasted. When checking whether the digital ticket information is transferred or tampered with, the blockchain can provide an undisputed proof of consistency. At the same time, the value of the bill can be transferred efficiently and conveniently. By constructing a pool of users hosted in smart contracts, new business scenarios such as real-time financing may also come into being. Bills often have the customization of payment systems, such as specifying a bank for hosting, etc., which requires very complex customization processing. Because Cypherium ‘s componentization design, separation of calculation and consensus, the network can adapt well to this complex customization. We are better equipped to connect actual businesses to their consumers and customers, thus further eliminating the back-to-back and flying of bills, while simultaneously eliminating some mediation chaos.
In closing, let’s not consider this matter sorted. Rather, in order to see smart contracts play the role that they should over the next 5, 10, 50 years, we must really listen to the needs of real world businesses, and we must be honest with ourselves regarding our proposed decentralized solutions. At Cypherium, we have been working tirelessly not only to understand the shortcomings of Bitcoin, Ethereum, and other major distributed ledger technologies, but also to imagine beyond the scope of their debugging. And we will continue to do so.
