Common image for Nexus users, here is the universal access point for anyone using Nexus
Signature Chains (Sigchains) provide a unique access mechanism in the crypto ecosystem. SigChains present a naitive quantum-resistant login system abstracted from the traditional public-private key setup, redefining key management. To access Nexus, anyone can log in from any computer in the world using their username, password and PIN. A recovery phase allows emergency access in case they forget or lose the username, password or PIN. By abstracting key management to a traditional experience, Nexus initiates features that set a basis for decentralized digital identity and sophisticated organizational management, while increasing its general usability.
The User tab on the Nexus desktop wallet. Here the owner can create tokens, NFTs, Namespaces and browse history. Compared to control systems in the crypto ecosystem, signature chains let users easily access functions that would need their own application. While accounts can be named for a small fee, the crypto typical address always is available.
SigChains control a data structure called a crypto object register. Your username, password and PIN are the keys to this register; inside of which you can create accounts, tokens, NFTs (called assets) and own unique ‘namespaces’. Accounts on Nexus are not public keys! All of the above exist as different registers and each register has its own address. Here lies the magic of SigChains, a familiar user experience is overlaid on to several core blockchain functions, because of the relationship hierarchy between registers, evolving past some of the rigidness while keeping the benefits of public-private key cryptography.
Nexus protocol employs a register-based virtual machine for data control, as opposed to the more common (for blockchains) stack design Virtual Machine. Virtual machines handle the translation from an application's source code language to the VMs bytecode, then executes the instructions. Other blockchains, such as ETH, Cosmos, Cardano, EOS, TRON and Polkadot utilize a stack-based architecture, WebAssembly (WASM) reigning as the most popular (2). Stack-based systems do not require a specific address for their operands (fancy word for instructions to be executed), claiming simplicity and efficiency in their bytecode. Register architectures use predefined operands contained within a register with an explicit address and memory usage, both of which help conserve resources and work quickly. Stack machines dominate the market generally, but In many cases registers can outperform their rivals (1). No stack-register analysis in the blockchain context has occurred as far as I am aware.
One of seven layers in theThis unique design for application code processing creates a unique user experience for Nexus users. Intuitively, registers with explicit addresses seem to fit well with the cryptographic nature of blockchain design, especially since developers are familiar with tracking accounts and contract addresses.
The register layer of Nexus, represents one of seven interweaving levels of control and organization in the software stack, which spans from low level networking access to interface design. Now that we can see the skeleton of Nexus’s design, how do SigChains work and why are they secure? Specifically, I will walk through how transactions occur and new users create SigChains.
Since the genesis (SigChain creation) transaction is pretty complex compared to regular transactions let’s begin with vanilla transactions. Say the user is logged in and wants to make a transaction; addressing on Nexus can be approached in a couple ways. Every register has an address which looks like the typical crypto addresses, but some registers such as accounts, tokens, assets and namespaces can be named with human symbology. Every named account uses the following format: Username:account_name . Other addressing formats exist for different types of names, but lets ignore that right now for simplicity sake. In general, however we have two choices when it comes to these transactions, either follow the above format or simply send to the typical cryptographic address.
Once the user chooses a sending and receiving account and hits send, they will be prompted to enter their PIN to confirm the transaction.
Confirmation. A user must enter their PIN to create any account, token, asset, namespace or transaction
SigChain transactions use one public-private key pair per transaction. After every transaction a key update algorithm activates, nullifying any access the previous key pair enjoyed. Every transaction requires a PIN input, which is combined with the transaction sequence number (along with the username and password) as inputs to the key update algorithm. The resulting public key is hashed multiple times to create a nexthash which is included in the transaction data. The subsequent transaction uses the previous nexthash to prove they have the proper public key for this transaction, while providing a new nexthash based on the public key for the next transaction.
This offers a non-mathematical design for Quantum Resistance. The public key is only exposed in the time between when the transaction is signed and when it is confirmed in a block. Since the key update algorithm activates immediately after every transaction, the old key pair no longer poses any security threat. The additional input of a transaction sequence number ensures that the new key pair bears no connection to the previous pair. The general design of SigcCain supports a variety of cryptographic functions. Instead of elliptic curve-based cryptography, users can opt for FALCON and ARGON2 currently, and potentially many others if they desire alternatives.
SigChain creation relies on a special type of transaction called tritiumfirst. Regular transactions fall under the tritium user type. To initiate tritiumfirst transactions a user must choose a globally-unique username, 8-character-long password and 4-character-long pin. As the name availability password and PIN confirm, the tritiumfirst transaction gets verified in a block. This initial transaction creates 5 object registers: one account object, one trust object, two name objects and one crypto object register. The two name registers ‘point’ to the account and trust register, meaning that they automatically route to them. Trust objects differ from accounts because they enable users to stake NXS. The crypto object register holds nine slots for various cryptographic keys and stores the hashes of users’ credentials. A nexthash is then published with the genesis transaction, initiating a long healthy line of nexthashes!
Create New User page. After the Userneame, password and PIN are chosen. The user re-types the credentials, hits Submit and waits for the transaction to be confirmed on the blockchain! Nothing here differs from traditional web experiences and we don't need an email confirmation!
Transaction log showing some off the object register created in the sigchain initiation.
Everything under the hood requires some patience to learn, but the user experience does not require contemplation of tough cryptographic concepts. As seen from these screenshots, everything is pretty straightforward and utilizes common user flows. The only recommended way to access the network currently is through the desktop wallet, however a light client mobile wallet and web applications are in the works.
References
2: https://www.freecodecamp.org/news/the-design-of-webassembly-81f1dcabaddd/
1: https://arxiv.org/pdf/1611.00467.pdf
Roadmap
What is Nexus?
What are the features of Tritium?
Technical Guides
Whitepapers
Nexus Github
This article was written by
HarmonyMedia
