Announcing Flashbake, an initiative to tackle BPEV on Tezos

Also posted on Medium

When a Tezos user submits a transaction, it is transmitted to the bakers who store it in their mempool until it is included in a block.

Every transaction contains a fee for the baker. When it is their turn to bake a block, the baker picks the transactions with the highest fees and assembles them into a block up to the size limit.

What happens then when blocks become full? The default baker implementation will prefer transactions with higher fees. The user can increase the fee to get the block included quicker, in the event of network congestion.

But including transactions in decreasing order of fees is not a requirement of the Tezos economic protocol. The protocol assigns baking rights to bakers, but the choice of transaction to include in a given block is a pure prerogative of the baker.

As is turns out, picking the transactions with the highest fees is not always the most lucrative choice. Consider for example Liquidity Baking. With every block may come an arbitrage opportunity between tez and tzBTC. The baker of the block has the power to capture this opportunity by inserting a trade as the first transaction of the block.

In Quipuswap or other automated market maker contracts, every trade changes the exchange rate of the traded pair. This creates additional opportunities for the baker to extract value from the transaction by inserting another transaction before and/or after the user’s trade.

This is detrimential to Tezos users, who generally want their transactions to be included cheaply, quickly and privately.

The theoretical gain for the baker is called BPEV: block producer extractable value, also known as Miner Extractable Value (MEV) in other ecosystems.

All it takes to wield this power is to modify the Tezos baker code. Bakers may select and order transactions themselves or outsource it to bots, which in turn pay the bakers for access. Anyone pushing a transaction to the network is at risk of being reordered or censored. This is colloquially known in the Ethereum ecosystem as the dark forest.

This is very much a reality in Ethereum and could become an issue in the Tezos ecosystem too. To address this, we are announcing the Flashbake initiative. We are a collective of three software engineers and Tezos enthusiasts. Look out for our rallying emojis​:zap::bread: on our Twitter profiles. This work is sponsored by the Tezos foundation and administered by MIDL.dev.

There are other initiatives to mitigate BPEV at protocol level: see for example Timelock.

Our minimum viable product: Flashbake Protect

Profitable transactions on Tezos are bid upon in the public mempool. We are proposing a private, off chain, system to send a transaction to a baker. It benefits the Tezos network and its users in a few ways:

  1. Less Mempool Congestion — By moving bidding transactions off chain, there are less transactions in the mempool, which lowers the memory consumption of Tezos Nodes, decreases P2P network I/O and quicker inclusion for other transactions
  2. Less Consumed Blockspace — Any transactions that are outbid for a profitable opportunity will generally fail, but still be included in a block. This failure consumes available block space, baker compute resources, and increases the amount of disk space required to run the Tezos chain.

Additionally, users of this system benefit in a few ways:

  1. Privacy — Users may submit transactions that are not publicly visible until inclusion in a block
  2. Decreased Cost — Since the private system drops transactions not able to be executed, transaction fees from these transactions are not paid by the users.

We are currently building such a system. It is named Flashbake Protect (:zap::bread::shield:) and composed of three parts:

Relay service

A service which relays private transactions to bakers. It exposes a RPC identical to the Tezos RPC, but intercepts injection operations to bypass the public mempool and send transactions directly to bakers.

Because the relay service exposes a native Tezos RPC, it is directly usable by Tezos wallets.

We will operate a public goods relay service, but anyone can run their own for additional privacy.

Flashbake endpoint

A new software service run by bakers to include private transactions sent from the relay. It runs a sealed auction system where only the transaction with the highest paying fee is included.

Smart Contract Registry

An on-chain map of Bakers’ public keys to a URI of their Flashbake Endpoint. Used by the relay service.

All work will be open-sourced and available in our Github organization. And for those of you on the tezos-dev slack, please join us in the #flashbake channel.

Future

The BPEV domain is vast. We aim to get this product up and running and some Tezos bakers onboarded as soon as possible, garner community feedback, and iterate from there.

11 Likes

Hello,
We have built a proof-of-concept of Flashbake in a private chain.

We transact by sending an operation to a flashbake relay. The relay acts as a regular tezos-node RPC endpoint, but intercepts the injection operation and forwards it to the next flashbake-capable baker, bypassing the mempool.

Flashbake-capable endpoint URIs are recoded in on-chain contract storage.

We then run 2 concurrent transactions, one with a higher fee than the other, and observe that the one with the higher fee is included first.

The experiment is described in more details here, along with intructions to replicate it.

Our focus is now to deploy flashbake on testnet and mainnet.

2 Likes

Flashbake is now operational on Ghostnet. Please read the Medium post for details.

1 Like

Forgive my ignorance, but how exactly does Flashbake prevent bakers from ordering transactions? They still get everything sent to them, right (outside of the mempool)? Or is the data encrypted in some manner? If it is encrypted, why could a similar system not be used for transactions publicly sent to the mempool?

I also wonder about the introduction of a new trusted party; what powers would theoretically be available to a hostile relay service?

Lastly, could a hostile party not spam the relay service with a high number of low-fee transactions, since that party doesn’t have to pay fees for transactions not included in the block?

Forgive my ignorance, but how exactly does Flashbake prevent bakers from ordering transactions? They still get everything sent to them, right (outside of the mempool)? Or is the data encrypted in some manner? If it is encrypted, why could a similar system not be used for transactions publicly sent to the mempool?

Flashbake does not prevent a baker from ordering transactions. It is a system to bypass the mempool. Your encryption idea sounds like timelock (which has a bug and should not be used for now).

I also wonder about the introduction of a new trusted party; what powers would theoretically be available to a hostile relay service?

A dishonest relay can see all the transactions and reorder them itself instead of simply forwarding them. But the mempool also has this problem. And this can be mitigated by running your own relay, the relay on flashbake.xyz is provided for convenience only.

Lastly, could a hostile party not spam the relay service with a high number of low-fee transactions, since that party doesn’t have to pay fees for transactions not included in the block?

Indeed, or you can also spam the baker’s Flashbake endpoint directly. But spam can be mitigated by prechecking every operation before accepting or fowarding it, much like Octez does it.

Thank you kindly for your replies. What I don’t really understand: if Flashbake doesn’t prevent a baker from ordering transactions (that it received through a relay service), how exactly does it address BPEV?

Having the transaction hidden from anyone but the baker is progress. Flashbake does not address BPEV by itself. It is a framework to make the extraction (if any) more transparent so the bad parts can better be addressed at protocol level. You can refer to the flashbots litterature on Ethereum to see why it’s a net positive.

Thanks, that does clarify it and I see the benefit. It also leads me to another question: could a malicious baker publish the information coming in from the relay service and effectively undermine the benefits from flashbaking?

Absolutely, the baker may “resell” the private transactions. This could be mitigated in-protocol by having flashbakers produce signed receipts, and such behavior would be slashable.

1 Like