Shutterized Beacon Chain

[fradamt]

@wjmelements

That’s not desirable because it incentivizes block producers to censor those transactions to avoid risking their conditional payments. Is there some reason they shouldn’t be at the end of the block?

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:

@cducrest

Block producers need to somehow ensure that encrypted transactions are worth including in a block, i.e. that they can pay for a transacion fee, without knowing the transaction data. If the fee would be paid at time of execution, the block producer would not be guaranteed to be paid, since the account could be depleted in between inclusion and execution.

Therefore, encrypted transactions justify their inclusion by providing a signed envelope paying the fees at the moment of its inclusion in the chain. The envelope includes the fields: gas consumption, gas price, and a signature on these fields, allowing to recover the fee payer address. The fee will be paid on inclusion of the ciphertext transaction to the block producer, i.e. not at the time of execution. The gas consumption of the ciphertext transaction counts towards the gas limit of the block it was included in

[Pandapip1]

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.

[cybertelx]

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

[pmcgoohan]

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?

[jannikluhn]

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.

@pmcgoohan

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

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.

@pmcgoohan

a new public reveal key ready for their next proposal

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

[pmcgoohan]

@jannikluhn

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.

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.

@jannikluhn

the proposer can always decrypt an honest keyper’s share and then pretend the keyper was dishonest and published it in plaintext

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.

[pmcgoohan]

Reading through again, a couple of things struck me:

@cducrest

the user will pay for all the gas it plans to use, even if it uses only part of it at the time the transaction is decrypted and applied

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.

@cducrest

We can also recover liveness by stating that if no block is produced during n slots (due to not having the decryption key)

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?

[mkoeppelmann]

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.

Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.