Skip to content

docs(tip-1043): add Tempo block access lists draft #3438

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
mediocregopher wants to merge 1 commit into
base: main
Choose a base branch
from
+162 −0
Draft

docs(tip-1043): add Tempo block access lists draft #3438

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
162 changes: 162 additions & 0 deletions tips/tip-1043.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,162 @@
---
id: TIP-1043
title: Tempo Block Access Lists
description: Tempo-specific decomposition of block access lists into implicit and residual components.
authors: Brian (@mediocregopher)
status: Draft
related: EIP-7928
---

# TIP-1043: Tempo Block Access Lists

## Abstract

This TIP defines Tempo BALs as a deterministic decomposition of an upstream [EIP-7928](https://eips.ethereum.org/EIPS/eip-7928) Block-Level Access List into an **Implicit Access List** (`IAL`) and a **Residual Access List** (`RAL`). Tempo blocks carry the `RAL`, not the full `BAL`. During validation, the validator reconstructs the effective `BAL` from its locally-derived `IAL` plus the block's `RAL`.

This draft also brings into scope the portions of TIP-20 transfer paths whose accesses are already statically inferable from transaction bytes.

## Motivation

Ethereum BALs assume the full access list must be shipped because arbitrary contracts do not generally have statically predictable state access patterns. Tempo is different: a large share of accesses come from protocol paths with deterministic storage layouts whose touched slots can be derived from the transaction envelope and calldata before execution.

If Tempo can treat those accesses as implicit without weakening correctness, it can reduce BAL bandwidth overhead while preserving the main BAL benefits: deterministic validation, parallel I/O preparation, parallel execution, and executionless state updates.

## Assumptions

- This TIP depends on EIP-7928 reaching a stable final form. Tempo BALs inherit the upstream BAL structure, ordering, and validation rules; this TIP only specifies the `IAL`/`RAL` split on top of that base.
- Any access placed in the `IAL` must be derivable as a pure function of the block's transactions using a canonical protocol rule. No implementation-local heuristics are allowed.
- Compatible `IAL` upgrades may move entries from `RAL` into `IAL`, but they MUST NOT move previously-implicit entries back into `RAL` or change what those previously-implicit entries mean. This lets newer validators accept blocks built with an older `IAL` rule set.

---

# Specification

Tempo inherits the upstream `BAL` format from EIP-7928. This TIP defines a canonical decomposition of that `BAL` into two components:

- `IAL`: the subset of BAL entries that Tempo defines as statically derivable from the block's transactions.
- `RAL`: the subset of BAL entries not derivable by those rules.

`IAL` and `RAL` are both **partial BALs**. Logically, each uses the same nested account/change structure as `BAL`; they differ only in which entries they contain. Empty account entries MAY be omitted from a partial BAL.

## Canonical Decomposition

Tempo blocks MUST carry the `RAL`, not the full `BAL`.

For the builder, the following relationships MUST hold:

```text
BAL = IAL_builder union RAL
RAL = BAL - IAL_builder
```

The builder MUST:

1. Compute `IAL_builder` from the block's transactions using the canonical protocol algorithm.
2. Construct `RAL` as `subtract_bal(BAL, IAL_builder)`.

The validator MUST:

1. Recompute `IAL_validator` from the same block transactions using the validator's canonical protocol algorithm.
2. Use an `IAL_validator` rule set that is compatible with the builder's `IAL_builder`: it may infer additional entries beyond the builder, but it MUST preserve every builder-implicit entry with the same meaning.
3. Reconstruct `BAL` by computing `union_bal(IAL_validator, RAL)`.
4. Reject the block if the reconstructed `BAL` differs from the BAL implied by execution.

`IAL` and `RAL` MAY overlap during validation. This is valid only if the overlap is non-conflicting: overlapping entries must imply the same BAL entry. The validator MUST normalize such overlap by deduplicating identical entries and MUST reject conflicting overlap.

Equivalently, validator-side reconstruction is:

```text
BAL = union_bal(IAL_validator, RAL)
where IAL_validator is compatible with IAL_builder
```

## Partial BAL Operations

### `union_bal(X, Y)`

`union_bal` takes two partial BALs `X` and `Y` and produces a BAL-structured result by deterministic fieldwise merge:

1. Group entries by address.
2. For each address, merge each BAL field independently.
3. For `storage_changes`, group first by storage key, then merge the per-slot `StorageChange` lists.
4. For each merged field, deduplicate identical entries.
5. If overlapping entries disagree, reject as conflicting.
6. Sort the final result using the same ordering rules as upstream BALs.

Two overlapping entries are **identical** iff they encode the same BAL entry. For example, two `storage_reads` overlap identically when they contain the same storage key for the same address; two `StorageChange` entries overlap identically when they refer to the same address, storage key, block access index, and post-value.

### `subtract_bal(BAL, IAL)`

`subtract_bal` takes a full `BAL` and a partial `IAL` and produces a partial `RAL` by deterministic fieldwise subtraction:

1. Group both inputs by address.
2. For each BAL address entry, subtract any identical entries present in `IAL` from the corresponding BAL fields.
3. For `storage_changes`, subtraction is performed per storage key and then per `StorageChange` entry.
4. Entries not present in `IAL` remain in `RAL` unchanged.
5. Empty fields, empty slots, and empty account entries are omitted from `RAL`.
6. Sort the final result using the same ordering rules as upstream BALs.

`subtract_bal` MUST reject malformed `IAL` input that contains an entry inconsistent with the BAL domain for the same field.

## Initial IAL Scope

This TIP includes in scope the portions of TIP-20 `transfer` and `transferWithMemo` paths that are already statically inferable from transaction bytes under finalized Tempo rules. Any TIP-20 access that is not yet covered by such a rule remains in `RAL`.

### TIP-20 `transfer` and `transferWithMemo`

The relevant TIP-20 method signatures are:

```solidity
function transfer(address to, uint256 amount) external returns (bool);
function transferWithMemo(address to, uint256 amount, bytes32 memo) external;
```

Per the TIP-20 specification and reference implementation, `transferWithMemo` behaves like `transfer` with an additional memo event. The `memo` field does not change which storage locations are selected by the transfer path.

For a transaction at position `i` in `ExecutionPayloadV4.transactions`, define `block_access_index = i + 1` as in EIP-7928. The current TIP-20 transfer-family `IAL` extraction algorithm is:

1. Decode the transaction envelope from `ExecutionPayloadV4.transactions[i]` far enough to recover:
- the transaction destination `to`, and
- the transaction calldata `input`.
2. Apply Tempo's TIP-20 destination classifier to `to`. If `to` does not satisfy that TIP-20 prefix rule, return the empty partial BAL.
3. Read the 4-byte selector from `input[0:4]`.
4. If the selector is neither `ITIP20.transfer.selector` nor `ITIP20.transferWithMemo.selector`, return the empty partial BAL.
5. Enforce exact ABI length:
- `transfer`: `len(input) == 4 + 32 + 32`
- `transferWithMemo`: `len(input) == 4 + 32 + 32 + 32`
6. Decode `recipient_raw` from ABI word 0:
- bytes `[4:36]` of `input`
- interpreted as the standard ABI-encoded `address to` argument.
7. Ignore later calldata words for `IAL` selection. In the current scope, `amount` and `memo` do not affect which partial-BAL entries are emitted.
8. Emit a partial BAL consisting of the following `AccountChanges` entries:
- One `AccountChanges` entry for the TIP-20 token account at address `to`.
- `storage_reads` for the token account MUST include:
- `transferPolicyId` (slot 0)
- `paused` (slot 4)
9. If `recipient_raw` matches the TIP-1022 virtual-address format, emit an additional `AccountChanges` entry for the TIP-1022 registry precompile account.
- Let `masterId = recipient_raw[0:4]`.
- Let `registry_slot = 0`, corresponding to the `mapping(bytes4 => address) _masters` storage slot in the reference `AddressRegistry` implementation.
- The registry `storage_reads` MUST include the TIP-1022 registry lookup slot:

```text
master_lookup_slot = keccak256(abi.encode(masterId, registry_slot))
```

In EIP-7928 notation, the current transfer-family `IAL` contribution is therefore a list of read-only `AccountChanges` fragments.

This draft intentionally does **not** yet include TIP-20 transfer-path writes in `IAL`. In particular, sender balance updates, recipient balance updates, reward-accounting writes, and policy-registry expansions remain in `RAL` because their final `storage_changes` entries are not yet derivable from transaction bytes alone under a finalized canonical rule set.

## Scope Boundary

This TIP does not yet enumerate every Tempo protocol path that may become implicit. Any access pattern which does not already have a finalized, canonical derivation rule MUST remain explicit in `RAL`.

This TIP does not specify FeeAMM batching, deferred settlement, or any other optimization that changes which accesses become residual versus implicit. Those can be proposed separately once this base partition is settled.

# Invariants

1. **Builder Residual Rule**: Relative to the builder's `IAL`, `RAL` MUST be exactly `BAL - IAL_builder`.
2. **Compatibility Rule**: A newer validator may infer additional entries into `IAL`, but it MUST NOT stop inferring or reinterpret entries that an older compatible builder would have treated as implicit.
3. **Derived BAL**: The validator MUST derive the effective `BAL` from `IAL + RAL`, not from a separately transmitted full BAL.
4. **Conflict-Free Overlap**: `IAL` and `RAL` MAY overlap only when the overlap is non-conflicting and `union_bal` resolves that overlap to the same BAL entry.
5. **Fail Closed**: Any access that is not covered by the builder's finalized canonical `IAL` rule set MUST remain in `RAL`.
6. **Upstream Consistency**: Tempo MUST NOT activate this TIP against a moving or incompatible upstream BAL format; the final Tempo encoding and validation rules must track the finalized EIP-7928 base.
Loading