Consensus Mechanism

Anubis' consensus layer must not only guarantee state consistency and immutability, but also support the critical functionality of a Threshold Encrypted Mempool (TEM), fundamentally addressing the MEV threat faced by privacy blockchains. Anubis employs a Proof-of-Stake (PoS)-based BFT consensus algorithm, combining cryptographic lottery and threshold decryption techniques.21

8.1 Core Consensus Parameters and Architecture

• Consensus algorithm It adopts a variant of IBFT 2.0 (Istanbul Byzantine Fault Tolerance) and has been pipelined for ultra-fast 2-second block production.

• Validator set At the initial mainnet launch, the active validator set is capped at 100, with re-elections occurring every Epoch (100 blocks) via VRF (Verifiable Random Function).

• Finality Single-block finality. Once a block is signed and confirmed by 2/3+ validators, it is considered irreversible. This is crucial for cross-chain interoperability of privacy assets, eliminating the time window of waiting for multiple confirmations.

8.2 Threshold Encrypted Memory Pool

In traditional blockchains, transactions in the mempool are in plaintext, allowing validators to censor, preempt, or perform sandwich attacks based on transaction content. On privacy blockchains, while transaction payloads are encrypted, metadata (such as gas prices and contract call addresses) can still potentially reveal intent. Anubis introduces TEM to defer the visibility of transaction content until after transaction ordering.16

8.2.1 Cryptographic primitives: Distributed Key Generation (DKG)

• Curve selection TEM uses BLS12-381 curves, due to their pairing-friendly nature, are well-suited for implementing threshold signatures and encryption schemes.

• Setup process At the beginning of each Epoch, the elected set of validators performs a DKG ceremony once.

• Generate a joint public key . The public key is broadcast to the entire network.

• Each validator holds only one private key fragment .

• Rebuilding the private key requires at least slices (threshold ). Any collusion of fewer than validators will be unable to decrypt the transaction.22

8.2.2 TEM process in the transaction lifecycle

• User encryption The user constructs transaction locally and encrypts the transaction payload (including the recipient, data, and even Gas Limit) using the joint public key of the current Epoch to generate ciphertext . Only a very small amount of public metadata (such as the highest Gas Price commitment used to pay fees) is retained for sorting purposes.

• Blind sorting The block proposer selects high-priority ciphertext from the memory pool. They are packaged into the block body and the block header is broadcast. At this point, the proposer has no idea about the specific content of the transactions and cannot perform targeted MEV extraction.16

• Consensus confirmed Validators vote on the block header. Once a 2/3+ majority consensus is reached, the block order is locked.

• Threshold Decryption

• After a block is confirmed, each validator broadcasts its own decrypted fragment for the ciphertext list of that block.

• Once shards are collected, any node can aggregate the plaintext transaction list.

• These plaintext transactions are then executed in the EVM in a predetermined order.

8.2.3 Trade-off between activity and safety

The biggest risk of introducing TEM is Activity Failure. If the decryption committee is offline or refuses to provide a decryption fragment, the block cannot be executed. Anubis has designed multi-tiered timeout fallback and dynamic threshold mechanisms to mitigate this risk:

Mechanism Level	Triggering Conditions	Response Strategies	Result
Normal Mode	Internet health	Threshold t = 2n/3 Lower limit	Strong resistance to censorship, strong privacy
Timeout Downgrade	Decryption delay > 4s	Once a view change is triggered, the next proposer can re-initiate the decryption request.	Slight delay, no change in security
Emergency Mode	Decryption failed for 5 consecutive blocks	The protocol temporarily lowers the threshold to the lower bound of t=n/2+1 and marks unresponsive nodes.	Prioritizes activity, reduces resistance to collusion
Rollback Mode	Extreme network paralysis	Suspend TEM, allowing plaintext transactions to be submitted (Level 0).	Privacy is downgraded to pseudo-anonymity to ensure network uptime

Table 8-1 Comparison of Activity and Safety Trade-off Models

8.3 Bulk Proof of Privacy Status

To support light client verification and cross-chain interoperability, the Anubis block header includes a special field, privacyStateRoot, and its validity proof.

• Recursive Proof Block proposers not only package transactions but also run an aggregation circuit. This circuit takes the ZK Proofs of all privacy transactions within the block and their corresponding Merkle Root update operations as input to generate a single, concise recursive proof .

• Minimalist Verification Any external observer (such as a cross-chain bridge contract on the Ethereum mainnet) only needs to verify . This ensures that all privacy asset transfers within the block are legitimate and that the Note Tree's state transitions are correct. This enables Anubis to achieve decentralized, trustless cross-chain bridging.24