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.
