Photo © 2018 Monica Rose Photo
At the 2018 Nexus Conference, Colin Cantrell, Nexus Founder and Software Architect, gave a brilliant presentation explaining the latest developments of the Nexus Tritium protocol. Tritium is the first release of the Nexus Three Dimensional Blockchain (3DC), and will be followed by Amine and Obsidian. He explained the necessity of each layer of the Tritium software stack (Network, Ledger, Register, Operations, Logical, API and Interface), their different functions, and gave a deeper explanation of the Lower Level Library (LLL). Colin displayed some impressive benchmark tests comparing the Nexus Lower Level Database (LLD) read / write speed to Ripple Nu DB, Google Level DB and Oracle Berkeley DB (spoiler: Nexus tested faster than all). He also demonstrated a live, functioning demo of Tritium with the entire stack running, and introduced many business use cases for advanced contracts.
The 3DC and the Tritium Software Stack
The design of the 3DC and the identification of node roles enables different nodes to perform different processes in parallel. This fundamental quality lays the foundation for scalable advanced contracts. The software stack also enables developers from all levels of experience to develop on the layer that is most suited to them. Colin explained that the stack design was inspired by nature: “As we know nature grows out in layers. Matter has certain layers of responsibility, where simple protons, neutrons and electrons form together a simple atom. They then start to form covalent Hydrogen or ionic bonds and then form molecules that form tissues and organs”.
Colin also gave a deeper explanation of the Lower Level Library (LLL), a polymorphic (able to inherit a class from a base class) template library and the foundation of Nexus. He compared the significantly faster performance of the Lower Level Database to other databases used in Bitcoin (Berkeley DB), Ethereum (LevelDB), and Ripple (NuDB). He highlighted the importance for the fundamental layers (Network and Ledger) to scale, as it supports the scalability of all the layers built on top (Register, Operation, API, etc.). The beauty of the LLL is that you can plug in any kind of processing system while maintaining high levels of scalability.
Here are the results of Colin’s 100,000 reads / writes benchmark test:
- Nexus LLD: 0.818129 seconds
- Ripple Nu DB 6.941530 seconds (Nexus
- Google Level DB 7.714264 seconds
- Oracle Berkeley DB 18.272793 seconds
Nexus Lower Level Database Performed:
- 8x Faster than Ripple Nu DB
- 9x Faster than Google Level DB
- 22x Faster than Oracle Berkeley DB
Photo © 2018 John Saviano
The Lower Level Protocol (LLP) is a custom-made network protocol that is responsible for end-to-end communication between nodes. Colin explained why he created the LLP: “the way that sockets are managed has a large influence on the ability to handle a large amount of connections and requests per second”. A screenshot of a Lower Level Protocol test showed it running at 194,761 requests per a second with over 1,000 simultaneous connections. Such high levels of scalability have been achieved by squeezing computing cycles through fundamental simplicity. He reiterated the importance of reducing the routing complexity to O(1) through IP-Multicast, so that the addition of nodes to the network does not decrease its performance. This makes the network less vulnerable to eclipse attacks and allows for larger blocks as messages propagate faster. Additionally, the Location/Identifier Separation Protocol (LISP) decouples your address space from your input identifiers, allowing the traversal of NATs (Network Address Translation) and the encryption of all data, creating a fully encrypted peer-to-peer communication system.
The Ledger layer manages register ownership and is responsible for maintaining data immutability. Ownership of data is proven on this layer through a cryptographic proof provided by Signature Chains. The Ledger layer of the Nexus public blockchain is not a storage system like the Cloud, but is instead “an ownership tracking device that allows immutable ownership to be stored, that other private systems can connect into”. This begs the question, why not simply create a private blockchain? “Well, because then you have a private MySQL database.” With a public blockchain, the more people that contribute resources toward validation, the more secure it is. Colin went on to explain that some blockchains with more centralized consensus mechanisms, such as Delegated Proof-of-Stake protocols, may be vulnerable to Zero Day attacks.
Colin was especially excited to present the Register layer of the Tritium software stack. Registers are stateful objects owned by the signature chain that published it. They form a relational database model, where the relationship between different registers can be managed by cryptographic proofs on the Ledger layer below. Registers can be chained to one another with coupled validation logic in order to record and track change in ownership, or to create multi-signatory accounts. Registers currently fall into two categories: raw state registers that store raw bytecode that can be read or modified by authorized accounts, and object registers, which are predefined, serialized classes that update and change state through the Ledger. For example, object registers can store the state of an account’s token balance, which can be used as a proof of ownership in another register, such as an escrow. The Register architecture makes Nexus significantly different than any other blockchain. Using the Operation layer built on top of the Register layer, registers can be transferred, read, or modified in different ways. These two layers together create what Nexus has termed an Advanced Contract. Unlike Ethereum and most other smart contract implementations that are stack-based and use a large number of operations, registers are very efficient, as accessing the value of a register is an order of one O(1), because its exact index is known.
While other smart contracts are executed by the nodes on which they reside, often requiring a specialized compiler and interpreter to execute the contract, advanced contracts can use the Operations layer to perform predefined operations on the registers. Additionally, distributed applications can be written and executed on clients computers, using raw state registers to store data. Operations are byte-code functions that change registers from one state to another. For example, a DEBIT will change the state of an account balance if authorized to do so. Likewise, a receiver will use this temporal proof to CREDIT their account by way of another state change. Colin explained how validation logic could be created by users to set parameters, i.e. escrow functions, and emphasized the importance of standardizing operations and registers through an open process to define secure and efficient logic. To that end, Colin welcomed all to participate in the working groups to help shape the standardization process, like an Internet Engineering Task Force (IETF) for blockchain.
Application Programming Interfaces (APIs) allow easy, high-level interaction with the internals of a system. Nexus plans to make integration with blockchain technology seamless by abstracting the OSI Application layer above the aforementioned layers through APIs. The Logical layer will handle the interpretation of API calls and will populate results to the end user on the interface. Meanwhile, the Application layer will do most of the processing and data handling. The Ledger will only be used for validation and authorization, i.e tokenization and other forms of ownership. This allows developers the freedom to build their own applications at the logical/interface layers, while having access to the ledger and contract logic through JSON-APIs. This is important for many businesses, as they have sophisticated systems that already use many different APIs. There are many different use cases for a blockchain, which is why Nexus is focusing on scalability and ease of interoperability with old systems.
Tritium Live Demonstration
Colin’s live demo of Tritium showed how signature chains interact with one another and how the Ledger, Register, and Operations layers work together to create register chains and tokenized ownership. The Operation layer includes DEBIT, CREDIT, REGISTER, and WRITE operation codes. The Register layer used state proofs, ownership proofs, register chains, and account / token object registers. The demo showed the Ledger with two signature chains and demonstrated how a royalties payment could be executed in real time, based on ownership proofs represented by the corresponding token balance of the two signature chains. The token, called ART with a 100 ART max supply, was published to the Ledger. One signature chain was created with 50 ART and the other with another 50 ART, showing a 50-50 ownership. From there, one signature chain published metadata representing a song, with ownership assigned to the token object register. This allows a signature chain to prove partial ownership based on a token balance. This process takes about five database writes, which is a very low level of complexity, considering the LLD can handle hundreds of thousands of writes per a second. The next transaction demonstrated a debit operation from a native NXS object register, directly into the metadata register address, which then waited to be claimed. Colin explained that a CREDIT has to be claimed from a DEBIT, meaning that NXS will not be lost if sent to an invalid address. All tokens on Nexus are going to transfer as quickly as the NXS native token, taking only two operations.
Colin then demonstrated how the tokens are used as a temporal proof to claim 50% of the debit. He also attempted a double spend, to prove security, which failed, as the temporal proof had already been claimed by the object register holding the state of the balance of ART tokens on that signature chain. The owner of the other signature chain is then asked to provide their temporal proof from the state of their ART token balance to claim their 50% of the 20 NXS debit (ie. 10 NXS). They credit it to their account using this proof. This is all recorded on the Ledger, essentially serialized into byte code, and is interpreted by the operations engine by the method EXECUTE. Colin then demonstrated another double spend attempt that failed, to prove that the temporal proofs work only once. This is really important, as tokens can currently only be used to hold an ICO. However, tokenization can be used in many different processes to prove ownership, as they can prove a wide variety of chained events.
New Use Cases for Tokens
Colin spoke about the future of Nexus by introducing many new use cases with genuine utility, such as the tokenization of ownership, data, or assets. Anyone who attended the conference could see the passion and excitement in Colin’s voice as he presented these innovative solutions. Colin strongly believes that through music, blockchain technology will reach many different people. In the music industry, a large percentage of royalties goes to middle men, as do revenues in other industries go to third parties. As the demo showed, tokens can be used in licensing and in the use of copyrights, to provide artists and musicians the opportunity to earn money for their creations. Tokenization in the music industry will increase with importance, especially with the new Music Modernization Act. Now, a music subscriber could make a debit by paying a license fee once a month that would be split, based on the token ownership. It is important to note that the tokens are transferable while also retaining their utility in providing temporal proofs to the Ledger. This will allow an artist to crowdfund their new album by selling a portion of their tokens to the public. These tokens could then be sold on an exchange, traded, speculated on, and also be used to receive royalty payments. This gives tokens real utility beyond value storage and provides artists a new way to connect with their fans.
Supply chain transparency could be created with ease by recording the change in state, as NXS moves between each level of the supply chain. Tokens could also be used for automatic budget allocation for revenue streams, creating layers of tokenized accounts, which would save a lot of resources that go to managing this manually. Across many industries, tokens could help fraud prevention, as tokenized revenue streams will create a transparent movement of funds. Colin explained that tokens could split rights between many different people in order to create joint ownership. For example, in the sale of a jointly owned house. Tokens could also support patent leasing. A group of inventors could create tokens to distribute to investors, without the need for legal paperwork. Colin affirmed that “you don’t need a court, as crypto is the court”. The investor only has to prove that they hold the tokens to claim their percentage of the available dividend. Likewise, tokens could be used to represent shares of a company. A certain percentage of the revenue stream could then be allocated to the token holders, so that the dividends disperse automatically. A token split could also be utilized between a car dealership and manufacturer. The token distribution between the two would define the ownership of the revenue from a lease of the vehicle, allowing the automatic clearance of the finances and frictionless payout of revenue.
A further example was for the distribution of donations to nonprofits to prevent internal embezzlement, and the inefficiencies of administrative and managerial cost. Tokenization could make charitable donation distribution just and transparent, ensuring that a definite % goes to the people in need. Colin also explained how registers, debits, and credits could form the foundation of a decentralized exchange. For example, a seller could put up an order on Nexus, as an exchange object, a debit for 50 ART requiring a 10 NXS debit to this register, to allow a credit based on that temporal proof. Once both debits are fulfilled, the 50 ART would be unlocked for credit to the new holder, along with the 10 NXS to the new owner. Arbitration triangles could also be created, using multi-signature contracts with three signatories, but only two required to unlock funds. The arbiter or neutral party could be a shipping company, who could resolve any dispute between buyer and seller. The arbiter would only have power if there was a disagreement. This would provide safety in escrow services, and prevent the risk of deadlocks in case one signatory doesn’t agree with the other. Colin further explained that tokenization will allow the creation of distributed autonomous organisations, through token votes, where tokens could be used as proofs for vote weights in such a DAO. He ended his excellent presentation with a long awaited demo of the new wallet.
Most companies are in the early days of understanding how blockchain technology can help them, and it’s important to educate them on what blockchain can and cannot offer. Some companies are already aware of the potential use cases of blockchain technology for their business model, but are finding limitations posed by other protocols, like the scaling issues of the Ethereum Smart Contracts Platform. The business development team helps businesses discern what they need from a public blockchain versus what can be accomplished with a public-private hybrid system, and welcomes anyone who thinks they could benefit from the technology to contact them.