Consensus for FHE Validation

🔍 Understanding POSIV

In this section, we'll delve into reaching consensus for FHE validation work post private voting and upon receiving all encrypted votes. It comprises four main components: POSIV_Input, POSIV_Output, POSIV_Consensus, and optionally, POSIV_Decryption.

POSIV_Input 📥

POSIV_Input gathers encrypted votes from each SIV and records them as immutable data for verification. Its size and voting windows are defined by the Hub. For instance, the Hub can decide to:

• Accept a fixed number of initial votes (e.g., fixCountCriteria=100 SIVs)

• Begin consensus after a fixed time period (e.g., fixIntervalCriteria=1 minute)

• Accept a fixed portion of opt-in SIVs (e.g., fixPercentageCriteria=70% of Opt-in SIVs)

• Or a combination of these criteria. Once criteria are met, POSIV_Input stops receiving new private voting entries and triggers POSIV_Consensus.

POSIV_Consensus 🤝

POSIV_Consensus activates after POSIV_Input and conducts a determined FHE Computation, converting an array of FHE encrypted values into one. The FHE Activation Function (fheActivationFunction) is specified by Hub in the Task Definition, for examplefheMean, fheAverage, fheMajority, fheRank, etc. POSIV_Consensus is a Hub dedicated focus on FHE Validation Consensus and in permissionless mode to accept FCN (FHE Consensus Node). Each FCN can opt-in a particular task and run the fheActivationFunction and send the result to POSIV_Output. Let us take fheAverage as an example. Each FCN will run fheAverage on all the stake by encrypted votes and send to POSIV_Output.

POSIV_Output 📊

Since fheActivationFunction is deterministic, each FCN should generate the same output with the same POSIV_Input. Thus, POSIV_Output conducts majority votes by checking if 2/3 FCNs respond to the same encrypted value, similar to classical POS consensus. It represents the output of FHE Consensus from all FCN responses.

POSIV_Decryption 🔑

Some Hubs prefer complete control and conduct fheDecrypt by themselves or a trusted party, completing the consensus here. Others may use Mind for fheDecrypt, where POSIV_Decryption comes into play. POSIV_Decryption focuses on FHE Validation Decryption with FDNs (FHE Decryption Nodes). Each FDN decrypts a portion and aggregates to the final true result in POSIV_Output. The decrypted result can be directly consumed by RPC or trigger calls to other smart contracts, or for example, to distribute rewards.

We have developed a docker image to enable FCN and FDN, and their main functions are as below:

/* FCN key functions */
// load fhe public evaluation key required by validation task
public async loadFheEk(fhePk: bigint)
// load fhe public evaluation key required by validation task
public async loadFheActivationFunction(fheActivationFunction: bigint)
// to encrypt votes with FHE
public async loadFheConsensusInput(fheConsensusInput: Array<bigint>)
// to encrypt votes with FHE
public async fheEval(fheActivationFunction: bigint, fheConsensusInput: Array<bigint>) 
// to sign with wallet and send the encrypted votes to chain
public async signSendFheEncrypted(encryptedActivation: bigint)

/* FDN key functions */
// load fhe secret key
public async loadFheSk(fheSk: bigint)
// to encrypt votes with FHE
public async loadFheConsensusOutput(fheConsensusOutput: bigint)
// to encrypt votes with FHE
public async fheDecryptPart(fheConsensusOutput: bigint) 
// to sign with wallet and send the encrypted votes to chain
public async signSendFheDecrypted(decryptedResult: bigint)