Research Featured

RISE’s Take on the Glamsterdam Upgrade

Thanh Nguyen

18 Aug 2025 • 13 min read

Introduction

The Ethereum community is actively shaping the Glamsterdam upgrade, scheduled for 2026, through a structured process to select which Ethereum Improvement Proposals (EIPs) will define this pivotal network upgrade. As developers and researchers evaluate candidate proposals, certain EIPs have emerged as frontrunners that could fundamentally transform how Layer 2 solutions like RISE chain operate. For RISE chain, we consider the following EIPs, among those being discussed by the community, to stand out for their potential to revolutionize rollup scalability, decentralization, and performance.

EIP-7782: Reduce Block Latency. Reduce Ethereum’s slot time from 12 s to 6s, halving on‑chain latency and epoch duration from 384s to 192s without reducing block and blob spaces.
EIP-7805: Fork-Choice Enforced Inclusion Lists (FOCIL). Enhance censorship resistance through committee-based mandatory inclusion.
- Beside the current proposer, 16 more randomly-chosen validators can also publish lists of transactions they want to include in blocks.
EIP-7928: Block-level Access Lists (BALs). Explicitly records all accounts and storage keys accessed or modified during the execution of every transaction within a block.
- Ethereum’s consensus mechanism can enforce strict compliance, requiring builders to provide correct BALs. If BALs are incorrect, the corresponding blocks are considered invalid.
- Previously, Ethereum has EIP-2930 for transaction access lists, but this is optional and not enforced by the protocol.

Understanding how these EIPs will enhance different aspects of RISE’s operations is crucial for comprehending how RISE will evolve into an even more powerful platform for next-generation Web3 applications.

RISE’s Take

Based Sequencing & Censorship Resistance

RISE is implementing based sequencing as our core decentralization strategy, where Ethereum L1 proposers directly handle transaction sequencing rather than relying on centralized sequencer infrastructure. This design choice immediately benefits from the FOCIL censorship resistance (CR) enhancements.

FOCIL plays a crucial role by allowing 17 randomly-chosen entities to build a block at a time, providing a guaranteed path for transaction inclusion on the L1, thereby, greatly strengthening censorship resistance. This represents a significant evolution beyond single-proposer systems, as of today, dramatically reducing bribery and attack surfaces.

EIP-7782 accelerates proposer rotations, making it inherently more challenging for malicious actors to censor transactions over extended periods. Furthermore, with EIP-7782, the number of slots is twice as many as before EIP-7782, significantly increasing the censor cost for a given timeframe.

For RISE, the enhancement of censorship resistance is obvious because even if individual L1 proposers attempt to censor specific transactions, there are still other pathways for transaction inclusion via the committee members.

Censoring Math of Based Sequencing

Suppose that a malicious actor (who wants to censor the rollup) can control at most $0 \le p \le \frac{1}{3}$ of the total number of L1 validators (this is the security model of Ethereum for it to function properly without any issues), $0\lt q \le 1$ of the validators are based sequencers (i.e, validators who opt-in to sequence the rollup). The probability that a transaction is censored by a based rollup in $k$ consecutive slots is \[ P_{\mathsf{censor}} \approx (p + (1-p)(1-q))^k = (1+pq-q)^k\quad (*) \]

Let’s explore some concrete numbers in the extreme case where $p=\frac{1}{3}$.

	$q=0.1$	$q=0.2$	$q=0.5$	$q=1$
$k=1$	$0.93$	$0.87$	$0.67$	$0.33$
$k=2$	$0.87$	$0.75$	$0.44$	$0.11$
$k=4$	$0.76$	$0.56$	$0.2$	$0.01$
$k=8$	$0.58$	$0.32$	$0.04$	$0.0001$

With the slot times reduced by half when EIP-7782 is applied, the number of slots is now twice as many (i.e, $k \rightarrow 2k$) for a given time frame. This means that the censoring probability quadratically decreases (e.g, from $0.87$ to $0.75$, $q=0.2$ within a timeframe of 12s) with an unchanged ratio $q$.

FOCIL allows more entities (i.e, 17) to build a block (although they have different roles and rights, for simplicity, we assume equal rights here). With FOCIL, as long as there is at least one non-censoring sequencer among the 17 chosen validators, users’ transactions will eventually go through (assuming unlimited gas). The censoring probability is now transformed to the following.\[ P_{\mathsf{censor}} \approx (1+pq-q)^{17k}\quad (*) \]

And the previous table is now updated as follows.

	$q=0.1$	$q=0.2$	$q=0.5$	$q=1$
$k=1$	$0.3095$	$0.0878$	$0.001$	$\approx 0$
$k=2$	$0.0958$	$0.0077$	$1\times10^{-6}$	$\approx 0$
$k=4$	$0.0092$	$5.9 \times 10^{-5}$	$\approx 0$	$\approx 0$
$k=8$	$8.4\times10^{-5}$	$\approx 0$	$\approx 0$	$\approx 0$

Of course there are many factors we do not consider here but the numbers give a good intuition that censorship is greatly improved when FOCIL and shorter slot times take effects.

Liveness and The Cold-start Problem

Liveness of a based rollup depends on the portion of L1 validations who opt-in to become the sequencers. If all L1 validators are based sequencers, we will have a very rigid based rollup. However, in practice, this is not always the case. A new based rollup faces the cold-start problem in the early stage because of low adoption from the L1 validators. That is, if the portion of based sequencers is small, it will experience a stall between two consecutive blocks, which is not wanted.

The good part is, not only does FOCIL improve censorship resistance to Ethereum and its rollups, but it also considerably reduces the chance of liveness failure.

Liveness Math of Based Sequencing

Similarly, let’s work on some math formulas to see how FOCIL greatly improves a based rollup’s liveness. Suppose $q, 0 \le q \le 1,$ of L1 validators are based sequencers. The probability that a based rollup does not produce any block in $k$ consecutive L1 slots is

\[P_{q,k} \approx (1-q)^k \quad (*) \]

Here are some concrete numbers.

	$q=0.1$	$q=0.2$	$q=0.5$
$k=1$	$0.9$	$0.8$	$0.5$
$k=2$	$0.81$	$0.64$	$0.25$
$k=4$	$0.6561$	$0.41$	$0.0625$
$k=8$	$0.43$	$0.168$	$0.004$

With FOCIL, as long as there is at least one sequencer among the 17 chosen validators, the based rollup will progress. The liveness failure probability is now transformed to the following.

\[P_{q,k} \approx (1-q)^{17k} \quad (*) \]

And the previous table is now updated as follows.

	$q=0.1$	$q=0.2$	$q=0.5$
$k=1$ (12s)	$0.1668$	$0.0225$	$7.6\times 10^{-6}$
$k=2$	$0.0278$	$0.0005$	$\approx 0$
$k=4$	$0.0008$	$2.6\times10^{-7}$	$\approx 0$
$k=8$	$6\times10^{-7}$	$\approx 0$	$\approx 0$

But it does not end it. Look at the cold-start problem again: pre-FOCIL, it requires at least 15% of validators who are based sequencers to guarantee >99% that there is at least one based sequencer per Ethereum epoch ($k=32$); after-FOCIL, this requirement is reduced to only 1%. Impressive, isn’t it?

Settlement, Latency and Finality.

With EIP-7782, what usually takes time $t$ for finality/settlement on the L1, will only take $t/2$. This means RISE can settle to Ethereum twice as fast, directly improving user experiences, e.g., L1 → L2 deposits now take less time to be credited; states on RISE are committed to the L1 twice as fast.

Furthermore, until we implement validity proofs, withdrawals on RISE must still need to pass the 7-day challenge window to be released on the L1. The challenge window is needed to make sure any misbehaviors of the sequencers can be detected and attested. One rule of thumb when setting the duration of the challenge window is “the challenge window must be greater than the amount of time that the attacker can censor all available challengers”. As we analyzed above, with better censorship resistance, optimistic rollups, especially RISE, can reduce the challenge window to as low as the time needed for the network to perceive frauds (e.g, <1 day).

(Parallel) Execution

Block-level Access Lists (BALs) in EIP-7928 aim to enhance the performance of execution nodes. BALs allow validators and nodes to know exactly which data slots will be accessed during execution, enabling parallel execution of block’s payloads and efficient data (pre)fetching from the database. For syncing nodes that do not require re-execution (e.g, indexer, explorer), applying just the provided state-diffs is more efficient and reduces synchronization become faster.

Although RISE does not directly benefit from this EIP, it showcases how we positions ourselves ahead of the curve, and there are still a lot of works along the way. RISE already implements a variant of BALs via $\mathtt{Shreds}$ (sub-blocks). The sequencer incrementally builds canonical L2 blocks via $\mathtt{Shreds}$ and broadcasts them out immediately for early updates. Each $\mathtt{Shred}$ is incorporated with a state-diffs (SDs). However, SDs are currently streamed with $\mathtt{Shreds}$ but not protocol-enforced. That is, SDs are discarded after canonical L2 block construction, and synchronization does not leverage SDs and requires re-execution instead.

The inclusion of this EIP in the Glamsterdam upgrade gives a strong signal that we should accelerate our $\mathtt{Shred}$ design. Here is our short-term plan:

$\mathtt{Shred}$ will eventually become slashable, providing cryptoeconomic guarantees comparable to the Ethereum’s consensus-enforced BALs.
SDs from individual $\mathtt{Shred}$ will be combined into canonical L2 BALs. This aggregation resembles the behaviors of Ethereum’s BALs.
Synchronization can also be done via applying provided SDs or BALs.

Last but not least, BALs enable building dependency DAGs, specifying which transactions can be executed in parallel, which transactions must be executed sequentially. With guaranteed-correct BALs, the (parallel) execution engine can construct complete dependency DAGs before any execution begins. This enables optimal thread allocation and lessens the overhead of speculative execution retries. Dependency DAGs are the last missing piece of our pevm, which can amplify the execution performance.

Conclusion

While Glamsterdam’s finalists are under consideration, RISE strongly believes that EIP-7782, FOCIL (EIP-7805), and BALs (EIP-7928) are leading candidates, poised to address core L2 scalability challenges.

FOCIL, combined with EIP-7782's halved slot times, quadratically reduces the attack surface for censorship, making transaction exclusion not just difficult but economically irrational. Furthermore, this combination solves the cold-start problem that has plagued based rollups, where previously 15% validator participation was required for reliable liveness, now can be reduced to as low as 1%.

The path forward is clear. As the Ethereum community finalizes the Glamsterdam upgrade selection, RISE will accelerate development of complementary features: slashable $\mathtt{Shreds}$, SD aggregation, dependency DAGs, etc,. The combined effect of reduced latency, enhanced censorship resistance, and optimized execution creates a network capable of supporting unprecedented applications we can imagine today.

(*) In practice, the probabilities are not exactly the same as shown in the equations but they give good approximations and intuitions about the meaning of the mentioned probabilities.