Note: In this post, we assume familiarity with some Solana-specific terms. If you're unfamiliar, check out, Solana Fees, Part 1: Solana's Fee Mechanism for a helpful glossary.

Introduction: why aren't my transactions included?​

A Solana transaction's journey from user submission to block inclusion can be arduous. Even once the transaction reaches the current leader, it must compete with other transactions for limited blockspace. Including transactions in a purely first-come-first-served fashion encourages spam and may block high-value transactions from ordinary users. To solve this problem we need a fee mechanism.

Priority fees to the rescue?​

Priority fees solve this problem, right? Unfortunately, not for most users.

Introduction​

Fee mechanisms are an important feature of blockchains. Network maintainers like validators have finite resources, so it’s important to charge for scarce resources in a way that reflects cost to the network. Fees also create incentives for participants of the network, such as users, application developers, and validators.

In this series, we will explore Solana’s current fee mechanism, formalize the design space for a fee mechanism, and analyze some proposed changes to Solana’s fee mechanism.

This piece is the first in the series. Here we explain how Solana’s fees work today, focusing on transaction-based fees.

Introduction​

This piece is the second in our series on the Ethereum supply chain. In Part 1, we covered the evolution of the supply chain to date and the justifications for proposer-builder separation (PBS). We also explored some issues that the current reliance on out-of-protocol relays has led to, and how various design decisions have led to centralizing tendencies up and down the stack.

In this part, we explore Enshrined Proposer-Builder Separation (ePBS), a high-level proposal to protocolize PBS and avoid the negative effects of out-of-protocol relays. First, we recap the reasons to enshrine PBS. Then, we define the design goals for ePBS, analyze the proposals themselves, and examine dependencies that may affect potential implementations of ePBS.

Introduction​

Ethereum aspires to be a credibly neutral infrastructure layer enabling censorship-resistant applications. Successful execution of this mission hinges on maintaining decentralization and neutrality of the protocol. The mechanisms that manufacture blockspace are critical to Ethereum delivering on its promise.

Under proof of work, Ethereum miners had unilateral leverage in including and ordering transactions. Since then, a labyrinthine supply network has emerged with responsibilities distributed across validators, builders, searchers, relayers, and other opaque off-chain actors. This reflects a natural maturation and evolution of the ecosystem, but the complexity introduces new risks. Centralization and chokepoints at any of these layers can enable censorship and discredit the core ethos and values of Ethereum. Understanding the incentives in the supply network is thus essential.

This series explores the past, present, and future of the Ethereum supply chain. In this part, we cover the evolution of the supply chain from proof of work (PoW), to proof of stake (PoS), proposer-builder separation (PBS), and MEV-Boost. We then analyze issues that threaten the network’s neutrality today. This will provide background for future parts that analyze proposals to mitigate these issues.

Introduction​

One future for Ethereum scaling is a world with thousands of rollups. Today, the dominant rollups are optimistic rollups, and most rollup-as-a-service companies are also building optimistic rollups.

There are two main issues with the design of optimistic rollups today:

• Rollups depend on centralized sequencers, which are a vector for soft censorship and centralization of MEV rents.
• There are no good solutions for atomic interoperability between optimistic rollups. Because of the 7-day challenge period in the optimistic rollup security model, an optimistic rollup cannot verify another’s state without waiting for the fraud proof window to pass. As a result, existing designs for cross-rollup bridging and interoperability (arbitrary message passing) are centralized and asynchronous in nature.

Shared, decentralized sequencer sets have been proposed as a way to decentralize the rollup sequencer role. But existing designs only perform transaction ordering, so they only solve the first problem and don’t solve atomic cross-rollup interoperability.

In this piece, we propose a shared sequencer architecture that enables atomic cross-rollup interoperability. Shared Validity Sequencing unlocks a unified layer of native assets that can serve an entire rollup ecosystem.

Introduction​

In this post, we explore the most common forms of MEV on Solana, how MEV will evolve as value and sophistication increase, and its effects on the Solana network.

We also compare MEV on Solana to MEV on Ethereum, and pose some open questions about the evolution and effects of MEV.

Readers should have some background on MEV and how transactions are included on Solana.

See Lifecycle of a Solana Transaction for the relevant background, and Solana’s MEV Problem for high-level discussion of MEV on Solana.

Introduction​

In this piece, we focus on the lifecycle of a Solana transaction. We examine how the Solana runtime processes transactions, with an emphasis on transaction execution and ordering. We also explore the differences in transaction execution between Solana and Ethereum.

The topics discussed assume some familiarity with blockchain mechanisms. The goal of this piece is to set the stage for discussing MEV on Solana.