Opening this thread is to discuss the Universal Enshrined Encrypted Mempool EIP (number pending).
2 Likes
Hi all — sharing a small prototype ( Github: janrockdev/nexeth ) that overlaps with the key-provider side of this EIP, and a question about whether this is the right thread for it.
I’ve been building nexeth, a consensus-anchored timelock encryption scheme: seal a payload so nobody — including the sealer — can read it before a chosen moment, with no custodian holding the key. Release is gated by a real drand threshold beacon signature, verified on-chain via the EIP-2537 BLS12-381 precompiles against a public key pinned at deployment. Whoever submits the round becomes a relayer, not an authority — they can delay release, but never forge, backdate, or release early.
I noticed EIP-8105’s key-provider registry is deliberately encryption-agnostic — a contract just needs to expose a decryption function and a key-validation function, with the actual scheme (threshold encryption, MPC, TEEs, delay encryption, FHE) left open. nexeth is essentially a working, on-chain-verified instance of one of those categories: a threshold-beacon key provider where the validation step is a pairing check against a pinned public key rather than a trusted submitter. It’s been run end-to-end (seal → verify → unseal, plus early-failure and tamper-detection paths) against a live 4-validator Besu QBFT devnet and the real drand quicknet network — not simulated. Not production-hardened, and not published anywhere yet, but happy to share the repo/writeup if useful.
Question for the group: is this thread the right place to bring up a concrete key-provider implementation like this, or would it be more useful as its own Magicians thread / ERC (e.g. a standard drand-beacon key-provider contract that other enshrined-mempool or timelock designs could reuse), or does it belong outside the ERC process entirely since it’s an application built on existing precompiles rather than a protocol change? Don’t want to derail the EEM design discussion with something that’s really about one candidate key-provider implementation.
Thank you,
Jan
1 Like
I wanted to explore if we could still achieve CR under a trusted set. One avenue is to have validators construct the weighted longest path of the trust DAG when enforcing the ILs.