In 1962, American spy planes discovered middle and long-range missiles in Cuba with capabilities to reach the United States. This only increased the fear of a global nuclear conflict. But it also did something else…

Back then, scientists were already connecting computers with each other, creating networks. It was still miles or even light years away from the internet that we know today, but it was a start.

Being the simple creatures that we are, humans tend to build and create things in the easiest possible way. Such was also the case with the first information systems of connected computers – the first ones built had a centralised architecture.

Soon people came to realise that whole communication systems with such architecture could be destroyed by removing only one central computer, say with a nuclear missile from Cuba. This was especially dangerous when it came to military systems. The US just couldn’t afford losing their means of communication during a potential conflict.

Centralised systems had to be replaced with decentralised systems.

This would be the perfect solution in case of an attack – a network would still be operative even if a few of its links were destroyed.

History Repeats Itself

This is basically where we are at on the timeline of blockchain development – recently we’ve realised that true decentralisation is the next step. Or should we rather say ‘only the first step’?

There is a popular saying, ‘History likes to repeat itself’. We couldn’t agree more. We also believe that further development of blockchain will mirror the development of the internet.

So, an important question we have to answer before predicting the course that blockchain will take, is: How did the first networks – the cornerstones of the internet – develop after becoming decentralised?

They became standardised.

Standardisation – The Key to Scalability

In order to enable development and growth of any system, the work needs to be based on some type of standardisation. First, to ensure the solution is compatible within the system, and second, to enable the connection of future systems and modules to this solution.

Without such a standard we would end up with one big, disordered mess of modules and frameworks which would be solving just one problem without considering the bigger picture.

To avoid such a hot mess, ‘The Basic Reference Model for Open Systems Interconnection’ (OSI) was developed in the late 1970s, and was published 34 years ago (1984) by the International Organization for Standardization. It’s very purpose was to enable easy scalability of the internet.

Three decades from now, people may very well describe the first standard that laid the foundation of blockchain scalability – the Tritium Protocol of the Nexus blockchain.

How Do the OSI Model and Tritium Fit Together?

Let’s address this one step at a time and focus on the OSI Model first. This Network stack is what the internet is built upon. Why a stack? Because it consists of layers, seven of them to be exact. Its functioning is fairly clear: each layer is served by the layer below it and serves the layer above it. The cooperation of these layers is what allows you to read this article.

The stack translates and interprets the stream of zeros and ones coming through your router, makes sure there aren’t any errors along the way from the server (and in case there are, it corrects them) and it aggregates the data in the correct order to finally be displayed in your browser.

Here is how it looks:

…and here is how it works (please note that this is only a rough explanation for the purpose of simplicity – the actual process is a little more complex):

The first layer is the Physical Layer – it’s responsible for transferring the data via physical means, say radio waves or electricity. Data Link Layer, the second one, is responsible for the communication between two physically connected nodes – it controls data flow between them and possibly corrects errors that might occur on the physical layer.

To manage the communication between devices across different networks we need the Network Layer (IP), i.e. this article is stored on a server which is most probably in a completely different network than your computer and the data must somehow ‘know’ how to get from one network to another.

The next, fourth layer, is the Transport Layer. It’s the one which is actually responsible, as the name suggests, for the transferring and receiving of data packets. Additionally, if packets don’t get transferred at all, or some other error occurs, this layer takes care of correcting such issues.

The next layer is really easy to understand – it’s the session layer. It establishes a session between two different computers of a network to enable the transfer of data. If we think of data as water that needs to get from one place to another, you can think of this layer as a hose.

Bear with us, we’ve almost made it.

Presentation Layer is the sixth one – basically what it does is translate the raw data provided by the previous layers. If one device was using ASCII to decode and encode files and the other was using EBCDIC, the translation would take place in this layer. Nowadays, however, many widely used applications and protocols don’t differentiate between this layer and the last one, which is the Application Layer – the closest one to the end user that can be interacted with, for example, a browser.

What does it all have to do with Tritium?

Well, similar to the OSI Model, Tritium describes a standardised software stack divided into seven layers. Its purpose is to enable scalability among other magnificent features we’re about to get into.

Layer One: Network

Remember the seven OSI layers we’ve just so elegantly outlined? Well we didn’t just do it for the kicks (although it definitely was fun, right?), but to ensure a better understanding of what Nexus is doing.

In the Nexus model, the Network Layer builds upon the first six layers of the OSI Model.

Here is where the true scalability of the blockchain begins.

Imagine you wanted to throw a party with some of your classmates, but not all of them. If you were a node in a decentralised network, you would first need to call every single one of them to let them know that there’s a party going on (regardless whether they’d be invited or not). That’s called unicast.

Nexus replaces unicast with multicast – now you can not only let only the invited folks know but also you can also make all these calls simultaneously. It might be hard to imagine with actual physical phone calls but it’s fairly comprehensible when thinking about sending multiple text messages at once.

Anyway, those are not all of the perks of this layer!

Decentralisation is good but it’s not good enough.

The keyword here is distribution.

Just as the internet ultimately went from decentralised to distributed, so must the blockchain. Otherwise, we’d still be vulnerable to critical single points of failure… cough, mining pools, cough.

Most cryptocurrencies are assumed to be distributed but it’s not all that simple. It’s because some devices (depending on the protocol they’re using) share the same public IP addresses which results in a decentralised network even if the assumption is to be distributed. Nexus realises this problem and adds the Locator / Identity Separation Protocol (LISP) to each node which maintains the desired distributed topology, regardless of the links’ location.

Layer Two: Ledger

This layer is essentially holding the distributed database (i.e. the blockchain) and all the benefits that come with it. It’s the basis for the introduction of Signature Chains which increase on-chain security and form a digital identity system. Thanks to them, users will be able to log into their accounts on any device using just a username, password and a PIN. There will no longer be need for a wallet.dat file.

This is a giant leap towards mainstream adoption of the blockchain technology.

After all, we’re used to being able to use online banking from anywhere and with any device. If we want to make banks obsolete someday, or at least degrade their influence, we have to replace their user-friendly solutions. We’re glad to see that Nexus is taking steps in the right direction.

Furthermore, with quantum computers on the horizon, Nexus makes sure that its system is also resistant against attacks. Nexus is basically untying public keys from the addresses, which means they can be used forever with the same level of security on the millionth use as with the first use. This cannot be achieved with multiple-used signatures, currently implemented in conventional designs.

Additionally, by tying accounts with a user’s signature chain and requiring a minimal ‘Proof of Work’ to create an initial account, Nexus can easily detect conflicting transactions, remove transaction fees, and prevent dust spam attacks.

Last but not least, this layer is also where the user’s reputation and trust are stored. They’re a key component in Nexus’ Proof-of-Stake and in its overall system. By introducing these mechanisms, Nexus incentivizes miners  to not behave maliciously. If you’d like to find out more about it, check out our issue on Nexus (NXS).

Layer Three: Register

To guarantee immutability and incontrovertibility, Nexus implements registers that live in the third layer. This layer is registering the changing states of raw data – like your balance or really any other type of data, such as medical records or intellectual property. It can be regarded as an additional level of abstraction.

Essentially, this means that anything stored in the register is gibberish without the proper interpretation of the higher layers – like the Logical and/or Interface layer. Thus we get a very facile way of performing various checks on privacy-sensitive data without actually compromising said privacy.

It’s the layer where all the fancy smart contracts will be saved – transfer of rights, ownership, value, etc. will all be recorded on this layer.

Layer Four: Operation

Any action on the register layer will be performed by the operation layer. You can basically view it as a toolbox to get things done. It implements all the necessary basic functions such as READ, WRITE, TRANSFER, AUTHORISE and so on. These operations will be computed on by nodes processing new data for the ledger, so using operations besides READ and WRITE ensures that you have a distributed computation happening as registers change states.

Layer Five: API

If you ever had anything to do with developing software that is supposed to communicate with another software program, you know how critical Application Programming Interfaces are.

If you hadn’t, well, in simple terms, API in the world of software development is what a waiter in a restaurant is. You sit down at your table, look at your menu, communicate with the waiter or waitress and (after a while) he or she serves you your meal.

To do all that you don’t need to know what happens behind the scenes – that would be the kitchen in our example. All you do is just give a fairly straightforward input and get a more or less complex output.

That’s exactly how APIs work. Well, once again, by ‘exactly’ we mean for the purpose of understanding it without going into the unnecessary technical details.

Now, imagine a restaurant without waiters. It doesn’t really make much sense. Well, neither does the internet without APIs.

A really simple example of an API would be you creating an account on some website by connecting it to your Google or Facebook account. The exchange of data between that website and Google or Facebook occurs via an API provided by either Google or Facebook.

Combining more APIs is even more exciting (if you’re the type of person getting excited by nerdy stuff which you probably are if you’re still reading) – think about that website where you can search for a flight across different airlines. The information you’re provided with after entering your desired location and time frame isn’t stored on that website – instead the website ‘asks’ all the airlines it possibly can via their APIs about your input query and neatly displays their answers as a result.

So what does Nexus do in its fifth, API layer?

Nexus lowers the barriers for adopting their solution. Their APIs will not only be designed with ease-of-use and seamlessness in mind.

The best part: They’re going to be programmable in any language the developer has mastered. Java? Check. C++? Check. Swahili and Latin? Double check on that! Okay, we might be getting a little over-enthusiastic here but it’s definitely justified. It would be like going to any restaurant in the world and being able to place an order in your mother tongue. Wouldn’t that be just mind blowing?

As we know, everybody has a different taste and not every API suits everyone. Requirements from various industries are what drive Nexus’ train of innovation. APIs for industries such as finance, copyright, or medical each have unique ranges of applications. Thus, industry-specific APIs must be developed.

We really appreciate Nexus’ approach on this matter. They’re planning on deciding the course of further API development after regular conferences, where people and businesses affected will get the chance to have a say in their respective matters. That’s what we call real transparency and giving people a voice!

Layer Six: Logic

This layer is the core application of the software stack. It’s where data can be encrypted, decrypted, interpreted and so on. Actions performed on this layer can be seen as the first domino being pushed, causing the next dominos in layers below to fall over.

If you think back to our neat restaurant simile, the API was the waiter. This layer would represent your thought processes before talking to the waiter. You don’t have to know every kitchen process, how the chef cooks, or how the waiter passes your order to actually place your order. This is why this layer can be described as the furthest level of abstraction.

Layer Seven: Interface

This is where you – as a user – actually come in. It’s the layer that allows you to ‘click around’ and interact with your data. For instance, this could be your balance, but as teased previously it could also be your medical record or whatever else that is stored on the Nexus blockchain.

Nexus will develop a stand-alone application so that users will have all the freedom necessary to customise an individual Interface. ‘Customise it with what?’ you may ask. Like anything they build, Nexus also created its new wallet in a modular fashion, enabling development of new modules.

These will cause their ecosystem to flourish, since on the one hand, users will have plenty of modules, and can select  the one that best suits their needs. On the other hand, programmers will be able to monetise their work by developing said modules. We believe that that’s another great step in the direction of diversifying the Nexus platform.


Nexus is creating a platform with the potential to become the cornerstone of many blockchain-based applications, businesses, and even whole industries. The Tritium update boosts our confidence that Nexus is on the perfect track to achieve that.

With all the fantastic features and perks, such as fee removal and amazing API considerations coming with this update we’re sure that Nexus, under the lead of Colin Cantrell, is capable of achieving greatness and paving the way toward a transparent, blockchain-based future.

Written By: London Letter