Meeting Summary:
This was the sixth meeting of Encrypted Mempool, focused on discussing Lucid protocol design and implementation progress. Justin Florentine hosted the meeting and introduced a new documentation repository called Lucid PM that collects pointers to PRs and specs needed for the protocol. The team discussed key release fees and their billing mechanism, with participants noting confusion about how these fees should be represented and calculated alongside gas fees. Gottfried presented research on optionality issues in the Lucid design, explaining that probabilistic front-running and builder optionality are inherent challenges due to the lack of threshold encryption capabilities. The group acknowledged that while threshold encryption isn’t currently ready for production deployment, particularly due to post-quantum security requirements, any future implementation would likely render Lucid obsolete. Boma and Mark expressed interest in working on CL specifications for standalone components like SSE containers and inclusion lists while waiting for CL developers to become more involved in the specification process. The conversation ended with a discussion about the need for a comprehensive list of requirements from the Ethereum perspective to share with cryptographers working on threshold encryption solutions.
Click to expand detailed summary
Justin opened the Encrypted Mempool meeting and discussed the need for CL dubs, noting that the team working on EPBS is currently busy. He introduced a new Lucid PM repo he created to collect documentation, PRs, and specs, with an EAP and draft PR for execution specs currently available. Justin invited feedback on the repo and encouraged participants to open PRs or comments to help coordinate technical work toward SFI.
Boma sought permission to work on standalone CL specifications in parallel with the EL specification that Justin is currently working on. Justin approved the approach, suggesting that early work doesn’t need to follow strict best practices since the process is still in an early stage. Mark expressed reluctance about getting involved in CL development due to Aragon’s typical approach of waiting for specs to appear before implementation, though he acknowledged this might be an opportunity to get more involved earlier in the process.
The team discussed the need for a CL implementation to progress their work, with Mark offering to engage CL developers and assist with implementation. Boma proposed starting with lower-hanging fruit items like SSE containers and payload bid extensions to prepare for CL developers’ involvement. Loring suggested the possibility of securing up to $10,000 in incentives through a bounty program, though Justin noted the challenge of defining success criteria without CL expertise. The team also demonstrated a Kurtosis stack for sandwich attacks on Fusaka, though they acknowledged the need to transition to Glamsterdam once it becomes more stable.
The team discussed key publication fees and their implementation in the Lucid spec. Mercy raised questions about how these fees are billed and their impact on gas calculations. The group debated whether to treat key publication fees as a separate object from gas fees or integrate them into the existing fee structure. They concluded that while the fees impact available gas funds, the spec should be rewritten to clarify this relationship and make it clearer how all fees come off the top from the beginning.
The team discussed the implementation of key release fees, which were determined to be orthogonal to bundling features. Mark and Justin proposed that wallets would need an RPC to estimate these fees, though Gottfried questioned whether this should be a public service. Justin identified a design gap regarding key publication fees and suggested working offline to simplify the language in EIP 8184, with himself and Anders potentially collaborating on this task.
The team discussed optionality issues in the Lucid design, particularly focusing on probabilistic front-running and builder optionality. Gottfried explained that without threshold encryption, Lucid inherently has optionality problems that cannot be fully solved, though some mitigations like top-of-block fees and punishing PTC vote equivocations could help reduce exploitation. The group acknowledged that if threshold encryption becomes sufficiently mature, Lucid would need to be redesigned entirely, as the current agnostic approach would be superseded by more advanced cryptographic schemes. The team also noted that post-quantum security requirements make existing threshold encryption solutions unsuitable for Lucid’s needs, and Benedict’s requirements list for threshold encryption was shared in the chat.
Next Steps:
- Justin: Talk to EF cat herders about improving the reliability of meeting startups.
- Boma: Scaffold the CL spec under EIP-484 and work on the standalone pieces (SSE container, inclusion list, payload and BDM extensions, Lucid key votes) in parallel with the EL PPR.
- Mark: Talk to Aragon’s CL guys to persuade them to get involved in the CL speccing process.
- Mark: Review Boma’s CL specs and provide feedback from a CL implementation perspective.
- Loring: Work with someone else in the next week to outline a bounty proposal for kickstarting the consensus spec, and coordinate with the relevant parties (shutter, Dow, 0x.3, 6) for potential funding.
- Justin: Make the Kurtosis stack for sandwich attacks public and share it with the group.
- Justin: Work with Anders (and others) to simplify the language in the spec regarding key publication fees.
- Justin: Talk to ACD about the optionality issue in Lucid to get clarity on whether it’s a deal-breaker for SFI.
- Justin: Talk to POTUS about the builder optionality issue and potential design mitigations.
- Gottfried: Share the link to the list of requirements for threshold encryption (from Benedict) in the Telegram chat.
Recording Access: