Development

GitHub metrics:

Developer activity (from Coinlib.io):

Komodo released the version 0.1.53 of #AtomicDEX

Fixes:

PIN setup Removed timer Pricing logic Improved application logic

Features:

New language support Traditional Chinese Simplified Chinese German French Scroll indicator on ToS page Quote Tweet

An Overview of Simple Payment Verification

Simple Payment Verification — better known as SPV or SPV clients — allows applications to make transactions on a blockchain without having to download the entire ledger. Instead, the application simply needs to sync the block headers of the blockchain.

(A block header is the cryptographic digest that results from six pieces of data: the version of the BTC code base being used, the block hash from the previous block in the chain, the Merkle Root of all of the transactions in that block, the time stamp of that block, a condensed form of that block’s target nonce known as the “bits”, and the nonce of that block.)

It’s important to note that Simple Payment Verification was described in Section 8 of the original Bitcoin white paper, authored by the person(s) known as Satoshi Nakamoto.

While this SPV system was detailed extensively in the white paper, Bitcoin Light Clients were not implemented until 2011 when the Electrum wallet was developed. This made it possible to develop mobile wallets, allowing users to send and receive digital assets from a smartphone.

According to Bitcoin.org, this SPV approach allows Bitcoin SPV clients to scale “linearly with the height of the block chain at only 80 bytes per block header, or up to 4.2MB per year, regardless of total block size.”

This is significant for three reasons. First, linear data inflation is generally acceptable, given the strength of modern smartphones and computers. Second, at only 80 bytes per block header, Bitcoin SPV clients won’t even hit 1 GB of data until the end of the year 2038. Third, block headers are always 80 bytes, even if every block is filled to the brim with transactions and data.

Limitations With Current SPV Implementations

While SPV is an essential technology for all blockchains and digital assets, there are still limitations.

In the long run, even Bitcoin SPV clients will hit a data bottleneck for mobile devices. If Bitcoin is to remain a global means of exchange and store of value, it must remain accessible from mobile devices for many centuries to come. Bottlenecks in the distant future are still bottlenecks.

In the short run, Bitcoin SPV clients still require a sufficiently large amount of hard drive space and memory that simple electronic devices cannot host a client. This prohibits Bitcoin and other blockchains from integrating with the Internet Of Things (IoT). If small devices, like watches, headphones, barcode scanners, and point-of-sale devices can’t host blockchain SPV clients, than it’s hard to imagine how blockchain can truly scale and integrate into the future IoT.

Further, the data parameters mentioned above don’t hold true for all blockchains. For instance, the block headers for Zcash and all Zcash forks, including Komodo and all Smart Chains launched with Komodo’s Antara Framework, are more than 80 bytes. Block headers on these chains are just under 2 KB, roughly 25 times more data than block headers on the BTC chain.

This means that some blockchains, including Komodo, and all Antara Smart Chains, run the risk of hitting a data bottleneck much sooner than do Bitcoin or ordinary Bitcoin forks.

Or at least they did, until last week when Komodo’s Lead Developer James ‘jl777’ Lee developed nSPV — a light client for blockchains that is up to one-thousand times more efficient than existing SPV methods.

nSPV: The Next Generation of Simple Payment Verification

Since the original implementation of SPV described in the Bitcoin white paper, there have been no further innovations upon SPV technology. Most projects consider current SPV methods acceptable and the limitations of SPV have not been pressing enough to inspire innovation.

This is true for all projects except Komodo. Ever since the Komodo Platform was created in late 2016, the Komodo Development Team has been solving problems in the blockchain industry that most people are not even aware of yet. This tradition continues with the development of nSPV.

nSPV is a form of simple payment verification that requires far less data than the original implementation of SPV. Whereas SPV requires a client to download the header of every block in the blockchain, Komodo’s new nSPV technology only requires clients to download 20 to 30 block headers for every desired transaction.

Even for wallets that wish to store dozens or even hundreds of UTXO — a small amount of data that represents funds on a blockchain — Komodo’s new nSPV technology is hundreds or perhaps even thousands of times more efficient than current SPV implementations.

A Closer Look At nSPV Technology

In order for a chain to have access to nSPV technology, it must be a Smart Chain built with Komodo’s Antara Framework and it must use dPoW security. Thus, in addition to dozens of customization options and a library of powerful built-in modules, there are now even more cutting-edge features for projects that build with the Antara Framework.

To gain a better understanding of how nSPV works, we first need to understand how Komodo’s Delayed Proof of Work (dPoW) security mechanism functions.

Delayed Proof of Work (dPoW) security leverages the enormous hash rate of the Bitcoin network through an extensive process of cross-chain notarizations. Komodo’s decentralized Notary Node network performs notarizations by taking a block hash from one blockchain (one of the pieces of data used to generate a block header) and saving them onto the ledger of a different, more secure blockchain. This notarization process occurs roughly every ten minutes.

nSPV leverages these notarizations to create an extremely efficient method for validating a particular transaction or some specific funds (UTXO). Rather than needing to compute all of the block headers in a blockchain to verify that a UTXO is valid, an nSPV superlight client only needs to download the block headers spanning two dPoW notarizations, which is on average 10 blocks.

Since each notarized block becomes a completely immutable history of the ledger up until that point, it is acceptable to use a notarized block as a starting place to begin verifying a UTXO via block headers. In some respects, every notarized block becomes a new beginning of the blockchain. The longest chain rule starts over again at every notarized block. Nothing that happened before a notarized block can ever be altered or changed.

To verify any particular UTXO, the nSPV superlight client only needs to download the block headers from the notarized block prior to the UTXO in question to the notarized block following the block in which the UTXO in question was created.

This is many times more efficient than the traditional SPV implementation, which requires downloading the block header of the entire blockchain, even for a single UTXO. This is true regardless of which block generated that UTXO.

With Komodo’s new nSPV technology, the superlight client only needs to download approximately 10–15 block headers per UTXO. In a worst case scenario, an nSPV client would need to download 25 to 30 block headers for one UTXO. This makes it hundreds or perhaps even 1,000 times more efficient than standard SPV clients, which always need to download every block header in the entire blockchain.

The Benefits Of nSPV Superlight Clients

There are three main benefits to this new superlight client technology: security, scalability, and efficiency.

Security

nSPV enables static HTML wallets, with no Javascript or Node.js code required. This will make mobile wallets far more secure than they are now, as Javascript and Node.js typically require leveraging external modules to function properly. Importing external modules creates dependencies and security vulnerabilities. In fact, a dependency upon an external module is precisely how Komodo’s previous wallet, Agama, was hacked in June 2019.

As nSPV is hundreds of times more efficient than the original implementation of SPV and also far more secure, this new superlight client technology is a huge value-add to all projects building with Komodo’s Antara Framework.

The nSPV static HTML wallet is still in development but developers and advanced users are welcome to download it and test it out. To learn more about these static HTML wallets, please see the nSPV documentation or visit the Lib nSPV repo on Github.

Scalability

nSPV superlight client technology allows users to send and receive digital assets on a mobile device much faster than what ordinary SPV allows. nSPV does not require any local data storage on a device’s disk drive (no HDD storage) and RAM usage is only about 3 Mb.

All of this also means that a user can store many different assets on a mobile device without constraints.With nSPV, it’s conceivable that a user could securely store dozens or hundreds of different digital assets on a single mobile device, with the ability to send and receive all of them at any time. This is the level of scalability required for true mass adoption.

Efficiency

nSPV lets users run a superlight blockchain client with just 300 Kb of data. For the sake of comparison, a typical photo taken on a smartphone is roughly 2 Mb — that’s 7 times the amount of data required for a user to start transacting on an nSPV-integrated Smart Chain.

This is especially important in IoT applications. nSPV is so lightweight it can manage hundreds of different coins on a typical 32-bit ARM SoC like the Allwinner H3 without using any external storage. Combined with Antara Modules like the Trustless Oracle, Komodo and nSPV is an ideal solution to build complex IoT systems like supply chain tracking.

All of these benefits are coming to the Komodo ecosystem soon. The Komodo Dev Team is planning on pushing this new nSPV technology live on the Komodo mainnet on October 31, 2019. After that, it will be available to all existing Smart Chain projects and also come standard for all new Antara Smart Chains.