ICON, deconstructed

Part III: Scalability and SCORE

In the last two parts of our series, 1) we introduced the ICON network at a high level, 2) took a look at the differences between ICON and some of the other leading blockchain technologies, and 3) discussed the differences in the blockchain layers and the framework of ICON’s technology. In Part III, we’ll provide an overview of ICON’s scalability solutions and smart contract functionality.

Reminder: the goal for this series is two-fold. First, we want to write this series in a way that’s easy to understand for beginners exploring our project for the first time. But, additionally, we also want to provide enough depth that it can be enjoyed by more advanced blockchain enthusiasts. We’ll be releasing each part in smaller segments, so please let us know if you have feedback as we can make adjustments to the releases as we go. We hope you enjoy!

Let’s unpack these concepts now.

DPoC Throughput

Blockchain performance is often measured by transaction throughout. This measurement is typically expressed as a number of transactions per second the system can handle (TPS). As we all know, one of the biggest pushbacks on blockchain technology is its limited throughput capacity compared to legacy platforms and the perceived lack of scalability to handle mass adoption.

One of the greatest weaknesses of Bitcoin and Ethereum is an innately low transaction speed, which is why these protocols require second-layer solutions like the Lightning Network to increase their throughput. That said, we believe DPoC provides an effective solution to one of blockchain’s most salient issues — scalability.

Ethereum supports a throughput velocity of 20 transactions per second (TPS), which is significantly smaller than payment systems like PayPal (~190 TPS) and Visa (~1700 TPS). ICON, on the other hand, offers a more competitive transaction speed of ~500 TPS. Before taking a look at what enables ICON to do that, let’s explore 3 common Ethereum approaches to improving scalability.

Raiden Network: State Channel / Off-chain

The Raiden Network is “an off-chain transfer network … that aims to scale Ethereum by using state channel technology.” This means that an off-chain payment channel is opened between parties, allowing to group and process multiple micro-transactions and saving time and transaction fees. The channels are governed by multi-sig smart contracts and require updating the blockchain on creation/deletion to lock/unlock the asset.

Plasma: Side-chain

Plasma is a framework that allows the creation of “children” blockchains that rely on the main Ethereum chain for trust and arbitration. Plasma enables users to move their assets onto a “child” blockchain configured specifically to match the demand of their use case for more efficient processing.

Sharding

Sharding refers to splitting the state into “shards” (hence the name). Currently, each node in Ethereum processes stores the entire state of the blockchain. Scaling via sharding allows dividing the validation process among many nodes.

ICON blockchain architecture

The ICON blockchain architecture derives from these predecessor scalability solutions. ICON leverages multi-channel technology (i.e. sharding into many channels) to provide interoperability functions, which we will explore later. The state of SCOREs, smart contracts in the ICON ecosystem, is likewise sharded, so that SCORE states are independent of one another. The 500 TPS speed provided by DPoC is scaled out to each channel, improving overall performance.

Smart Contract on Reliable Environment (SCORE)

Since we touched on SCOREs several times already, let’s explore these enhanced smart contracts in greater detail. SCOREs offer the following advantages over smart contracts running on protocols like Ethereum:

• SCORE (Smart Contract on Reliable Environment) is a smart contract running on the ICON network. Recall, a smart contract is a collection of codes (functions) and data (states) that resides at a specific address on the blockchain. SCORE can be regarded as a state transition machine that a user could implement a service logic such as token transfers. The state transition is triggered by sending transactions to an address that the SCORE resides. Any service logic that can be modeled by a state transition machine can be implemented in the SCORE code.
• SCOREs have a versioning capability, which means that updating them is extremely easy and fast. This is conducive to iterative development, which is the process of designing, developing, and testing code in repeated cycles.
• Within a node, the ledger and smart contracts exist in separate domains, which increases work efficiency.

The last of the advantages ties into our discussion of how Cosmos separates the application and protocol layers. Since applications built on ICON are based on smart contracts, separating blockchain processes (e.g. adding blocks) from smart contract processes (e.g. versioning) makes sense on a node level. Let’s now look at how this separation affects developers.

Building applications on ICON

Separating the protocol and application layers is also useful for developers looking to build on ICON. Before delving deeper into developing applications, we need to learn about remote procedure calls — the technology that enables developers to “talk” to nodes.

Remote procedure call (RPC)

Communicating with an ICON node requires making a remote procedure call (RPC) to the node. An RPC is nothing more than a request asking a remote server to do something for you that does not require a response from the server; in this analogy, the server is an ICON citizen node. The type of RPC protocol used in ICON nodes is known as JSON-RPC.

ICON SDK

The ICON SDK enables building DApps on ICON by providing a framework for developers. Beyond allowing developers to define the state of their applications, the SDK comes equipped with functionalities to create wallets, transfer ICX, and deploy IRC2 tokens built on ICON.

The ICON SDK/RPC structure allows DApps to technically be programmed in any language. However, the ICON SDK currently supports four programming languages: Java, Python, JavaScript, and Swift.

The diagram above depicts the separation between the protocol and application layers in ICON. Applications developed with an ICON SDK use the JSON-RPC protocol to make requests to Citizen nodes. Citizen nodes propagate requests between each other and the validator nodes using the gossip protocol. Validators receive the request and reach consensus on a block that encompasses the request.

The way ICON separates the protocol layer (LFT) from the application layer (SDK and RPC) provides developers with a lot of flexibility to build DApps. It’s important to note that while ICON DApps can be programmed in any of the four officially supported languages, SCOREs have to be written in Python.

However, smart contract development with Python is still a better developer experience than building on Ethereum, which requires programmers to learn Solidity. In contrast, Python is one of the most simplistic of the most popular programming languages and enables easy idea prototyping. It is also the preferred language for domains like machine learning and data analytics, both of which have strong synergies with the future of blockchain technology.

At this point, we’ve covered decentralization, as well as the architecture of the ICON blockchain and how it differs from other chains. We still have to explore blockchain interoperability, but before that, we’ll discuss governance on the ICON network in next week’s ICON, deconstructed Part IV.