ICON, the South Korean based blockchain network, today announced the roadmap for its powerful next-generation blockchain software architecture, which is initially being dubbed ICON 2.0, which represents a sweeping upgrade to the current ICON platform.
Unlike most new platform overhauls, ICON 2.0 is not expected to require a bridge or token swap, but will be seamless to current users, while providing superior functionality.
ICON 2.0 uses an enhanced and completely rewritten blockchain engine written in Golang. “Goloop” will provide an improved blockchain experience over the existing Python-based loopchain, including more speed, stability, and scalability than the current architecture. Most importantly, the platform will launch with interoperability features to support and power cross-chain DeFi solutions, which is clearly a driver of the next wave of cryptocurrency adoption and blockchain use cases.
At launch, the ICON Foundation will deploy all necessary smart contracts on high-profile blockchains and will also run the relayers. ICON 2.0 is expected to be complete by Q2 2021.
New Features in ICON 2.0
One of the most exciting aspects of ICON 2.0 is it contains a large number of enhanced core features, and an opportunity to redesign some of the current blockchain’s features:
Interoperability Between Blockchains, Including Ability to Earn ETH as Fees
BTP is a general purpose interoperability protocol, however, it will come standard on ICON 2.0 with a specific initial use case in mind. ICON will be supporting interoperability with other public blockchains in order to support cross-chain DeFi solutions. At launch, the ICON Foundation will deploy all necessary smart contracts on high-profile blockchains and will also run the relayers, however, any individual or group may run a private relayer with their own fee system.
ICX holders will have the opportunity to pre-register a relayer in preparation for a decentralized relayer network. There will be a minimum ICX stake requirement to pre-register, and pre-registered relayers will earn any inflation allocated to relayers and the fees generated by cross-chain transactions based on the amount of ICX they have staked. The fees earned will be paid in the asset which was sent, meaning that if somebody sends ETH to the ICON blockchain, Relayers will earn ETH as fees.
Supports and Improves Current Python Programming
This program provides a pure Python execution environment that will be operated in a separate process from the consensus engine. It can execute the already deployed Python SCOREs on the ICON network as it is. By separating the executor process from the consensus engine, ICON can handle infinite loop and instability issues of Python SCOREs.
Native Support for Java Programming
Now SCORE developers can write their program using the Java programming language. SCOREs written in Java would run on the Java virtual machine, thus SCOREs can be executed securely and stably without requiring an audit process, which has been a major pain point for developers on the current ICON mainnet. Since Java SCOREs don’t require an audit, ICON will be encouraging future developers to use the Java SCOREs. Furthermore, Java SCOREs can be interoperable with the existing Python SCOREs through inter-SCORE calls, which makes for a smooth transition to the Java SCORE environment.
New P2P Protocol
A new protocol to synchronize the state between nodes will be integrated. A new node uses both gossip and multicast protocol to deliver messages. This requires a structured network supported by community members. In most cases, messages are delivered through multicast protocol using redundant paths, but they use gossip protocol in some exceptional cases like discovering the last state, recovering missed messages, and so on.
Fast Sync
Normally nodes need to synchronize all of the historical blockchain data before joining the consensus or querying the last state. But most users are not interested in historical data. For those users, ICON is planning to support the Fast Sync feature. If it’s enabled, they can provide most services, except querying old transactions, in a fairly short time. DApps using historical data do not use this feature. Representative nodes may use this feature for a fast start-up, but they need to synchronize all the historical data.
Object Merkle Patricia Tree
Most merkle tree implementations calculate hashes of stored data at adding an entry. And also they provide just an interface to store bytes. Object Merkle Patricia Tree (OMPT) calculates hashes only when they’re required; until then it manages all data as immutable objects. With this scheme, it calculates the hashes at the end of the execution of all transactions in the block.
Performance Enhancements
With Python implementation, it’s hard to utilize multi-cores using multiple threads because of the global interpreter lock (GIL). Go provides goroutines to manage threads efficiently. Although the runtime supports garbage collection, it does not make any big response delay for collecting garbage. It reduces response time in handling most user requests and enables handling more user requests concurrently compared with Python implementations.
Vote Spreading
Vote Spreading is a novel solution for systematically decentralizing a DPoS network, where inactive voters have their ICX spread to all top 100 P-Reps. This will solve the issue of vote stagnancy and allow active ICX holders to have the greatest impact on governance.
IISS 3.1
ICON 2.0 gives us more freedom to design a cleaner and more easily understood economic design. The basic structure of IISS 3.1 follows the structure of IISS 3.0 already discussed in the community. However, the IISS 3.1 design simply divides inflation into a few different predefined categories. For example:
- P-Reps: 17.5%
- Relayers: 2.5%
- Contribution Proposal Fund: 10%
- Voters: 70%
ICON 2.0 will include a network proposal to allow P-Reps to easily adjust these inflation allocations using an on-chain and self-executing vote.
Multi-Channel Technology
Multi-channel is a form of scalability, where each DApp on ICON could instead be an application specific channel (see Band Protocol and Kava for examples of application specific chains using the Cosmos SDK). Each channel is essentially its own blockchain, sparing DApp developers platform risk while making it easy to launch their own network. The technology behind channel chains is complete for ICON 2.0, however, additional work will need to be done to productize the software after the successful migration.
Fully open-source development process
In order to make the development process completely transparent, and to share all the progress with the community, ICON Foundation has decided to share all the development processes on Github at the beginning. On this Github, you can see the source code of the next generation loopchain based on Go, called “goloop” which ICON has developed for over a year. Any community member can verify the code and technology of the ICON team on this Github Repository.
