IOST Testnet 2.0 Everest Launches — 19th Dec 2018
We are excited to announce that IOST Testnet v2.0 Everest is launching today!
This is the final version of the IOST Testnet before the launch of Mainnet in February 2019. As this is the final build before Mainnet launch, Everest 2.0 is highly analogous and includes all of the essential functions of Mainnet v1.0. Everest 2.0 has already begun utilization by third-party developers and running dapps. We welcome all developers to test & run IOST Everest v2.0!
What’s in Everest v2.0?
- IOST Economic Model
- PoB Consensus
- Smart Contract System
- IOST Virtual Machine (IVM)
- High Performance Storage Layer
- Decentralized Network layer
1. IOST Economic Model
1.1 Resources abstraction
If we think about what comprises a blockchain network, the list includes all running nodes/computers, the network that connects these nodes, and all data that’s processed and stored by each node. Every transaction on the blockchain consumes resources, and each blockchain needs to have mechanisms for managing the usage of these resources.
EOS network has abstracted these computational, network, and storage resources as CPU, NET and RAM. In Ethereum, all these resources of the network are bundled as one resource — GAS.
Having three separate resources to configure is making the system complex and hard to use. But having one computation-network-storage bundled resource is making the bandwidth and storage utilization really low.
In reality, the applications are either CPU-sensitive or storage-sensitive. Computing and network resources are always used jointly. So we integrated the computation and network resource as iGAS, and re-designed the storage resource as iRAM accordingly. Our resource model is a dual-resource iGAS-and-iRAM model.
By having iGAS-and-iRAM resource model, we enhanced the utilization rate of both computational and storage resources and lowered complexity and barriers for users.
1.2 Transaction Scheduling Model
In the Highest-Fee-First-Serve (HFFS) model, transactions are processed by block producers (or miners) in the order of their transaction fees. When the network is congested, users can pay higher fees to get their transactions processed faster.
In the First-Come-First-Serve(FCFS) model, transactions are processed by block producers (or miners) in the order they are submitted. If the network is congested, transactions needs to wait in line and may get dropped over time. With this model, there is no way to guarantee transactions will be processed.
In the IOST transaction scheduling model, we use a HFFS model without transaction fees. IOST generates iGAS for a user when the user stakes IOST tokens, which is then produced at a stable rate every day. The gas generated for a user will not be diluted (discussed in 1.3). Users can use iGAS to send transactions and get transactions processed faster at a user’s discretion. Thus in the IOST scheduling model, users can have free transactions and can also adjust transaction processing order.
1.3 No Resource fluctuation
DPoS based blockchain EOS is facing a CPU crisis. The available CPU on the network fluctuates tremendously and makes EOS simply unusable.
Observations of EOS:
- You don’t use any resources and your CPU is fully used and all of a sudden you cannot do anything.
- You spend $100 to stake for CPU and after playing a few rounds of a cards game, you are out of CPU.
This is why several EOS token Leasing services have emerged, such as Chintai, CPU Emergency, EOS Bank etc to mitigate this severe issue.
IOST uses a different staking approach. In the IOST staking model, the system is designed to make user’s available resources NOT diluted or fluctuate. Any users’ available CPU and NET resources are stable. The generation rate of iGAS is fixed. 1 IOST is generating a certain amount (currently 10,000) iGAS per 24 hours. On the other hand, EOS CPU generation rate fluctuates from 0.1 to 120 milliseconds CPU time per 24 hours. EOS CPU variation is over 1000 times and makes user experience unpredictable. Our fixed-rate generation model makes transaction experience stable.
2. PoB Consensus
IOST’s consensus algorithm — PoB — includes a more decentralized committee election process than current DPoS systems while still maintaining the scalability benefits and censorship resistance. Our design ensures a voting and committee formation process where most nodes are qualified for block production (instead of only the top few nodes) and where nodes with more votes are assigned a higher probability to produce a block. To achieve this, we do not use the voting result as the only factor for selection. Instead, we introduce a point system (Servi) to select and rotate members of the committee.
2.1 Servi Committee
In each round, all candidates get Servi proportional to their votes. Ranked by Servi, the top nodes will form a committee who are in charge of the block production for the next round. All selected committee members will have their Servi balance reduced by the balance of the last node. In other words, the node with the least votes will have its Servi reset to zero, and the other nodes will lose the same amount.
2.2 Frequent Rotation
The committee rotates once every 10 minutes in the IOST network. Due to the Servi clearing mechanism, there may be hundreds of different nodes selected to participate in the committee every day. In fact, any qualifying node will ultimately produce a block due to the rotating election process. This results in a highly decentralized version of DPoS where, instead of a fixed, small number of “super nodes” who control the network, hundreds- potentially thousands — of different “Servi Nodes” on the IOST network will be producing and validating blocks. The system becomes even more dynamic as a result of voting changes.
While this design ensures decentralization of the block production process and fairness throughout the network, it does not compromise the benefits of a DPoS system that enables high scalability and throughput speeds.
3. Smart Contract System
IOST has designed a new smart contract system with flexible and powerful control, with highlights as follows:
3.1 Plug-and-play Multi-language Support
IOST has implemented multi-language smart contracts. Currently, we are supporting JavaScript with V8 engine and native Golang modules to handle high-performance transactions.
3.2 Flexible Access Control
Transactions in IOST now support multiple signatures. Also IOST smart contracts can check the call stack, and can answer questions such as “Who invoked this ABI?” Smart contracts also have special permissions control, such as upgrade and removal. IOST uses fine-grained user-level access control on upgrade and deletion of smart contact. This largely reduces the pain of smart contract management present on Ethereum and similar platforms.
3.3 Result of Consensus Receipt
After execution, smart contracts will generate a Receipt into the block and seek consensus. Users can then use remote procedure calls (RPC) to track Receipts of on-chain transactions, which creates transparency and accountability for the entire network.
3.4 Event Topics Subscription
Besides the on-chain Receipt feature, which can be used as a proof of transaction, IOST also supports Event feature which is stored off-chain. IOST Event is implemented in system level; there are different Event Topics and users can subscribe to different topics. Topics include different lifecycle status of transaction, block, smart contract, and block producer, and this makes blockchain accessible and informational.
4. IOST Virtual Machine (IVM)
IOST has designed its virtual machine (IVM) with the principles of ensuring elegance, easy-of-use, and security. After researching the pros and cons of different versions of EVM, EOS VM, C Lua(used in Everest v0.5) and V8, our team have resolved many design issues that present in EVM and EOS by building the IOST VM based on the V8 engine. The core of IVM is VM manager, with the following features:
4.1 Unified Entrance
VM Entrance interfaces external requests from other modules, including RPC requests, block validation, transaction validation etc. The work received from entrance is handed off to VMWorker after pre-processing and formatting. It gives unified entrance for all requests.
4.2 Efficient Lifecycle Management
In IVM, the number of workers, aka VMManager threads, are set dynamically based on virtual machine system load resulting in efficient reuse. Within the workers, JavaScript hot launch and persistence of hotspot Sandbox snapshots help reduce frequent creation of VMs, and avoid heavy load in CPU and memory when the same code is loaded. This increases the throughput of the system, allowing the IOST V8VM to achieve high performance even when processing contracts with high transaction volumes, such as the fomo3D application.
4.3 Fast State Access
VM manager has an unified interface with State Database. This ensures atomicity, prevents partial updates to the database of each IOST transaction, and denying the entire transaction when there is an error of insufficient funds. At the same time, two-level cache is achieved in the State Database before being flushed to RocksDB. This ensures less access time for different versions of data, and optimized performance for temporary data.
4.4 Ensuring Security
4.4.1 The IVM underlying architecture implements the JavaScript sandbox based on the V8 Isolate feature, and strictly limits the system call, ensuring complete isolation and secure execution of the contract.
4.4.2 IVM disables a series of functions and class libraries with uncertain time and space complexity. They will even generate exponential-level calls with different input parameters, such as RegExp, Math part methods, ArrayBuffer, Reflect, Proxy, etc. We also remove most of the high-risk JavaScript functions, such as eval and Function, etc.
4.4.3 In addition to the user-set iGAS and iRAM usage limits, IVM also sets the maximum CPU time and maximum memory usage limit for each contract execution to prevent malicious attacks.
4.4.4 IVM rewrote all standard libraries of JavaScript, adding iGAS stats for each standard library function to prevent malicious attacks using standard library functions.
4.4.5 IVM grammar tree level disables the ArrayPattern, ObjectPattern and other syntax, rewrites the SpreadElement, TemplateLiteral and ordinary binary operations to more accurately charge iGAS.
5. High Performance Storage Layer
IOST has implemented a storage layer with Multiversion Concurrency Control (MVCC) cache. Specifically, the IOST storage layer offers:
5.1 Multiversion Concurrency
Due to the paradigm of data handling on blockchain, we implemented MVCC cache to process requests and cache them concurrently in memory. This improves usability and performance. In the presence of block-forks, we do not need to roll back the state; we can directly access the state from cache.
5.2 Simplicity
The storage layer is the final persistence of data. We adopt the simplest key-value database form, and achieve access to different databases on different service level agreement (SLA) scenarios.
5.3 Dynamic Access
Our storage layer has commit manager implemented for the out-most layer, this handles the management and maintenance of multi-version data. Higher layers, therefore, can treat the interface as a typical database and switch to any version at will.
6. Decentralized Network Layer
IOST implements a fully decentralized network topology that achieves fast discovery of nodes and efficient whole-net broadcasting of transactions and blocks. At the same time, we limit redundancy within the network while achieving secured data transmission among the nodes. The highlights are as following:
6.1 Discovery and Connectivity
We secure all data with a TLS layer on top of TCP. To better utilize each and every TCP connection, we adopt stream-multiplexing to send and receive data, dynamically establishing multiple streams between nodes and maximizing the bandwidth. With nodes, we use Kademlia to maintain their gateway tables. This means IOST can prevent eavesdropping and unwanted manipulation of data across the network.
6.2 Fast Transmission
To reduce bandwidth and to speed up data transmission, we serialize all structured data with Protocol Buffers, and compress them with the Snappy algorithm. During our tests, this integration reduced the size of the data by over 80%.
6.3 Accessibility
IOST network layer uses Universal Plug and Play (UPnP) Protocol to achieve LAN penetration. UPnP is different than other solutions, such as UDP Hole Punching and STUN; it does not require port exposure without publishing the server. This means our user can use commodity computer to access our network and communicate with other nodes, without having to use a cloud server. We want make sure our network is always accessible to any user.
Conclusion
Everyone working on the IOST blockchain are very excited to have reached Everest v2.0 in a comprehensive shape. We’d like to thank our developer community for working around the clock and around the globe. We look forward to continuing to deliver on the promise of real-world blockchain technology with our mainnet launch in 2 months.
We encourage you to get involved and join with our Testnet ecosystem. Developers and projects can now prepare for Mainnet DApp launches on Everest v2.0. As always, let us know your thoughts and we look forward to continuing to improve the IOST blockchain.
Developer’s one-stop-site: https://developers.iost.io
Developer Community: https://invite.iost.io
Happy hacking!
