ICON FoundationThe ICON Foundation has introduced a roadmap for its next-generation blockchain software architecture. It is, at least initially, calling this ICON 2.0. It believes this represents a major upgrade in capabilities to the current ICON platform.

Unlike most new platform overhauls, ICON 2.0 does not expect a requirement for a bridge or token swap. The objective is to make the upgrade seamless to current users, while providing the improved functionality.

ICON 2.0 platform and DeFi

ICON 2.0 uses a wholly rewritten blockchain engine written in Golang.  ‘Goloop’ will improve the ‘blockchain experience’ over the existing Python-based loopchain. This will include betters speeds, stability and scalability.

Significantly, the updated platform will launch with interoperability features which can support and power cross-chain DeFi solutions. This matters because DeFi looks like being a major driver of the next wave of cryptocurrency adoption and blockchain use cases. At launch, the ICON Foundation is committing to deploy necessary smart contracts on high-profile blockchains. It will also run the relayers.

New ICON 2.0 features

ICON 2.0 contains multiple enhanced core features. These provide an opportunity to redesign some of the current blockchain’s features:

  • interoperability between blockchains, including the ability to earn ETH as fees
  • support for and improved Python programming
  • native Support for Java Programming
  • a new P2P Protocol
  • Fast Sync
  • an Object Merkle Patricia Tree
  • performance enhancements
  • vote spreading
  • IISS 3.1 (ICON Incentive Scoring System).

BTP is a general purpose interoperability protocol. It will become standard on ICON 2.0 with a specific initial use case in mind – supporting interoperability with other public blockchains in order to support cross-chain DeFi solutions. At launch, any individual or group may run a private relayer with their own fee system (if they do not wish to adopt the ICON2.0 approach). The fees generated by cross-chain transactions – based on the amount of ICX staked – will pay out in the asset sent. For example, if somebody sends ETH to the ICON blockchain, relayers will earn ETH as fees.

Improved programming offers a pure Python execution environment. This will:

  • operate in a separate process from the consensus engine
  • can execute 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.

SCORE developers can, alternatively write programs using the Java programming language. SCOREs written in Java will run on the Java VM: SCOREs can execute securely and stably without requiring an audit process (which has proven to be 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 this capability. Furthermore, Java SCOREs can interoperate with existing Python SCOREs – through inter-SCORE calls. This makes for a smoother transition to the Java SCORE environment.

P2P, Fast Sync, OMPT, performance enhancements

In ICON 2.0 the new P2P Protocol will synchronise state between nodes. A new node will use both gossip and multicast to deliver messages. This requires a structured network supported by community members. In most cases, messages will deliver through the multicast protocol using redundant paths. But they can use the gossip protocol in exceptional cases, for example discovering the last state, recovering missed messages, etc.

Nodes need, normally, to synchronise all historical blockchain data before joining the consensus or querying the last state. yet most users are not interested in historical data. For those users, ICON is planning to support the ‘Fast Sync’ feature. This can provide most services, except querying old transactions and DApps using historical data, in a short time. Representative nodes may use this feature for fast start-up. But they will still need to synchronise all the historical data.

Most Merkle tree implementations calculate hashes of stored data at adding an entry. In addition this offers an interface to store bytes. Object Merkle Patricia Tree (OMPT) calculates hashes only when required; until then it manages all data as immutable objects. With this scheme, OMPT calculates the hashes at the end of the execution of all transactions in the block.

With Python implementations, it is hard to utilise multi-cores which use multiple threads. This is because of the global interpreter lock (GIL). Go provides ‘goroutines’ to manage threads efficiently. Although the runtime supports garbage collection, it does not incur any big response delay for collecting garbage. In turn this reduces response time in handling most user requests and enables handling more user requests concurrently when compared with Python implementations. The result: performance enhancement.

Vote spreading, IISS3.1

Vote Spreading in ICON 2.0 is a solution for systematically decentralising a DPoS network, where inactive voters have their ICX spread to all top 100 P-Reps. This should:

  • solve the issue of vote stagnancy
  • allow active ICX holders to have the greatest impact on governance.

ICON 2.0 has brought the freedom to initiate a cleaner, more easily understood economic design. The basic structure of IISS 3.1 follows the structure of IISS 3.0 (already discussed in the ICON community). The IISS 3.1 design 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.

Enterprise Times: what does this mean

ICON claims to be one of the larger decentralised networks. ICON’s blockchain is already in used for real-world mainstream applications in banking, healthcare, education, etc. Its attractions include that it is:

  • scalable – for both public and private blockchain use cases
  • employs a transparent governance system and AI to create a sustainable, decentralised ecosystem.

In order to make the development process transparent, and to share all the progress with the community, the ICON Foundation has decided to share all development processes on Github. On the latter, will appear the source code of the next generation loopchain. This, called “goloop”, is based on Go and been in development for over a year. The significance is that any community member can verify the code and technology of the ICON team on this Github Repository.

New blockchain architectures are not uncommon. Major upgrades which do not require major changes to encompass previous versions – as ICON 2.0 promises – are. Note, however, that ICON 2.0 is not expected to be complete before Q2 2021. That is some time to wait.

Previous articleFocus your business on people post COVID
Next articleThe Access Group launches Access People
Charles Brett
Charles Brett is a business/technology analyst consultant. His specialist areas include enterprise software, blockchain and enterprise mobility tech (including metering). Specific industry sectors of interest and experience include finance (especially systems supporting wholesale finance), telecommunications and energy. Charles has spoken at multiple industry conferences, has written for numerous publications (including the London Times and the Financial Times). He was the General Chair of the bi-annual High Performance Systems Workshop, 2005. In addition he is an author and novelist. His Technology books include: Making the Most of Mobility Vol I (eBook, 2012); Explaining iTunes, iPhones and iPads for Windows Users (eBook, 2011); 5 Axes of Business Application Integration (2004). His published novels, in the Corruption Series, include: The HolyPhone Confessional Crisis, Corruption’s Price: A Spanish Deceit and Virginity Despoiled. The fourth in The Corruption Series - Resurrection - has is now available. Charles has a B.A. and M.A in Modern History from the University of Oxford. He has lived or worked in Italy, Abu Dhabi, South Africa, California and New York, Spain, Israel, Estonia and Cyprus.


Please enter your comment!
Please enter your name here