Shutterized Beacon Chain

Encrypting them is useless if they don’t go at the front of the block after the key is released, because they will be frontrunnable.

Also, the payment isn’t conditional and it is effective immediately:

Idea: let’s make this a two-step process:

Step 1: Submit a transaction with the data hashed. Eventually, it is included in a block. 5/3 of the value of the priority fee is locked, and 1/3 of the value of the priority fee is sent to the coinbase.
Step 2: Submit a transaction with the data unhashed and a link to the first transaction receipt. Eventually, it is included in a block. 2/3 of the priority fee is sent to the coinbase of the second block (twice as much to incentivize producers to include those over new step 1 transactions). The rest of the ether is unlocked. If two epochs pass since the step 1 transaction was included and no step 2 transaction is included, locked 5/3 of the priority fee is burned.

about the sandwiching, sandwichers wouldn’t get any profit (they would actually lose money from gas) from sandwich attacking a transaction so these should stop happening

and i agree with you on the other points

1 Like

I’m trying to think how the proposer can be made to see the decrypted contents before anyone else. There are a few advantages to this.

proposer reveal

  • when keypers reveal their portion of the eon key, it must be in an envelope encrypted using a one-off public reveal key published by the validator, or they can be slashed
  • the validator then publishes their block containing
    • transactions decrypted by the validator using the keyper envelopes only they can read
    • the valid private reveal key they used to do this
    • a new public reveal key ready for their next proposal

Do you think something like this would work? Is there a better way of doing it perhaps?

What’s the advantage of this? In general, it seems risky because it gives a single proposer the ability to withhold blocks if they don’t like the decrypted transactions.

How exactly would the slashing mechanism work? I’m not sure if it’s possible to build a secure one as the proposer can always decrypt an honest keyper’s share and then pretend the keyper was dishonest and published it in plaintext. It’s essentially an unattributable fault.

What you could do instead is make the users encrypt transactions twice. First for the proposer and second to the keypers.

To avoid this step, you could use something like HD wallets.

So honestly, it doesn’t really add anything to shutter as it stands. I’m researching an idea for combining shutter with fair ordering where it would be significant.

Good point about the proposer being able to withhold blocks, although in my application I think the proposer would be spiting themselves, as the transactions would be included in the same order in next block anyway.

Yup, your right. We are already trusting keypers not to reveal early though aren’t we? So perhaps slashing is not required anyway.

Thanks for the input. I hope these questions haven’t distracted from the main thread. It’s a great proposal and I back it wholeheartedly. My only comment is that it needs to be non-optional to be truly effective.

Reading through again, a couple of things struck me:

This is not necessarily a disadvantage. It has the benefit that backrunners will be more selective when sending txs because they have to pay as if execution is successful even if it reverts. This should reduce spam.

This would impact users setting tight slippage for mev protection, except that this will no longer be required as transactions are protected from sandwiching anyway. Slippage can be used as it was designed, as a volatility parameter, not an MEV parameter.

I am very interested in a non-optional version of this proposal where all txs must be encrypted. This avoids a two-tier system where those exposing MEV are otherwise prioritized.

It seems trivial to require that all txs are originally submitted in ciphertext. The failsafe above seems like a good method of recovering liveness in the event keypers go offline. Do you think that is enough for a non-optional version, or are further steps required?

Hey everyone - @jannikluhn and I went ahead and developed a proposal on how to be able to try out this concept with minimal changes. In our proposal validators will opt in and voluntarily commit to building blocks following the rules of the shutterized beacon chain. In further steps, slashing could be introduced, and eventually, it could become part of the consensus.
To even simplify integration further, there could be one (or a few) “mev-boost relays” that build blocks according to those rules. All a validator would need to do is connect to them.

On Gnosis Chain we are confident that we can get a decent % of validators to opt into this scheme. To make it as easy as possible for users to use such transactions a “trusted RPC” can be introduced that can accept regular transactions but then encrypt them and schedule them for the next block that will be built by a participating validator.