Advancing nSPV: Komodo Custom Contracts Integration & Static HTML Wallets

Note: Since this blog post was originally published, "Modules" have been renamed to "Contracts", and "Antara Framework" has been renamed to "Komodo Custom Contracts." However, both might still be referenced by their original names in other blog posts or in the developer documentation.

In August 2019, Komodo introduced nSPV technology, the next generation of Simple Payment Verification (SPV). This new nSPV technology is hundreds, or in some cases even thousands, of times more efficient than traditional Electrum SPV server methods.

As development continues on nSPV, several additional features are emerging: enabling UTXO smart contracts (known as Komodo Custom Contracts) to run on mobile devices, enabling static HTML wallets, compiling nSPV to Web Assembly (WASM) to support cryptocurrency transfers from within a web browser, improving opportunities for blockchain gaming, and using nSPV to integrate with the Internet of Things (IoT).

This blog post will explain all of the new technologies that Komodo is developing alongside nSPV.

A Brief Introduction To SPV Architectures

In the previous article on nSPV technology, we described the advantages that nSPV has over traditional peer-to-peer SPV clients. This is true for Equihash blockchains like Zcash and all of its forks, including Komodo and all Smart Chains within the Komodo ecosystem, whose block headers are many times larger than those of the Bitcoin blockchain.

The large size of Equihash block headers causes the P2P SPV clients of these blockchains to run into potential bottlenecks: the need to download gigabytes of data before being able to create a transaction; a long wait time while the client downloads all the block headers from the Genesis block to the current block from the peer-to-peer network.

As a result, long before the creation of nSPV, an alternative architecture for SPV based on a Server/Client model was created. It’s called the Electrum SPV architecture, named after the most popular implementation. Most of the “Lite” wallets (also known as SPV wallets) popular today use the Electrum SPV architecture. (See this guide for a list of the best SPV Komodo wallets.)

With Electrum SPV architecture, instead of validating all the block headers from the Genesis block to the current one, SPV clients (light clients) connect to a single Electrum server for transaction data and address histories. At the same time, they also query multiple other SPV servers for block header data of the latest blocks.

If enough Electrum servers answer with the same data and the client is satisfied that enough Proof of Work has been committed to these blocks, it will accept that these blocks exist in the actual blockchain. With this information, light clients can accurately validate the existence of past transactions.

Below is a list of pros and cons for each of the two SPV architectures: P2P and Electrum.

Peer-to-Peer SPV Client Architecture

Some of the more popular peer-to-peer SPV clients are lite wallets, such as the Android Bitcoin Wallet and the Bread Wallet. Both of these wallets only support Bitcoin (BTC), since P2P SPV is impractical for blockchains with larger block header sizes and faster block times.

Pros:

There is no SPV server in this architecture. The SPV client directly connects to the existing peer-to-peer network and all of the Full Nodes of the blockchain.
This architecture provides almost the same level of decentralization as the peer-to-peer network to which it connects, as it directly interacts with the Full Nodes to fetch block headers and transaction-related data.
This architecture is more secure than the Electrum SPV model, as there are fewer attack vectors.

Cons:

Clients must sync with the network before making any transactions. This means downloading all block headers from the Genesis block to the current one, plus information of transactions related to the client’s addresses. Even the smallest-sized block headers can add up to several gigabytes of data that must be downloaded before the SPV client’s user can create a transaction.
This model is not very private, as the SPV client may reveal its blockchain address and IP address to all the nodes in the network when it requests transaction data.

Server/Client based SPV Architecture

Electrum SPV is the most popular implementation in this category and is used by most of the world’s SPV users today.

Pros:

This model does not require downloading all the block headers, so there is no need to wait for network synchronization before making the first transaction.
This method requires very low system resources and internet data.
The connections to the Electrum servers can be protected by SSL so MITM (Man In The Middle) attacks can be prevented.
Privacy is also somewhat protected, since only the Electrum server will know the IP address and blockchain address of the SPV client, rather than every Full Node in the blockchain’s network.

Cons:

Less decentralized compared to a true peer-to-peer network, as Electrum SPV clients can only talk to Electrum SPV servers and not directly to the blockchain’s network. While the architecture requires a single SPV wallet to query many different SPV servers, in many instances, smaller blockchain communities don’t have the resources to maintain a large number of SPV servers.
Electrum SPV servers can be DoS attacked if they aren't hardened for security. If enough of these servers are brought down, the SPV clients in this architecture will have no way of accessing the blockchain network.

Further Exposition On The Limitations Of Electrum SPV Architecture

An Electrum Simple Payment Verification (SPV) server is a computer that runs two different pieces of software: a specific blockchain’s daemon (known as running a “Full Node”) and the Electrum SPV software.

This allows applications running on other devices, such as mobile phones or tablets, to access blockchain data by issuing RPC calls to the Electrum SPV server. These external devices, known as light clients, don’t need to download and run an entire blockchain in order to send and receive coins from that blockchain.

Instead, they only need to download and install a light wallet application, which contains all the code necessary to connect and interact with the Electrum SPV server. Ultimately, this makes it possible for mobile devices to validate past transactions based on block header data and create and sign new transactions. The signed transactions are then sent to the SPV server, which in turn broadcasts them over the blockchain’s peer-to-peer network via the full node.

Here, the range of actions that can be performed by the light wallet application is limited by the Electrum server software, which is standard to most Bitcoin-protocol coins. While the use-case of simple blockchain payments is served well by the Electrum server implementation, a more complex use case, like using Komodo Custom Contracts in a light wallet, requires improvements to both the wallet app and the SPV server implementation itself.

Furthermore, a single SPV server can serve only a limited number of clients. To allow more light wallet users to connect to the network, an increasing number of Electrum servers must be launched in diverse geographic locations. The costs of providing reliable Electrum server access to a large number of users around the world can quickly become prohibitive for startups and small blockchain projects.

Common Attack Vectors On A Typical Light Wallet

In addition to the limitations described above, there are several security vulnerabilities associated with traditional Electrum SPV server infrastructure. There are three primary attack surfaces:

The environment in which the Electrum software is run (e.g. key-logging software).
Injection of malicious code through the build pipeline (Learn more about this attack vector and some countermeasures in this academic paper.)
Malicious update of a dependency in the software itself (Learn more about this attack vector in this detailed lecture.)

While a developer has no control over the security of the environment in which a light wallet application is run— that is, the device on which the app is installed— there are still a few reasonable steps that developers can take to secure the build pipeline. These steps include auditing all the dependencies used to build a Javascript-based GUI wallet, a herculean task.

This is because the Javascript programming language evolved to the current day following a hostile implementation battle between all the major web browser providers called the “Browser Wars.” During this time, it was very difficult for any new feature of Javascript to be accepted by all browsers and implemented across the board.

As a result, many of the basic features a developer might expect from a programming language are missing from Javascript. While tools like npm make it easy to share and use features (called “packages”) from other developers, it also makes keeping control of your whole codebase almost impossible. Every package used in application creates an external dependency, and therefore an attack vector through which a hacker can insert malicious code.

nSPV: Komodo’s Solution To The Problems of Legacy SPV

As Komodo uses delayed Proof of Work (dPoW) to secure the KMD chain, as well as Smart Chains in the Komodo ecosystem and a few external blockchains, there is no longer a need for a light wallet to validate the block headers from the Genesis block to the current one.

While nSPV replaces and adds to the features provided by Electrum SPV wallets today, its architecture is based on the peer-to-peer SPV client model. In fact, the core nSPV implementation is an improvement of the peer-to-peer SPV client implementation for Bitcoin named libbtc.

What this gives us is the decentralization and reliability that P2P SPV clients offer, without the overhead of downloading gigabytes of data and dealing with a long wait time for the SPV client to sync with the network to create the first transaction. It’s a best-of-both-worlds development.

By leveraging the cross-chain notarizations already performed for dPoW security, light-client nodes can verify far more efficiently than what would be possible with traditional Electrum SPV server methods. This new innovation is called Notarized SPV, or nSPV for short.

To validate the existence of a transaction on the blockchain, an nSPV superlight client only needs to confirm the block headers from the last notarized block prior to the transaction in question to the notarized block immediately following the block in which the transaction in question was created.

Consequently, there is no need for dedicated SPV servers that index a blockchain and respond to RPC calls, as an nSPV client can simply query any full nodes on the blockchain’s peer-to-peer network for the transaction and block header data, then validate that data locally and independently from the node(s) that provided the data.

An nSPV superlight client is more responsive than the Electrum SPV client wallet, since it directly interfaces with a blockchain’s decentralized network. nSPV technology is also more reliable, as any full-node on the network can act as a source of information. nSPV clients are not dependent upon a limited number of servers in the same way that Electrum SPV clients are.

To sum it up, Komodo Lead Developer jl777 created a superlight client (a tiny executable written in C) that interfaces with a blockchain’s peer-to-peer network directly and validates transactions independently with very, very little data. When we consider the amount of work involved in adding new features to the Electrum implementation, which already presents a scalability bottleneck, the benefits of this new nSPV superlight client technology become very clear.

nSPV & Static HTML Wallets

A significant breakthrough for nSPV technology is that it offers support for static HTML wallets. As all necessary wallet functionality is present inside an nSPV client, a wallet application only needs to issue RPC calls to the nSPV client running locally and display the response in a readable format to the user. This enables static HTML wallets, which have no dependencies and are thus far more secure than ordinary cryptocurrency wallet applications.

The nSPV client can generate web pages using pure HTML and CSS based on user input. This way, the risk of a malicious dependency update— one of the three most common attack vectors for a Javascript-based application described earlier in the article— is avoided entirely, significantly reducing the potential attack surface.

To further reduce the attack surface, the Komodo team recommends running the nSPV static HTML wallet in a standard web browser with Javascript disabled and with no extension or add-ons enabled, as they might have permissions to read all data on all websites accessed in that browser. This would obviously present a serious security risk.

Integrating nSPV To Komodo Custom Contracts

Another explosive opportunity for nSPV technology is integrating the superlight client feature into Komodo’s toolkit for custom blockchain development. Doing so has the potential to make Komodo Custom Contracts accessible on mobile devices and in web browsers.

As things currently stand, a user must run a full-node in order to activate and run contracts, such as the trustless oracles contract or the Dilithium quantum-secured blockchain contract. With nSPV technology, the Komodo team is developing a way to make Komodo Custom Contracts available via superlight clients, including even the smallest of electronic devices.

Compiling nSPV Clients To Web Assembly (WASM)

The Komodo Development Team is exploring a way to compile nSPV technology into Web Assembly (WASM) and make it available as an extension in web browsers. Significantly, the WASM edition of the nSPV client will make all Komodo Custom Contracts available on every web page you visit and allow interactions that turn KMD and any Smart Chains’ coins into truly web-native currencies.

For example, a highly-anticipated use case for cryptocurrency is innovating a method for making a single micropayment for every article or piece of content you consume online. In theory, this would combat invasive ads, eliminate the need for excessive tracking of users, and provide a source of revenue to content creators. This blockchain use case could be trivially implemented using the Channels Contract once nSPV technology is fully compiled into WASM.

Building on that same use case, the Tokens Contract would make it possible to use synthetic digital assets representing any currency or security as web-money (rather than just KMD and Smart Chain currencies).

Once the Pegs Contract is ready to be deployed, fiat-denominated stablecoins would also be eligible for use within a browser. The stablecoins could be easily converted into fiat currency through a fintech service. This scenario would eliminate two of the primary barriers preventing online merchants and e-commerce sites from accepting cryptocurrency payments— the price volatility of digital assets and the difficulty of converting digital assets to fiat currency.

nSPV & Blockchain Gaming

A major benefit of nSPV technology advances the possibilities for blockchain gaming. A game server using the Rogue Contract, in conjunction with nSPV technology, can easily bring the blockchain’s built-in cheating prevention and consensus validation mechanisms to multiplayer gaming. This is true for games with state changes that can be deterministically calculated based on a randomly-generated seed and player actions/input.

For instance, the Komodo Team has already implemented a multiplayer version of Tetris, where all players start with the same seed phrase and then have their inputs recorded on the blockchain for decentralized validation via the network to determine the last man standing. The blockchain can also enable a mechanism that collects an entry fee from each player, then automatically distributes the rewards to the winner(s) in a predetermined ratio.

nSPV & the Internet of Things (IoT)

The final feature that nSPV enables is integrating blockchain with the coming decentralized internet and the Internet of Things (IoT). As the nSPV client itself is written using the C programming language, it can be compiled to run on almost any hardware available today. And, as the functions it needs to execute are very small, it takes up very little resources in terms of disk space (hard drive) and memory (RAM).

The above two properties make it a perfect client to bring Komodo and Smart Chains to the IoT world. Any sensor or signal interaction on an Arduino or Raspberry Pi like device will be able to trigger an on-chain transaction or activation of a contract.

Looking Forward

As the Komodo team prepares for 2020, advancing nSPV technology is a major area of focus. While all of the features discussed in this article are still in development, it reinforces the fact that Komodo is one of the most active and innovative blockchain projects in the world today. Always developing at the cutting edge of the blockchain industry, Komodo is pushing the boundaries of what is possible with blockchain technology.

If you'd like to learn more about blockchain technology and keep up with Komodo's progress, subscribe to our newsletter. Begin your blockchain journey with Komodo today.