Neo X Documentation
  • Overview
  • Development
    • Development Environment Information
    • Running a Neo X Node
    • JSON-RPC API
  • Bridge
    • How Native Bridge Works
      • Hash Chain and Decoupled Relayer
      • Architecture
      • Technical Flow
    • Quick Start: Bridging Assets
  • Integrations
    • The Graph
      • Introduction
      • Quick Start
    • Oracles
      • Supra
  • Governance
    • Governance in Neo X
    • Neo X System Contracts
  • Security
    • Anti-MEV Protection
      • Threshold Encryption
      • Envelope Transaction
      • dBFT Enhancement
  • FAQ
    • Transaction Underpriced Error
Powered by GitBook
On this page
  • Decentralized Key Generation (DKG)
  • DKG Process
  • Threshold Public Key Encryption (TPKE)
  • Encryption
  • Decryption
  • Signature
  1. Security
  2. Anti-MEV Protection

Threshold Encryption

PreviousAnti-MEV ProtectionNextEnvelope Transaction

Last updated 1 month ago

Decentralized Key Generation (DKG)

The DKG mechanism in Neo X enables a fully decentralized key generation process among consensus members. Before each epoch change, the upcoming consensus group must successfully complete a DKG round to establish a new threshold public-private key pair. This process ensures that no single participant controls the decryption or signing capabilities.

DKG Process

Each DKG round consists of three key steps:

  1. Share – The next consensus group generates nnn distributed secret shares and a global public key, where nnn is the number of Neo X consensus nodes.

  2. Reshare – The current consensus group (if available) transfers the previous round’s secret to the next group.

  3. Recover (Optional) – If up to fff secret shares are lost, the remaining 2f+12f+12f+1 shares reconstruct the secret to complete the transition.

Starting from , the DKG module automates the entire process, except for setting up the initial Anti-MEV keystore with a secret passphrase.

Share Phase

Each participant executes the following steps:

  1. Take a random polynomial f(x)=a0+a1x+a2x2+⋯+at−1xt−1f(x) = a_0 + a_1x + a_2x^2 + \dots + a_{t-1}x^{t-1}f(x)=a0​+a1​x+a2​x2+⋯+at−1​xt−1 as their local secret, where t=2f+1t = 2f+1t=2f+1 (the threshold for consensus).

  2. Compute f1,f2,...,fnf_1,f_2,...,f_nf1​,f2​,...,fn​ where fi=f(i)f_i=f(i)fi​=f(i) and share them with corresponding participants, where iii is the index of different participants of Share.

  3. Accept all fif_ifi​ from other participants as f1(i),f2(i),...,fn(i)f_1(i),f_2(i),...,f_n(i)f1​(i),f2​(i),...,fn​(i), where iii is the index of receiver, and compute si=∑fis_i=\sum f_isi​=∑fi​ to get the final secret key.

Generating the Global Public Key

The global public key is generated using Publicly Verifiable Secret Sharing (PVSS):

  1. The contract verifies each PVSS and computes S=∑i=1nFi(0)S=\sum_{i=1}^n F_i(0)S=∑i=1n​Fi​(0) as the global public key.

A well-constructed PVSS includes:

  • F(x)=f(x)G1F(x)=f(x)G_1F(x)=f(x)G1​ as the sender’s local secret commitment.

  • rG1,rG2rG_1,rG_2rG1​,rG2​ as a pair of commitments for a random scalar rrr.

  • F=(F(1),F(2),...,F(n))F=(F(1),F(2),...,F(n))F=(F(1),F(2),...,F(n)) as the commitment share messages.

The KeyManagement contract validates F(1),F(2),...,F(n)F(1),F(2),...,F(n)F(1),F(2),...,F(n), and verifies scalar rrr. Recipients validate their received shares using e(r1f(i),g2)=e(F(i),r2)e(r_1f(i),g_2)=e(F(i),r_2)e(r1​f(i),g2​)=e(F(i),r2​).

Future Enhancement: Zero-Knowledge Proofs (ZKPs) will be integrated to enhance encryption verification.

Reshare Phase

Each participant executes the following steps:

  1. Regenerate his local secret f′(x)=a0+a1′x+a2′x2+⋯+at−1′xt−1f'(x)=a_0+a'_1 x+a'_2 x^2+ \dots +a'_{t-1}x^{t-1}f′(x)=a0​+a1′​x+a2′​x2+⋯+at−1′​xt−1 while preserving the constant term a0a_0a0​.

  2. Follow the step 2 and 3 in the Share phase, but send the shares to the next consensus group.

The KeyManagement contract ensures F(0)=F′(0)F(0)=F'(0)F(0)=F′(0), preserving the global public key unchanged and preventing leakage of the original secret shares.

Recover Phase (Optional)

If some secret shares are lost, the remaining consensus members help restore them:

  1. The current consensus group forwards all received shares fif_ifi​ from the lost index iii to its successor.

Security Note: Recover exposes at most fff of the original secrets, so it is only allowed when the index iii is confirmed absent from Reshare.

Threshold Public Key Encryption (TPKE)

Neo X's DKG enables a Threshold Public Key Encryption (TPKE) scheme, ensuring that encrypted transactions can only be decrypted if at least 2f+12f+12f+1 consensus nodes cooperate. This mechanism is crucial for preventing premature exposure of transaction details.

Neo X TPKE utilizes the BLS12-381 curve, encoding any secret to G1G_1G1​ for encryption and any message to G2G_2G2​ for signature generation.

Encryption

For a given secret message msgmsgmsg, the encryption process follows these steps:

  1. A random point G1G_1G1​ point PPP is chosen as a seed to generate an AES key. The encrypted ciphertext is computed as C1=AES(Hash(P),msg)C_1=AES(Hash(P), msg)C1​=AES(Hash(P),msg).

  2. To ensure security, a random scalar rrr is selected to encrypt PPP as C2=P+rSC_2=P+rSC2​=P+rS

    where:

    • rrr is a random scalar,

    • SSS is the global public key.

  3. The final encrypted message CCC, which is broadcasted across the network, consists of C=(C1,C2)C=(C_1,C_2)C=(C1​,C2​).

Decryption

To recover the original msgmsgmsg, the Neo X consensus network must decrypt C1C_1C1​ to recover PPP. The decryption process follows:

  1. Each CN computes and shares siRs_iRsi​R, where:

    • RRR is the commitment of the random scalar rrr,

    • sis_isi​ is the local secret key.

  2. Once the seed PPP is recovered, the original message msgmsgmsg can be decrypted using AES.

Signature

For a given message msgmsgmsg, Neo X generates a signature through the following process:

  1. The message is encoded to G2G_2G2​ as Q=HashToG2(msg)Q=HashToG2(msg)Q=HashToG2(msg)

  2. A signature share is computed as siHs_iHsi​H where sis_isi​ is the local secret key.

Each participant uploads F(x)=f(x)G1F(x)=f(x)G_1F(x)=f(x)G1​ within his PVSS to the contract.

The recipient reconstructs the original local secrets using .

Since validator indices (DKG indices) are publicly known within Neo X Governance, these shares can be aggregated and solved using a .

After collecting enough broadcasted shares, CNs aggregate and get the final signature with in the same way as TPKE decryption.

v0.3.0
Lagrange interpolation
Vandermonde matrix
Vandermonde matrix
KeyManagement