Encrypt The Mempool #010
Transcript
- Justin Florentine
- Anders Elowsson
We should use effective balance. Otherwise it can be gamed by splitting up stake
- Boma
https://github.com/ethereum/consensus-specs/pull/5403#issuecomment-5623731714 Dropping this here as I might have to drop from the call soon little context - jtraglia wants to merge the CL draft and the only open question is whether key publishers should be in-protocol, which is exactly what the validator whitelist voting discussion is trying to answer. Should we merge the current off-protocol base now and update it once the whitelist design settles, or hold the merge until that decision is made? Please leave a comment in the pr
- Justin Florentine
i think we should hold it
- Boma
Reacted to "i think we should hold it" with 👍🏿
- Anders Elowsson
For spam protection, need to check the votes to see if they make sense before bandwidth limiting someone. Otherwise you can create situations (non-reveal) where everyone needs to vote to update the list several times and then get bandwidth limited.
- Anders Elowsson
I always felt that the original idea where the transaction specifies which key publishers can precede it was more safe
- Anders Elowsson
Yup the trust graph
- Anders Elowsson
Yeah
- Anders Elowsson
Yeah that’s true
- Gottfried Herold
The problem with the trust graph is that it puts (unneeded) restrictions on ordering.
- Gottfried Herold
Where we actually only care that we decrypt at all.
- Gottfried Herold
(from the protocol side)
- Gottfried Herold
since we have ordering via a fee mechanism.
- Anders Elowsson
But why would it be unusable. We would just do regular LUCID and this is like a spice on top
- Anders Elowsson
I think they just can’t go on top
- Anders Elowsson
Yup like that
- Anders Elowsson
Those in the white list are sorted y fee on top, the rest sorted by fee below
- Anders Elowsson
Yeah but’s not as bad
- Anders Elowsson
It allows for a less black-white mechanism
- Anders Elowsson
Better do 50% among all stake
- Anders Elowsson
You can “prove yourself” before entering the whitelist
- Anders Elowsson
Yes imo
- Anthony
See you in a month
Call summary
Decisions
- •Encrypt The Mempool call cadence changed from bi-weekly to monthly - 00:14:37
- •PQ threshold encryption deferred indefinitely; crypto not mature enough - 00:17:34
- •50% of total effective stake as allowlist admission threshold (Schelling point); negative votes not added due to complexity - 00:49:32
- •Allowlist spec kept in one EIP (EIP-8184) for now; split only if it becomes unwieldy - 01:03:17
- •Hold merge of consensus-specs CL draft PR #5403 until allowlist design settles - 00:35:52
Highlights
- Eip Updates:
- ·Question raised whether allowlist warrants a separate EIP; consensus is keep as one document for now, split later if needed - 00:55:21
- ·Bundles (batching) under reconsideration in Lucid EIP — adds complexity; capital burden may fall on key publishers instead - 00:59:44
- ·Hold merge of CL draft spec PR (consensus-specs#5403) until allowlist/in-protocol key publisher decision settles - 01:04:35
- Organizational:
- ·Justin taking lead for Besu on Hegota; call cadence moving from bi-weekly to monthly - 00:13:43
- Pq And Threshold:
- ·PQ threshold encryption off the table: no efficient silent-setup scheme exists; won't be ready for years - 00:15:02
- ·Lucid remains PQ-secure but has the optionality problem; focus shifts to mitigating optionality via allowlist - 00:17:40
- Lucid Allowlist Design:
- ·Proposal: validator set votes (by effective balance, 50% threshold) to allowlist trusted key publishers; implemented as EL voting contract - 00:20:33
- ·Delegation supported: validators can follow a curated list managed by a delegate rather than maintaining their own - 00:22:03
- ·New idea: top-of-block ordering prioritizes allowlisted key publishers over unknown ones (two tiers, not hard rejection); self-reveal still permitted - 00:46:58
- ·Two-tier top-of-block lowers market-entry barrier: newcomers can build track record and earn revenue before hitting 50% threshold - 00:51:00
- ·Reminder: one commitment in the Lucid EIP must be hiding (needs randomness added); 128x penalty may be reducible if allowlist provides sufficient abuse prevention - 00:56:47
Action Items
- •Jannik Luhn - Open a PR to EIP-8184 capturing allowlist/voting design; Jannik to be added as author - 01:02:34
- •Justin Florentine / Anders Elowsson - Update Lucid EIP: add randomness to the commitment that must be hiding; review 128x penalty given allowlist mechanism - 00:56:47
- •Meeting participants - Leave comment on consensus-specs PR #5403 — hold merge until in-protocol key publisher question is resolved - 00:35:21
Key decisions
Encrypt The Mempool call cadence changed from bi-weekly to monthly
Organizational change to meeting frequencyPQ threshold encryption deferred indefinitely; crypto not mature enough
Post-quantum threshold encryption schemes lack efficient silent-setup and are not ready for implementation50% of total effective stake as allowlist admission threshold (Schelling point); negative votes not added due to complexity
Validator set votes by effective balance to allowlist trusted key publishersAllowlist spec kept in one EIP (EIP-8184) for now; split only if it becomes unwieldy
Consensus to maintain the allowlist and voting design within the existing Lucid EIP documentHold merge of consensus-specs CL draft PR #5403 until allowlist design settles
Delaying consensus-spec updates until the in-protocol key publisher mechanism is finalized
EIPs discussed
AI Disclaimer: Some content or metadata on EIPsInsight may be AI-inferred or automatically compiled. If you find any discrepancy, please contact us at dev@avarch.org.