Cryptobiometric blockchain protocol

Humanode implementation is planned to be a maintainable, reliable codebase that will be under active development in the years to come. To build a high-quality system, a good foundation is needed, and the first thing to settle on is a programming language for the implementation.

Rust

We have evaluated Rust, Go, and C++ and chose Rust for our implementation, with Go being the second-best option. Rust offers a very expressive type system and a novel approach to memory safety, ultimately being the best choice for a long-term project with high demands on code quality and maintainability. Being a language that compiles to native code rather than a VM, it is also very efficient. Rust follows C++'s principle of “if you don't use it, don't pay for it” and powers developers with zero-cost abstractions. It doesn't use a garbage collector, and even async runtime is implemented in the user code, rather than being a part of the language. By modern standards, this is a very high degree of control. The downsides of Rust are that it is difficult to master, and the development process with Rust is slower than with, for instance, Go. Rust enables you to take control over many aspects of a system, and it takes knowledge and time to implement them right. We figured that for our use case, the benefits far outweigh the cost, and thus, we chose Rust.

Substrate

Every blockchain developer faces a choice: build the codebase from scratch or adopt an existing one for their needs. This decision is simple on the surface, but it is a tough one to resolve.

Substrate is a modular framework that enables the creation of purpose-built blockchains by composing custom or pre-built components. Since dismantling the involvement of the token in the consensus mechanism is one of our main goals as a project, we want to focus our development on building biometric-based consensus aspects on the network. And that is why the modular customization vision is a great ally on our path.

We chose Substrate after carefully evaluating the alternatives (build the code from scratch and using one of the other existing codebases) for several reasons:

• Substrate is designed to be used as a platform to build blockchains, i.e., it is by design a developer tool rather than a final product. Using it was more appealing than basing our development on a codebase that implemented a particular blockchain project.

• Substrate code quality is rather high, and it is clear that people working on it care about the quality.

• We decided that we want something that is a library rather than a framework, and with Substrate, the flexibility and modularity of the code are exactly where we needed them. If we were building the code from scratch, we'd go with a very similar approach to the one that Substrate developers have taken.

• Substrate is being constantly worked on and improved by many people and this means that we can get a stable stream of improvements simply by building on Substrate. There is also a vibrant community around Substrate and many people we can talk to that can help us if we face any trouble with Substrate itself.

• Substrate has proven to be an excellent tool so far, and it allows us to focus on issues specific to Humanode, rather than spending time on the common ones of blockchain building.

Components

Here’s an overview of our system on the component level. Only a subset of the most important pieces are represented here, and there’s a lot more that wasn’t included.

Below is the list of key components that covers the main Humanode requirements to achieve our goals.

Humanode App—an application that allows users to be a part of the Humanode network by exploring the network, submitting transactions, passing biometric identification, running a node, joining the block production, participating in the Humanode DAO.

Humanode Peer (substrate-based node)—a blockchain node in the Humanode network.

Humanode-runtime—a business logic that defines Humanode network behavior including storage, state transition logic, block, and transaction processing. Also, it enables one of the defining features of Substrate-based blockchains: forkless runtime upgrade.

Humanode-rpc—a component that allows blockchain users including the Humanode app and other dapps to interact with the Humanode network by HTTP and WebSocket RPC servers.

Consensus—a logic that allows Humanode network participants to agree on the state of the blockchain defining one of the key Humanode features: proof-of-human-existence.

Aura consensus—a deterministic consensus protocol that primarily provides block authoring by a limited list of authorities (validators) that take turns creating blocks. The authorities must be chosen before block production begins and all authorities must know the entire authority set. Time is divided up into “slots” of fixed length. During each slot, one block is produced and the authorities take turns producing blocks in order forever.

Grandpa consensus—deterministic consensus protocol that provides block finalization where each authority participates in two rounds of block voting. Once two-thirds of the authorities have voted for a particular block, it’s considered finalized.

Bioauth consensus—an addition to deterministic consensus protocols that is responsible for validating whether block authors of proposed blocks have successfully passed biometric authentication (bioauth-authoriized).

Frontier consensus—a component that provides an Ethereum compatibility layer that allows the running of Ethereum dapps natively by enabling the functionality of running EVM contracts, Ethereum block emulation, and transactions validation.

Main Pallets (runtime modules)

Bioauth—a component that defines required storage items and calls to manage authentication tickets that allow bioauth-authorized peers to participate in block production.

Fath—responsible for providing a Humanode monetary algorithm with a proportional distribution of issued tokens.

Cost-based fee—provides a logic to enable Humanode transaction fee economics of the network.

Ethereum—a module, combined with the RPC module, that enables Ethereum block emulation, validates Ethereum-encoded transactions, and allows existing dapps to be deployed on a Humanode network with minimal modifications.

Biometric Provider—a component that provides biometric registration and authentication that guarantees the image’s privacy and resistance to various vectors of attack on biometrics.

The scheme below illustrates communication and interaction between the components.

Figure 1. Humanode network components.

Consensus agnosticism

One of the interesting features of Humanode that we pursue is consensus agnosticism, the ability to change the consensus mechanism of the network if the Humanode DAO approves it. It derives from the necessity for constant research on the most suitable consensus for a leaderless system with equal validation power of nodes. Different consensus mechanisms have various pros and cons which constantly evolve, change, and shift due to the large amount of research done by thousands of scientists across the world on this topic. Swappable consensus mechanisms would allow the Humanode network to evolve and not be constrained by a framework of a singular consensus. Moreover, the Substrate ecosystem has ongoing attempts (Swappable Consensus, Re-Genesis) to support such a feature.

Residual increase in the number of human nodes

The limitation on the number of human nodes will be set following Vortex voting. When the limit is still low, it remains possible to attack the system by coordination among active human nodes. In order to lower the number of malicious human nodes that verify transactions in the early days of the protocol, we impose additional selection criteria for candidate human nodes based on Proof-of-Time and Proof-of-Devotion. Those with a higher tier or longer governing history are going to be the first candidates to enter the Humanode public network on the main net as nodes.

Ethereum compatibility

To bring cryptobiometric technology to existing protocols, the Humanode network includes an EVM pallet that allows it to run Solidity smart contracts and use existing developer tools. Its implementation is based on SputnikVM, which consists of four modules: evm, evm-core, evm-runtime, and evm-gasometer.

One of the goals of the Humanode network is to solve current issues of transaction fee pricing by making the fees stable in USD terms despite the volatility of the native token. Hence, the evm-gasometer is replaced with a cost-based fee system.

Unified accounts, first proposed by Moonbeam, solve the problem of account incompatibility between H256 Substrate addresses and H160 Ethereum addresses where the user is unable to send transactions directly and thus have to have two accounts and move assets between them to get access to both chains. With unified accounts, a single H160 is all the user needs to make the multichain experience seamless.

Moving a dapp or a smart-contract framework from Ethereum to Humanode will require minimal changes. Solidity smart contracts, block explorers, development tools, bridges, and frameworks for decentralized autonomous organizations are easily ported to the chain based on equal validators.

By bridging Humanode to other EVM-compatible chains, the network will be able to provide private biometric processing and Sybil resistance to dapps and protocols based on other chains. A biometric smart contract written in Solidity deployed on a needed chain will communicate with, for instance, a decentralized finance protocol, and then send the request to the Humanode network where biometric data is stored. Without revealing the user's identity, the Humanode network sends ZK liveness proof and identity checks back to the DeFi protocol to prove the user is the same real human being without using any PII (Personally Identifiable Information).

Slashing system

Any verification system requires executive tools that safeguard consistency, immutability, and governing mechanisms of the network. The fiat credit-cycle utilizes law-enforcement and jails, PoW blacklists mining equipment, PoS slashes staked cryptoassets, and Humanode slashes your biometric identity by blacklisting malicious actors for a period of time. If a malicious actor tries to harm the network in any way, the system will blacklist his biometrics. After being slashed the perpetrator will remain blacklisted for a determined period and will not be able to sign any transactions in the Humanode network. That period is defined by the severity of the malicious act itself. Any changes to severity levels of perpetrations and blacklisting periods are defined through Vortex. Proposal rights to change any slashing conditions are given to governors upon reaching the Legate tier.

Some perpetrations have blacklist-period scaling mechanisms. Blacklist periods start with the base parameters stated in the table below and then can only scale upwards. Scaling has steps pre-determined by Vortex: 0.5 months (the basic one), 1 month, 2 months, 3 months, 6 months, 1 year, 2 years, 3 years, 10 years, 20 years, forever.