What Is The IN3 Client?

Earning its name as a minimal verification client, IN3 (INcentivized Node Network, pronounced “in-cubed”) is the smallest client only needing 300kb of storage, making it easy to integrate into IoT and mobile or web applications. The IN3 client is a crypto-economic, non-synchronizing, and stateless blockchain client with minimal resource requirements.

Click here to access the release package.

A Primer

When Ethereum was conceived, the vision was to have a distributed peer-to-peer (p2p) network of independent nodes and access to decentralized applications (dApps) using these nodes, all without any centralized services.

In reality, the current situation for most applications looks more like the illustration below rather than the original ideal of complete decentralization. The development and use of dApps are already underway, but for several reasons, most dApps rely on remote servers to connect to the blockchain.

However, there are major issues with this centralized solution:

• There is a single point of failure: If your server is offline for whatever reason, all services stop working.
• Any hacker could simply attack this server and gain access to the service. This would be a nightmare! And please don’t say that your server is safe or that this would never happen; it happens all the time. And if it is not an attacker, your admin may simply be having a bad day.
  The process creates a paradox: We connect to the decentralized world using centralized access.

Connected Devices To The Blockchains

We set out to enable IoT devices to connect to the blockchain—to give these devices the ability to use dApps to make or receive payments for services, or to realize truly secure access management. Many of these IoT devices are based on microcontrollers, which are, unfortunately, severely limited in terms of computing power, memory, storage, and connectivity. The same also applies to mobile applications on smartphones or web applications. So, the question remains: How do we connect IoT devices to the blockchain?

To connect, we usually become a peer and start synchronizing and verifying all the network’s transactions. For a full node on Ethereum, we need about 140 GB of storage and have to constantly synchronize and verify blocks and transactions to be sure we have the correct data. That is way too much for an IoT device.

To address this issue, some developers optimized storage with the pruned node, which simply tosses older states and reduces the node to only 90 GB. It’s better, but still too much.

Once the first light client was released, everyone hoped it would finally solve the storage problem. A light client only stores the data it needs, but this comes with a price: It relies on full nodes. However, it’s still able to verify the blockchain’s data because it constantly syncs with other peers. The light client takes us down to a few hundred MB, which is good, but that still doesn’t fit on a microcontroller. Even syncing requires a constant bandwidth, and if you’re offline for a few days, it takes several minutes to catch up. Bandwidth is very expensive for mobile devices!

That’s why some developers started to use a so-called remote client: A central full node on a server (or even a centralized RPC service like Infura). However, this option brings us back to the centralized server option we mentioned earlier.

Using IN3

Establishing a secure connection to the blockchain on a small loT device isn’t easy, but that’s why we built IN3, a stateless client that can run with zero storage (except for the code and optional cache). IN3 operates without a single point of failure and is able to verify all data. In the same way a light client uses full nodes to fetch data to verify, IN3 relies on a set of distributed full nodes – and anybody can run and register such a node in the registry contract. But unlike the light client, we don’t constantly sync within the p2p network; we only send requests as needed. It’s an important difference and means that with IN3:

• We get immediate responses (no need to catch up); and
• No constant bandwidth reading the blockheaders.
  This is crucial not only for IoT devices but also apps and websites connecting securely to the blockchain. However, if anyone can run such a node, we must be able to prove and verify the data. (When we talk about data, we mean all standard JSON-RPC calls, including eth_call.)

The solution is to use minimal verification clients, which were introduced in the IN3 protocol. Such a client combines the security of a light client with the advantages of a remote client at least for the most common IoT solutions, as well as mobile and web applications.

With IN3, it’s possible to connect devices in a fully decentralized way, without a central instance, and with (almost) full security.

An IN3 client is a stateless client that can verify whatever requested information belongs to a given block and confirm that this block is, in fact, a valid block of the blockchain. The client can do this all by itself, without the need to trust any external source.

Verifying The Blockheader

IN3 is able to verify transactions and even functions calls of smart contracts by using Merkle proofs against a blockheader. But how can we be sure this blockheader is correct? This depends on the consensus mechanism the blockchain uses.

For proof of authority, there is a list of keys allowed to sign the blockheader. To verify the blockheader, we simply check if the signature was created from a key on the list. Since the signature is part of the blockheader, this is all we need (along with the correct set of validators).

For proof of work (like the public Ethereum network), anybody can create blocks as long as they are able to put enough work into it. But to know whether a block is accepted, we ask the registered IN3 nodes to pay a deposit and sign blockhashes (the hash of the blockheader). If the nodes were to sign a wrong hash, they would lose their deposit because this signed blockhash can be verified by anyone inside a smart contract. All you need is an independent node to verify that the signature is correct before it is received on the service’s end. Since anybody is incentivized to find a wrong blockhash and can receive the deposit of the signer, the same node that gave us the proof can check the signature, which reduces the number of requests. Because the client chooses which signature to accept, the server cannot cheat and sign with a different key.

Putting It On A Microcontroller

This verification allows us to put everything on a small chip like nRF52840, which only has 256 KB of RAM and 1 MB of flash memory. One of these costs about $3 and enables a completely decentralized, stateless, and verified connection to the blockchain.

Typescript Vs. C

The TypeScript IN3 client provides a library to integrate the client directly into a mobile app or a web application. It’s possible to use the IN3 client directly or simply as an HTTP-provider for Web3.js – also making it possible to easily and quickly convert existing applications into truly decentralized applications based on the IN3 protocol.

However, for IoT devices with very limited resources, this might not be an optimal solution. To address this, we are also publishing our C implementation with this release, which makes it possible to integrate the IN3 client into any program, including the firmware of microcontrollers. Depending on the edition — each differs in the functional scope and thus the resource requirements — the client can verify transactions and account information, access the state, or interact with smart contracts.

The IN3 EVM is the most resource-efficient implementation currently available. This makes the IN3 client fully capable of running on a microcontroller.

The native implementation of the IN3 client requires minimal resources. The nano edition (which only verifies transactions) requires the lowest amount of resources, only about 150KB. But even the full version (including EVM), which can enable all interactions with the blockchain, only needs about 450KB, depending on the firmware.

Stable Release

The IN3 protocol is currently live on the Ethereum mainnet and various Ethereum test networks. IPFS is supported, too. As the IN3 protocol is platform-agnostic, other blockchains like Bitcoin are in development or an experimental phase.

The TypeScript- IN3 client, the IN3 node, and the IN3 registry are published with the release version. The C-client, as well as the binding to Java, and the WASM-client are available as a beta version. A command-line application to interact directly from the console with the blockchain – without the need to install and synchronize a local client – is part of the package, too.

All software is offered under a dual license — AGPL for open-source software applications and a commercial license for all other applications.

An important feature of the IN3 protocol, the incentive layer, will first be available in the upcoming Stable II (productive) release. This will make it possible to compensate IN3 nodes for the delivery of verifiable (and thus secure) data.

The software components dealing with security and holding or managing values were audited by ConsenSys Diligence.

Roadmap

The next big milestone, which we are working on now, will be the release of the above-mentioned incentive layer. We will also publish the C version of the IN3 client as a productive release version. With this version, bindings to other programming languages like Python, Go, and others will be available. The TypeScript version will be replaced by a much more resource-efficient WASM version without any dependencies to other libraries.

Longer-term development milestones include the integration of further blockchain technologies, level 2 technologies, and other verifiable data services into the protocol.

Try It!

The source code is available within our GitHub repository and you can also check out the release packages.

Thanks for reading!