We have uploaded the Nexus Development & Ambassador quarterly report for July 2020 to Publish0x in order to make available information on past development updates.
Current Blockchain Metrics
The below graphics are pulled from the Nexus Blockchain Explorer Metrics section showing mining difficulty statistics on the blockchain for this year. Please visit the Nexus Blockchain Explorer and NXS Orbital Scan website for updated and additional blockchain information.
Examining the number of tokens, accounts, names and similar values can provide greater insight into the development activity on a blockchain. Between Q1 and Q2, the number of account registers on the Nexus blockchain have grown 99.8%, while the total Signature Chains (SigChains)gained 24.5%. Additionally, we have seen a 5.8% increase in overall NXS staked vs total supply, increasing from 33.6% (Q1) to 39.4% (Q2). This shows improved engagement in the ecosystem and willingness from users to self manage funds and help secure the network. The below information is pulled from a node using the System Application Programming Interface (API) functions. specifically the “system/get/metrics” command.
Github can be another great guage for the level of development activity. It is clearly not a timely or ultimate indicator as many tasks, activities and related work are done offline until ready to be merged. This is especially true for Nexus considering extra-curricular activities such as consulting, onboarding and piloting new Dapp projects as well as innovating with satellite, terrestrial mesh networks and other special projects being worked in parallel.
The below charts are pulled from the Nexusoft Github repository on the insights page. LLL-TAO has received the most activity although additional progress on other portions of the project are reflected on the website as well.
LLL-TAO contributions to master
Development Updates and Accomplishments
05/27/20 — Rice Crypto interviews Colin in a two part series — All Things Nexus Blockchain With Colin Cantrell Part 1 on YouTube and Colin Cantrell Unfiltered CoronaVirus Fireside Part 2 (Patreon Exclusive)
06/15/20 — Colin and Chuck Williams discuss Nexus Safenet, Web3 technology and how Nexus is changing the internet landscape.
06/24/20 — Scott Simon shared the first pooled staking block combining 2 stake transactions (genesis and trust) into a single block on testnet. The trust transaction is the block finder below.
06/26/20 — Scott Simon and Paul Screen provided additional insight into the pooled staking design on the Telegram Community Channel. A summary is included below:
- Pooled staking allows more people to participate in staking blocks, enhancing decentralized operation of the network. Difficulty on the Proof of Stake (PoS) channel should rise significantly after pool staking goes live. This is desired, as it enhances the security of the entire channel.
- All staking nodes create a candidate block. They then serially hash all the transactions within that block and include this hash within the coinstake operation before relaying it to the network.
- Anyone receiving this coinstake checks the hash proof against their own, and only uses coinstakes with a matching proof. The use of the hashproof in the coinstake operation adds a whole new layer of security to each individual PoS block.
- Thus, all coinstakes included within a given block are verified as working on the same exact block. It then totals the balance of included coinstakes, and uses that balance, with your local trust, for stake hashing.
- Different parts of the network may have different hash proof values, but any that are included within a given block candidate must have matching values.
- In both cases, solo and pool staking, you will need to keep your node operational to participate. Like PoW pools, you don’t necessarily have to find the block yourself within the stake pool to earn your portion of the reward, but you must still participate.
- There are a fixed number of PoS blocks per day. So with the solo PoS mechanism (without pooled staking) there is a hard limit on the number of users who can successfully increase their trust. Essentially, there are not enough PoS blocks to go around if the number of users exceeds this limit resulting in decaying trust (since it decays if no block is found within 72 hours). A comparison of stake block finding mechanisms follows:
- node 1 calculates coinstake reward from balance, trust, block age
- so does node 2
- so does node 3
- whichever one finds a block first earns reward, others must keep searching
- 3 nodes calculate reward as above
- all 3 stake combined balance using their own trust
- one of them finds block, all 3 earn their reward
- reward of 2 non-block finders is reduced by the pool fee, which goes to the block finder
07/07/20 — Nexus Developer Zoom Update — Another amazing update from the development team. A near verbatim transcript is provided below with key highlights in quotes.
Initially, there will be a Decentralized Application (DApp) registration to authenticate and associate user accounts to the DApp. This will simplify the creation process allowing developers to drop in and easily build native DApps with React. It will enable the trustlessness, redundancy and security of a non-custodial solution while supporting standalone or multiple DApps that share the same node.
DApp registration via authentication is the current architecture Nexus is moving forward with, however, it is open to community suggestions. A DApp user will need to log into their SigChain to gain access although additional security precautions are being applied and considered. This is basically a type of sandbox isolation that will progressively be improved.
When a user authenticates to the DApp they will be prompted on the wallet to authorize access. This will eliminate the DApp from handling logon credentials while preventing a wide variety of potential vulnerabilities including DDOS. Banking and other heightened security implementations typically require independent authorization for similar adjustments. Additionally, the dev team is creating a framework to quickly create and iterate DApps.
Because this is not a typical mobile wallet that doesn’t maintain blockchain state, but instead a core node, it is taking much longer to work out the intricacies. Client mode will only maintain blockchain headers and SigChain data so the disk footprint will remain small (approx 240Mb for the current chain height). This type of packaging has not been done before and IOS has been a significant challenge. Huge props to Kendal for driving out all the issues and overcoming the obstacles!! This will change the way users and developers see DApps!
An IOS node is running although we are still working through an Argon2bug, although the path looks clear moving forward. Krysto’s production UI is near completion and the core component Kendall is working on will be merged with this soon. The architecture we are striving for is breaking new ground. Similar solutions have been attempted, for example, a DApp browser for Eth was briefly available on Apple, Google and Coinbase but removed quickly.
Client mode will be released on the next hard fork along with pooled staking and Lower Level Database (LLD) performance enhancements. The client mode will be the first option for all wallet installations, including desktop. This provides a quick sync and minimal impact (approx 20mb of RAM) option applied by default.
Staking will still require a full node, client mode does not have the full blockchain history so establishing trust and preventing double spends will be a challenge. There are a few ideas on how to address this although it will take time to sort out and staking will not be included in the first release. Apple also removes apps with mining functionality, so this is another hurdle to jump.
Lower Level Library (LLL)
The scaling tests in March uncovered several additional bottlenecks, with database access in particular degrading unacceptably during the longer simulations. These issues have been addressed with a new bloom filter design, linear probing and additional minor adjustments, resulting in near constant time access regardless of the dataset size.
Disk seeking is the highest form of latency encountered in an operation. For example, in a conventional database with 1 million keys (used to access data on the disk, not cryptographic), using a binary search tree will typically take 15–17 disk seeks. After redesign, with approximately 1000 hashmap files only 2–3 disk seeks are required to find the key. This means with the new Lower Level Database (LLD) a search across 1 billion keys will only take 2–3 seeks on the disk compared with 15–17 for only 1 million keys on a conventional database design!!
“A conventional database like MySQL begins to degrade heavily with even 500k keys. Berkely DB, used by a majority of blockchains out there, can only maintain 70–90k reads per second on average. During testing, with a load test of 10 million keys Berkely degraded down to 2k per second.”
With the previous design, false positive probability and duplication rates were building up causing a degrade in performance. When a false positive is encountered the file on disk will need to be read creating an eventual bottleneck. A primary and secondary bloom filter were created in order to address these issues. The primary row level bloom filter performs checks against the entire bucket which could include thousands of individual files. The secondary is a byte level bloom filter that allows a selection on the number of desired bits per stream or keys. 7 hashes and 13 bits (single filter) was decided upon and this resulted in a duplication false positive rate of about 0.1% or 1 in 1000.
With the new bloom filter design the primary row filter will be checked first. Typically this will rule out any false positive issues and checks approx 600k records per second. This enables the check for a specific key in a dataset to occur extremely quickly. The reads are about 200k and the writes are approx. 120k per second with no memory buffer and straight to disk. The secondary byte level bloom filter is checked after, then the actual file containing the recorded key in the hashmap slot. The first disk seek is for the index file to read the location of the filters. Based on the new design and improved probability rates, the second seek into the actual hashmap will be found instead of having to sift through multiple files, and numerous disk seeks.
With a fresh database testing reflects approx. 180k reads per second. During heavy load tests, with 50–100 million keys the reads come down to about 140k per second. This is only a minor decrease and is still within the realm of constant time (or O(1) time in computer science terminology). Constant time doesn’t mean the exact time will be constant, it refers to the average number of cycles to perform the instructions on CPU and disk.
“This is a very compact and efficient way to use the bloom filters. These hashmap files are stacked together to aid in resolving the collisions. When a new hashmap file is introduced into the LLD this potentially adds another disk seek. To get the probability down to 0.1% means that the LLD can have 1000 hashmap files and not encounter a duplication false positive.”
As an example, to better understand the potential scaling capability, if the maximum 1024 hashmaps were used and each is approximately 500mb, that will equal roughly 12 million keys. 12 million multiplied by 1000 equals 12 billion making the LLD extremely extendable. 12 billion keys is beyond typical disk capacities at this time, even 1 billion is excessive by today’s standards from a database perspective. The team’s confidence level is high that the LLD performance will be maintained even if NXS were to explode tomorrow with millions of transactions based on these changes.
“This brings about a huge increase in processing capabilities because the database is one of the biggest bottlenecks. Theoretically, these changes increase checking proofs by 6 fold although everything will be significantly faster than previous tests reported on the last zoom update (25,000 to 80,000 Contracts Per Second). Linear probing also dropped the DB size from 11gb to 8gb, a 27.2% space savings for full node operators!”
It will be difficult to actually determine the improvements until a final load and TPS test are accomplished but things are looking significantly better. Colin now considers this foundational element of the design to be a “symphony of informational processing!”
Since the beginning of June pooled staking has been code complete and have since moved into testing and fine tuning details. The current stake design is similar to hash and prime Proof of Work (PoW) mining however uses staking rules to generate blocks. A transaction that awards the miner is called coinbase for PoW and coinstake for PoS. While these have similarities, pooled staking is a different animal entirely, it has a pooled staking insert but that is just scratching the surface. It’s combining inputs from different systems that can be in various parts of the world. For this to happen the Lower Level Protocol (LLP) was updated to facilitate the pooled staking information.
To be included in pooled staking a node will submit a new LLP message to the network indicating its intention to pooled stake. Similar messages will be received by the node from other pooled stakers and added to a local “stake pool”, much like the existing mempool. These messages are only relayed (forwarded to other connected nodes) a certain number of times, meaning any given pool stake message will only reach a subset of the total nodes on the network. This process naturally forms clusters of pooled stakers, largely determined by geographic location and network latency.
As your pool stake fills, the staking process will select a set of coinstakes from the local stake pool, a selection mechanism that is random but weighted. This will force it to favor coinstakes with a higher balance and blockage. The weighted attributes of balance and blockage will prevent users from getting stuck, to avoid trust decay with the 72 hour window. As your blockage increases it will also be allowed to include more coinstakes from other nodes improving the probability of finding a block for all users.
“Minimum staking balance for pooled staking will be 1 NXS, enabling equal opportunity for everyone!”
The resultant stake block — whoever finds it first — will include coinstakes (rewards) for all users who contributed their balance to the pooled balance used by the block finder. To allow multiple coinstakes in a single block the block structure has been changed and versioned so that it will self upgrade on the time of the activation. Now that the coding is complete, a public testnet will be performed soon to assist with fleshing out real world issues. The team would like to have at least 100 volunteers to accomplish a proper test so please reach out if you are interested.
Transport Layer Security (TLS), the successor of SSL, has been implemented across all servers — Tritium, RPC, API and P2P. TLS is an effective way to secure communication between nodes and is very useful for API updates. Currently TLS is not enabled by default to prevent overuse and potential influx of problems at this early stage of deployment.
It has been implemented so each server will listen on a separate port for TLS connections. This can be enabled for the server and will establish secure connections where it is able, but also support non-encrypted sessions for those that don’t. Additionally each server can be configured to force TLS connections only, both incoming and outgoing. TLS is especially important for API and Peer to Peer (P2P) connections because generally speaking there is sensitive information exchanged.
The notifications processor can now be enabled in multiuser mode. The notifications processor is a service that runs in the background managing transactions and wasn’t previously available in multiuser mode. This is necessary for developers running DApp servers with numerous users logging into the same wallet.
Bubble is a rapid app development tool similar to Wix, Weebly or other no code web application creators. It has a connector that can snap into the Nexus API. The team initially using this for development decided to leverage their efforts to create a plug-in so this can be downloaded and reused by anyone.
“This will enable easy development for DApps, even for average users without coding experience!! For instance, to create a login screen for a DApp and tie it into a Nexus node literally takes minutes. Then one can create users, tokens, assets or anything that the Nexus API exposes to build any creation of your choice.”
While most of the work on the plug-in has been accomplished there is still documentation and testing being done to finalize. Additional efforts for full instructions including how to setup a Nexus testnet with the plug-in to get folks off the ground quickly is being developed. Once these are complete and fully vetted they will be released to the public.
Crypto API helps manage public/private key pairs, signature generation and verification, data encryption/decryption, TLS certificates, as well as switching between key schemes like brainpool and falcon (post quantum) used by your signature chain. Each signature chain has a crypto object register containing 9 named slots, which contain 9 hashed public keys. The private keys for these are generated deterministically (username+password+pin+id). This means any of the 9 slots can be used to generate a signature for various purposes.
A user or application can then verify the signature to prove ownership of the private key (the same as any other chain), and additionally validate that the public key exists in the senders crypto object register (SigChain) on-chain, proving provenance irrefutably.
The API also exposes functions to encrypt and decrypt data. This includes symmetric encryption using AES 256 with keys generated from the entropy of their sigchain, using a name as the identifier of the key, essentially allowing the encryption and decryption of data by key name and login credentials. This is in stark contrast to key derivation algorithms that currently exist, that generally rely on the storage and safe retention of cryptographic keys on the physical device, being prone to loss, theft, and device malfunctioning.
The Crypto API also provides the ability to encrypt/decrypt using a shared key generated from a peer’s public key. This will allow user1 to encrypt based on the public key from user2. Then user2 will then use their private key to decrypt. This enables the TAO framework to augment blockchain in new ways and provide increased value to a variety of individuals, applications, and industries.
“In essence, this removes the complexities commonly associated with encryption systems allowing any developer to apply cryptography techniques safely and securely!”
Paul provided a demonstration in the most recent Zoom for both the Crypto (briefly) and P2P APIs starting at approximately 1hr and 5min. The P2P API was born through the requirement that has come up numerous times from a variety of developers in order to send encrypted data from P2P or DApp2DApp. This functionality can be applied quite easily with the Nexus TAO framework.
The connection is established using only the username or genesis ID. A user receiving the connection request can accept or reject the encrypted session. Once accepted the session is established directly between these two nodes, with no other interaction with the network necessary. This is completely off-chain, no additional overhead or burdens are encountered.
An Application Identifier (AppID) is also used to uniquely identify DApps in the ecosystem for proper separation to prevent any overlap. The only requirement for the connection is the user’s computer must be publicly available by being on a dedicated IP address, or using port forwarding techniques such as Universal Plug and Play (UPnP), Network Address Translation Port Mapping Protocol (NATPMP), or similar. This is a temporary requirement pending additional features currently under development.
Nexus is developing its own implementation of the Location Identifier Separation Protocol (LISP) being written in C++ so it maximizes bare-metal efficiencies that are currently not available in LISP implementations. The team ultimately decided not to utilize lispers.net’s implementation because it only worked on Debian based systems, where full cross platform functionality between Linux, Windoze, and OSX are minimum requirements for components of Nexus. You will see more of this new protocol integrated directly into the nexus architecture, so that your sigchain will provide you routing identification services, sharding, and many more features that were not previously available.
Re-encapsulating Tunnel Router (RTR) is a component of LISP. Development of the RTR is underway and the team is currently working on UDP hole punching. Think of the RTR as a server that has a public IP address, so when you make an outgoing connection it punches a hole through a Network Address Translation (NAT) to establish the connection with a specific port. The connection will not run through the server, it just maintains port and related connection information.
Four different network traversal techniques will eventually be supported: UPNP, NAT-PMP, Port Control Protocol (PCP) and RTR. Eventually 99% of the Nexus nodes will likely be available on the internet through one of these methods, however this will not induce vulnerabilities. In order to keep a traversable hole in the router, keepalive packets need to be constantly initiated from the node. The NAT will act similar to a firewall for the public IP address in that it will drop all connections except for the peer established using the network pipe on a particular port that will close automatically when traffic stops. The NAT does not replace the need for a firewall, it merely provides similar functions in a limited capacity.
This opens the door for so many user experiences with secure application to application (App2App) capabilities. For example, take a simple btc transaction, to obtain the receiving address and send a transaction, this can involve a number of different devices and applications depending on the situation. With App2App secure connections this will remove the complexities involved in device to device communications. The P2P genesis ID association also provides elevated security proving the identity irrefutably when necessary, for example when needed to send large sums of money.
“These sessions are cryptographically authenticated eliminating spoofing and other common problems with the internet. The TAO framework changes the landscape for all types of developers and projects, not just blockchain. An application like Signal could be built on Nexus without even knowing one is using blockchain. The barrier for entry has been lowered significantly decreasing developer cycles, especially with consideration of the Bubble inclusion.”
Paul has begun working on the Filesystem API that will include file metadata as references in blockchain registers. This provides methods to transfer files to each other, prove integrity and more. When Amine becomes available, this filesystem will include new storage mechanisms such as a distributed file system (LLD Filesystem). Another major challenge being overcome with the file system is “gamification” (monetizing hard drive space), as many cryptocurrency implementations using IPFS are currently encountering.
Think of it as a decentralized cloud with incentives to pay your peers rather than to large corporations. The plan is to provide a selective function so if one wants to utilize a known peer for storage this can be achieved. Reputation will be applied to establish additional security and reliable selection bias so even unknown peers will earn trust in the system, and this trust will be directly related to that node’s ROI, creating a direct feedback loop for merit built in the system, and the monetary impact it provides.
The Amine distributed file system segways into Satellites. The LLD Filesystem is the first step towards the satellite storage system. The first satellite was purchased back when Nexus was working with Vector Space Systems (VSS). VSS’s GalaticSky was a system virtual machine designed to load software for various solutions like renting storage on a space cloud. However, there were a lot of architectural challenges, such as monetization of services, trustless capabilities and many more. The shortcomings in this collaboration ended up being a blessing in disguise, as the available architecture was constraining and the data management model was limiting to say the least.
When in orbit, it’s important to minimize onboard processing as much as possible. Satellites are moving through giant radiation fields, which are essentially beta particles or electrons. With the way a transistor works, for example a N channel transistor, it uses a higher voltage on the gate to trigger the switch to open. Flying through space with all these electrons floating around, they start collecting in the transistors and the build up can eventually flip the bit causing it to open unintentionally. What should have been a zero now becomes a one, breaking many parts in the system if gone undetected. In order to provide compute effectively, high redundancy and shielding needs to be built into the system.
Typical routers use a stateful system that apply routing tables to direct traffic to a particular location, mapping a hardware address (IP) to a physical location, essentially allowing a computer or physical device to send electrical signals to another physical location, so in essence your IP address contains a known physical location associated with it, which is how packets get from one side of the planet to another side.
One of the critical portions of our design is a stateless routing solution, it does not need to know about anything on the network except the node location and common neighbors. There is no need to update routing tables, exchange information or other cumbersome activities required for managing state. When dealing with the extraneous conditions of satellites, managing the smallest amount of information is crucial.
“The routing system has materialized far beyond what the team expected, significant progress has been made. The possibilities of satellites that seemed distant on the last meeting are now looking to be obtainable in a much shorter time-frame!!”
Routing will not be in a ring network structure but more of a fixed state (e.g. satellite to satellite). For example, if a satellite is accepting packets from another but does not forward, then it will slowly degrade and eventually be removed from the network. This will create the incentive to provide continuous routing services including multicast traffic which ISP only does in a limited and questionable capacity.
Providing a Return on Investment (ROI) to everyday people will ensure that a decentralized Satellite network will be built and maintained, just as the Nexus blockchain has. The benefits need to be something users and organizations can monetize. Therefore, the value proposition of building our own decentralized satellite network is very high for many reasons. The unit is physically isolated by an atmospheric margin significantly diminishing the ability for side channel attacks, physical theft or similar. Furthermore, satellites and the intercontinental routing system provide additional layers of redundancy for the many earthly disasters that could take shape. Given the elevated security and contingency stature of the environment, the price per byte of storage will be at a premium in comparison to ground based options running the LLD Filesystem.
One example of a continuous disparity is Internet Service Providers (ISP), the internet should be free to consumers, and only monetize service providers (e.g. websites), without censorship or surveillance.
The majority of the hurdles in the design of the satellite network have been overcome. The major obstacles were frequency licensing, value propositions, gamification, technical architecture, physical hardware and routing. Routing was crucial because the IP (Internet Protocol), BGP (Border Gateway Protocol), and others would simply not fulfill our long list of requirements.
07/20/20 — Rex Bear from the Leak Project provides an amazing interview: Quantum Internet & The Biggest Shift In History: Nexus, This Changes Everything, Colin Cantrell
- The conversation begins with Colin’s history with programming, rockets and economics as well as creative minds, concepts and projects that have inspired his evolution into the creation of Nexus Three Dimensional Chain (3DC).
- They progress into problems with societies, economies, and the internet we use today, and how truly decentralized blockchains enable solutions to solve these challenges.
- The discussion spins into the new Nexus operating system being designed and philosophical constructs, game theory, incentives and related topics. They also cover Safenet innovations including stateless routing, decentralized satellites, mesh networks and more. Overall, this is another magnificent, must see interview with Colin in top form!
Community Updates and Accomplishments
05/20/20 — Ahmed Asaad (Medo), posted an idea on Telegram regarding an inheritance module for distributing funds to a desired address, either evenly or weighted, based on preset conditions (e.g. Owner hasn’t logged into their SigChain for 12 months). This would basically create a “Will” or dead-man’s switch function for Nexus and token holders. The development team has added this on their list of features to work on. Great concept Ahmed!
05/25/20 — A sleek new block explorer was created for the Nexus website. Great job, Glenn Bogaerts!!
05/25/20 — An incredibly thorough article was provided by BitShills titled, “Nexus — The Most Advanced Universal Blockchain”
05/29/20 — An excellent article was published by a community member highlighting the benefits of Nexus and why destination moon is soon!
05/30/20 — Colin Cantrell nominated for Uptrennd.com poll — “Who is the Best Changemaker and Innovator in Crypto”. While he didn’t win, second place is certainly commendable considering the competition.
06/02/20 — Nexus Community held a contest on Twitter celebrating the 3,333,333 block mined. 33 NXS were awarded to the first person who posted the appropriate answer in our Official Telegram. We decided to honor two winners, @kanchapun2 and @Redrose27759695, who both posted at the same time. Congratulations!!
06/10/20 — Invoice DApp Module overview was posted to the Nexus website.
06/14/20 — Community members tweeted a challenge to the cryptoverse.
06/16/20 — Nexus Blockfolio has been updated. Huge kudos to Ahmed Asaad!
06/18/20 — @TheLibertyADVSR and @colinjcantrell discuss the Pentagon’s plans to counter a $BTC uprising, panoptic perspectives into historic & current agendas shaping conscribed narratives, consciousness & how #NXS is positioned for resistance
06/19/20 — A Linux Nexus wallet installation video provided by Aeonwise (Telegram Name).
06/29/20 — Nexus Decentralized Identity published on Medium.
07/15/20 — SmileyGnome was interviewed by Shepard Ambellas show titled Covid and Crypto. Topics covered in the interview with SmileyGnome highlighted Bitcoin, Nexus, blockchain, decentralized/distributed software and hardware technologies, and Bitcoin ATMs.
07/20/20 — The TAO: A New Framework to Power the Web, has been published on Medium
Partnership, Special Project, Exchange and DApp (Modules) Update
Satellite and mesh network updates were provided in the 07/07/20 developer Zoom meeting. No exchange or partnership changes occurred during this quarter.
06/10/20 — Free and Equal Elections Foundation provides a United We Stand live interview session with Christina Tobin, Chuck Williams and Colin Cantrell discussing topics surrounding United States elections and updates on Nexus DApp progress
- April Bunje put together a shorter video synopsis (15 min.) highlighting the primary conversations. Thank you, April (Telegram ID — Maid)!
- The DApp will provide transparent information about ALL their candidate choices by allowing users to view candidate details, ballot access requirements, interactive candidate support tools, and educational videos.
07/12/20 — The CoolADE project architecture design and requirements refactoring are making great strides!
Roadmap and Roadblocks
The roadmap below is referenced from the Nexus website.
No roadblocks are worth noting at this time.
Goals for Next Quarter
Pooled staking, API enhancements, performance and LLD optimizations, and mobile wallet / client mode continue to remain top priorities.