Delegation in Bolt: Outsourcing Sophistication While Preserving Decentralization

Tags

preconfirmations

Author

Francesco MostertsJonas Bostoen

Publish on

January 14, 2025

Read Time

7 minutes

Theme

Bolt

Introduction

Delegation is an approach that allows a proposer to outsource certain duties—both technical (bandwidth, CPU, memory) and economic (pricing, informational)—to a trusted third party. This can dramatically lower the technical and economic sophistication required of individual proposers, but it also introduces a range of important design considerations around centralization, subjectivity, and fault attribution.

This article explores various “levels” of delegation, each with increasing scope for outsourcing, and discusses how each setup fares in terms of five critical properties:

1. Attributability: the ability to objectively attribute faults.
2. Barrier to entry: whether new participants (TTPs) can easily join.
3. Centralization: the tendency for the protocol to consolidate around a few trusted parties.
4. Economic efficiency: ensuring correct pricing for users and adequate fees for proposers.
5. Censorship-resistance: the capacity to withstand censorship by having multiple, diverse participants.

We focus on inclusion preconfirmations as this will be enabled day 1 by the Bolt protocol, enabling L1 users to receive near-instant preconfirmations of inclusion on their transactions.

One key insight for this type of preconfirmations: it is relatively easy to delegate these duties to multiple third parties at the same time, making it more “compatible” than execution preconfirmations (which typically require strict exclusivity unless state is sharded on a per-preconfer basis). This is because theoretically, inclusion preconfirmations should not be sharing state, and their outcome is not dependent on their position in the block. [1]

When explaining delegation in this context, it is useful to distinguish 2 roles:

• The committer: the entity that makes commitments. Inclusion preconfirmations, in this case.
• The enforcer: the entity that enforces that those commitments end up fulfilled.

In Bolt today, the proposer is both the committer and the enforcer. It makes commitments through the bolt-sidecar, saves those commitments, communicates them as constraints to block builders, and then finally enforces them when it’s time to propose a block. This means that if a commitment was made, but not enforced, there is no ambiguity about who is at fault. A key design choice here is the decision to build a local fallback block, that can be proposed even if PBS fails to deliver a valid block. This gives the proposer everything they need to correctly enforce their commitments.

Separating these 2 roles (which is what delegation would do) is hard in the same way that building a reliable distributed system is hard: there is a variety of stuff that can go wrong in between 2 different entities on the internet (formally known as faults). And since we’re operating in a setting where trust is minimal, we have to assume some of those faults can be Byzantine. Because of this, fault attribution becomes much harder to do objectively, which is a big problem in a system that will eventually need to penalize someone for breaching their commitments.

Note: Historically, the difficulties above have made us hesitant to implement delegation. Additionally, there is uncertainty about whether the benefits of outsourcing (e.g., higher proposer revenue in a PBS-like system) apply to inclusion preconfirmations, and if they do, whether they outweigh the downsides.

Level 1: Firewall + Pricing

In this minimal form of delegation, the proposer registers a third-party RPC router (like the Bolt RPC) as a firewall. This firewall handles:

• Receiving and filtering user inclusion requests (based on validity and priority fee).
• Exposing a permissioned streaming endpoint that the proposer’s sidecar can subscribe to.
• Preconfirmation pricing, and communicating that to users (wallets)

Even this minimal form of delegation brings a lot of value. Proposers do not have to expose any endpoints anymore, as well as deal with spam and DoS, because the firewall takes care of that. It also implements any pricing algorithms on behalf of the proposer (which the proposer can still verify).

The proposer’s sidecar still signs every inclusion preconfirmation request. As a result:

• Attributability remains high because only the proposer can sign commitments.
• The proposer can set multiple RPC routers; they do not conflict, because only the proposer’s sidecar signs the final commitment.
• The committer and the enforcer are still the same entity, even though some complexity has been outsourced to a third party!

Property Scores

Level 2: Signer Delegation

At this next level, the proposer outsources not just firewall-like filtering but also commitment signing to a third-party operator. In this arrangement:

1. The operator issues and signs commitments on behalf of the proposer (including pricing logic). The operator is the committer.
2. The proposer must then build a fallback block matching these commitments, and propose that in case none of the PBS blocks are valid. The proposer is the enforcer.

However, due to the separation between committer and enforcer, we enter the realm of subjectivity: if a block is proposed that deviates from the commitments, who is at fault?

• The proposer (for including the wrong block)?
• The operator (for not forwarding the commitment in time)?
• An external network fault?
• Any malicious intent across the spectrum of malicious intent?

When operator and proposer logic are split, it becomes harder to attribute which party caused a fault. This can lead to a “split-brain” scenario, reminiscent of distributed systems where separate nodes disagree on a shared state due to partial communication failures or other (Byzantine) faults.

From our perspective, this arrangement is less desirable because fully objective fault attribution is a priority, especially when slashing is at stake.

Property Scores

Level 2.5: Signer Delegation with Common Broadcast Medium

Introducing a Common Broadcast Medium (CBM) addresses some subjectivity by ensuring a shared log of commitments:

• Common knowledge: If a commitment is available to one party, it’s available to all (within a bounded time).
• Timed records: Commitments are timestamped, removing confusion about “who saw what and when.”

When an operator publishes commitments on this CBM, both users and the proposer read from the same channel. The proposer cannot claim they never received the commitments, and the operator cannot hide them from the proposer. This dramatically reduces the ambiguity of “who is at fault” if the final block deviates from published commitments.

This CBM could be any DA layer with short enough block times.

Property Scores

Conclusion for Levels 2–2.5

A CBM improves the reliability of delegated signer scenarios but requires implementing broadcast infrastructure. For systems like Bolt—where objective fault attribution is paramount—Level 2 without a CBM is risky. Level 2.5 is more robust but requires more engineering complexity.

Level 3: Market-Based Delegation

All prior delegation mechanisms tend to be reputation-based: operators are selected based on trust and performance track records. This can lead to a small operator set, harming both the barrier to entry and censorship-resistance scores.

In market-based delegation, these operator rights (e.g., the right to issue inclusion preconfirmations) can be sold or rented in a more fluid marketplace. By relying on a Common Broadcast Medium and minimal trust assumptions, operators no longer need reputation—capital in the market can fulfill that role.

• For inclusion preconfirmations, proposers can “sell” partial block rights (e.g., a subset of the block’s gas). Multiple operators could purchase these rights.
• Operators then guarantee inclusion to users by issuing commitments from the gas allotments they’ve bought.
• Proposers are still responsible for enforcing the commitments made, by holding up their end of the bargain and including whatever the operator comes up with. A CBM is leveraged for fair exchange.

Note that this would be by far the hardest to implement, and may not be worth it if execution auctions / execution tickets end up being implemented in protocol.

Property Scores

Practical Considerations and a Phased Approach

Bolt remains committed to enabling a trustless protocol where proposers can issue commitments securely and efficiently. In preparing for our initial go-to-market, we carefully evaluated a spectrum of delegation options and identified two key factors driving our decision:

1. Short-Term Practicality vs. Long-Term Trustlessness
2. Managing Fault Attribution and Slashing

After weighing the tradeoffs, we’ve decided to launch with Level 1: Firewall + Pricing. In this model, RPCs handle filtering and pricing of incoming transactions, while the proposer retains responsibility for signing commitments (preconfirmations). Retaining signing at the proposer level directly addresses the attributability concerns we discussed—making it clear who is liable for faults, and thereby increasing the credibility of Bolt commitments. Firewall delegation will be the default in the next Bolt release.

Moreover, internal testing and early market feedback confirm that the user experience impact (slightly higher round-trip times and marginal extra proposer-side computation) is not significant enough to warrant migrating to more complex delegation right now. We believe that this Level 1 solution offers the best balance of reliability, ease of implementation, and a clear path to iterate toward deeper trustlessness in future upgrades.

Towards Full Trustless Delegation

Looking further ahead, we believe there are 3 core solutions that—rather than being mutually exclusive—could ultimately work together to advance a trustless delegation ecosystem. These solutions would become especially important in other types of commitments like execution preconfirmations, where proposers cannot be burdened with their complexity.

1. Trusted Execution Environments (TEEs):

By using TEEs, delegators can reduce the need to fully trust the external operator. Enclaves and secure hardware can handle critical execution steps, thereby minimizing the attribution risks typically associated with third-party delegation. Some types of faults would theoretically be eliminated by the integrity guarantees of TEEs.

2. Common Broadcast Medium:

A shared broadcast channel ensures that operators are fully liable for any commitments they publish. This approach strengthens protocol-wide accountability and helps avoid the “split-brain” scenarios that arise when commitments fail to reach all participants in a timely, verifiable manner.

3. Sub-slot Auctions

A spin on the current version of PBS cooked up by Nethermind, where multiple auctions are held within the duration of a slot. This has the nice benefit of omitting the need for ahead-of-time delegation, assuming these partial slots can be short enough. Just like in regular PBS, the sophistication of building these (partial) blocks is outsourced to a builder.

Together, these technologies pave the way for robust, trust-minimized delegation, enabling Bolt to maintain strong fault attribution while offering a seamless user experience in an increasingly decentralized environment.

Footnotes

1. Unless these inclusion preconfirmations end up being misused for shared state transactions, or users invalidate their own transactions through nonce overrides (user equivocation).