Blockchain Architecture

The Humanode implementation will be a manageable, dependable codebase that will be actively developed for many years. A good foundation is required to develop a high-quality system, and the first decision to make is on a programming language for implementation.

Rust

We compared Rust, Go, and C++ and decided on Rust as our implementation language, with Go coming in second. Rust is the ideal choice for a long-term project with high demands on code quality and maintainability since it has a very expressive type system and an innovative approach to memory safety. It is also incredibly efficient because it compiles to native code rather than a virtual machine. Rust follows the C++ idea of "if you don't use it, don't pay for it," and provides zero-cost abstractions to developers. The garbage collector isn't used, and the async runtime is implemented in user code rather than being built into the language. This is a fairly high level of control by today's standards. The disadvantages of Rust are that it is harder to grasp and that the development process takes longer than, say, Go. Rust allows you to take control of many components of the system, but doing so correctly takes knowledge and patience. We decided that the benefits significantly outweighed the drawbacks for our use case, thus we went with Rust.

Substrate

Substrate is a modular framework that allows you to compose bespoke or pre-built components to create purpose-built blockchains. We want to focus our development on establishing the biometric-based consensus features of the network because eliminating the token's involvement in the consensus mechanism is one of our key aims as a project. As a result, the modular customisation idea is a valuable ally on our journey.

After carefully weighing the alternatives (writing the code from scratch and using one of the existing codebases), we decided on Substrate for various reasons:

Substrate is intended to be used as a platform for creating blockchains, hence it is more of a developer tool than a finished product. It was more enticing to us to use it rather than base our development on a codebase that implements a specific blockchain project. The quality of the substrate code is rather excellent, and it is evident that those who work on it are concerned about it.

We determined that we wanted something that was more like a library than a framework, and Substrate's code flexibility and modularity were just what we required. If we were starting from scratch, we'd take a similar approach to the Substrate devs. Many individuals are always working on and improving Substrate, which means we can get a steady stream of improvements simply by building atop Substrate. There is also a strong community surrounding Substrate, with a lot of individuals we can chat to if we run into any issues with the Substrate. So far, Substrate has shown to be a wonderful tool, allowing us to concentrate on the Humanode details rather than the standard blockchain architecture.

Consensus-agnostic

Consensus-agnosticism is one of the intriguing properties of Humanode that we pursue. Naturally, the Humanode community has the capacity to update and/or change the network’s consensus process if the Humanode DAO agrees and passes the proposal for change . It stems from the need for continuous study into the best consensus for a leaderless system with equal node validation power. Different consensuses have unique advantages and disadvantages that constantly evolve, change, and shift as a result of vast study conducted by thousands of scientists all over the world. The Humanode network would be able to evolve without being restricted by a single consensus framework if it had swappable consensus. Furthermore, the Substrate ecosystem is working on supporting such a feature (Swappable Consensus, Re-Genesis).

Compatibility with Ethereum

To integrate crypto-biometrics into existing protocols The EVM pallet in Humanode Network allows it to run Solidity smart contracts and use existing developer tools. It is built on SputnikVM, which is made up of four modules: evm, evm-core, evm-runtime, and evm-gasometer.

One of Humanode Network's goals is to address present transaction fee pricing difficulties by keeping fees steady in USD despite the volatility of the native token. As a result, the evm-gasometer has been replaced by a cost-based fee structure.

Unified accounts, first proposed by Moonbeam, tackle the problem of account incompatibility between H256 Substrate addresses and H160 Ethereum addresses, requiring the user to have two accounts and shift assets between them in order to access both chains. With unified accounts, all a user needs is a single H160 to enjoy a smooth multichain experience.

Moving a Dapp or smart contract framework from Ethereum to Humanode will only necessitate minor adjustments. Equal validators make it simple to move Solidity smart contracts, block explorers, development tools, bridges, and frameworks for decentralised autonomous organisations to the chain.

The network will be able to provide private biometric processing and sybil-resistance to Dapps and protocols based on other chains by connecting Humanode to other EVM-compatible chains. A biometric smart contract created in Solidity and put on a required chain will communicate with a DeFi protocol, for example, and then submit the request to the Humanode network, which stores biometric data. Humanode network transmits ZK liveness evidence and identity verification back to DeFi protocol without revealing the user's identify, demonstrating the user is the same genuine human being without utilising any PII (Personally Identifiable Information).

Slashing system

Any verification system requires executive tools to protect the network's consistency, immutability, and governing procedures. PoW blacklists mining equipment, PoS slices staked cryptoassets, and Humanode slashes your biometric identity by blacklisting bad actors for a period of time. If a bad actor attempts to harm the network in any manner, his biometrics will be blacklisted by the system. After being slashed, the culprit will be blacklisted for a set period of time and will be unable to sign any Humanode network transactions. The length of time is determined by the seriousness of the malicious deed. Vortex is used to define any modifications to the severity levels of perpetrators and blacklisting durations. Governors who achieve the Legate tier gain the ability to propose changes to any cutting criteria.

There are blacklist-period scaling systems in place for some perpetrators. The base criteria for blacklist periods are listed in the table below, and they can only go upwards from there. Vortex has set the steps for scaling at 0.5 months, 1 month, 2 months, 3 months, 6 months, 1 year, 2 years, 3 years, 10 years, 20 years, and forever.