Currently, the benefit PBS might provide to on-chain execution is limited by the lack of a reliable link between a block builder and EVM execution. The most direct link - the block.coinbase address - is set by builders but can be arbitrarily assigned; its association with the builder is not verified. Requiring a signature verification (or similar) to prove ownership of the block.coinbase as part of the consensus layer’s block validation process will unlock novel DeFi primitives and turbocharge the benefits of PBS to the execution layer.

Example Use Cases:The consensus layer signature verification of a block’s block.coinbase unlocks many novel protocol designs and decentralizes many existing ones. Many of these designs would operate by having builders stake through a block.coinbase smart contract - think on-chain, atomic EigenLayer for builders. Validation of ownership of the block.coinbase allows for fully in-protocol slashing / reimbursements. Some examples:

Unfortunately, most of these are quite tricky to explain without first defining in detail the exact design of the underlying smart contract. So for this post, I want to stick with something relatively simple:

OK, actually that isn’t simple at all… but it’s the most straightforward to diagram out the full flow and fully define all core functions. 

Why Can’t We Do Multi-Tx Flashloans Now?

tldr: because of reorgs and relays.

First, let’s define a “multi-tx flashloan” as a permissionless loan offered by the builder to a user in a transaction and that is repaid in a separate transaction, later in the block.

It’s true that builders currently control the contents of a block. If a builder wanted to, they could set a block.coinbase address to a smart contract that they control that has some of their collateral in it for lending. This contract could define a borrow() function, and put a modifier on it that stipulates require(block.coinbase == address(this));.

dApps could then call a borrow() function on that block.coinbase contract, and the builder could only include the borrowing tx in their block if they also have a handleRepayment() tx that fully repays the borrowed amount. They would only sign the block if they’re fully repaid by the end of it.

Unfortunately, this could end up costing the builder a lot. As you’ve probably already surmised, an attack vector is created by the fact that any builder can build a block with any block.coinbase address. Should a “reorg” leak the contents of the builder’s block, another builder could copy the original builder’s block.coinbase address and put it as the block.coinbase for their own block and then execute the borrow() function, which would pass the require(block.coinbase == address(this)); check. This other builder wouldn’t need to include the repayment tx.

Technically, a reorg isn’t even required - anyone can spoof a block.coinbase address, meaning anyone could steal the builder’s collateral without even sending a tx to the builder. This could be overcome by the builder’s lending contract requiring that all multi-tx flashloan requests can only be issued after a preapproval tx signed by the builder in the same block. The builder would initially be the only entity to have the full preapproval tx, but it would be vulnerable to a reorg.

But even if reorgs were “solved” and the builder used a same-block preapproval system, the builder would also need to trust that their PBS relay wouldn’t leak the transactions. A single rogue employee at one of these block relays could easily drain the builder of their entire collateral by initiating the borrow() transaction themselves, intercepting the “preapproval” tx from the relay, and then making their own block without the loan repayment.

Terminology

The EVM’s inability to see future state leads us to one conclusion: only by consensus layer validation of the builder’s ownership of block.coinbase (or a similar EVM-accessible address) can builders atomically offer or accept guarantees that are dependent on a future event and that have monetary value to adversarial actors.

We refer to a builder’s capacity to preemptively confirm the fulfillment of their counterparty’s precomittment as “Builder-Observed Preindemnification” (BOP).

We refer to the aggregated locations of the data needed to determine if Builder-Observed Preindemnification (BOP) has been achieved as the “BOP Surface.”

We refer to a builder’s capability to atomically, trustlessly, and permissionlessly offer services in exchange for precommitments by leveraging Builder-Observed Preindemnification (BOP) as “Builder-Offered Optimistic Precommitment Settlement” (BOOPS).

Full coverage of the BOP Surface is a precondition for BOOPS. Note that properly understanding any sequence-dependent aspects of the BOP Surface is critical to enable cross-domain BOOPS - we’ll write more on that subject in a future post.

Multi-Tx Flashloan Flow

We revisit many of the same strategies as outlined above, only now it’s trustless because we know that the contract at block.coinbase will only execute if the entirety of the block was built by that specific builder.

MultiTxFlashloan1623×1234 218 KB

The key breakthrough here is that the builder is empowered with the knowledge that their smart contract will only execute when the builder has signed and validated the entire block. The entirety of the BOP Surface is covered, allowing for trustless BOOPS.

While it’s true that this means that the builder’s smart contract “trusts” the builder’s backend, this should not be an issue for builders. Handling the trust assumptions between a smart contract and a backend is an experience shared by every MEV searcher on every chain… and seeing as how most top builders are current searchers (Rsync, Beaver), former searchers (Titan), or have former searchers on the team (Flashbots, bloXroute), I do not think this will slow them down.

Potential ImplementationsThere are two primary paths to implementation:

Other Thoughts

Assuming SGX can be fully trusted, a limited version of this should be possible on SUAVE for BOOPS that have a BOP surface entirely inside of the SGX.

I also want to state for the record that I tried to come up with less silly-sounding acronyms for these terms, but they are literally the only things I could think of that accurately describe the complexity of what’s going on in less than a dozen words.

Please let me know if you can poke any holes in the logic or uncover any attack vectors on the multi-tx flashloan system as diagrammed above… This kind of design is always an iterative process and I’m sure there’s at least one or two things I’ve overlooked. Please break it so I can rebuild it.

Thanks for reading!