The Nexus Tritium Whitepaper is unlike others I have seen in that much of the work defined in it has already been completed. This is not a wishful document dreamed up by unknown crypto developers, and the imminent release of Tritium does not depend on finding and hiring an experienced and diverse team. The whitepaper below was written after a year of planning and development. Any problems with the original plans have been worked out, and important improvements to the original design have been incorporated. The Nexus team is putting on the finishing touches and has started testing parts of Tritium for imminent release.
Tritium is the foundation and first update of a much larger design framework called the TAO. The Tritium whitepaper outlines the components by defining seven interacting layers which are important to additional releases in the future. It goes into some very technical details, but it is worth going through the actual whitepaper and understanding just how the Tritium design improves on the traditional blockchain.
Below I summarize the seven layers defined in the whitepaper which make up the backbone of the Tritium protocol. I start with the Network layer, which is the deepest, and work my way up to the interfaces and applications most of us will use regularly. This is a very summarized version of the information in the WP, and I encourage you to look over at the actual document when something here is not clear enough. The seven layers are…
1. Network
2. Ledger
3. Register
4. Operation
5. API
6. Logical
7. Interface
The Network layer is the seventh layer of the software stack, and is where the Tritium Protocol will begin addressing scaleability. In a traditional blockchain, messages must be sent from one node to another in a linear fashion, and in the case of transactions, confirmed by every node on the network creating network overhead. This is considered “Decentralized” and is illustrated in the Network Topology graphic below, but is actually more centralized and at risk than people realize. Tritium has incorporated an optimized and efficient routing system, allowing nodes to communicate much more efficiently through the use Multicast Locking Groups, making Nexus truly “Distributed” (see topology again). Multicast gives the ability to have single data packet replicated to an entire ‘node group’ by handling the distribution of the data to each of the nodes. Using LISP gives an identity to each node on the network allowing open and secure communication between the nodes no matter where they are or how they are connected. For much more information on LISP, see the whitepaper Appendix section D.
The Ledger layer is where the blockchain resides (eventually the Nexus 3DC), and is powered by the LLL (Lower Level Library). It introduces Signature Chains to increase security and simplicity in Nexus transactions. Signature Chains remove the need for a wallet.dat file by incorporating a user name, password, and pin number to be used for retrieval of private keys. The signature chain allows you to have an identity on the network, leading to personalized blockchain experiences without compromised security. This identity will be useful in the future in decentralized exchanges, online marketplaces, and social networks built on top of the Nexus 3DC. The Ledger layer will also record the personal trust, or reputation, of your node on the network. The higher your trust, the more weight is associated with the transactions your node processes, and the greater the reward for your contribution.
The Register layer is made of many memory spaces stored entirely on chain, each of which can be associated with a signature chain or chains. This layer will be accessed by developers using the API sets (defined below) to store or retrieve data on the blockchain. This is an important difference between the Tritium protocol and others running smart contracts. On Ethereum, for example, the users run a smart contract on chain, and the network nodes do the processing. On Tritium, applications will be able to pull byte code, or machine code, data from a Register to perform a function, and the processing is done locally instead of on the network.
The Operation layer contains the code to allow developers to work with the register layer defined above. There are standardized and well tested codes working on this layer, allowing things such as the writing and reading of data from a register, or the debit and credit of an account balance. It is important to limit the ability of the codes to only necessary functions, though new ones can be added as needed when agreed upon. The other codes in this layer are covered in the whitepaper if you are interested in reading about them. This layer also verifies the data sent in from the API’s to assure it meets the formatting requirements.
The API layer is where data requests and other commands are sent by developers. It follows a standard JSON-REST format, which gives developers the ability to use many options to interface with the Nexus network. This is an important feature which opens development on the Nexus chain to anyone using any programming language, rather than restricting development to specific Turing-complete languages. Using API simplifies what happens behind the scenes, so no longer does a programmer need to know how to account for everything happening under the hood, they can just perform a simple command. The ease of using APIs opens up the power of distributed systems to the world.
The Logical layer is where applications can be added to improve and simplify interfaces with the Tritium chain. For example, an application can reside on the logical layer receiving data for a contract, use an API to secure it using a signature chain, and then use another API to write the data to a register. This type of application would potentially be used by many people and developers, so rather than have everyone knowing all the fine details of calling multiple APIs to make this happen, an application on the logical layer can simplify the process.
The Interface layer is defined most easily by thinking of your Nexus wallet. The Tritium protocol provides enhancements the old QT wallet just was not able to handle. For example, a feature enhancement to the blockchain will be able to be added seamlessly without requiring a wallet update. It will also allow personalized customizable modules to run in the background, so if someone develops a weather application and you want your local forecast to show in your wallet, you can simply add it.
The latest plan for Tritium provided by Colin Cantrell in the Nexus slack channel has pieces related to enhanced security being released ‘soon,’ followed by additional updates as they are tested and ready to move to production. Nexus fans and the community have been waiting for a long time for this update, and from everything I have seen in the whitepaper it has been worth the wait. When all of Tritium’s features outlined in the white paper are released, it will be the most advanced and developer friendly chain in the world, addressing many of the issues traditional chains are facing and providing the opportunity for blockchain development using any programming language.
The explanations in this article would not have been possible without hours of discussions with @Shea in Nexus Slack. @Shea also worked on much of the whitepaper and has answered innumerable questions concerning the details of Tritium in the last month for the community. If you see him, please let him know how much you appreciate the many hours he spent working on this.
