There is a large number of long-running discussions, designs and proposals focused on solving, broadly speaking, this “inclusion-time privacy” issue for transactions.
This particular EIP serves as a template of how EIP-8141 Frame Transactions may be applied and extended to address this issue with a relatively simple design.
Some links to relevant publications or discussions I could find so far (comment to add more):
Thanks for the proposal. It’s very close to the Sealed transactions design with a hash that goes into the first payload. However, I made a series of improvements to, .e.g, facilitate shorter slots under ePBS, protect against probabilistic front-running, and maintain decentralization, which led to the LUCID encrypted mempool design in EIP-8184.
Concerning the commitments in the payload as in your proposal; in Appendix B of the LUCID research post I discuss requirements and strategies that can be used for protecting transactors when putting the commitments there. However, I think you will find after a review of those options that it is still more desirable to put the commitments in the beacon block as in LUCID.
Is there an attack where a well-peered attacker publishes a commitment, withholds the reveal until the very last second, and then only directly sends the reveal to validators other than the one currently building the block?
I guess the idea is that because the non-building validators would forward the reveal to the building validator before the end of the slot, the building validator would have time to include the reveal?
Thanks for your response @aelowsson! I have added the link to “Sealed transactions” link to the topic header.
Sure, and I appreciate the benefits of the beacon block placement of ST commitments in the current LUCID proposal. However, I was hoping that a somewhat similar set of properties and timelines could be potentially achieved with Frame Transactions, by including the “VERIFY” and “COMMIT” frames in the “regular” inclusion lists. (With “regular” meaning a future, Frame Transaction compatible variant, of course).
I would appreciate any feedback on this topic, as the outlook for this EIP is simply “if Frame Transactions are in fact included, what is the simplest functional design for mempool protection”.
Yes, exactly. And ideally, as long as the REVEAL_DEADLINE is short enough, the current builder/proposer would eventually catch the delayed reveal and include it, protecting itself from producing a violating block.
This is probably too much analysis to throw at you to satisfy my idle curiousity, but I’m hoping that this has already been thought through. I’m also not at all familiar with how mainnet is actually connected; maybe every validator is directly peered with every other validator, but…
I’m imagining an attacker with perfect knowledge of how the p2p network is laid out, like who is peered with who.
By selectively sending or not forwarding reveal transactions, like for example sending reveals only to validators that are connected to the current builder through attacker-controlled nodes who drop the reveal, an attacker could force a block to be under-attested.
Using something similar to how mainnet is laid out today, what percentage of nodes would the attacker need to control to perform this attack?
On the contrary, thanks for your interest in this topic.
Well, to the best of my understanding, this implies some level of naivety on the side of the builder - when in fact successful block builders must be deeply invested in being the best-connected nodes in the network. I was hoping that as long as at least one validator is able to “leak” the “reveal” to any part of a p2p network that is not controlled by the attacker, this “reveal” will reach the block builder relatively soon.
Unfortunately, I don’t have this information, but I will be happy to look into it, especially if there exists a p2p network data you could recommend.
a few questions reading 8209 next to 8141 and 8046:
with 8046, does a REVEAL frame also pay the marginal inclusion fee? the escrow is only COMMIT_GAS_RESERVATION at max_next_base_fee, so it doesn’t cover it. should REVEAL be exempt, or should the escrow cover both?
in integers base_fee * 1.125 equals base_fee when base fee is under 8 wei, but 1559 still raises it by at least 1 wei, so the refund goes negative. would base_fee + max(base_fee // 8, 1) work?
what’s the caller of a REVEAL frame? 8141 sets it only for SENDER, DEFAULT and VERIFY. is the payload hash meant to be the only link between a REVEAL and the commit’s payer?
I am not an expert on EIP-8046, but from what I understand it would be preferable to not have any special exemptions for REVEAL frames. In any case, it is probably a little too early to actually reconcile EIP-8209 and EIP-8046 at this point, as both are early drafts and neither is currently proposed for inclusion.
This appears to be an accidental omission in the specification, I will update the spec.
I believe that for the most basic use-case the REVEAL frame should be very similar to the DEFAULT frame in everything, except for being “detached” from the VERIFY one.
If a real use case arises that requires a SENDER frame alongside the REVEAL one, we may need to reconsider this behaviour or add some kind of a flag for the REVEAL frame.
Thank you, I’ve merged that PR. Would be happy to collaborate further on these ideas, and potentially propose the EIP for the I* upgrade.
