Skip to content

pull_request_template.md: specify merges are OK#164

Merged
spalladino merged 1 commit into
masterfrom
adam/pr-wording-proposal
Apr 4, 2023
Merged

pull_request_template.md: specify merges are OK#164
spalladino merged 1 commit into
masterfrom
adam/pr-wording-proposal

Conversation

@ludamad

@ludamad ludamad commented Apr 4, 2023

Copy link
Copy Markdown
Collaborator

Description

More realistic PR message. Rebases can waste time for squashed PRs

Checklist:

  • I have reviewed my diff in github, line by line.
  • Every change is related to the PR description.
  • I have linked this pull request to the issue(s) that it resolves.
  • There are no unexpected formatting changes, superfluous debug logs, or commented-out code.
  • The branch has been rebased against the head of its merge target.
  • I'm happy for the PR to be merged at the reviewer's next convenience.

@spalladino spalladino merged commit 7372e9d into master Apr 4, 2023
@spalladino spalladino deleted the adam/pr-wording-proposal branch April 4, 2023 12:25
ludamad pushed a commit that referenced this pull request Apr 14, 2023
* initial version of merge rollup

* move previous rollup data from base to merge and update root

* fix ci

* add rollup subtree height

* add tests

* test: change expectd failure regex (#164)

* just use one type of public inputs for base/merge (#168)

* this better work and ignore wasm tests

---------

Co-authored-by: Lasse Herskind <16536249+LHerskind@users.noreply.github.com>
ludamad pushed a commit that referenced this pull request Apr 17, 2023
* initial version of merge rollup

* move previous rollup data from base to merge and update root

* fix ci

* add rollup subtree height

* add tests

* test: change expectd failure regex (#164)

* just use one type of public inputs for base/merge (#168)

* this better work and ignore wasm tests

---------

Co-authored-by: Lasse Herskind <16536249+LHerskind@users.noreply.github.com>
ludamad pushed a commit that referenced this pull request Apr 17, 2023
* initial version of merge rollup

* move previous rollup data from base to merge and update root

* fix ci

* add rollup subtree height

* add tests

* test: change expectd failure regex (#164)

* just use one type of public inputs for base/merge (#168)

* this better work and ignore wasm tests

---------

Co-authored-by: Lasse Herskind <16536249+LHerskind@users.noreply.github.com>
spalladino pushed a commit that referenced this pull request Jun 9, 2026
Fixes A-819 (Audit #164).

## Problem

`RollupContract.getAttesters`
(`yarn-project/ethereum/src/contracts/rollup.ts`) made several
sequential RPC reads with no pinned block:

- `getActiveAttesterCount()` (read at `latest`)
- N chunked `getAttestersFromIndicesAtTime(...)` reads, one per 1000
indices (each read at `latest`)

The `ts` timestamp argument was already captured once and reused
consistently across chunks, so the literal "stale timestamp across
chunks" framing of the title doesn't occur. The real defect is that the
**reads are not pinned to a single L1 block**: across a block boundary
or reorg, the count and the individual chunk reads can observe different
attester sets, yielding an inconsistent or truncated result. This only
bites for attester sets larger than the 1000-entry chunk size, read
precisely across a set-changing block — hence low impact, but real.

## Fix

Fetch the current block once in `getAttesters`, then thread its `number`
as a `blockNumber` option through `getActiveAttesterCount` and every
chunked `getAttestersFromIndicesAtTime` read so they all evaluate
against the same L1 block. This follows the existing
`checkBlockTag(options?.blockNumber, ...)` pattern already used by many
reads in `rollup.ts` (e.g. `getCheckpointNumber`, `status`,
`canPruneAtTime`).

- `getActiveAttesterCount` and
`GSEContract.getAttestersFromIndicesAtTime` now accept an optional `{
blockNumber }`.

## Testing

Verified the full TypeScript build passes. No automated test added:
reproducing the block-drift race deterministically would require anvil
plus a hook to advance an L1 block between the count read and the chunk
reads (or deep viem-client mocking), which isn't justified for this
low-impact, pattern-following change. The block-pinning behavior mirrors
other pinned reads in the same file.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants