During the month of June Nexus released the Nexus Wallet, a product of years of work culminating into one of the fastest crypto wallets available, being 20x faster than the legacy version.
Our developer team has been busy testing and optimizing the code of Tritium, which began security audits with ISE on July 22nd. We expect this audit to take at least 4 to 5 weeks. After the completion of the audit, we will assess how much work is required for full deployment, and at this time we will announce the official Main Network release date. This release will be a mandatory upgrade for all nodes, which will contain an activation timestamp of 2 to 3 weeks, in order to give all nodes and exchanges ample time to upgrade.
Many of us got involved with Nexus due to our vision of placing satellites into LEO, and the pursuit of the decentralized management of hardware that powers the Internet. Back in 2016, in a famous tweet, Jim Cantrell stated: “The deed is done, Bitcoin in Space”. As this dream has experienced a few delays, we would like to inform you of the current outlook.
Galactic Sky is a software defined satellite platform by which you can upload any type of software to the constellation, in order to provide greater access to satellite technology without the cumbersome requirement to deploy, manage, and operate a constellation. Think of it like AWS (Amazon Web Services) in space. As this is a very unique technology, naturally Vector has obtained patents, and thus is the only company in the industry capable of deploying it. As many of you know, in mid 2017, Nexus signed an MOU with Vector to pursue a technical partnership with not only a focus on satellites, but also the application of blockchain technology for the management of the constellation. Some of the current areas of exploration include:
Hosting Nexus on the constellation to provide greater access to Nexus, while adding additional redundancy to the network.
Utilizing Nexus as a means to tokenize the ownership of Galactic Sky to manage split revenue payments from fees earned.
Using Nexus to improve the process of authorizing access to the constellation.
Vector has just closed its Series B financing round, and is rapidly moving closer to their final C round before their first launch scheduled later this year. Galactic Sky is set to deploy its first 6U satellites in late 2020, which will begin the important move towards realizing the potential of software defined satellites. We are very excited to be working with Vector on such an important milestone in the satellite industry.
Two Zoom meetings took place, where the fee model of Nexus was discussed, and a demo of the DEX was shown. To view the recordings, please follow the links below:
Recently we have held fewer zoom meetings as the team has been very busy polishing the code for submission to the security auditors.
The Nexus Wallet passed its first security audits, and was released on June 26th, 2019 at 4:44 PM GMT – 7, with many stating that it is one of the best wallets they have encountered in crypto. We are grateful for such a positive reception!
The Nexus Wallet provides a platform to install and create modules using APIs that will be released with Tritium, giving access to features such as Contracts, Tokens, Assets, and Decentralized Exchange. Modules can also be built using other available APIs, such as those for trading dashboards or alternative cryptocurrency wallets.
To download the latest version (1.1.0), please follow this link:
Over the last couple of months, there has been discussion surrounding the Nexus fee model. The current view is that part of the fees earned from decentralized solutions provided by Tritium will go to validators, the other would be locked up in a reserve, the release of which will be voted on by the Nexus DAO. We welcome anyone who would like to contribute to this field to join the economics working group.
Nexus is developing many decentralized solutions such as supply chain tracking, secure data recording on a hybrid network, watermarking, and a new backend for web services. Other services, such as the recording and the exchange of assets, and the licensing of digital media, and music royalties, will depend on the exchange of NXS. It is necessary that the exchange of assets priced in terms of NXS is variable relative to BTC or Fiat, in order to make transacting viable. The seller of an asset or token will be able to peg the required NXS to a field in an object register that their wallet updates to reflect the NXS price in terms of BTC or Fiat. The buyer would then be the “check and balance” that decides if the price is fair.
Component Based Web
Currently, our website (nexusearth.com) is a combination of many facets, spanning Technology, Enterprise, and Community. As a movement towards a more decentralized management of content, we have begun to separate the main site into three core components namely: develop.nexus.io, enterprise.nexus.io, and community.nexus.io.
Each of these components will operate independently of one another being managed by their respective teams. We see this as an important step forward in tailoring content to groups that hold specific sets of values.
The current website will become the enterprise component. The next component to be released is community.nexus.io. If anyone would like to help with the community website, please join the website working group. The final component will be develop.nexus.io, which will be focused on how to develop on the Tritium Software Stack, including documentation, code examples, and tutorials to build with contracts. If anyone would like to help with the developer website, please join the developer working group.
All three subdomains will link from a bridge or landing page, nexus.io. The eventual goal is to use the L5 stack, standing for ‘Linux Lower Level Library & LISP’, to serve as the foundation for our component based design.
TNS Integration with nexus.io
TNS (Tritium Name System) is a global naming system that will provide the opportunity to purchase a global namespace, which could be compared to owning a specified domain extension, such as *.io or *.com on the Nexus network. Names can then be created in this namespace, that point to IP addresses, or accounts, in order to transact without having to use large hexadecimal addresses such as:
An example would be, send coins to nexus::checking
Namespaces can also be local to the username which can be created for free without a limit. This would be accessed by using a single colon, such as send coins to viz:checking.
TNS will serve the above mentioned component architecture, which will be used through the nexus.io domain name to register subdomains in the nexus.io namespace. The result of this will be a decentralized DNS management of subdomains or components of nexus.io, which will further decentralize the content management and ownership of the main nexus.io domain. This serves two main purposes:
Integration of TNS into existing DNS systems through the use of bridge domains like nexus.io
The decentralized management of components built on the L5/TAO framework, that uses Nexus as an authorization and permission system.
Though this is a longer term implementation, it holds great promise to improve the dynamics of content contribution for websites like Wikipedia, blogs, and social media sites.
Our main Tritium++ feature, the DAO (Decentralized Autonomous Organization), will govern project funding through a democratic vote. The feature will be released as a post-Tritium hard fork. This technology is necessary for a stronger community, consensus-oriented fund allocation, and improvements to the overall governance of the network. The DAO will prevent governance issues such as hard forks (Bitcoin vs Bitcoin Cash), and it will create a stronger ecosystem through community participation in decision-making, resulting overall in a more resilient and secure public network.
The DAO has been discussed in recent Zoom meetings to gather input and to explain how it could function. We welcome anyone who would like to contribute to join the social working group. The underlying architecture is in its final design phase, and currently we see it following the below principles.
You will be able to abstain, vote, or withdraw your support for a contract (the frequency of voting is yet to be decided). Votes will be weighted by Trust and Stake. Therefore, your power to vote will be determined by your total NXS staked, combined with your Trust. This protects against gaming of the voting system by short term holders of NXS. Likewise, anyone with an adequate amount of Trust, will be able to submit a contract.
Voting will be done in groups, where the values of people and the resources that they contribute to the network define the group. The first two voting groups will be: Trust and Ambassador. More groups will be defined and added over time.
The Trust group will decide the percentage of funds allocated to each of the contracts. Voting is zero-sum, meaning that contracts can only gain voting weight, by another losing it. You will have a total voting weight, which can be allocated by percentage to the contracts you wish to support. An example would be 35% to the U.K., 35% to AUS, and 30% to the US Embassy.
Contracts will become active when they exceed a voting threshold, creating resilience to individual gaming if one voter happens to have a large voting weight.
When the round of trust voting has finished, the Ambassadors of the contracts can then vote to either endorse the support for their contract or to redistribute funds to other contracts. This will allow Ambassadors or Embassies to reallocate part of their funds to other contracts, if they choose to do so.
This is an important step towards the longer term sustainability of the Nexus Ecosystem, and the creation of direct accountability of those who are paid to complete work on behalf of the community. In order to fully maintain an active contract, Ambassadors or Embassies will be required to uphold the utmost transparency, accountability, and performance necessary for continued public support. This will prevent the mismanagement of funds, corruption, coercion, and complacency that can arise in a large organization making the management of the funds of Nexus open, and mathematically enforced.
Tritium Wallet Features
Tritium will introduce many new features to the wallet, most notably the move to account based transactions provided by Signature Chains. Below is a reminder of what is to come.
A signature chain is a personal blockchain accessible by a username, password, and pin. This means you can access your wallet anywhere, simply by downloading the app and logging in. Logging in to a Signature Chain will be like accessing a banking app, without the requirement of providing a centralized service with your personal data (birth name, birthdate and passport details) in order to set up an account.
Signature Chains allow a user to create a digital identity on the Nexus Blockchain, and to transfer and prove ownership of assets (tokens, titles, certificates, licenses, domain names etc) through Contracts.
A PIN is requested every time a transaction is made (unless the wallet is unlocked) to increase security, much like using a bank card.
The wallet will have a password recovery system, where you can set a ‘master seed’ or a ‘recovery phrase’, (either 10, 20 or 100 words). The master seed phrase provides extra assurance, enabling one to recover their account in the event of a forgotten password or compromised account. You will only be able to change the master seed phrase if you know it.
Speed and Scalability
Signature Chains replace the clunky UTxO (Unspent Transaction Output) architecture, and are a fundamental component of the Nexus 3D Chain. Along with this, our blocks decouple transactions resulting in them only holding a hash (32,263 transactions per 2MB block) for each transaction. Together these innovations produce lightweight, efficient and extremely fast transacting, without the requirement of off chain, centralized scaling solutions, or a large block size. Nexus also removes the need for a wallet.dat for key storage that is commonly required in legacy blockchain systems.
The key pair to your Signature Chain is changed with every transaction and the public key is hidden until used. The result of this is a high security standard with support for multiple signature schemes such as FALCON, and hardware password managers for increased Quantum Resistance. In the future the wallet will also be able to support biometric usernames.
Prevention of Sending to an Invalid Address
The Nexus Wallet already verifies addresses upon entry, though this doesn’t confirm that an address is in existence. However, with the implementation of Signature Chains, transactions are required to be claimed (signatures are required from both sender and receiver), resulting in a two-step validation process. This is to prevent people from losing funds that are sent to non-existent accounts, and the burning of NXS.
A sender is required to set a time window in which the transaction has to be accepted. This can be configured for each transaction, or alternatively a certain time window can be set as default. All that is required from you to acknowledge a transaction is to login to your Nexus Wallet during the time window, and accept the transactions you wish to receive in the notifications page of the wallet. Alternatively, you are able to set the wallet to automatically accept and claim new transactions, and specify which accounts to credit to.
In a case where the time window expires, the NXS is claimable by the sender, which prevents NXS from being lost if either sent to an invalid address, or if the recipient doesn’t accept the transaction within the set timeframe. Transactions will be reversible if the recipient has not claimed within the set timeframe. The sender then redeems the funds by claiming the transaction back to themselves.
There has been quite a lot of content written over the past few months, in an effort to educate people on the importance of the technology of Nexus. We are now focussed on writing content detailing the decentralized solutions provided by Tritium, and welcome anyone who would like to help in this area to join the use case working group. Below is a summary of the new content that has been published on the website.
The Three Dimensional Chain
Fundamental to the scaling of contract processing is the seven-layered Nexus Software Stack set to be released with the Tritium upgrade, which introduces the first iteration of the 3DC as the Ledger Layer. The 3DC is a promising candidate to solving the “Blockchain Trilemma”, an opinion that only two of the three qualities, Security, Decentralization and Scalability, are achievable concurrently. We call it the “Three Dimensional Chain (3DC)” which transforms the Ledger into a multi-layered processing system, in order to scale the protocol securely with a high degree of decentralization.
With the rise in the power of classical computers and the emergence of quantum computers, public keys are becoming increasingly vulnerable. Most cryptocurrency addresses are created by hashing or obscuring the public key, however, once a user transfers funds from this address, the public key is then revealed on the blockchain. In the realm of classical computing there is little risk with this method. However, a Quantum Computer running Shor’s algorithm could break most public key cryptography in little to no time at all, resulting in funds being stolen. Though most conjectures range from five to ten years before security could begin to break, Nexus has prepared by integrating a number of cryptographic innovations that support increased levels of quantum resistance.
LISP (Location Identifier Separation Protocol) is a protocol designed by a small group of Cisco engineers who were deeply involved in the creation of the internet. It provides important advancements to the network layer, and many necessary features for ease of use, decentralization, security, and scalability.
The last few months have been very productive as the launch of the Tritium Main Network nears. We invite all to get involved with our social media channels, keep an eye out for tweets, and to make suggestions if you believe Nexus can be improved in any way. Together we continue to design decentralized solutions, and work to build a shared vision of the future.
Nexus is implementing an architecture that is a promising candidate to solving the ‘Blockchain Trilemma’, an opinion that only two of the three qualities, Security, Decentralization and Scalability, are achievable concurrently. We call it the ‘Three Dimensional Chain (3DC)’ which transforms the Ledger into a multi-layered processing system, in order to scale the protocol securely with a high degree of decentralization. It chains together cryptographic primitives into a three-dimensional immutable object (a 3D block), and has three core dimensions: reputation channels (X), immutability or authenticity (Y), and time (Z). This architecture is being deployed through the TAO framework.
Fundamental to the scaling of contract processing is the seven layered Nexus Software Stack set to be released with the Tritium upgrade, which introduces the first iteration of the 3DC as the Ledger Layer.
The architecture of legacy blockchains is comparable to driving a car on a single lane highway – as the volume of cars increases, traffic occurs. Nexus views ‘scalability’ as a requirement, not a feature. Therefore, we design protocols that scale as more nodes join the network, processing unhindered even with the increase of resource requirements.
Using ‘Signature Chains’, ‘Aggregation’ and ‘Computational Sharding’, the 3DC creates parallel lanes of transaction processing to produce the L1 layer, the base layer of the 3DC. Data is then stored between many nodes using what we term ‘Data Sharding’, which eliminates the need for synchronizing and storing the entire blockchain. ‘LISP’ (Location Identifier Separation Protocol) and the ‘LLL’ (Lower Level Library) together form the common interface for this, which results in an increase of data storage as more nodes join the network providing longer term scaling potential.
Nexus transactions no longer use the UTXO (Unspent Tx Outputs) architecture, where you have outputs from one transaction being inputs to another, resulting in a large amount of expensive signature verifications for even small transactions. Though UTXO was an important cornerstone of the Bitcoin architecture, it has proven to be outdated and vulnerable to many different types of attacks and scaling limitations.
As a move away from Legacy Blockchain architecture, Nexus has designed and implemented an architecture named Signature Chains, which act as personal user-level blockchains that contain all of your data as one unique chain. This architecture provides higher scaling characteristics, as only one signature needs to be verified per transaction. Conversely, a single UTXO transaction could contain 1000’s of inputs (and therefore require 1000’s of signature verifications), in order to transact even a small amount of coins (< 0.00001). Additionally, Signature Chains don’t require wallet files, as they are accessible by login credentials (username, password and pin). This verifies authenticity and identity of individuals (through reputation) on the network, without sacrificing privacy.
Transactions in legacy blockchains are not only referenced in a block, they are also transported with it. Though this does contain some positive characteristics for processing, it limits scale as transactions require transport twice, once when created, and again when the block itself is broadcast. In order to combat this inefficiency, the Tritium protocol stores the transaction object separately from the block object, and references its txid inside the block. This is the first form of ‘Aggregation’, that means that a single reference can represent the entire transaction, which reduces the data that is transported in blocks. This results in better levels of scaling, and improved security by lowering the probability of successful Finney attacks on the network.
Computational Sharding is necessary for the division of work between specific types of nodes, to create ‘lanes’ which process data in parallel comparable to multiple lanes of a highway. Though computational Sharding is powerful, it can be insecure if implemented incorrectly. The reason is that a ‘shard’ is easier to dominate than an entire network, as it is smaller. The way to resolve this is through the use of a multi-layered ledger (explained in Security) inherent in the 3DC. Layers of consensus allow the shards below to be smaller in size than those above, and ensure that conflicts can be resolved to prevent attacks.
Data Sharding is the division of data to be stored between many nodes. This can be thought of as having many warehouses to store packages (data) after they have been transported (computation). Due to every object being ‘verifiable’ by its index hash, the 3DC can provide Data Sharding with limited trust in remote nodes.
The difficulty is, how is the state of so many objects and shards managed? The use of LISP solves this problem. The method by which the 3DC performs Data Sharding, a ‘network’ is created that exists everywhere, where instead of ‘IP’ addresses, you have ‘Hashes’. This could be compared to typing in a txid in your web browser, and receiving that transaction. Using LISP in this manner, we would enable the browser (or LLP in network terms) to open a connection to a hash, which would point to the group of nodes that held that particular piece of data.
The end result of this is, a user can login to their node that has never communicated with the network before, generate their ‘genesis-id’ from their username and open a connection to this hash, which would then use the existing internet to route to the node that contained this particular piece of data. The beauty of this is that the network itself doesn’t need to add superfluous data synchronization across nodes to know where data is held. Nodes use the overlay to route requests to other nodes, resulting in IP addresses as hashes of data that exists in the wonderful world of Nexus.
Data sharding is an essential facet of the 3DC in order to achieve long-term scalability. Amine will provide the opportunity for nodes to run in ‘shard mode’, lowering their disk and memory usage even when the network is experiencing high load. Data sharding in Obsidian will extend to critical network functions, resulting in nodes being required to store only a portion of the entire chain.
Additional to the cryptographic structures, the Internet, must be capable of routing efficiently. We utilize what is termed ‘IP Multicast’ which allows a single broadcast of a message to be initiated by a node, rather than every node needing to replicate the message as it is verified. This can be likened to a public speaker broadcasting a message to an audience (multicast), rather than having a one-on-one conversation (unicast), where the message is gossiped from one person to the next. You can imagine how this would not only improve the scalability, but also the integrity of the message (as gossip doesn’t always reflect the original conversation). Packets and transactions will route in constant time no matter how many nodes are part of the system.
The LLL is the foundation of the TAO Framework, which powers many of the protocol’s subsystems. It includes three core components.
The Lower Level Database (LLD) is Nexus’ fast and modular storage engine, which to the best of our knowledge, is capable of outperforming most existing embedded database engines. Our average results are around 0.33 seconds for 100k writes and reads to disk (one then the other). This rivals other storage engines such as Google’s LevelDB.
The Lower Level Protocol (LLP) is a fundamental component of the Network Layer, a light and fast protocol that allows a developer to customize their packet design and message interpretation. It gains scalability through simplicity, and is capable of managing a large number of concurrent connections.
The Lower Level Cryptography (LLC) is a light and efficient library that contains many useful cryptographic functions such as Post-Quantum Cryptography, AES and Argon2. The library provides an easily accessible set of high performance cryptographic functions to ensure maximum scaling potential. An example would be our benchmarks of FALCON (used in the TAO) that verified 150k signatures/s on a consumer grade apple laptop, where ECDSA (used in Bitcoin, Ethereum, etc.) performed only 4k signatures/s.
Nexus employs multiple consensus systems that ‘check and balance’ one another. Diversity strengthens the gene pool of the human species, likewise it is an equally important property for the security of a decentralized system.
The 3DC is designed as multiple layers of transaction processing or ‘consensus’, and each of the layers aggregate data from the layer below. The nodes performing work on L2, resolve any conflicts in L1 shards, using ‘Stake’ and ‘Trust’ as the ‘Weight’ to determine consensus. In the event that there is a conflict, it is resolved through the validity of data, which is defined as (Trust + Weight). The L3 layer will consolidate hashes from L2 to create the final 3D block.
Nexus considers the use of cryptography very seriously, as a flaw in these functions could render the entire network insecure. We only employ well tested and thoroughly peer reviewed cryptography, all of which have survived at least the first round of crypto-analysis at NIST competitions.
Trust and Weight
Trust is defined as the total time a specific user (Signature Chain) has been contributing to the network. This time is measured by the consistency and availability of a node to validate transaction data.
Weight is defined as the real time resource contribution that a given node has provided for a one time transaction process. This can be measured in computing cycles through Proof-of-Work (PoW) or other resources such as ‘Stake’ that incurs a cost to provide.
As transactions are received by the network, nodes start verifying them immediately. The transaction speed of L1 channels will vary based on the risk that a merchant wishes to assume, ranging from sub-second speeds to five seconds. For higher value transactions, it will be recommended that they receive additional weight from validation on the next consensus layer: L2, reducing transaction speed to 15 seconds plus.
pBFT + PoS Trust Network (L2)
As an extension to the existing Proof-of-Stake system, L2 will form the second layer of consensus above L1. The L2 layer ensures safety and liveness, cross-shard communication, and resolves conflicts from the L1 layer. It represents the horizontal chaining of L1 channels, and is a major step towards a truly decentralized and scalable ledger.
Decentralized Mining Pool (L3)
This layer will use PoW based mining shares computed from the work performed by the nodes of L2. Consensus will be determined by the largest value of shares + Trust, in order to reach a final agreement on the most valid 3D block.
Checking and Balancing
In order to have the highest degree of security, decisions cannot be concentrated in one form, as this creates the ability for ‘coercion’. If there is only one form of cost that provides security, the system can be easily dominated due to limited ‘checking and balancing’. Bitcoin is a prime example of a victim that is suffering from resource domination or ‘centralization’.
As can be seen from the link above, four organizations control more than 51% of Bitcoin’s hashrate, meaning, that the entire security of Bitcoin is reliant on them and the decisions that they make. This situation is an example of centralization resulting from resource domination, which has lead to proposed solutions such as UASF (User Activated Soft Fork) and multiple Bitcoin forks such as Bitcoin Cash, Bitcoin SV, Bitcoin Gold, etc.
Though promising, UASF was unable to reach a level where it could be effective, as the required percentage of miner’s consent was too high.
The copy/paste mentality of source code used to create many cryptocurrency projects has led to many critical flaws in security. Below is one such example that created a pandemonium for hundreds of projects that inherited a flaw from Zcoin.
Nexus employs the following cryptographic functions: FALCON (a second round contender for the NIST Post-Quantum cryptography competition), Argon2 (winner of the password hashing competition, and a superior alternative to S-Crypt or B-Crypt), and Keccak (winner of the SHA3 competition).
We also do not rely on the security of only one cryptographic function for the security of the entire system, and treat every public key as disposable once used. This means our security uses many different layers of redundancy to provide protection, in the event that one of them becomes vulnerable. Relying on a single private key for security is a ticking time bomb, though this approach is largely used by most blockchain applications.
Signature Chains decouple key management from the user account, meaning that with the click of a button, you are able to change the type of key that your account uses. This gives users the option to use Post-Quantum cryptography such as FALCON, or the option to use more time-tested Brainpool curves. If there were any flaws found in either of these cryptographic schemes, you are able to change with ease your key type.
These safeguards are important in order to protect systems over time, as ongoing crypto-analysis are always finding vulnerabilities and attack vectors that will begin to break cryptographic standards.
Many protocols have moved away from PoW due its large energy requirements Its very competitive nature also leads to an increasing amount of resources in order to search for a block, as the traditional model of PoW only rewards the winning miner of each block, which incentivizes miners to pool resources.
An alternative is EOS’ Delegated Proof of Stake, though it relies on only twenty-one block producers, yielding a low degree of decentralization. There are several solutions that have been proposed for the scaling of a blockchain: Bitcoin’s Segregated Witness and Lightning Network, and Ethereum’s Plasma. Though promising, both essentially depend on off-chain solutions to provide scaling (a more centralized approach). They create payment channels or ‘side chains’, that rely on a small group of verifiers to recommit updated balances. Younger protocols have proposed multilayered systems, though we are unaware of any designs that place as much emphasis on Decentralization as the 3DC.
The 3DC aims to improve decentralization through many methods that include; L1 Reputation Channels, Decentralized Pools on the L2 and L3 layers, Reputation Incentive Structures, and Peer Discovery.
L1 Reputation Channels
L1 Reputation channels are designed to require a low amount of resources in comparison to the L2 and L3 layers. This is to enable the use of smaller mobile devices which in turn will provide higher levels of decentralization. This is possible as the L2 consensus layer above adds weight to ensure the security of the channels below. Reputation is the final ingredient that the 3DC employs to maintain security while achieving high levels of decentralization. It is aggregated through all three layers of the 3DC, to quantify the ‘validity’ of the 3D block.
Decentralized Staking Pool (L2)
The L2 layer is the core of the 3DC that manages data aggregation and contract processing. This layer also receives shares from the miners on the L3 layer above, in order to accumulate their work and reward the miners collectively. The more shares that are included from the L3 layer, the greater the accumulated Weight and Trust will be for the given 3D block. Therefore, the 3DC incentivises L2 validators to include as many shares as possible to ensure that their 3D block is accepted as the most valid in the 3D chain.
The L2 layer is driven by a ‘Proof-of-Stake’ weighting, that identifies all nodes in the consensus process as contributors, and therefore produces a higher degree of decentralization compared to existing Proof-of-Stake (PoS) protocols. The 3DC will require a lower minimum balance in order to stake with than the current PoS protocol.
Decentralized Mining Pool (L3)
Instead of miners having the authority to determine the next block by finding the winning hash, mining will become a group-wide activity forming the L3 layer of the 3DC. Miners who submit hashes to the network perform work that locks the L2 cross links. This provides the infrastructure for a more decentralized consensus process, while also inheriting the positive properties that mining offers.
Any blockchain relies on the ability of nodes to connect directly (peer-to-peer) to maintain a decentralized and evenly distributed topology. Therefore, nodes must be able to be discovered by their peers, by being able to accept connection requests. Though this is not a novel concept, it is pivotal to peer-to-peer networks and yet is seldom achievable, due to the need for NAT (Network Address Translator) traversal logic which is why Bitcoin has only a meager 10% of nodes that are discoverable.
Alternatively, Nexus uses the LISP Overlay for ‘NAT traversal’ to maintain higher levels of node availability. LISP uses static Endpoint Identifiers (EIDs) that can even be reached when roaming between different networks (WiFi, cell towers, etc.). This gives nodes higher levels of mobility, allowing them to be located anywhere on the internet, behind NATs in residential environments, in cloud providers, and behind mobile carriers while still being discoverable.
Reputation Incentive Structures
Reputation is an important requirement for the functioning of decentralized systems, in order to create a healthy global network. We will implement reputation on all three layers of the 3DC, as a secondary component to Weight to improve the overall Byzantine Fault Tolerance. Of equal importance, reputation can improve the decentralization through incentive structures facilitated through variable rewards to nodes that have earned a higher reputation. Longer term contributors to a system can be awarded a higher reputation, and therefore a higher return for their contribution, giving rise to a long standing view of Nexus that:
We are currently unaware of any other multi-layered architectural design that combines both PoS and PoW, that integrates the LISP Overlay, that is able to provide data sharding, or any technology similar to that of Signature Chains. Combined with the seven layered Software Stack, the 3DC holds promise to be a highly scalable, secure and decentralized contract engine fit for global adoption.
The Software Stack, set to be released with Tritium, provides an easy to use API interface to build with Contracts that can be used for a variety of decentralized solutions, including the registration of digital assets and certificates, supply chain management, graphic licensing, educational certificates, royalty payments and Securitised Token Offerings (STOs). We envision that this technology will aid in the distribution of resources to more people, so that they can benefit from all the exciting innovations that blockchain is able to provide.
The architecture of the 3DC is inspired by ‘Metatron’s Cube’ that depicts the five platonic solids, which are geometrical forms that are said to act as a template for all life.
The team has been refining and finishing the API, with respect to contract scripts, batched transactions, and our new API standard. There is a debit/credit function for fungible tokens, and a transfer/claim function for non fungible tokens (assets). Validation scripts then determine the logic, which create a decentralized exchange (i.e. in order to sell/buy an asset, limit how much can be withdrawn from an account per day, or how much to send to a particular account per month).
We have also been working on the interface for staking functions, so that one can move coins more easily from a main account to a trust account, for example.
The API will contain an events processor that will automatically respond to notifications to accept and claim new transactions. The user will be able to configure the settings of the events processor, i.e. to specify which account to credit to.
Now a whole set of transactions can execute in one transaction that clears at once, such as all of the transactions of one split-revenue payment. This will all be actioned in one API call.
Tritium Name Services (TNS)
Tritium name service will allow users to exchange human readable text that represents account addresses, rather than sending QR codes or large hexadecimal formats. This will allow accounts to be identifiable by your own local names eg. Checking, Savings, Trust, Payroll, etc. There can only be one of each local name per username, which is useful for managing personal accounts. Therefore, when you request a payment from someone, you can either give them the register address or you can ask them to send the payment to paul:savings, for example.
When Paul creates an asset such as ‘MyContactInfo’, it will be retrievable by the register address (QR code or hexadecimal format) or by its name prefixed with the username of the signature chain that created it, e.g. paul:MyContactInfo. The username prefix is required to allow two different users to create with the same name.
Tritium name services will also provide the option to purchase a global namespace which could be compared to owning a specified domain extension, such as *.io or *.com on the Nexus network. The namespace registration will require a fee, which we plan to burn to enrich the entire network.
Once a user registers their namespace, they will be able to register any name within it such as asset.io, which can then be sold to another user as an asset on the Nexus DEX. This provides the opportunity for ‘investors’ to purchase namespaces, and gain ROI by reselling desirable unique names inside of their namespace. We anticipate this to be like the ‘DNS’ (Domain Name Service) of Nexus.
The name object itself will have fields in it that can be updated which point to register addresses, your public-id, or other convenient types of data. Being the owner of the name object, you will have the freedom to change it to whatever you see fit, similar to updating a DNS record when you own a domain name. This opens the possibility for name objects to point to IP addresses, meaning that TNS could eventually be integrated with existing DNS nameservers.
The team implemented the first stage of hybrid mode on a private test net, with multiple nodes connected together on their own private chain. Previously, private mode functioned on a single node. Each of the multiple nodes are ‘permissioned’ to sign and create a block which is then propagated to all the nodes in the private network. We have been demoing this and some basic applications, for some of our use cases.
Paul, Mike and Alex met with the USA based team to discuss the DAO, fee structures for Tritium, architectural designs for Amine, and to hold a briefing and planning session with the business development team.
We propose that the following services will incur a fee:
Permissioned Access Schemes for Hybrid Networks
Creation of an Asset
Creation of a Token
More than 2 transactions made per block
We propose that the fees are burned which will result in a reduction of the total supply of NXS to enrich the network. The fee amounts are undecided, and will vary in response to transaction volume. An increase in transaction volume will decrease fees, rather than increase fees like Bitcoin. We welcome all perspectives on this topic. Please contact @Jules to join the economics working group.
Small load test on one computer
Mike made a video showing the local API server receiving 150-200 HTTP requests per second, processing the JSON to turn it into a transaction. The tests are creating an asset object register with a random name, and is then relaying those transactions to the other nodes on the network, which in turn verifies the transactions, sequences them correctly by signature chain, and then packages them into a block. It is handling 150+ transactions per second with a single node. The limiting factor of this test is that Colin’s machine can’t generate the test transactions any faster!
Since early March the tritium testnet has been functioning with the primitive core APIs and Operations, and we are now engaging with a security firm to perform a code audit. They will start an audit on the staging branch (tritium beta running over the legacy rules), and the wallet.
The Proof-of-Stake system is almost complete. The reward earned now goes to your spendable balance, whereas your stake remains locked up. If you make a transaction that withdraws from your stake account, it will result in a partial loss of trust, depending on the percent withdrawn.
Recovery of Signature Chains
We have designed a method for password recovery, by developing into the signature chain a ‘master seed’ or a ‘recovery’ phrase, which will be 20 words (128 bits of entropy), similar to hyper deterministic wallets for Bitcoin. The master seed phrase provides extra assurance, enabling one to recover their signature chain in the event of a forgotten password or compromised account.
With the implementation of signature chains, transactions come to your sig chain and then you are required to claim them. This is to prevent people from losing funds sent to non-existent accounts. All transactions will have a timeout after a certain duration which means a transaction can be returned to the sender if somebody doesn’t accept it within the set timeframe. This technology is facilitated through the use of validation scripts, that essentially are appended at the end of a transaction that specify its behavior or anything that is trying to claim it. One can debit or credit back to oneself as transactions are by nature reversible. The validation script will specify the time frame the transaction can return to the sender.
Object registers are now complete and running in the core, which allow user defined type-safe objects. They will combine together data members that are either mutable or immutable, and will be accessed or modified through different formats in the API such as JSON or XML.
Validation scripts operate on a 64-bit register virtual machine, whereas Ethereum operates as a 256-bit stack virtual machine. In this case, Ethereum has gone beyond the hardware’s limits which has lead to major slowdowns, being that the processor can only operate natively on 64 bits at a time. To add to this, an Ethereum account balance uses 256 bits, where a balance is unlikely ever to need more than 64 bits. This creates a massive bottleneck in the processing of every account on Ethereum, which is one reason they have found troubles scaling. Our register virtual machine performs at 30 to 50 nanoseconds per instruction, compared to an average instruction time on Ethereum being on the order of 1,767,258 nanoseconds. You can read in the article below about how moving gas computation to 64 bits, increased the Ethereum virtual machine performance by an order of 70%. This shows that using 64-bit CPUs to synthesize 256-bit arithmetic, produces significant performance losses for no apparent advantage.
SDKs (software development kits) are written in a native programming language, and are abstracted on top of the API, allowing one to make native calls to access the functionality of the actual API. Dino has been working on the Python SDK, and Daniesan on the C# SDK. We hope to see more community involvement in the development of SDKs. It is simplified to port into any language without having to handle the HTTP protocol. The API also will contain an ‘events’ processor that will automatically respond to notifications, to accept and claim new transactions.
Anyone who is keen to learn can join the testnet, can use a new cookbook Dino created that we hope will give better insight into the use of the API. The link is as follows:
The module framework is an exciting feature of the wallet. It has now been integrated into the main UI code. The core modules are complete and awaiting final security audits. We are in the process of obtaining developer certificates for both Apple and Microsoft for the auto updater, which means that the binaries themselves will be signed by a certificate that is approved through each of these vendors. This will also solve some of the flagging issues when downloading the application.
In the last Zoom meeting, Kendal gave a demonstration on the Binance module to show the functionality of a module:
The following results are benchmark results running on a consumer grade Apple laptop:
[13:47:57.791] ADD::Processed 34.7858 million ops / second
[13:47:57.933] MUL::Processed 35.1867 million ops / second
[13:47:58.174] EXP::Processed 20.7175 million ops / second
[13:47:58.313] SUB::Processed 35.9769 million ops / second
[13:47:58.418] INC::Processed 38.1832 million ops / second
[13:47:58.523] DEC::Processed 38.1486 million ops / second
[13:47:58.663] DIV::Processed 35.8513 million ops / second
[13:47:58.805] MOD::Processed 35.1786 million ops / second
[13:47:59.211] SUBDATA::Processed 9.85513 million ops / second
[13:47:59.358] UNIFIED::Processed 20.3705 million ops / second
[13:48:00.353] Parse::5.02705 million values / second
[13:48:00.363] Write::102.072 million uint8_t / second
[13:48:00.374] Write::89.6941 million uint64_t / second
[13:48:00.384] Write::97.8953 million strings / second
[13:48:00.394] Write::98.5319 million vectors / second
[13:48:00.405] Read ::97.1723 million uint8_t / second
[13:48:00.405] Read ::97.1723 million uint8_t / second
[13:48:00.415] Read ::92.584 million uint64_t / second
[13:48:00.425] Read ::100.746 million strings / second
[13:48:00.436] Read ::93.633 million vectors / second
Signature Chain Generation with Argon2
In the first Zoom meeting of April, Colin showed the speed of signature chain generation. We have designed it to be slow, to limit offlinepassword attacks. Generating a Genesis ID for a signature chain took 891 milliseconds. This means that if someone tried to brute force attack your account, Argon2 would limit the amount of passwords that can be guessed in a given period of time. Users will also be able to increase the duration of Argon2 to heighten security, and enterprise will be able to reduce it, to increase transaction speed.
Ethereum charges a fee per transaction called ‘gas’, which is based on the computational complexity of a contract. In the case of Nexus, we can choose what transactions will carry a fee. DEBITS and CREDITS will be free on Nexus, though other functions such as creating a token or registering a vanity name will have a cost to prevent them from being consumed. Our current fee model reduces the supply of NXS as demand increases.
In the first Zoom meeting of April, Colin presented a live demonstration of a split revenue payment, to exemplify the distribution of royalties between three parties.
The BlockPass Security Token (STO) event which discussed the future of tokenized securities and blockchain applications.
The Olympia London expo – a multi-feature event focusing on Blockchain, IoT, Cyber Security and AI/Big Data.
We also took part in our quarterly TechUK DLT Working Group – the paper we have been working on will be published in June.
Dino and Colin participated at the Prague IETF (Internet Engineering Task Force) at the end of March. They presented the 4th revision of the draft-farinacci-lisp-decent-03 where they showed screenshots of demos for the push-based and the new pull-based decentralized LISP mapping system. Once the main LISP RFCs are accepted as proposed standards, they will request working group adoption for LISP-Decent.
Over recent years there has been a growing interest in the possible application of tokens. Generally, this has been limited to the raising of capital in the form of Initial Coin Offerings (ICOs) on the basis of the ideas of a whitepaper. Conversely, Nexus is building different token functionality to power applications with utility that extends beyond a store of value. Our technology is essential to creating many diverse and vibrant, interconnected networks to form the Nexus ecosystem.
Non-Fungible Tokens (NFT) Nexus ‘Non fungible tokens’ are designed whereby each token represents total ownership of a physical or digital asset. The digital certificate that represents the physical or digital asset is represented by metadata that underlies the token.
Fungible Tokens Nexus ‘fungible tokens’ hold identical information and are interchangeable, and can either represent a store of value such as a native token, or enforce partial ownership or a ‘right’ to an underlying digital or physical asset. Any digital or physical asset can be licensed by attributing ownership of the underlying asset through token issuance. ‘Proof of rights’ to this license, are thus determined by the total number of tokens a certain user has. These rights can represent shares of a company, asset, or copyright, and therefore can facilitate the automatic dispersal of revenue streams for payments such as royalties and dividends, for example. Token distribution allows the network to enforce the automatic splitting of license payments, providing users free exchange of their rights to subsequent revenue streams.
In the above diagram, we show how the flow of a split payment functions, assuming that the asset has been created by the owner, and the tokens (TKNs) have been created and distributed to the token accounts. In this example, the split is 50-25-25. First, a user pays a license fee (here it is 1000NXS) for use of an asset represented by meta-data. The asset is then detected to be owned by the token account holders. The token holders are notified to claim their percentage of the payment (DEBIT), which is represented by their total token balance divided by the total token supply. Each token holder is then able to CREDIT their accounts proving their right to this payment with their TKN balance.
Thus, fungible tokens issued on Nexus are far more than a store of value; they have the ability to represent a right to a revenue stream of an underlying asset represented by a NFT. This empowers many people and organisations including: viz. artists, musicians, inventors, scientists, enterprises, agricultural producers, schools, charities and gamers.
Decentralized Exchange Under development is the Nexus Decentralized Exchange (DEX), which will allow the buying and selling of any registered asset represented by a NFT through its certificate of authenticity in exchange for any token. All Fungible and Non-Fungible tokens will be tradable between buyers and sellers, without a third party, custodian, orany ‘permissions’. Therefore, the entire network itself is a native DEX to items that exist on the Nexus blockchain. No matter what the value of the item being traded, the orders will be fulfilled as soon as receiving enough confirmations.
Wallet Modules Currently in Beta, the Nexus interface is capable of running third party modules which extend the standard logical and interface layers provided through the wallet. We believe it is important to allow the customization of the interface, to allow developers to build modules that support other coins, exchange trading dashboards, or custom Tritium applications such as online games.
“If an asset or token has to be listed by anyone other than the owner of the asset or token, it’s not a decentralized exchange“
The Nexus Ecosystem Permissionless ‘Sister’ networks and permissioned ‘Hybrid’ networks can be ran, so that services/applications do not need to develop their own blockchains, but can rather leverage the modular Nexus Software Stack. The two types of networks will be able to choose their own consensus rules, and the Nexus blockchain will record intermittent block hashes from them as proofs of immutability. Hybrid networks will have similar properties as sister networks, although they will be less open and designed for managing private services.Both types of networks will use PoS (Proof of Stake) based consensus with their own native tokens. We expect that the growth of services and applications, as part of the Nexus ecosystem, will begin to flourish in the following sectors:
Voting – Token Voting Structures for organisations and companies
Working Groups Nexus has adopted the Internet Engineering Task Force’s (IETF)time-tested open process through ‘Working Groups’. Our Working Group model connects a decentralized collection of people who work together to set standards or develop new components of our technology.
Coders-wg: Develop code and set higher level standards for the Nexus Architecture
Use cases-wg: Discuss functionality for different sectors
Communications-wg: Write content for the website, WIKI, and social media
Website-wg: Develop the standards and design of the official Nexus Website
Graphics-wg: Develop graphics to support the Nexus Brand
Social-wg: Discuss and design Decentralized Voting Structures
Translations-wg: Translate content for the website
If you are interested in joining any of the working groups please email [email protected]. We welcome the community to set up additional working groups not listed above if you feel it would contribute to the standards and development process.