It is clear that organisations can only operate effectively with easy access to products and services. Likewise, no organisation can continue to grow if late payments and poor procurement processes remain in place. This is where blockchain technology can play a crucial role, in both the modernisation and improvement of the logistics and operations which are vital to the performance of supply chain systems.
With the highly anticipated release of the Nexus Tritium Mainnet scheduled for the end of January 2019, application developers will be able to interact with the functionalities of the Nexus blockchain through an easy to use, feature-rich API set. APIs will create user-friendliness for developers who will be able to build in a wide range of languages, and interoperability for existing private systems to interact with the Nexus blockchain. Nexus has designed its software stack based on the Open System Interconnection (OSI) network reference model, with the fifth layer as the API layer.
What is an API?
An API is an Application Programming Interface. While a user interacts with a system through a user interface, an API allows developers to interact through a programmatic interface. The way this works is that the API provides a list or set of simple commands that execute a series of operations, which would otherwise require specialist programming knowledge. This allows a developer to request or submit data to a system providing functionality to a higher-level application. For example, Facebook’s Graph API allows access to “Login with Facebook” and other features of their system.
The distributed validation method provided by a public blockchain or Distributed Ledger Technology (DLT) (on-chain) is very secure in comparison to that of a private blockchain (side-chain) or centralized database (off-chain), because it is validated by many nodes forming a global consensus. However, private blockchains which are serviced by their own nodes provide other benefits that are much easier to develop and scale. One such benefit is to record proofs of private, sensitive, or proprietary data that are generally stored in a private database. This provides the private database the ability to edit or delete this data, in order to comply with regulations such as General Data Protection Regulation (GDPR), while maintaining the positive qualities of immutable proofs from the private blockchain. An optimum balance between a Public Ledger, Private Ledgers, and Private Databases, will provide the performance and efficiency necessary for global adoption.
Nexus is developing the systems to enable private networks to utilize the public ledger, creating what is essentially a hybrid system, through an array of both private and public ‘template’ use case APIs. Public APIs will be provided by Nexus as open source technology, while Private APIs will be developed with businesses as their proprietary technology.
Nexus welcomes any interested parties to participate in our working groups to help shape the standardization process for the Nexus Software Stack, as we continue to develop the standardization body for DLT, similar to how the Internet Engineering Task Force (IETF) shapes the internet.
In addition to accessing the Public APIs, developers will be able to build their own Private APIs, providing the privacy of a permissioned system required to keep proprietary information and logic concealed, while harnessing the security of a public blockchain. This is possible through the use of state recording checkpoints between the private and public networks to ensure that agreements in the private network are also recorded in the public network, shown by the diagram below.
Given that only the aggregated state of the private ledger is recorded, sensitive or private data is not stored on the public ledger. Therefore, private APIs can secure proprietary contract logic, such as private supply chains, notaries, consumer verification services, etc., providing private services that the public layers are unable to. Since a private API functions as its own private network that synchronizes to the public network, one can expect the level of reliability and security of DLT. A private network can be operated under a software services license, or by the commissioner of a said API service. The final result, is a robust service that provides interoperability with existing private systems.
Nexus Private API Service for Enterprise range from hosting solutions to full private API buildout. Private APIs can be custom-built either by Nexus on behalf of a private client, or by any third party with or without consultation. Private testnets can also be provided during development to avoid loading the public and final private ledger with redundant data.
It is often claimed that the ratio of demand to supply for blockchain developers is 20:1, which has led to the high costs associated with blockchain development and low business adoption. Since most programmers are already comfortable interacting with an API, building on the Nexus API can be as simple as developing a web-app. Through improvements in accessibility, Nexus is set to significantly reduce the barriers to entry for blockchain technology.
It has been a very productive month for Nexus with the commitment of many new lines of code for the Tritium upgrade, ambassadors attending conferences, engineers meeting at the Internet Engineering Task Force, and the continued development of our distributed Embassy structure. The developers are also continuing to improve the Tritium Wallet and gearing up for the next set of beta testing.
Tritium Development Update
Most of the foundational developments of Tritium are complete. Recent tests of the Lower Level Library (LLL) show requests reaching 197,744 per second, and the Lower Level Database (LLD) handling the workloads handed to it when testing Lower Level Crypto (LLC) verification at over 4k tx/s.
The Nexus developers are at the stage of weaving together code over the network, establishing local databases to handle Signature Chains and register indexes, and adding lower level RPC commands to interact with the Ledger, with the higher level API being the interface in the command set.
Jack McGowen, a new Nexus developer, has been actively working with Scott Simon on the backend LLL-TAO Framework, cleaning up the code and helping to weave it together with the Tritium and Legacy code, into a live Tritium node (minus Tritium activated features) running over the live network. The code cleanup process has involved writing new code for existing functionality, and code comment-based documentation. A lot of the legacy code contained functionality from third party libraries such as boost. “We wrote new code to replace boost while maintaining the same functionality so now the code is less bloated and more portable. I got so excited about removing boost, that I removed it from the prime GPU miner as well,” said Jack. Moving forward, new users looking to build the code from source will no longer have to download boost. The team will use doxygen, an industry standard tool, to build an HTML format document from code comments that will be the foundation for learning for developers building on top of Nexus.
According to Colin Cantrell, in his latest TAO update, “Tritium will be released by the end of January, 2019. Yes , a timeline! As we have noticed over the last year, the removal of road maps and timelines didn’t do what was intended, it only created further uncertainty and rumors about the project. As we move into Chapter 3 of our history with distributed Embassies, new architecture, and distributed governance models, we felt it was appropriate to augment this with commitment from the development teams to set and meet deadlines.”
The Nexus Tritium update implements Signature Chains (Sigchains) that create a unique cryptographic identity system, a key-management authorization system, and a proof-of-ownership device. This allows a user to safely transfer and prove ownership of assets and data through advanced contracts. When a user publishes, transfers, or leases data, an event is recorded. This allows for a relationship between users and transparent chains of events to be recorded. That relationship provides the utility of managing data and assets: titles, deeds, patents, currency, records, music, copyrights, trademarks, websites, etc.
The Bitcoin Cash community went through yet another civil war where miners had to decide which new protocol upgrade to support with their hashing power. The two sides: Bitcoin Cash ABC (ABC) and Bitcoin Cash Satoshi’s Vision (SV), split on November 15th, 2018. Craig Steven Wright, leader of SV, threatened the entire cryptocurrency ecosystem, promising he would use every miner that supports his chain to 51% attack ABC, followed by attacks on all other blockchains. Alas, the first hash war was anti-climatic as the majority of hash power turned out to be on the side of ABC. Of course, the situation may still change if there is shadow mining afoot.
During the conflict, Colin Cantrell shared his perspective on the hash wars, and reminded us that “we must take a moment to ask ourselves: “What is our vision?” And if our actions aren’t in accordance with this, we must find ways to support projects that are.”
World Crypto Con was hosted in Las Vegas over Halloween week, and Nexus was a big part of the 10 year Bitcoin White Paper celebration. Nexus’ participation was funded by the community, and the event was staffed by Dionna and Anastasiya (US Embassy), Chris (Community Volunteer AU), and Cain (AU Embassy). Nexus sponsored the conference’s hackathon and the Bloqathon, which was hosted and organized by the Bloq team. Anastasiya gave an informative speech to the participating developers explaining the Tritium upgrade. Nexus also had a kiosk in a prime location, stacked with a 50 inch TV playing the wallet demo, and lots of Nexus swag. The team educated attendees about the Nexus technology along with our ledger layer scalability architecture. We want to thank everyone who stopped by to talk about the tech! A special thank you to community members Chris and Frank for going above and beyond to support the Nexus vision!
Blockchain Unbound: Tokyo
Nexus Ambassador, Dionna Bailey, attended the Blockchain Industries conference Blockchain Unbound: Tokyo. She was interviewed by several podcasts, participated in the Satoshi is Female & Women in Blockchain Luncheon, and connected with blockchain projects in Asia. Additionally, she represented Nexus in the Token Alliance Roundtable Tokyo where blockchain leaders in the Asian market discussed the current landscape of the industry and the challenges of regulatory changes. Among the attendees were the former commissioner of the SEC, NEO, Quoine, Huobi, Bittrex, Blockchain Industries, Perianne Boring, and Matt Roszak. As part of our membership in the Digital Chamber of Commerce, Nexus was featured on the front cover of Understanding Digital Tokens book given to legislators in the US and abroad.
As part of Nexus’ education initiative, the team has taken steps to expand into Korea. As a result, we now have our homepage live in Korean. There is also a dedicated Telegram channel for those in the community who want to get involved and keep up with news as well as a Twitter channel for public announcements. Future plans include meetups in Seoul as well as other initiatives to grow our international network.
Jack McGowen has joined the Nexus Core Dev Team! Jack is relocating this month to the US office in Tempe, AZ to work closer with the team as a software engineer. He obtained his BSCS:RTIS (Real-Time Interactive Simulation) from DigiPen Institute of Technology April 2017 and joined the Nexus community shortly after, and has been an active community member for over a year.
Jack learned about the outdated prime miner software and began working on a new one. He found that his GPU programming skills translated nicely from computer graphics to high-performance computing or HPC. “Any miner is trying to solve a HPC problem, and so the problem felt like a natural fit for my skill set.” Jack successfully implemented a fast 1024-bit primality test using Montgomery modular multiplication, and offered a significant speedup from efficient use of GPU resources. “The Prime GPU Miner is rid of boost, OpenSSL, and libprimesieve; it only requires CUDA and GMP to build now.” He has plans to write an even more scalable miner as he continues R&D on an efficient prime mining algorithm, and is currently working on the backend LLL-TAO Framework.
Quý is a web developer with six years of experience and has been involved in cryptocurrency and blockchain technology since 2014 when he was first working with NEM. He was attracted to Nexus because of the innovative technology it introduces, as well as its ambitious goal, and believes he can help Nexus improve on the UI/UX side to bring its great tech closer to the users. In his free time, he enjoys music, Salsa and Bachata dancing, and playing board games.
Colin, Alex and Jules met up with some long-time community supporters and new faces in London, including @borris and @cryptosi who shared their welcomed wisdom, @kat who is helping to organize the Polish meetup, @supernova who works in the satellite industry and @danielsan, who created the brilliant Nexplorer.
November 16th-17th: Colin Cantrell will be at CryptoFinance conference in Oslo.
November 18th: Colin Cantrell and Alex El-Nemer will visit Warsaw, Poland. We invite you to our first Working Group Conference, an opportunity to hear Colin and Alex present and answer questions, and to participate in a Contract, Functionality and DAC working group.
We are excited to collaborate and explore further with all types of developers to extend the application space from the conventional OSI design to build on the Nexus Tritium Software Stack and hold regular working-group meetups with people from around the world.
The Nexus Tritium update implements Signature Chains (Sigchains) that enable account-based transactions and create a unique cryptographic identity system on the blockchain. This allows a user to safely transfer and prove ownership of assets and data through advanced contracts.
Sigchains provide a cryptographic identity and a proof of ownership system. When a user publishes, transfers, or leases data, an event is recorded. This allows for a relationship between users and transparent chains of events to be recorded that provide the utility of managing assets and data: titles, deeds, patents, currency, records, music, copyrights, trademarks, websites, medical records etc.
Access to your Sigchain will be through a distributed login system which will generally include a username, password, and a 2FA pin code (Two-Factor Authentication). This can be comparable to logging into an online bank account without a central authority that could hack or control your information. A Sigchain identifies who you are on the blockchain without you having to disclose any personal data, such as birth name or passport number. They also remove the need for a wallet.dat for key storage that is commonly required in legacy blockchain systems.
As we progress into the 21st century, biometrics are becoming increasingly prevalent in our lives. Since a Sigchain is essentially a distributed login system, biometrics could be easily integrated. Though useful, it is important to note that biometrics function well only as a username, not a password. We leave our fingerprints and imprints of our face in digital media all over the world, so we wouldn’t want biometrics to be used in the way many devices use them today.
Unique Routing Identity
Locator / ID Separation Protocol (LISP) on the Network IP Address Layer decouples the endpoint identifiers (EIDs) from routing locators (RLOC’s), providing static addresses while roaming across many networks (Wi-Fi’s, Cellular, Satellite, etc.). By coupling the Sigchain with an EID, the routing identity of any node can be verified through the ledger. This prevents an endpoint from spoofing an EID, and provides the ability to discern the reputation and reliability of who one is communicating with. The result of this is the reduction of fraud, hacking, fake accounts, and identity theft for both consumers and service providers.
Signature Chain Process
A small amount of Proof-of-Work is required to create a Sigchain. The first event of every Sigchain is the creation of the Genesis transaction and the corresponding GenesisID which registers it on the Ledger Layer. A user can then create a register that represents an account, token, some other digital data or asset. The event is witnessed by a consensus of nodes that verify the cryptographic proof corresponding to the Sigchain.
The diagram below shows the transference of a patent register and the corresponding balance transfer of NXS. The transfer of the patent is conditional on the required debit or commitment of funds. If the validation script evaluates to true (REQUIRE DEBIT), then a temporal proof can be produced, allowing the corresponding OP_CREDIT and OP_CLAIM to take place.
Nexus Signature Chains
Why Signature Chains?
Sigchains create user-friendliness through a distributed login system. They facilitate account-based transactions which replace the clunky legacy UTxO (Unspent Transaction Output) architecture, making transactions and their corresponding verification process lightweight and efficient. They enable easy prevention of dust spam attacks, allowing for low cost transactions.
Sigchains also provide additional resistance to both classical and theoretical quantum computing attacks. This is achieved by updating the key-pairs after every transaction and obfuscating them until they are used. They also provide a key-management authorization system.
Different forms of reputation can be established and recorded by a Sigchain and verified through the ledger. These reputations can be referenced and utilized by other distributed applications. Sigchains are also fundamental to the recording of Trust which supports the security of the 3DC (Three Dimensional Chain).
Welcome to the next update of the TAO update series, to continue the journey through the development of the TAO Framework. This particular article is centered around Tritium, our version 3.0 software client.
Are we ready?
Alright, here we go. The following includes a list of all the most recent code changes since the last “git pull origin master”.
Wow, that’s a lot of changes. It’s interesting to look back on it and see how much has been accomplished. As shown here, there was a total of 5,885 new lines of code, with 3,980 lines replaced. This generally means that there was some older code replaced with new, better code, along with almost 2,000 lines of new and fresh code.
Now we get to explore what it is that was changed on the more granular detail level, to present to you what will be included in the Tritium update.
Since the last update, there have been some improvements to the Network, or the LLP in our instance. So what is it that makes the network important?
The network is responsible for all end-to-end communication.
If the network was unable to propagate messages, the core peer to peer network would be unable to function. The crypto (LLC) in our case is an overlay for certain network messages to deal with cryptographic objects such as our transactions or blocks. Let us look at the newest results of the LLP in action (you would have also seen this in my Tritium presentation at the 2018 Nexus Conference, linked here: https://www.youtube.com/watch?v=P2pdz4zO38k).
Here it’s good to see requests top out at 197,744 per second as the LLL is the foundation for the TAO, hence the repository name LLL-TAO(shhh, you’ll see the code soon enough if you can find it).
The next aspect of the Network that was formally demonstrated by Dino Farinacci is the LISP architecture, and how it fundamentally works together with the Ledger to provide a safer data layer on the internet. As we know right now, there are a lot of the same problems with identity: it used to be seen that the internet was a place full of fake accounts, trolls, and misinformation. Lately though, we have discovered that the internet can be full of amazing things and incredible possibilities for promoting the ideas of freedom and prosperity.
Now, one of the reasons the network has been plagued with the negative aspects is that there is no trust layer in the actual system. We have no way to identify someone other than their IP address which is easy to forge or fake by any means. This can create problems, because one cannot reliably know who they are talking to (this doesn’t mean they need to know personal information, but rather consistency across identities). Now, with tying LISP and Nexus together over the ledger, we create the ability to establish a cryptographic identity of the user. This happens over the network with the static EID in LISP, and over the ledger with a signature chain for a user. This becomes very important for reducing fraud and identity theft, which is one of the focal points for Nexus.
The ledger consists of the series of events that establish the ownership of any register in the stack. This makes the ledger operate very quickly, since it doesn’t have an incredible overhead in processing requirements beside general cryptographic functions. The biggest bottleneck of the Ledger falls under the LLC (Lower Level Cryptography), as this is where the cryptographic verification happens. The newest results of a Ledger scaling test (transactions only, no blocks in this test) shows over 4.3k tx/s capable of being processed by a single node.
This generates a good picture of what a full LLL stack running real transaction data over it would look like. This shows that the LLD is easily keeping up with the demand of writing over ~1,500 Kb/s (Bitcoin has a maximum of ~1.7 Kb/s). The reason for the slowness in Bitcoin is because of the block size limit of 1Mb every 10 minutes. In this case, we wanted to demonstrate the efficiency of the LLL stack in its capability to handle large loads of data. This particular example shows the maximum processing capabilities of one node, which essentially would be the limits of one L1 state processing channel. The signature aggregation being passed from L1 to L2 through L1 verification nodes in a 3DC would enable greater levels of the scalability without sacrificing the security of a global set of consensus validators.
Operating well, with a simple data structure that allows easy indexing and locating of the signature chain transaction history and identification of register ownership. Since the signature chain GenesisID is of a 256-bit number space, it is easy to transfer the permissions of a register to be owned by a signature chain, or simply another register. This sets the foundation now of the Nexus Digital Identity System.
Let’s recap what a register is for better context here:
A register is a data object that changes state through global consensus, or a logical layer application.
Why are registers important?
Computers are state machines by nature. They contain a value that correlates to something on the outside world and change this value based on a sequence of logic. I know this sounds complicated, but in reality, it is quite simple.
If I have 5 apples, I record this number in a register I own to prove I have these 5 apples. When other people can ask me how many apples I have, I can give them my register address, and they can see, ahh, viz. has 5 apples. Now if I sell an apple, let us say through an order I put on the network saying: I’ll give you this 1 apple if you give me 0.1 NXS, then we are able to have state changes recorded and verified by the network, correlated to financial transactions.
This means that if someone were to make this transfer into my contract order it could execute the state change of my total apples of value 5 to value 4, while I send off the apple to the lovely customer. This is a crude example, I know, but the intention of it is not to show secure program logic — but rather, logic that shows the use of a register on Nexus.
Now that we have gotten this out of the way, let us look into what Object registers have been defined as of this update:
Each of these 4 objects are objects that can have the state changed through the ledger consensus mechanism. This is important for Tokens, Escrow, Orders, and Accounts as I shouldn’t be able to modulate the balance of my account without approval from the network. The downside to having the ledger do all the state changing of the registers through the operation codes is the resource requirement of all nodes to process this state change and ensure that it does not create a conflict with another state. It becomes very important to find the balance between logical and ledger state changes, as the network doesn’t always need to know everything that the logical layer is doing, and the logical layer shouldn’t be doing everything that the ledger is doing. This distinction is important for understanding how Nexus Advanced Contracts will scale to levels of requirement for mass adoption.
Raw State registers on the other hand are defined through specifications on the Logical layer. They operate very quickly because nodes only need to write the data, address, and owner of the register. Only the owner of this register will be capable of writing a new state to it if it is not defined as read-only. This allows the Logical / Interface layers (The Application Space) to state record important data to their system such as hashes to IPFS files, private database transactions, or even to create authorization objects to modulate the state of their database based on user actions.
The following operations are implemented fully, with functionality that executes through the vchLedgerData data member of the Tritium Transaction class:
1. OP_WRITE: Write a new state to a register address given as a parameter to the operation code.
2. OP_REGISTER: Create a new register on the network. It must contain a unique register address, claiming it for this signature chain.
3. OP_TRANSFER: Transfer ownership of a register to another signature chain, or to another register address. This is an important function for establishing the ownership of data by signature chain, and the supply chain that moves it from one owner to the next.
4. OP_DEBIT: Debit a token from a given Account Object Register. This is the commitment of funds operation that gives the recipient the ability to claim with a corresponding credit. The balance of the debit that can be claimed is determined by the percentage ownership displayed through the temporal proof.
5. OP_CREDIT: Claim a balance referencing the transaction debit that was used to commit funds to the given receive account. If a credit is claiming a debit fund from an account they are joint owner of through register chain, a temporal proof is required to satisfy the display of their ownership.
The method that processes the operation codes is called execute:
This method is responsible for the changing of the states on the ledger level, as operations are instructions to the processing nodes to modulate the state of a register through global consensus. The operations and register layers are being designed to be processed on higher locking levels of the 3DC (namely L2), to ensure that transaction processing is broken up across multiple node layers which adds to our ability to scale the advanced contract processing.
If an operation code is followed by a validation script it will require the validation boolean logic to evaluate to true if an operation code is to be claimable as a proof. What this means is that a certain logic needs to be true for that operation to be claimed. An example would be, “Do not call me past 9:00 PM”, if one was to try and make a phone call the call would not be possible.
src/TAO/Operation/include/validate.h | 54 ++++++
A simple example of this would be relating to debits and credits, where one could put stipulations on the OP_DEBIT requiring the time to be of a certain point in the future. What this would result in is the OP_CREDIT satisfying this script by being submitted past the timestamp that was required. This allows one to program logic beyond the basic operation logic to create greater functionality and customization.
The Application Programming Interface will use what is termed JSON (Java Script Object Notation) to submit commands to the nodes that create these state changes in the register, resulting in program logic that gives us the ability to use advanced contracts.
The API will have two components, public and private.
This is important, as the public API will always be developed with public funds through the multiple Nexus Embassies, and provide the required functionality for public use. This will include most of the use cases and programmable logic.
The reason for this is for the integration of businesses that require some of their application logic to be more specialized as far as API functionality, due to the proprietary nature of their developments. This also becomes a “software-as-a-service” integration opportunity for an Embassy to generate additional revenue streams, in which the profits can be recycled back into the core development process.
Logical and Interface
The new Nexus Tritium Wallet is now in public beta. The launch of this has brought an incredible amount of feedback and bug reporting to improve the interface and logical layers. As many of you already know, we provide one common interface for such functionality, where any other distributed application developers will be able to develop their own.
The logical layer is where most of the processing gets done. It is an extended application space through the OSI.
It is important to understand this, because the idea of a blockchain carries many connotations that extend beyond just the ledger. It can coordinate many systems, have private networks that operate and state record off the ledger, access control schemes, state recording based on user actions, and the list can go on. We like to leave this area open for any new type of developers to extend their application space from the conventional OSI design.
What’s in Our Future?
As you can see from this blog post, most of the hard developing is now complete for Tritium. This means that we are in the stage of weaving together code over the network, establishing local databases to handle your sigchain and register indexes, and adding lower level RPC commands to interact with the Ledger, with the higher level API being the interface in the command set.
What does this mean?
Tritium will be released by the end of January, 2019. Yes — I said it — a timeline. As we have noticed over the last year, the removal of roadmaps and timelines did not do what was intended, it only created further uncertainty and rumors in the project. As we are moving into Chapter 3 of our history books with distributed Embassies, newer architecture, and distributed governance models, we felt it was appropriate to augment this with commitments from the development team to set and meet deadlines.
The new Nexus Tritium Wallet GUI (Graphical User Interface), which will replace the original Nexus QT wallet, debuts today in a public beta through October 27th, 2018. This new GUI is still in beta testing and should not be used as your primary wallet. The GUI is the second phase of the full Tritium release, following the Tritium Trust system integrated into the 2.5.1 wallet in September. This is the long awaited combination of new technology that Nexus has been developing throughout the year. Since the original vision, Tritium has expanded past these two phases to include the entire Tritium Software Stack which is in continuous development. Future releases will include Tritium Core with Signature Chains, Tritium Advanced Contracts and more.
Created by the Nexus developers Dillon Dugan, Kendal Cormany, Bryan Hallmark, Brian Smith, and Demorio Fluker, one of the most revolutionary changes for this wallet is the decoupling of the interface from the daemon (the back-end functionality tied to the Nexus blockchain). This significant advancement allows for modular design, separate updates, and enhanced ease of use for both developers and end-users.
The Overview page now contains a globe which shows your peer connections. Each wallet that your wallet connects to shows the city on the map along with the connection path. The globe can also be turned on and off based on user preference. Here you can easily view all of your important wallet statistics:
Currency value in USD
Number of transactions
Market price in BTC
NXS market capitalization
24 hour percent change
Number of connections
Staking information (block weight, trust weight, stake weight, interest rate)
The wallet also includes a send/receive module, transactions page, an address book, customization settings, market data, the trust list, and an integration with the Shapeshift Exchange, allowing you to exchange other cryptocurrencies and tokens.
The Console is a special module for developers that was a feature in the original QT. This is where you can use console commands such as: