• Intros

• Deep dives

• Phase 1 closing

• Phase 2 opening

Holon is a software service that runs on a host machine alongside an Ethereum full node. Its purpose is to provide users with a software suite to record and assess rollup related transaction activity with L1

• Extensibility? What are things to monitor that would be worth looking at, beyond security and proofs? How about fee markets, batch posters?
Paying for gas on L1 to be used on L2, consolidating this pattern in an abstract approach applicable to all rollups is challenging
With DA, abstract approach to build stuff that can be extended for each rollup
Mostly optimistic rollups atm but like l2beat could have more columns for eg, different risks, you could have more details based on abstract classes

• Metrics for DA: variable cost measured by payload sizes in transactions

• Blobs are 131kb,

• Block-packing with txs from more than one rollups, because you pay a flat fee for the whole blob
But tradeoffs with timing and legibility (”I only want data from my rollup, so I have an easy filter if I just look at blobs from one address”)
Could even have coordination to e.g., not post in the same block (e.g., optimism posts every 3 blocks, arbitrum every 7 blocks, every 21 blocks there is a clash)
But looking at DA as just a service receiving an input stream, why does it need to be aware of some kind of coordination?
More like a natural load-balancing

• Also questions on cost-sharing, in e.g., 4337
But implementing cost-sharing introduces smart contracts, which use gas and introduce overhead themselves

• But are rollups the abstraction we need to look at when we think about these costs? Users come first in that pipeline, and from a shared sequencer perspective there may be different optimisations.

• Also not a lot of thought on economic models for history preservation, possibly complementary with data availability
Ethstorage, following a ~Filecoin model

• Davide’s analysis on EIP-4844
EIP-4844 Fee Market Analysis
Thanks to Barnabé Monnot, Danny Ryan, and participants to the RIG Open Problem 3 (Rollup Economics) for helpful discussions and feedback. EIP-4844 introduces two main components to the Ethereum protocol: (1) a new transaction format for “blob-carrying transactions” and (2) a new data gas fee market used to price this type of transactions. This analysis focuses mainly on the data gas fee market and its key parameters. We first discuss the relation between the 4844 and 1559 fee mechanisms and th...

https://ethresear.ch/t/eip-4844-fee-market-analysis/15078

• Review parameters of the L2
In particular, speed of the update rule of EIP-4844 base fee can be tuned appropriately based on the nature of the L2 data market
Sequencer comes in at a regular frequency. But if the sequencer is decentralised, there may be re-orgs which then mess up the rollup’s accounting, and can lead to more dramatic differences if the update rule is very responsive
Another reason to have a not-too-aggressive update rule: for users who get in now the cost is incurred later, so variability is also perhaps undesirable

• Also important to think about these parameters as EIP-4844 is the first instantiation of multi-dimensional EIP-1559, so could inform development moving forward

• Thanks to Kofi, Ameya, Dan, Mark, and all others that made phase 1 exciting!!

• L1-L2 Fee Markets

• L2 Data & Data Tools

• Transaction ordering policies for rollups
Transaction ordering policy
The Arbitrum sequencer receives transactions from users and publishes an ordered sequence, which serves as input to the execution stage of Arbitrum. Currently the sequencer follows a first-come, first-served (FCFS) sequencing policy. There’s a lot to like about FCFS. It’s simple and easy to explain. It is seems intuitively fair. It minimizes latency because the policy allows each transaction to be appended to the sequence immediately on arrival. Other rollup protocols use FCFS as well. Optimis...

https://research.arbitrum.io/t/transaction-ordering-policy/127

Encrypted mempools are also a question here, for the user strategy (Arbitrum plans to use HoneyBadger for threshold encryption)
Time boost: a new transaction ordering policy proposal
[cross-posted from Medium] tl; dr: We’re proposing a modified transaction ordering policy for the Arbitrum sequencer, adding a “time boost” to the current first-come, first-served policy, where a transaction could pay a priority fee to get a small advantage or “time boost” in the ordering. This shouldn’t affect most users, but can provide a better way to manage “latency racing” behavior. The Arbitrum sequencer receives transactions from users and publishes an ordered sequence, which serves as ...

https://research.arbitrum.io/t/time-boost-a-new-transaction-ordering-policy-proposal/8173

But how does it work with a decentralized sequencer?

• Decentralized sequencer alignment