Hi, I’m Tei from Sunnyside Labs.
Sunnyside Labs is a core dev company of Optimism Collective and Ethereum. We’re scaling Ethereum by contributing and building products.
We’re sharing a high-level proposal to extend Flashtestation for decentralized, untrusted L2 block building. Feedback on onchain Builderhub, WS orderflow, payload propagation, and the path to MEV auctions is very welcome.
Beyond Flashtestations
Flashtestations is a framework that enables verifiable and trusted offchain workload execution by managing and validating TEE workloads onchain.
It was initially developed for Unichain, integrated with op-rbuilder, to prove priority fee ordering.
By extending this framework, we can delegate block building to fully untrusted parties and move toward a more decentralized L2 design, such as enabling MEV auctions.
This document discusses the additional development required to enable such an expansion. However, it does not cover the reasons for delegating block building to an external untrusted party (e.g., MEV).
It focuses on high-level design proposals and highlights key points for further discussion, with the goal of collaborating with the Flashbots team to build a truly decentralized L2 block-building architecture together.
Missing Parts & Proposed Solutions
Flashtestation is not yet production-ready.
While key components such as the onchain registry, DCAP contract, and TDX quote provider are mostly implemented, some detailed integrations—like the block proof transaction—are still in progress.
Since the design for these parts is already prepared and work is underway, this document will focus on discussing major remaining issues instead.
Orderflow(Mempool) Sharing
Existing OP Stack based L2 chains generally operate with a closed, private mempool structure.
Unlike L1, user transactions are not shared among public nodes but are directly forwarded to the sequencer.
While adopting an L1-style public mempool is one possible approach, if we assume that the chain operator prefers not to do so—especially since orderflow can be sensitive in future MEV-related solutions—we need a secure way to share mempool content with untrusted block builders.
Fortunately, we can find a solution in existing systems. Flashbots has developed and operates Buildernet, a decentralized and fair MEV block-building network for L1. Buildernet enables builders to share their orderflow with other builder nodes while ensuring that the node operators themselves cannot access the data.
This is achieved through aTLS, a system built on TEE attestation.
aTLS is currently being discussed for replacement with a simpler, lower-overhead system. However, since the core concept—verifying mutual trust between systems through TEE attestation before data exchange—remains the same, we will continue to describe it as aTLS here.
Each Buildernet node runs inside a TDX VM. TDX boots a fully deterministic VM image with a fixed application. During boot, the VM generates a new TLS certificate, whose private key never leaves the enclave. All of this can be proven by issuing a TEE attestation that includes the public key of the TLS certificate.
Before establishing connections, Buildernet nodes fetch and verify each other’s attestations.
This ensures that both sides are running the correct software and that orderflow data will not be leaked externally.
Moreover, since connections are only established against TLS certificates verified through attestation, each node can be confident that its communication peer is indeed a TDX VM.
By adopting this concept, we can enable op-rbuilders running inside TEEs to exchange attestations, verify each other’s software integrity, and securely share encrypted orderflow.
However, there are several improvements we can introduce beyond the current Buildernet approach.
1. Onchain Builderhub
In Buildernet, components such as TEE attestation, public key registration, and node discovery rely on a centralized service called Builderhub.
In the L2 context, we can take advantage of significantly lower gas costs to move these functions onchain.
Flashtestation’s existing implementation already supports basic onchain TEE workload registration and attestation verification, and this can be extended to manage public keys, TLS certificates, and connection permissions between workloads directly onchain.
This approach reduces central trust points and enables a truly decentralized solution, allowing onchain governance to take over the management authority of the Builderhub configuration.
There is growing interest and development around customized transaction ordering and other forms of block-building customization.
If we imagine a future where such features coexist with untrusted block building and even MEV auctions, it becomes possible to register custom policies—such as priority rules—on the onchain Builderhub to meet each chain operator’s specific business requirements.
2. Websocket Connections
When designing an L2 system, the key difference from L1 is the need to handle shorter block times and much higher throughput. Major L2 chains like Base process a far greater volume of transactions at significantly higher speeds compared to L1.
To avoid performance bottlenecks and enable further scaling, performance must be a top priority.
Using a simple transaction-sharing model similar to Buildernet—based on aTLS and HTTP—could introduce overhead that impacts performance.
To address this, L2 builder nodes should maintain persistent websocket connections to minimize aTLS handshake overhead and enable fast, bidirectional communication.
The entire process of establishing websocket connections between builders—including discovery, public key and certificate retrieval, and permission verification—can be implemented in a decentralized manner by relying on the onchain Builderhub described earlier.
Engine API & Block Payload Propagation
Beyond transactions, two more data streams must be shared securely: the sequencer op-node’s Engine API calls and the built (flash)block payloads. Details:
-
op-node → rollup-boost → op-rbuilder
- newPayload & FCU: Engine API calls that deliver the next canonical block payload and forkchoice state.
- FCU: An Engine API call carrying deposit transactions that triggers new block building.
-
op-rbuilder → rollup-boost → op-node
The builder’s (flash)block payload.
As with TX pool sharing, we can use onchain-builderhub-based discovery and websocket connection.
If the number of builders exceeds what direct rollup-boost ↔ op-rbuilder links can handle, we can also consider a mesh topology where builders connect peer-to-peer and forward information.
In this extended design, the role of rollup-boost becomes more critical.
In the original flashblock-focused setup, its scope was relatively small (though important).
In a multi-builder architecture, rollup-boost must implement the key function of selecting a builder (payload) for each block. We won’t detail that logic here, but in future MEV auction–style systems it will likely be the core component.
In other words, rollup-boost effectively becomes the MEV-Boost/relayers for L2 in the full sense.
Future Discussion Topics
Progressive Permissionless
A fully permissionless system will likely require significant trial and error from both security and scalability perspectives.
To make it realistically shippable, we can start with a permissioned set—similar to L1 Buildernet—and progressively open the system over time.
This gradual approach can be easily supported through permission management implemented within the onchain Builderhub.
Incentive Design
Another essential component of a permissionless system is incentives.
True decentralization doesn’t come for free—different parties need a reason and reward to run block builders.
While an initial permissioned set or a few altruistic builder runners can provide minimal decentralization and basic liveness, a sustainable system ultimately requires a solid incentive structure.
The most promising model, as already well-known, is the MEV auction.
It not only serves as the incentive mechanism for decentralization but can also help reduce spam and provide additional revenue opportunities for chain operators.
This design will likely become the most important topic in the expansion of Flashtestation and the broader decentralized L2 block-building ecosystem.
Sunnyside Labs is excited to join the journey of building this future together.