We are delighted to welcome Gabriel René as our newest Advisor. Gabriel serves as Executive Director of the VERSES Foundation, an organization at the intersection of Augmented and Virtual Reality, IoT, Blockchain, and Artificial Intelligence. He is a technologist, entrepreneur, researcher, media producer with a 25-year career in the High-Tech, Telecom and Entertainment Industries. With a focus on emerging technologies and their applications across the industrial and enterprise mobile and spatial computing markets, Gabriel adds high value to the real world applications developed by Nexus.
Gabriel has helped multiple start-ups and founders navigate their way to success as an advisor and board member. He has worked with and advised some of the largest brands in the world, spanning media conglomerates, telecoms, mobile manufacturers, governments and major brands like Verizon, Sony, Intel, Coca-Cola, Microsoft, Qualcomm, Apple, Samsung, Universal, AT&T, Boost Mobile, Obama Campaign, Condé Nast, Cannes Film Festival and more. The addition of Gabriel René to the Nexus Advisory Committee further expands the potential of the Nexus Blockchain within enterprise adoption.
As a valued Advisory Committee member, Gabriel will leverage his expertise to advise Nexus in strategic marketing, business development and philanthropic endeavors. Gabriel will support Nexus in designing and architecting their multidimensional blockchain for a 3D world. He will also add special focus on interoperability with IoT, AI and Spatial Computing technologies. “Nexus’ blockchain technology has the potential to enable scalable blockchain solutions. I look forward to helping Nexus stay at the top of innovative new technologies improving trust, transparency and security.”
Gabriel’s expertise in the Spatial Web will allow Nexus to explore new possibilities of using blockchain and LISP technology to advance Web 3.0. VERSES plans to utilize blockchain technology to allow for a trusted data layer for the provenance of information related to activities, objects and interactions that occur spatially. Nexus Founder and architect Colin Cantrell said, “When I first met Gabriel we had an incredible synergy and it quickly became apparent that our visions were aligned. I am excited to be working with him to see our visions become a reality”.
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!
Two innovative technologies, LISP and Nexus, have come together to create a one-of-a-kind scalable blockchain that many believe is the next generation blockchain solution the industry has been waiting for. LISP (Locator/ID Separation Protocol) was created by Silicon Valley’s, Dino Farinacci, to revolutionize scaling the Internet. The Nexus Hybrid Blockchain is being developed by twenty-eight year old Founder, Colin Cantrell, to solve the challenges of first generation blockchain architecture. Together, these two pioneers are advancing blockchain technology on the network layer in a way that has never been done before.
Dino is a software engineer and the largest individual contributor to running code on the Internet. He was the first ever Cisco Fellow appointed in 1997 and currently holds over 40 Internet and networking related patents. For the last 30 years, Dino has been a member of the Internet Engineering Task Force (IETF), which develops standards for the Internet we use every day. When Dino left Cisco in 2012, he wanted to pursue and focus on next generation use-cases for this new LISP technology. LISP is currently being tested by tech giants such as Comcast, Bloomberg, NBC and Cisco.
In 2017, he met Nexus Founder, Colin Cantrell, who is a self taught coder creating the Nexus blockchain from the ground up. Dino recognized the blockchain community was neglecting the real value of the network layer and making the same mistakes that were made when designing the Internet. Nexus was open to experiment, trial and deploy a LISP overlay, while Dino was eager to apply his networking experience to blockchain. The collaboration between Dino and Nexus was a perfect fit. Two years later, what started out as a passion project for Dino, is now the next generation scalable blockchain set to release this summer. Nexus Director of Business Development, Brian Vena said, “What Dino and Colin have created not only advances blockchain technology, but it will heavily impact our daily lives when it comes to the future of IoT and 5G. It also finally provides businesses a cost effective way to integrate a scalable blockchain solution with their current systems through easy to use plug and play APIs and advanced contracts that can be written in any coding language.”
The original Internet architecture was not built to handle the growing number of devices being used around the world or their ability to roam. This same architecture has now run out of IPv4 addresses (the Internet equivalent of phones numbers) which are required for devices and services to connect to the Internet. In order to solve this problem, Dino built the LISP overlay architecture to support both IPv4 and IPv6 addresses which will help make the Internet scale. With LISP, separating identity and location changes how you use the Internet. It allows you to roam, use multiple connections at one time and scale the core of the Internet. Scaling the core of the Internet is crucial so it can grow and support more devices and newer applications that are coming. “Today, people want performance, scale and accountability, and that’s exactly what LISP and the Nexus Hybrid Blockchain create together,” said Dino.
Nexus is the only blockchain using LISP, allowing it to scale along with the future advancements of the Internet and the new devices that connect to the network. The addition of LISP gives Nexus a scaling advantage by selecting the shortest paths between locations of Nexus nodes, allowing them to be located anywhere on the Internet, along with residential environments, cloud providers and mobile carriers. Using LISP also allows Nexus connections to remain active while the node moves around or temporarily goes off the network so re-connection and application state synchronization can be avoided. This increases the speed and performance of a Nexus node that no other blockchain in the world has.
The integration of Nexus and the LISP overlay also helps achieve scalability through reduced network latency in a truly unique manner. Just like the Internet, the 32-bit IPv4 address used by most network protocols will be unable to support the future growth of networked devices. Nexus and the LISP overlay will use 128-bit IPv6 EID addresses that can accommodate far more devices on the network. When asked about the future of LISP and Nexus, Dino believes the partnership will take advantage of more LISP features such as multi-homing, mobility, better security through the LISP mapping system’s access control features, crypto-EIDs for anti-spoofing and multicast miner pools. Dino says, “What the LISP layer provides you is an up to date network database and the Nexus Blockchain provides you with an immutable tracking database, the two can be used to provide robust and comprehensive data analytics. This is a data lake of information for machine learning models at multiple layers in the software stack that we have never seen before.”
Nexus has spent the last two years meeting with key executive decision makers and gathering market research in the areas of fraud, supply chain, digital rights and identity. This information has led Nexus to adapt their technical architecture and build a hybrid blockchain solution that allows businesses to utilize the benefits of both a public and private blockchain. The Nexus architecture solves the challenges of scalability and integration for a vastly improved user experience. APIs allow advanced contracts to be written in any language, ensuring easy integration, reduced development costs and a more efficient developer experience. With the Nexus mainnet set to release this summer, businesses looking for alternatives to first generation blockchains will now have a viable solution through the combination of Nexus and LISP.
Article by John Saviano, Nexus
For more information on Nexus and LISP, please visit:
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.
The notion of a “trustless” ledger continues to gain in popularity. A public blockchain is often described in this way as it does not require a “trusted” third party. The responsibilities of third parties such as banks, payment or credit card providers is to act as the authority that prevents double spending. Blockchains on the other hand, use various types of consensus mechanisms to reach an agreement on the ledger and to authenticate each transaction. Ironically, trust is still a factor in trustless systems, with trust derived not from a central system but from decentralized consensus.
The cost to attack a decentralized consensus mechanism is directly related to its security. To increase security, Nexus implements reputation as a cost, which is related to how much consistent time a staker contributes resources. A mechanism called “Trust” records past work to create a reputation system, which is currently implemented on the Nexus Proof of Stake channel.
Proof of Stake is a form of mining based on ownership of a digital currency. This ownership represents a “stake” in the sense of an interest in something. By staking, NXS holders earn a NXS Stake Reward. NXS can only be staked inside the official Nexus wallet. In return, stakers are rewarded for operating the wallet (a Nexus node) which provides security to the network.
Trust adds another weighting to the security of the Nexus protocol. A Trust score is defined as the total time a specific user has contributed weight or realtime resources to the network. A Trust score is gradually built over time as one consistently operates a node in an honest, trustworthy, and timely manner to validate transaction data by running a wallet on a computer with continuous internet connection (24 hours a day, 7 days a week). In some circumstances, such as when a node goes offline for a significant period of time, the node’s Trust Score will be reduced. Therefore, one has the incentive to operate a node continually and consistently providing security to the Nexus network.
The Stake Reward rate depends on the node’s Trust Score. The Stake Reward rate is a value that represents your current annual NXS rate of return (%). Unlike most other PoS systems, the Nexus reward rate isn’t constant. The rate starts at 0.5%, and can increase to 3.0% after 12 months of consistent staking. The rate increase is nonlinear, slowing in terms of its increase over time. It takes several weeks of consistent staking to reach 1.0%, and around four months to reach 2.0%. With this rate, you can calculate the average amount of NXS you can expect to receive each day for staking.
The key to a good reputation system lies in the effort required in gaining a reputation versus the comparative ease of losing it. By coupling an economic incentive with greater trust, such as higher returns on verification, there is a non-trivial cost incurred by loss of reputation. Trust in our implementation is gained by consistent block production within a three day moving window. If this time is exceeded, the value of trust decays at a rate of 3x, which means if a node misses one day of staking, it receives a penalty of three days worth of lost trust. This mechanism forms a basic foundation for the discernment of the quality of nodes.
It is possible to stake with only one single NXS at a rate of 0.5%. However, as of 15th April 2019, it takes at least ten thousand NXS to be able to reach the maximum stake reward of 3.0%. The amount of NXS required to achieve a higher stake reward depends on its fiat price, as an increase in the price of NXS increases the required amount to attain the maximum stake reward. Trust supports the viewpoint that “not everyone has money, but everyone has time,” implying that anyone can build trust if they have some time, as only a minimal amount of hardware and NXS is required to begin building a trust score.
Similar to other forms of mining, Proof of Stake mining has a level of difficulty. As more people successfully stake on the network, the difficulty of staking increases. This results in an increasing amount of NXS required to increase the stake reward. Furthermore, a larger balance of NXS in the wallet will increase the frequency of NXS rewards.
Trust adds a layer of protection against attacks that further increases the Nexus network’s Byzantine Fault Tolerance. Together with the other two Nexus mining channels, limitations on block frequency, ten-minute decentralized checkpoints, it is very unlikely for an attacker to perform a successful 51% attack, because it would take an enormous amount of resources and time to gain enough trust from the network, in order to take control of all three channels. Not only does Trust increase the security of the protocol, it also increases the efficiency of the protocol and therefore its potential to scale.
We believe reputation is an important mechanism to take into consideration when discerning the mathematical truth of a decentralized consensus. Reputation in Tritium will extend beyond just Trust, by implementing signature chains. A signature chain is comparable to having a personal blockchain, which can be accessed by a username, password and pin, and augmented with various hardware password managers or biometric usernames. The result is a transparent ledger of events associated with a given user, that can provide the data set to form more complex reputation systems interpreted from this series of events. We plan on extending our current reputation systems into many more areas, such as our multidimensional chain.