Takeaways

• You can enshrine arbitrary sidecars into the fork-choice rule of the chain.

  • Coprocessors are an example of a protocol-enshrined sidecar.

• Novel blockspace is abundant and largely undifferentiated. New protocols should reside on an opinionated point on the protocol design frontier to incentivize desired behaviors.

  • One differentiated point on the design frontier is to operate as a sufficiently decentralized “server with blockchain scaffolding” – a centralized entity that provides necessary guarantees such as forced inclusion, an escape hatch, etc.

• Base layers should enshrine more useful tools for developers to build novel applications without the need for deep infrastructure-level knowledge.

Blockchains are inherently social systems that establish credibility by exercising agency over all participants and activities within their scope. However, blockchain participants often rely on exogenous “sidecars” to augment the protocol utility. These sidecars, such as MEV-boost (Ethereum) or Jito (Solana), introduce vulnerabilities that can undermine the protocol's credibility due to their potentially misaligned incentives.

To strengthen credibility, blockchains must consider enshrining certain sidecars directly into the protocol, so all participants benefit from augmented utility within a uniform trust and security model. While this might go against the ‘minimalist’ Unix philosophy tradition of creating software, social systems like blockchains must make opinionated decisions that their community is willing to defend.

Enshrining sidecars into the protocol enables developers to build novel applications without deep infrastructure-level knowledge, offering three distinct advantages:

1. Greater Ecosystem Cohesion

2. Enhanced DevX and UX

3. Better Censorship and MEV Resistance Guarantees

Greater Ecosystem Cohesion

Enshrining sidecars into the protocol prevents outside actors from having leverage and agency over the core protocol, reducing the surface area for social coordination.

The most popular sidecars today offer valuable services related to the block production supply chain. But, their value comes at the expense of a constant friction between the protocol’s goals and the sidecar’s incentives.

• On Ethereum, mev-boost is responsible for the production of over 90% of blocks today. Key infrastructure components such as relays (with yearly operation costs over $500,000 per year) are necessary under the current block-building supply chain regime to facilitate a fair exchange between validators/proposers and builders. The concentrated power of relays (and other key pieces of infrastructure) – to the tune of single-digit entities with the vast majority of slot share – exposes attack vectors for internal or external parties to censor transactions.

• On Solana, over 80% of stake is staked via the Jito-Solana client, a modified fork of the solana-labs client. The Jito-Solana client integrates with Jito, an out-of-protocol blockspace auction for partial blocks (unlike MEV-boost where full blocks are built). Jito’s now-deprecated mempool service created a canonical out-of-protocol mempool that became a significant source of frontrunning MEV attacks at the cost of end-user welfare. Solana protocol had no direct agency over Jito’s decision to discontinue mempool services, a move that had immediate negative impacts on searcher margins in favor of user welfare and the long-term health of the protocol. In a permissionless setting, external entities have the clear incentive to build an out-of-protocol mempool and attract stake, enabling additional value extraction from users.

Enshrining MEV auction infrastructure or more general sidecars brings them into the “view” of the protocol, creating atomicity between sidecar functions and the protocol view. Furthermore, this enables a direct relationship between the community, protocol, and set of validators to participate in important mechanism structures and decisions:

• Increased transparency and aligned incentives: Enshrined sidecars operate within the agency of the protocol, eliminating the risk of the sidecar acting in ways that might be beneficial to itself but detrimental to the broader ecosystem.

• Permissionless composability: The sidecar’s functionality can be seamlessly integrated with other protocol features without adding additional trust assumptions to the system. This enhanced composability can lead to more efficient and innovative applications built on top of the protocol with uniform security guarantees.

• Unified upgrades: The sidecar can be upgraded in tandem with the main protocol, ensuring that all components of the system evolve together. This coordination prevents fragmentation and ensures the entire system remains cohesive over time.

Some might argue that enshrining sidecars “crowds out” the viability of private-market, off-chain solutions, creating an equilibrium where the enshrined solution dominates and constrains out-of-protocol innovation. However, well-designed enshrined sidecars increase optionality and impose healthy market forces among solutions, yielding better products and services. ePBS is one example where it enshrines optionality by providing an additional, in-protocol mechanism for block-building while retaining credible neutrality by allowing market actors to choose between ePBS and MEV-boost. The same logic applies to other sidecars that can be enshrined such as a coprocessor, which is explored later in this piece.

Enhanced DevX and UX

Protocols should constantly strive to offer better versions of the following to their constituents:

1. A highly expressive developer environment that enables developers to build truly differentiated applications without relying on external agents.

2. A seamless user experience that offers users access to uniform security guarantees and composability across multiple applications.

When the underlying protocol isn’t expressive enough, developers are forced to rely on external sidecars to enhance the protocol’s capabilities. This outsourcing inevitably degrades user experience since the protocol can’t guarantee the security or composability with that sidecar.

Consider the case of a cryptoeconomic coprocessor as a sidecar to a given chain. While building applications using external coprocessors increases the expressivity of applications, it also introduces additional friction:

• Misaligned incentives: The coprocessor and the protocol could have misaligned incentives. For example, a malicious coprocessor might censor transactions from certain users.

• Non-uniform composability: In the event of a coprocessor reorg, applications on a chain could have different results for the same coprocessing job, leading to broken composability. Developers would need to ensure that their applications are “coprocessor fork-aware” to ensure they do not incorporate any later disputed or re-orged results.

Instead, by enshrining the coprocessor into the protocol, these complexities can be abstracted away, providing an environment that optimizes for the developer and user experience goals stated above. Developers don’t need to write code to deal with reverting their application’s state due to incorrect sidecar results. Users don’t need to worry about the first-order effects of incorrect externally imported values used by the protocol, as is the status quo of current DeFi protocols.

If the coprocessor is enshrined, it falls within the jurisdiction of the protocol’s consensus mechanism, ensuring that:

• Any malicious results are rejected by the protocol, and the incentives are aligned.

• Developers don’t need to encode revert logic into the application since that is coded into the protocol.

• App composability stays intact as coprocessor results used across the chain are consistent.

Better Censorship and MEV Resistance Guarantees

External sidecars have a higher exposed surface area for censorship and MEV attacks. For example, centralized builders in PBS can censor transactions from certain users, external coprocessors can withhold results to front-run user transactions, etc.

If the protocol oversight is extended to restrain the sidecar’s degrees of freedom, this attack area can be minimized. Enshrining ensures that the users leveraging the sidecar inherit the censorship resistance guarantees of the protocol, instead of being at the whim of external entities.

Continuing the coprocessor example, if the coprocessor is external, there are several ways it can adversely impact the chain:

• Censorship - An external coprocessor could censor requests by certain users or applications, causing liveness failures.

• MEV attack - Say an external coprocessor is used to change the governance parameters of a Uniswap pool (e.g. to determine the swap fees). A searcher can detect the transaction including the coprocessing result (changing the fees from say 1 -> 5%) and frontrun that transaction to either execute many trades at the previous fee or to JIT add liquidity that will benefit from higher fees. Results of the coprocessor are “information leaks” in the mempool and can have adverse effects on the onchain applications.

Now let’s see how enshrining the coprocessor would change this dynamic. An enshrined coprocessor can operate in two modes: synchronous (request and result occur atomically in the same block) or asynchronous (the request and result occur in different blocks).

When operating synchronously, the coprocessor directly inherits the censorship resistance of the chain itself since the transaction is atomic with the on-chain execution, i.e., the outputs of the coprocessor can be used as inputs to other transactions within the same block. The protocol can enforce mechanisms to ensure the result delivery within a pre-specified time, instead of relying on the liveness guarantees of external entities. Since the coprocessing request is atomic, the information isn’t “leaked” in the mempool, also reducing the MEV attack area.

For asynchronous coprocessing, the protocol can reserve a priority lane (say top-of-block) for the coprocessor results to be included on-chain. For example, a coprocessor can run an encrypted mempool via threshold encryption/decryption for an AMM that lives on-chain, with a validity rule that if an encrypted bundle is included/committed to in block N then the protocol must decrypt it in block N+1, with the decrypted bundle placed at the top-of-block N+1. Enshrining this reservation as a block confirmation rule ensures that censoring or frontrunning coprocessor transactions for MEV is not possible as blocks are invalid unless the coprocessor results are decrypted and placed at the top of the next block.

This design pattern of encrypted mempools, enabled by a coprocessor, can be generalized to other DeFi primitives to provide guarantees about order privacy, mitigating the effects of front-running.

Moving Beyond Minimalism

While there are challenges to enshrining sidecars – such as design complications, potential overloading of consensus, and increased protocol complexity – opinionated protocols can offer a significantly better developer/user experience, security, and composability. In a world where undifferentiated blockspace can be spun up at will, protocols should be opinionated where it matters most, balancing minimalism with the need for integrated, community-driven solutions that enhance the experience and security of all participants.

Thanks to Barnabe, Mike, and Shivanshu for feedback and review.