# notes on Ferveo: DKG + TPKE 4 mempool privacy

## [Ferveo: Threshold Decryption for Mempool Privacy in BFT networks](https://eprint.iacr.org/2022/898.pdf)

### intro

"Ferveo is an efficient distributed key generation and threshold public key encryption
protocol for Tendermint-based Proof of Stake blockchains with minimal assumptions over
those used to achieve consensus. The assumption alignment and concrete efficiency are
the key features"

Ferveo consists of:
• A publicly verifiable DKG scheme with acceptable performance
• A threshold public key encryption scheme with excellent performance that can scale
to thousands of transactions: Figure 1
• A pure-Rust implementation of both the DKG and TPKE schemes, built on arkworks [1]
• Naturally integrate-able into Tendermint based blockchains

### security assumptions

"The details of Ferveo mirror the security assumptions of the underlying blockchain very
closely. Ferveo achieves this by using a single non-interactive round for each validator in
both the DKG and threshold decryption schemes."


### timing


"While our O(nm) communication synchronous DKG protocol with n validators and m
private key shares is worse than the best achievable O(m log n) communication complexity,
the concrete performance remains good for reasonably sized (100-200) validator sets. Future
work can substantially improve performance in this area."

### other private mempool approaches


### design goals

- Weighting - "DKG computational complexity scales significantly in the number of shares.... A compromise approach is to give validators private key shares according to their approximate relative staking weight"
- Approximation of voting power by shares
- Public fees - Transaction fees and gas limits must remain public
- Consensus Efficiency

### handling malicious transactions

This section in the paper goes over what happens when undecryptable garbage ia submitted and how to avoid throwing away the block or even halting the chain.

I dont really understand how the design addresses this issue.

### drawbacks

- pub keys are generated using the DGK every epoch, and the next epochs generation starts during the current epoch. Sending txns on the boundary of the epoch is a tough UX as users must chose between them and which key to encrypt to.
- "In particular, it is desirable to have a publicly verifiable DKG, so that a party’s lack of liveness during a DKG complaint round does not affect their risk of getting invalid key shares." although fevereo is publicly verifiable

### protocol details

check da paper