New FRP: Incentive-Compatible Encrypted Mempools

[nicolas3355]

No description provided.

[sarahalle]

Thanks for submitting this proposal! We are reviewing it and will get back to you with any questions or feedback

[jopasserat]

Hello and thanks for your submission! The overall topic and direction are both interesting and relevant to our interests. I have a few comments and questions about the proposal though:

• while i agree with the important element of calibrated costs when applying penalties, i didn't remember the traitor tracing construction you're citing as leading to unreliable detection: can you unpack what you mean here?
• what kind of timelock puzzles are you considering? we're not super comfortable with VDFs' guarantees in general. as far as i understand you intend to improve on a paper that relies on non-sequential DL-based puzzles? I'm not an expert on the topic but I have concerns on how this can be calibrated in the first place to even obtain some meaningful security.
• will your construction be designed so that it can be extended to handle a programmable privacy variant? we would love to make sure that the design could support FHE as underlying encryption for instance
• you need better positioning against more recent literature on the topic: recent works (BEAT-MEV, BEAST-MEV) have addressed the issues of efficiency and solved the privacy problem when that led to non-included transactions to be revealed upon decryption

[nicolas3355]

Thanks for your feedback! Please find our answers below:

1. Regarding the cited paper, they do not provide protection against MPC attacks. In particular, they consider that running an MPC protocol to compute a function depending on all secret shares is outside their model. Please refer to the main paper and the “Secret Sharing with Snitching” for more details. Furthermore, we believe this is not limited to the techniques of the above papers and can potentially lead to generic impossibility results about reliable detection for threshold decryption. We would be happy to look into this direction in our research and/or include a formal proof.

2. We are not relying on VDFs or strong sequentiality guarantees. An adversary can parallelize as much as they like. Instead, we use discrete-log-based puzzles as the delayed-decryption mechanism in a Nakamoto-style model, where we assume that the aggregate honest computational power exceeds that of any adversary.

   The goal is to tune the puzzle difficulty so that, with high probability, no party can decrypt before the relevant on-chain commit point, while decryption becomes feasible after that point. We do not claim to rule out the event of having the adversary decrypt before the commit point; instead, our target is to make the probability of such early-solved events small enough under our computational assumptions.

   Two additional subtleties we explicitly account for:

   Non-reporting of solutions: A party that solves the puzzle is not forced to report it on chain. In particular, a malicious solver might prefer to keep the solution private and exploit MEV rather than claim the public reward. This means the on-chain record of reported solutions underestimates the true solving power; we cannot safely treat the observed reward claims as a complete calibration signal.

   Calibration and difficulty adjustment: Because of the above, we treat difficulty calibration as a conservative analytical exercise, not as a tight feedback loop driven purely by on-chain statistics. We choose parameters so that, under reasonable upper bounds on adversarial computation (and given that honest power is larger overall), the probability that an adversary solves “too early” (i.e., far enough before the commit time to profitably reorder) is practically small.

   Our contribution is to structure the puzzle and parameter regime so that, given honest-majority computational power, this happens with very low probability and within clearly stated, analyzable assumptions.

3. Our current focus is on constructions instantiated over DL-based encryption on elliptic curves, which (to the best of our knowledge) is partially homomorphic encryption (e.g., group homomorphism in the exponent). However, the techniques we develop are orthogonal to the specific hardness assumption. We aim to design the system in a modular way such that any suitable "delayed decryption" mechanism could be plugged in without affecting the underlying blockchain. We would be happy to explore a lattice/FHE extension if that better aligns with your vision of programmable privacy.

4. Our understanding is that these works make strong progress on efficiency and on privacy for non-included transactions, but remain vulnerable to undetectable collusion by the committee. That vulnerability is precisely the core focus of our proposal. We agree that BEAT-MEV, BEAST-MEV, and related works deserve a more explicit and detailed positioning in the write-up, and we plan to expand that discussion. We view that as a very natural next step and avenue for future works.