From 5cc94668cf296ee715c47ddf825df1531a760f92 Mon Sep 17 00:00:00 2001 From: Philippe Camacho Date: Tue, 7 Apr 2026 16:50:16 -0400 Subject: [PATCH 1/3] Move Espresso related docs to directory espresso/docs. --- README_ESPRESSO.md | 10 +++++----- {docs => espresso/docs}/CELO_TESTNET_MIGRATION.md | 0 .../docs}/README_ESPRESSO_CODE_SYNC_PROCEDURE.md | 0 .../docs}/README_ESPRESSO_DEPLOY_CONFIG.md | 0 .../docs}/espresso-deploy-config-pipeline.drawio | 0 .../espresso-deploy-config-pipeline.drawio.png | Bin {docs => espresso/docs}/op-succinct-repos.png | Bin {docs => espresso/docs}/op-succinct-repos.puml | 0 8 files changed, 5 insertions(+), 5 deletions(-) rename {docs => espresso/docs}/CELO_TESTNET_MIGRATION.md (100%) rename {docs => espresso/docs}/README_ESPRESSO_CODE_SYNC_PROCEDURE.md (100%) rename {docs => espresso/docs}/README_ESPRESSO_DEPLOY_CONFIG.md (100%) rename {docs => espresso/docs}/espresso-deploy-config-pipeline.drawio (100%) rename {docs => espresso/docs}/espresso-deploy-config-pipeline.drawio.png (100%) rename {docs => espresso/docs}/op-succinct-repos.png (100%) rename {docs => espresso/docs}/op-succinct-repos.puml (100%) diff --git a/README_ESPRESSO.md b/README_ESPRESSO.md index 684e40a7094..dbc9a24d7f8 100644 --- a/README_ESPRESSO.md +++ b/README_ESPRESSO.md @@ -2,8 +2,8 @@ Notes: -* For deployment configuration, read `README_ESPRESSO_DEPLOY_CONFIG.md`. -* For code sync with upstreams, read `README_ESPRESSO_CODE_SYNC_PROCEDURE.md`. +* For deployment configuration, read `espresso/docs/README_ESPRESSO_DEPLOY_CONFIG.md`. +* For code sync with upstreams, read `espresso/docs/README_ESPRESSO_CODE_SYNC_PROCEDURE.md`. ## Development environment @@ -519,7 +519,7 @@ Note importantly that OP Succinct (both in the case of Celo and Espresso) import The OP Succinct repository for Espresso generates using Github actions the docker images for the challenger and proposer services. -![image](docs/op-succinct-repos.png) +![image](espresso/docs/op-succinct-repos.png) The table below is more specific regarding which branches of these repositories are used. @@ -553,8 +553,8 @@ We are working on a set of scripts to handle the migration from a Celo Testnet t Some relevant documents: -* [Documentation of configuration parameters](docs/README_ESPRESSO_DEPLOY_CONFIG.md) -* [Celo Testnet Migration Guide](docs/CELO_TESTNET_MIGRATION.md) (WIP) +* [Documentation of configuration parameters](espresso/docs/README_ESPRESSO_DEPLOY_CONFIG.md) +* [Celo Testnet Migration Guide](espresso/docs/CELO_TESTNET_MIGRATION.md) (WIP) ## Generating alloc.json file diff --git a/docs/CELO_TESTNET_MIGRATION.md b/espresso/docs/CELO_TESTNET_MIGRATION.md similarity index 100% rename from docs/CELO_TESTNET_MIGRATION.md rename to espresso/docs/CELO_TESTNET_MIGRATION.md diff --git a/docs/README_ESPRESSO_CODE_SYNC_PROCEDURE.md b/espresso/docs/README_ESPRESSO_CODE_SYNC_PROCEDURE.md similarity index 100% rename from docs/README_ESPRESSO_CODE_SYNC_PROCEDURE.md rename to espresso/docs/README_ESPRESSO_CODE_SYNC_PROCEDURE.md diff --git a/docs/README_ESPRESSO_DEPLOY_CONFIG.md b/espresso/docs/README_ESPRESSO_DEPLOY_CONFIG.md similarity index 100% rename from docs/README_ESPRESSO_DEPLOY_CONFIG.md rename to espresso/docs/README_ESPRESSO_DEPLOY_CONFIG.md diff --git a/docs/espresso-deploy-config-pipeline.drawio b/espresso/docs/espresso-deploy-config-pipeline.drawio similarity index 100% rename from docs/espresso-deploy-config-pipeline.drawio rename to espresso/docs/espresso-deploy-config-pipeline.drawio diff --git a/docs/espresso-deploy-config-pipeline.drawio.png b/espresso/docs/espresso-deploy-config-pipeline.drawio.png similarity index 100% rename from docs/espresso-deploy-config-pipeline.drawio.png rename to espresso/docs/espresso-deploy-config-pipeline.drawio.png diff --git a/docs/op-succinct-repos.png b/espresso/docs/op-succinct-repos.png similarity index 100% rename from docs/op-succinct-repos.png rename to espresso/docs/op-succinct-repos.png diff --git a/docs/op-succinct-repos.puml b/espresso/docs/op-succinct-repos.puml similarity index 100% rename from docs/op-succinct-repos.puml rename to espresso/docs/op-succinct-repos.puml From 215b9891f585a0c7477ca58e1842a425592e4639 Mon Sep 17 00:00:00 2001 From: Philippe Camacho Date: Tue, 7 Apr 2026 16:52:09 -0400 Subject: [PATCH 2/3] Remove obsolete documents. --- espresso/SECURITY_ANALYSIS.md | 951 ------------------------ espresso/docs/CELO_TESTNET_MIGRATION.md | 162 ---- 2 files changed, 1113 deletions(-) delete mode 100644 espresso/SECURITY_ANALYSIS.md delete mode 100644 espresso/docs/CELO_TESTNET_MIGRATION.md diff --git a/espresso/SECURITY_ANALYSIS.md b/espresso/SECURITY_ANALYSIS.md deleted file mode 100644 index 57dffdfcbfe..00000000000 --- a/espresso/SECURITY_ANALYSIS.md +++ /dev/null @@ -1,951 +0,0 @@ -# Security Analysis: Celo-Espresso Integration - ---- - -**Document Date:** February 2, 2026 -**Version:** 1.0 - ---- - -## Executive Summary - -This document provides a security analysis of the Celo-Espresso integration, which adds fast finality capabilities to the Optimism rollup stack while maintaining full compatibility with the standard OP Stack security model. - -### Architecture - -The integration introduces three main components: - -1. **L1 Smart Contracts** (~163 lines of Solidity) - Minimal on-chain verification layer with `BatchInbox` and `BatchAuthenticator` -2. **TEE-Based Batcher** - Runs inside AWS Nitro Enclaves with ZK-proven attestation (~240× gas reduction: 63M → 260k) -3. **Espresso Streamer** - Batch verification and ordering service with signature validation - -### Security Model - -Every batch is expected to undergo validation through **three independent layers**: - -- **TEE Attestation** - Cryptographic attestations verified via zero-knowledge proofs (Automata SDK + Succinct SP1) -- **Smart Contract Verification** - On-chain validation of sender address and TEE signatures -- **Batcher Signature Verification** - Signature validation during batch unmarshaling from Espresso - -A dual-key design separates the long-lived batcher key (operator-managed) from the ephemeral TEE key (hardware-isolated), requiring both for successful batch posting. - -### Safety Guarantee - -**Critical Property**: In all failure scenarios, the system degrades gracefully to vanilla Optimism behavior—never worse. Whether Espresso becomes unavailable, the TEE enclave fails, or both, the system falls back to standard L1-only operation identical to the vanilla Celo L2 rollup. - -The integration is strictly **additive**: it adds fast finality without replacing existing OP Stack security mechanisms. - -### Test Coverage - -The codebase includes **23 test scenarios** (14 integration + 9 devnet) covering: - -- Stateless batcher recovery and restart resilience -- TEE attestation validation and signature verification -- L2 reorg handling and state consistency -- Censorship resistance via forced transactions -- Fallback mechanism activation and mode switching -- Real AWS Nitro Enclave and full Espresso node validation - -All Espresso integration tests and L1 contract tests run automatically on every PR. Devnet and enclave tests are available on-demand. - -### Trust Assumptions - -The integration relies on AWS Nitro Enclave hardware, L1 Ethereum consensus, cryptographic primitives (ECDSA, Keccak256), and ZK proof system security (Succinct SP1, Automata SDK). **These assumptions affect only fast finality**—the base security model remains unchanged from vanilla Optimism. - -### Document Scope - -The following sections detail the technical implementation, validation mechanisms, testing methodology, contract architecture, failure recovery procedures, and future security enhancements. - -## Architecture Overview - -The integration introduces three primary components: -1. **L1 Smart Contracts** (`BatchInbox` and `BatchAuthenticator`) - On-chain verification layer -2. **Espresso Batcher** - Trusted execution environment for batch processing -3. **Espresso Streamer** - Batch verification and ordering service - -Each component operates within well-defined trust boundaries with multiple layers of validation. - -## 1. Multi-Layer Validation Architecture - -### Validation Flow Overview - -The integration implements three independent validation layers. Each layer checks different properties using separate mechanisms. A batch proceeds through all three layers before acceptance into the L2 chain. - -### 1.1 The Three Security Layers (How a Batch Gets Validated) - -Let's follow a batch from creation to acceptance to see how the layers work: - -#### **Layer 1: TEE Attestation** - -The batcher runs inside AWS Nitro Enclaves, which: -- Isolates the batcher code from the host operating system -- Generates cryptographic attestations of the running code (PCR0 measurements) -- Creates private keys within the enclave that cannot be exported - -**Implementation**: The enclave generates an attestation document containing the hash of the batcher code and a public key. This attestation is converted into a zero-knowledge proof (using Automata Network's SDK and Succinct's SP1) and verified on-chain before the key is registered as authorized to sign batches. The ZK proof approach reduces verification costs from ~63M gas to ~260k gas (approximately 240× improvement). - -References: -- [`BatchAuthenticator.sol`](packages/contracts-bedrock/src/L1/BatchAuthenticator.sol) -- [ZK Attestation Verification](https://docs.espressosys.com/network/concepts/rollup-developers/integrating-an-optimistic-rollup/zk-attestation-verification) - -#### **Layer 2: Smart Contract Verification** - -When a batch is authenticated on L1, the `BatchAuthenticator` contract verifies the TEE signer: - -1. **Signature Check**: Verifies the batch hash signature against registered TEE signers -2. **Event Emission**: Emits a `BatchInfoAuthenticated` event recording the commitment and signer - -```solidity -// From BatchAuthenticator.sol -address signer = ECDSA.recover(commitment, signature); -require( - espressoTEEVerifier.espressoNitroTEEVerifier().isSignerValid(signer, ServiceType.BatchPoster), - "BatchAuthenticator: invalid signer" -); -emit BatchInfoAuthenticated(commitment, signer); -``` - -**Implementation**: Before posting batch data to the BatchInbox EOA, the batcher calls `authenticateBatchInfo()` with a signature from the TEE ephemeral key. The derivation pipeline then scans L1 receipts for `BatchInfoAuthenticated` events within a lookback window to determine which batches are authenticated. - -Reference: [`BatchAuthenticator.sol`](packages/contracts-bedrock/src/L1/BatchAuthenticator.sol) - -#### **Layer 3: Batcher Signature Verification** - -Each batch contains a signature from the batcher. When the streamer unmarshals batches from Espresso, it verifies: -- The signature cryptographically validates -- The signer matches the authorized batcher address - -**Implementation**: Batches posted to Espresso include the batcher's ECDSA signature over the batch data. The streamer calls `UnmarshalEspressoTransaction()` which recovers the public key from the signature and verifies it matches the expected batcher address before accepting the batch. - -Reference: [`espresso_batch.go:95-113`](op-node/rollup/derive/espresso_batch.go) - -### 1.2 Validation Flow: Complete Example - -The system has two parallel derivation paths that both validate batches: - -#### **Batch Creation and Submission** - -``` -1. User submits transaction to Sequencer - ↓ -2. Sequencer creates L2 block and bundles into batch - ↓ -3. Espresso Batcher (inside AWS Nitro Enclave): - - Reads batch from sequencer - - Signs batch with batcher private key - - Submits to Espresso (for fast confirmation) - - Waits for Espresso finality - - Calls BatchAuthenticator contract to register batch hash (Layer 2: TEE signature) - - Posts batch data to L1 BatchInbox -``` - -#### **Two Parallel Derivation Paths** - -After submission, batches flow through two independent paths: - -**Path A: Fast Confirmation (Caff Node)** -``` -1. Espresso Streamer (in Caff Node): - - Reads batches from Espresso network - - Verifies batcher signature during unmarshal - ↓ -2. Caff Node Derivation Pipeline: - - Derives L2 blocks from validated batches - - Produces optimistically finalized L2 state -``` - -**Path B: L1-Based Derivation (Standard OP Node)** -``` -1. OP Node reads from L1: - - Reads batch data from BatchInbox contract - - Validates batches were authenticated via BatchAuthenticator - ↓ -2. Standard OP Derivation Pipeline: - - Derives L2 blocks from L1 data - - Produces L1-finalized L2 state -``` - -**Key Points:** -- The **Espresso Batcher** submits to both Espresso and L1 -- The **Espresso Streamer** is used by the Caff Node for fast derivation from Espresso -- The **OP Node** uses standard L1-based derivation -- Both paths independently validate batches -- Layer 1 (TEE Attestation) validates the batcher's enclave -- Layer 2 (Contract Verification) validates on L1 via address check + TEE signature -- Layer 3 (Batcher Signature) validates when reading from Espresso - -### 1.3 Dual-Key Architecture - -The implementation uses two distinct private keys with separate roles: - -#### **Batcher Key** (Long-lived, managed by operator) -```solidity -address public immutable espressoBatcher; // E.g., 0x1234... -``` -- Registered in the rollup configuration -- Gives authority to post batches to L1 -- Can exist outside the TEE -- **Role**: Proves "this is the official batcher" - -#### **Ephemeral Key** (Short-lived, generated in TEE) -```go -func (bs *BatcherService) initKeyPair() error -// Generates key inside enclave -// Private key NEVER leaves the hardware -``` -- Generated inside AWS Nitro Enclave -- Used to sign batch commitments -- Cannot be extracted from the hardware -- **Role**: Proves "this came from the correct TEE code" - -#### Key Separation Properties - -The dual-key design implements the following separation: - -| Scenario | Batcher Key Compromised | Ephemeral Key Compromised | -|----------|------------------------|---------------------------| -| **Attacker capability** | Send transactions to L1 | Sign batch hashes | -| **Missing capability** | Cannot forge TEE signatures | Cannot post to L1 BatchInbox | -| **Observed result** | Batches rejected (no TEE sig) | Signatures rejected (wrong address) | - -**Design note**: Successful batch posting requires both keys. The keys are stored in different locations: -- Batcher key: Configured on the server -- Ephemeral key: Generated and stored within the Nitro Enclave hardware - -## 2. Fault Tolerance and Recovery - -The implementation includes mechanisms for handling Espresso component failures. - -### 2.1 Fallback Mechanism - -The system includes a fallback batcher that can be activated when TEE components are unavailable. The owner can switch between Espresso and fallback modes: - -**Fallback Batcher Activation** -```solidity -function switchBatcher() external onlyOwner { - activeIsEspresso = !activeIsEspresso; // Toggle between Espresso and fallback mode -} -``` - -#### When to Use Fallback - -The fallback batcher is activated when any Espresso or TEE component fails: - -- AWS Nitro Enclave failure (Espresso batcher cannot start) -- Espresso network unavailable (cannot get fast confirmations) -- TEE attestation service down (cannot register new keys) -- Succinct Network unavailable (cannot generate ZK proofs) - -#### Fallback Mode Behavior - -When operating in fallback mode: -- Batcher posts directly to L1 without TEE attestation -- No Espresso confirmation required before L1 posting -- BatchInbox accepts batches from the fallback batcher address -- Derivation continues using standard OP Stack mechanisms - -**Switching Procedure** -1. Owner calls `switchBatcher()` on the BatchAuthenticator contract -2. Fallback batcher begins posting to L1 -3. When ready to resume Espresso mode, update caffeinated height -4. Owner calls `switchBatcher()` again to re-enable Espresso mode -5. Espresso batcher resumes operation from the new heights - - -References: -- [`BatchInbox.t.sol:84-165`](packages/contracts-bedrock/test/L1/BatchInbox.t.sol) -- [Specification §36.4.2](https://eng-wiki.espressosys.com/mainch36.html#x43-22900036) - -### 2.2 Worst-Case Degradation: Equivalent to Vanilla Celo Rollup - -**Security Property**: In all failure scenarios, the system degrades gracefully to behave identically to the current vanilla Celo L2 rollup, never worse. - -#### Degradation Scenarios - -The Espresso integration adds fast finality capabilities without compromising the baseline security of the standard OP Stack. All component failures are handled by switching to the fallback batcher, which operates identically to the vanilla Celo L2 rollup: - -- **Espresso network unavailable** - Cannot retrieve batches for fast confirmation -- **TEE enclave failure** - Cannot generate attestations or run Espresso batcher -- **Succinct Network down** - Cannot generate ZK proofs for attestation verification -- **Attestation service failure** - Cannot verify new TEE attestations - -In each case, the owner activates the fallback batcher via a single `switchBatcher()` transaction, and the system continues with standard L1-only operation. - -#### Why Degradation is Always Safe - -**1. L1 Derivation Path Always Exists** - -The standard OP Stack derivation pipeline remains fully functional regardless of Espresso status: - -``` -OP Node → L1 BatchInbox → Standard Derivation Pipeline → L2 Blocks -``` - -This path operates independently of: -- Espresso network availability -- Espresso batcher status -- Fast finality features - -**2. Fallback Batcher is Pre-Configured** - -```solidity -address public immutable espressoBatcher; // Espresso-enhanced batcher -address public immutable fallbackBatcher; // Fallback (standard) batcher -``` - -The fallback batcher address is immutably configured in the contracts. The owner can activate it instantly via `switchBatcher()`. - -**3. Espresso Features are Additive, Not Replacement** - -The integration **adds** capabilities without **replacing** core functionality: - -| Capability | Standard OP Stack | With Espresso Integration | -|------------|-------------------|---------------------------| -| L2 block production | ✅ Sequencer | ✅ Same sequencer | -| Batch posting to L1 | ✅ Batcher → L1 | ✅ Same, plus optional Espresso | -| Derivation from L1 | ✅ OP Node | ✅ Slightly different derivation logic | -| Fault proofs | ✅ Dispute game | ✅ Same dispute game | -| Withdrawals | ✅ Standard bridge | ✅ Same bridge | -| **Fast finality** | ❌ Not available | ✅ **New**: Caff Node + Espresso | - -**4. Fallback Mode is equivalent to Vanilla Behavior** - -When operating in fallback mode: - -```solidity -if (!activeIsEspresso) { - // Fallback batcher posts to BatchInbox - // No TEE attestation required - // No Espresso submission required - // Identical to standard OP Stack -} -``` - -The system: -- Uses standard batcher (no TEE) -- Posts only to L1 (no Espresso) -- Derives blocks using standard OP Node (with slight change in derivation pipeline) -- Processes transactions identically -- Maintains same security guarantees - -**5. No New Trust Assumptions for Base Security** - -The standard security model remains unchanged: -- L1 Ethereum consensus (same) -- Sequencer liveness (same) -- Fault proof system (same) -- Contract immutability (same) - -New trust assumptions (Espresso, Succinct, Automata) **only** affect fast finality, not base security. - -**6. Minimal Derivation Pipeline Changes** - -The Espresso integration makes only **one architectural change** to the OP Stack derivation pipeline: moving sender verification from the pipeline to the L1 smart contract. - -**The Single Modification: `isValidBatchTx()` Function** - -In the standard OP Stack, the derivation pipeline verifies the batch sender: - -```go -// Standard OP Stack (vanilla) -func isValidBatchTx(..., l1Signer types.Signer, ..., batcherAddr common.Address) bool { - // ... other checks ... - - // Verify sender matches authorized batcher - from, err := l1Signer.Sender(tx) - if err != nil || from != batcherAddr { - return false - } -} -``` - -In the Espresso integration, this verification is removed from the pipeline: - -```go -// Espresso integration -func isValidBatchTx(..., _ types.Signer, ..., batcherAddr common.Address) bool { - // ... same checks (tx type, inbox address, receipt status) ... - - // NOTE: contrary to a standard OP batcher, we can safely skip any verification - // related to the sender of the transaction. Indeed the Batch Inbox contract - // takes care of ensuring the sender of the batch information is a legitimate batcher. - - return true -} -``` - -**Why This Change is Safe** - -The sender verification hasn't been removed—it's been **moved to a more secure location**: - -| Verification Location | Standard OP Stack | Espresso Integration | -|----------------------|-------------------|----------------------| -| **In derivation pipeline** | ✅ `l1Signer.Sender(tx) == batcherAddr` | ❌ Removed | -| **In L1 smart contract** | ❌ Not present | ✅ `BatchInbox.sol` enforces sender check | - -**L1 Contract Enforcement:** -```solidity -// BatchInbox.sol -fallback() external payable { - if (msg.sender != batchAuthenticator.espressoBatcher() && - msg.sender != batchAuthenticator.fallbackBatcher()) { - revert("Not authorized"); - } - // ... store batch data ... -} -``` - - -#### Tested Degradation Paths - -The test suite validates degradation behavior: - -| Test | What It Validates | -|------|-------------------| -| `TestBatcherSwitching` | Switching between Espresso and fallback modes maintains correctness | -| `TestBatcherRestart` | Batcher failures don't compromise chain state | -| `TestSmokeWithFallback` | System operates correctly in fallback mode | -| Fallback tests | Manual switch to vanilla mode preserves all functionality | - -#### Operational Guarantees - -**Guarantee 1: No Additional Liveness Risk** -- If Espresso fails → system continues via L1 -- If TEE fails → system continues via fallback batcher -- Worst case: vanilla Celo rollup liveness - -**Guarantee 2: No Additional Safety Risk** -- L1 contracts validate all batches (Espresso or fallback) -- Standard derivation path validates all blocks -- Fault proof system covers all state transitions -- Worst case: vanilla Celo rollup safety - -**Guarantee 3: Instant Fallback** -- Owner can switch batchers via single transaction -- No migration or state transition required -- Chain continues from current block -- Worst case: vanilla Celo rollup behavior - - -References: -- [`BatchInbox.sol`](packages/contracts-bedrock/src/L1/BatchInbox.sol) - Dual batcher support -- [`BatchAuthenticator.sol`](packages/contracts-bedrock/src/L1/BatchAuthenticator.sol) - Mode switching - -## 3. Testing Strategy - -### 3.1 End-to-End Integration Tests - -The integration includes extensive scenario-based testing across two test suites: - -#### Environment Integration Tests (14 test scenarios) - -These tests run in a controlled environment with mock Espresso nodes: - -| # | Test File | What It Tests | Why It Matters | -|---|-----------|---------------|----------------| -| 1 | `espresso_benchmark_test.go` | High-throughput performance | Validates system under load | -| 2 | `espresso_liveness_test.go` | Continuous operation | Core functionality | -| 3.1 | `espresso_caff_node_test.go` | Caff node derivation | L2 state correctness | -| 3.2 | `deterministic_state_test.go` | State determinism | Same inputs → same state | -| 3.3 | `fast_derivation_and_caff_node_test.go` | Optimistic derivation | Fast confirmation path | -| 4 | `confirmation_integrity_with_reorgs_test.go` | Reorg handling | L2 reorganization safety | -| 5 | `batch_authentication_test.go` | TEE attestation | Authentication security | -| 6 | `batch_inbox_test.go` | Contract validation | On-chain security | -| 7 | `stateless_batcher_test.go` | **Stateless recovery** | **Critical: restart safety** | -| 8 | `reorg_test.go` | L2/Espresso reorgs | Multi-layer consistency | -| 9 | `pipeline_enhancement_test.go` | Derivation pipeline | Integration correctness | -| 10 | `soft_confirmation_integrity_test.go` | Fast confirmations | Espresso confirmation validity | -| 11 | `forced_transaction_test.go` | Censorship resistance | Security invariant | -| 12 | `enforce_majority_rule_test.go` | Query service voting | Byzantine fault tolerance | -| 13 | `dispute_game_test.go` | Fault proof system | L1 dispute resolution | -| 14 | `batcher_fallback_test.go` | Fallback mechanism | Graceful degradation | - -#### Devnet Tests (9 real-world scenarios) - -These tests run against a full Docker-based devnet with real Espresso nodes: - -| Test | What It Tests | Environment | -|------|---------------|-------------| -| `TestSmokeWithFallback` | Basic operation with fallback batcher | Standard mode | -| `TestSmokeWithEspresso` | Basic operation with Espresso batcher | AWS Nitro Enclave | -| `TestBatcherRestart` | Batcher restart resilience | Failure recovery | -| `TestBatcherSwitching` | Switch between Espresso/fallback | Fallback activation | -| `TestBatcherActivePublishOnly` | Active batch publishing | Data availability | -| `TestForcedTransaction` | Force inclusion via L1 | Censorship resistance | -| `TestWithdrawal` | L2→L1 withdrawals | Bridge security | -| `TestChallengeGame` | Fault proof challenges | Dispute resolution | -| `TestChangeBatchAuthenticatorOwner` | Ownership transfer | Access control | - -#### Critical Test Deep Dive: Stateless Batcher (Test 7) - -```go -// Validates batcher can restart randomly without data loss -// Verifies Espresso-L1 consistency after restarts -func TestStatelessBatcher(t *testing.T) -``` - -**What it does:** -1. Starts sequencer, batcher (Espresso mode), Caff node, OP node -2. Loops over N iterations: - - Randomly picks one iteration to **stop** the batcher - - Randomly picks another to **start** the batcher - - For all other iterations: send 1 coin to Alice -3. Asserts: - - Alice's balance on Caff node = Alice's balance on OP node - - No transactions lost during batcher downtime - -**Why this is critical:** Proves the batcher maintains no persistent state and can recover from arbitrary restarts without data loss or inconsistency. - -Reference: [`7_stateless_batcher_test.go:21-38`](espresso/environment/7_stateless_batcher_test.go) - -### Test Coverage Analysis - -#### 1. **Security Property Validation** - -Each security validation layer has corresponding test coverage: - -| Validation Property | Test Coverage | Validation Method | -|-------------------|-----------|-----------| -| Authenticity | Test 5, 6, TestSmokeWithEspresso | TEE attestation verification | -| Integrity | Test 7, 10, TestBatcherRestart | State consistency across restarts | -| Liveness | Test 2, 14, TestBatcherSwitching | Operation under component failures | -| Consistency | Test 3.2, 4, 8 | Deterministic state across nodes | -| Censorship Resistance | Test 11, TestForcedTransaction | Force inclusion via L1 | -| Fallback Behavior | Test 14, TestBatcherSwitching | Mode switching validation | -| Query Service | Test 12 | Majority voting implementation | -| Dispute Resolution | Test 13, TestChallengeGame | Fault proof verification | - - - -#### 2. **Failure Scenario Testing** - -Tests include various failure scenarios and recovery mechanisms: - -| Failure Scenario | Test Coverage | Recovery Mechanism Tested | -|------------------|---------------|-------------------| -| Batcher crash | Test 7, TestBatcherRestart | Stateless recovery | -| TEE unavailable | Test 14, TestBatcherSwitching | Fallback to fallback batcher | -| Espresso unavailable | Test 14 | Direct L1 posting | -| L2 reorg | Test 4, 8 | Automatic state reset | -| Invalid attestation | Test 5 | Contract rejection | -| Query service disagreement | Test 12 | Majority rule application | - -**Test design**: Each test verifies that the system detects the failure condition and executes the corresponding recovery mechanism. - -#### 3. **Environment Testing Characteristics** - -The devnet tests differ from environment tests in their setup: - -- **AWS Nitro Enclaves**: `TestSmokeWithEspresso` runs against actual Nitro hardware -- **Espresso Nodes**: Tests interact with running Espresso consensus nodes -- **L1 Interaction**: Full Ethereum L1 deployment using actual contracts -- **Docker Networking**: Inter-service communication over Docker networks - -**Setup difference**: Environment tests use mocked Espresso components for faster iteration, while devnet tests use the full production stack. - -#### 4. **Layered Testing Strategy** - -Tests are organized by scope: - -``` -Unit Tests (Go packages) - ↓ -Contract Tests (Foundry) - ↓ -Environment Tests (Mocked Espresso) - ↓ -Devnet Tests (Real Espresso) - ↓ -Enclave Tests (Real AWS Nitro) -``` - -Each layer catches different classes of bugs: -- **Unit**: Logic errors -- **Contract**: Smart contract vulnerabilities -- **Environment**: Integration issues (fast iteration) -- **Devnet**: Real-world scenarios (high confidence) -- **Enclave**: Hardware-specific issues - -#### 5. **OP Stack Test Suite Availability** - -A test script exists for validating OP Stack compatibility: - -```bash -# From run_all_tests.sh (manual execution) -make -C ./cannon test -just -f ./op-batcher/justfile test -just -f ./op-challenger/justfile test -just -f ./op-node/justfile test -just -f ./op-proposer/justfile test -# ... (all OP Stack component tests) -``` - -**Test scope**: These tests validate that the integration maintains compatibility with existing OP Stack components and behaviors. - -**Note**: This comprehensive suite is available for manual testing but does not run automatically in CI. CI focuses on Espresso-specific integration tests and L1 contract tests. - -Reference: [`run_all_tests.sh`](run_all_tests.sh) - -#### 6. **Continuous Testing in CI** - -Every PR triggers: -- ✅ 14 integration tests -- ✅ 9 devnet tests -- ✅ L1 contract tests (Foundry tests for BatchInbox, BatchAuthenticator) -- ✅ Enclave tests (on actual AWS infrastructure) - -**CI configuration**: Tests run in parallel across multiple groups with 30-minute timeouts. - -**Additional Testing**: An OP Stack regression test suite (`run_all_tests.sh`) is available for manual execution to validate compatibility with all OP Stack components (op-program, cannon, op-challenger, op-node, op-proposer, op-service, op-supervisor, op-e2e). - -References: -- [`espresso-integration.yaml`](.github/workflows/espresso-integration.yaml) -- [`espresso-devnet-tests.yaml`](.github/workflows/espresso-devnet-tests.yaml) -- [`espresso-enclave.yaml`](.github/workflows/espresso-enclave.yaml) - -### Test Coverage Characteristics - -The test suite exhibits the following properties: - -- **Component independence**: Each component has dedicated test coverage -- **Path coverage**: Tests include normal operation, failure scenarios, and edge cases -- **Environment variety**: Tests run in both mocked and production-like environments -- **Continuous execution**: CI runs all tests on every pull request -- **Property validation**: Each validation layer has test coverage -- **Deployment simulation**: Devnet tests use the same deployment process as production - - -### 3.2 Smart Contract Security Tests - -The Espresso integration includes Foundry-based smart contract tests that validate security properties of the L1 contracts responsible for batch data submission. - -#### BatchInbox Contract Tests - -The `BatchInbox` contract enforces batcher authentication based on operating mode (Espresso vs fallback). Test coverage includes: - -**Espresso Mode Authentication** - -```solidity -// Espresso batcher requires valid attestation -function test_fallback_espressoBatcherRequiresAuthentication() external - -// Espresso batcher succeeds with authenticated batch -function test_fallback_espressoBatcherSucceedsWithValidAuth() external - -// Fallback batcher cannot post when Espresso mode is active -function test_fallback_fallbackBatcherRevertsWhenEspressoActiveAndUnauthenticated() external -``` - -These tests verify that when the system operates in Espresso mode: -- Only the designated Espresso batcher address can submit batches -- Batches must be pre-authenticated via the `BatchAuthenticator` contract -- The fallback batcher is rejected even if attempting to submit authenticated batches - -**Fallback Mode Authentication** - -```solidity -// Fallback batcher can post after mode switch -function test_fallback_fallbackBatcherCanPostAfterSwitch() external - -// Fallback batcher doesn't require attestation -function test_fallback_fallbackBatcherDoesNotRequireAuth() external - -// Inactive batcher (TEE) reverts in fallback mode -function test_fallback_inactiveBatcherReverts() external - -// Unauthorized addresses are rejected -function test_fallback_unauthorizedAddressReverts() external -``` - -These tests verify that when switched to fallback mode: -- Only the designated fallback batcher can submit batches -- No attestation or pre-authentication is required -- The Espresso batcher cannot post (even with valid attestations) -- Random unauthorized addresses are rejected - -**Security Properties Validated:** -- **Exclusive access control**: Only one batcher can be active at a time -- **Mode enforcement**: Authentication requirements match the active mode -- **Address authorization**: Unauthorized addresses cannot submit batches - -#### BatchAuthenticator Contract Tests - -The `BatchAuthenticator` contract manages batcher switching and batch authentication. Test coverage includes: - -**Ownership and Access Control** - -```solidity -// Only owner can switch active batcher -function test_switchBatcher_revertsForNonOwner() external -``` - - -**References:** -- [`BatchInbox.t.sol`](packages/contracts-bedrock/test/L1/BatchInbox.t.sol) - 7 test functions covering all authentication scenarios -- [`BatchAuthenticator.t.sol`](packages/contracts-bedrock/test/L1/BatchAuthenticator.t.sol) - 4 test functions covering ownership and initialization - -### 3.3 Enclave Testing - -**Real TEE Validation** - -The integration includes tests running on actual AWS Nitro Enclaves: - -```yaml -# .github/workflows/espresso-enclave.yaml -- name: Run enclave tests - run: just espresso-enclave-tests -``` - -These tests validate: -- Attestation generation in real Nitro environment -- Key generation isolation -- PCR0 measurement consistency -- Contract registration flow - -Reference: [`espresso-enclave.yaml`](.github/workflows/espresso-enclave.yaml) - -### 3.4 Continuous Integration - -**Automated Security Checks** - -Every pull request triggers the execution of different test suites: - -**1. Espresso Integration Tests** (automatic on every PR) -```yaml -# .github/workflows/espresso-integration.yaml -- Parallelized across 4 groups -- Tests all Espresso-specific components -- Runs: ./espresso/... test suite -- Timeout: 30 minutes -``` - -**2. L1 Contract Tests** (automatic on every PR) -```yaml -# .github/workflows/contracts-l1-tests.yaml -- Foundry tests for BatchInbox and BatchAuthenticator -- Validates on-chain security properties -``` - -**3. Devnet Tests** (on-demand via workflow dispatch) -```yaml -# .github/workflows/espresso-devnet-tests.yaml -- Full Docker-based environment with real Espresso nodes -- Tests 9 real-world scenarios -``` - -**4. Enclave Tests** (on-demand via workflow dispatch) -```yaml -# .github/workflows/espresso-enclave.yaml -- Runs on actual AWS Nitro Enclave hardware -- Validates TEE attestation and key isolation -``` - -CI ensures no regression in Espresso-specific security properties and contract behavior. - -References: -- [`espresso-integration.yaml`](.github/workflows/espresso-integration.yaml) -- [`contracts-l1-tests.yaml`](.github/workflows/contracts-l1-tests.yaml) -- [`espresso-devnet-tests.yaml`](.github/workflows/espresso-devnet-tests.yaml) -- [`espresso-enclave.yaml`](.github/workflows/espresso-enclave.yaml) - -## 4. Contract Security Architecture - -### 4.1 Minimal On-Chain Complexity - -The L1 contracts follow a minimalist design philosophy: - -**`BatchInbox.sol` (77 lines)** -- Single fallback function -- Clear authentication logic -- No complex state management -- Minimal attack surface - -**`BatchAuthenticator.sol` (86 lines)** -- Straightforward signature verification -- Immutable TEE verifier reference -- Simple batcher switching -- Event emission for auditability - -Small, focused contracts are easier to audit and less prone to vulnerabilities. - - -### 4.3 External Dependency Isolation - -Contracts minimize external dependencies: - -```solidity -import { ECDSA } from "@openzeppelin/contracts/utils/cryptography/ECDSA.sol"; -import { Ownable } from "@openzeppelin/contracts/access/Ownable.sol"; -``` - -Only battle-tested OpenZeppelin libraries are used, reducing supply chain risks. - - -## 5. Off-Chain Component Security - -### 5.1 Batcher Architecture - -**Isolation and Compartmentalization** - -The batcher separates concerns into independent loops: - -```go -// Batch queuing: Fast submission to Espresso -func (l *BlockLoader) BatchQueuingLoop() - -// Batch loading: Validation and L1 preparation -func (l *BlockLoader) BatchLoadingLoop() - -// Frame publishing: L1 submission -func publishingLoop() -``` - -Each loop can fail independently without compromising overall system integrity. State is minimized to enable easy recovery. - -### 5.2 Streamer Security - -**Validation Pipeline** - -The Espresso streamer implements defense-in-depth: - -```go -func (s *BatchStreamer[B]) CheckBatch(ctx context.Context, batch B) (BatchValidity, int) { - // Check ordering and buffering - i, batchRecorded := s.BatchBuffer.TryInsert(batch) - - // Verify batcher signature during unmarshaling - batch, err := s.UnmarshalBatch(transaction) -} -``` - -**Buffering for Resilience** - -The `BufferedEspressoStreamer` adds resilience: -- Absorbs temporary streamer resets without data loss -- Maintains consistent read position across reorgs -- Enables efficient batch retrieval - -Reference: [`buffered_streamer.go`](espresso/buffered_streamer.go) - - -## 6. Internal Security Reviews - -The Celo-Espresso integration has undergone comprehensive internal security audits covering TEE contracts and the Espresso streamer component. - -### Audit Summary - -| Audit | Date | Reference | Scope | Critical | High | Medium | Low | Status | -|-------|------|-----------|-------|----------|------|--------|-----|--------| -| **TEE Contracts** | Jan 28, 2026 | [PR #43](https://github.com/EspressoSystems/espresso-tee-contracts/pull/43) | Attestation verification, signer registration, enclave hash validation | 2 | 1 | 0 | 0 | ✅ All resolved | -| **Streamer** | 2026 | [PR #339](https://github.com/EspressoSystems/optimism-espresso-integration/pull/339) | Batch validation, reorg handling, L1 consistency, buffer management | 0 | 2 | 2 | 7 | ⏳ Documented. Resolution in progress. | -| **Total** | - | - | - | **2** | **3** | **2** | **7** | **3 fixed, 11 documented** | - -### Key Outcomes - -**TEE Contracts:** All critical and high-severity vulnerabilities resolved, including cross-chain deployment replay attacks, missing journal validations, and signer deletion DoS attacks. - -**For more details**, see the [internal Security Audit Report](https://github.com/EspressoSystems/espresso-audits/blob/main/internal-reviews/Integration/internal_report_30_january_2026.pdf). - - -## 7. Trust Model and Assumptions - -### 7.1 Trust Boundaries - -**Trusted Components** -- AWS Nitro Enclave hardware -- L1 Ethereum consensus -- Espresso consensus (for liveness) -- Succinct Network (for ZK proof generation) -- Automata's Nitro ZK Attestation SDK -- Espresso's Attestation Verifier service - -**Untrusted Components** -- Sequencer -- Batcher operator (networking, infrastructure) -- Espresso query service (validated via majority voting) -- Individual Espresso nodes - -### 7.2 Adversarial Scenarios Considered - -**Batcher and Attestation Attacks** - -| Attack Vector | Mitigation | Test Coverage | -|---------------|------------|---------------| -| Malicious batcher operator | TEE attestation proves code integrity | [Test 5](espresso/environment/5_batch_authentication_test.go), [TestSmokeWithEspresso](espresso/devnet-tests/smoke_test.go) | -| Invalid TEE attestation | On-chain ZK proof verification rejects unauthorized batches | [TestE2eDevnetWithInvalidAttestation](espresso/environment/5_batch_authentication_test.go) | -| Unattested batcher key | Unsafe blocks produced; safe blocks require valid attestation | [TestE2eDevnetWithUnattestedBatcherKey](espresso/environment/5_batch_authentication_test.go) | -| Forged batch signature | BatchAuthenticator validates ECDSA signatures against registered signers | [BatchAuthenticator.t.sol](packages/contracts-bedrock/test/L1/BatchAuthenticator.t.sol) | -| Invalid batch commitment | BatchInbox verifies keccak256 hash of calldata/blobs before acceptance | [BatchInbox.t.sol](packages/contracts-bedrock/test/L1/BatchInbox.t.sol) | - -**Network and Infrastructure Attacks** - -| Attack Vector | Mitigation | Test Coverage | -|---------------|------------|---------------| -| Compromised Espresso node | Majority voting across multiple query service nodes | [Test 12](espresso/environment/12_enforce_majority_rule_test.go) | -| Espresso query service disagreement | 2/3 majority rule; inconsistent responses trigger re-query | [Test 12](espresso/environment/12_enforce_majority_rule_test.go) | -| TEE/Espresso unavailability | Fallback to fallback batcher with standard OP Stack security | [Test 14](espresso/environment/14_batcher_fallback_test.go), [TestBatcherSwitching](espresso/devnet-tests/batcher_switching_test.go) | -| Succinct Network unavailability | Batcher cannot register new attestations until service restored; existing keys continue | - | -| Execution engine crash | Stateless restart recovery; no persistent state required | [Test 7](espresso/environment/7_stateless_batcher_test.go) | - -**Censorship and Liveness Attacks** - -| Attack Vector | Mitigation | Test Coverage | -|---------------|------------|---------------| -| Sequencer censorship | Forced transaction inclusion via L1 after sequencing window expires | [Test 11](espresso/environment/11_forced_transaction_test.go) | -| Batcher refusing to submit | Users can force-include transactions through L1 deposits | [Test 11](espresso/environment/11_forced_transaction_test.go) | -| Sequencer downtime | Forced inclusion mechanism activates after sequencing window | [Test 11](espresso/environment/11_forced_transaction_test.go) | - -**State and Consistency Attacks** - -| Attack Vector | Mitigation | Test Coverage | -|---------------|------------|---------------| -| L1 reorg invalidating posted batches | Batcher re-derives and re-posts same batches in same order after L1 reorg | [Test 4](espresso/environment/4_confirmation_integrity_with_reorgs_test.go) | -| Submitting batches derived from unfinalized L1 blocks | Batcher and Caff node wait for L1 finality before submission/processing | [Test 8](espresso/environment/8_reorg_test.go) | - -**Smart Contract Attacks** - -| Attack Vector | Mitigation | Test Coverage | -|---------------|------------|---------------| -| Unauthorized batcher switch | Only contract owner can call switchBatcher() | [test_switchBatcher_revertsForNonOwner](packages/contracts-bedrock/test/L1/BatchAuthenticator.t.sol) | -| Zero address configuration | Constructor rejects zero addresses for batchers | [test_constructor_revertsWhen*IsZero](packages/contracts-bedrock/test/L1/BatchAuthenticator.t.sol) | -| Wrong batcher in Espresso mode | BatchInbox enforces only Espresso batcher can post in Espresso mode | [test_fallback_espressoBatcherRequiresAuthentication](packages/contracts-bedrock/test/L1/BatchInbox.t.sol) | -| Wrong batcher in fallback mode | BatchInbox enforces only fallback batcher can post in fallback mode | [test_fallback_unauthorizedAddressReverts](packages/contracts-bedrock/test/L1/BatchInbox.t.sol) | -| Unauthenticated batch in TEE mode | Derivation pipeline checks BatchInfoAuthenticated events in lookback window | [test_authenticateBatchInfo_succeeds](packages/contracts-bedrock/test/L1/BatchAuthenticator.t.sol) | - -**Future Threat Vectors** - -| Attack Vector | Current Exposure | Planned Mitigation | -|---------------|------------------|-------------------| -| Operator network MitM | Operator controls enclave networking | SSL certificate pinning or in-enclave L1 light client | -| Espresso query service trust | Majority voting across operators | Direct QC and namespace proof verification | -| Centralized batcher operation | Single Espresso batcher address | Permissionless batching with stake-based selection | - - -## 9. Next steps - -### 9.1 Planned Audit with Least Authority - -All L1 smart contracts for the Celo-Espresso integration will undergo external security audit by [Least Authority](https://leastauthority.com/), a security research firm specializing in privacy-focused and cryptographic systems. - -**Audit Scope:** -- `BatchInbox.sol` - Batch data submission and authentication -- `BatchAuthenticator.sol` - Dual-batcher switching and TEE signature verification -- TEE Verifier contracts - - -Least Authority proactively identified and disclosed a bug in the [Espresso Jellyfish cryptographic library](https://github.com/EspressoSystems/jellyfish), demonstrating their commitment to responsible disclosure and deep understanding of cryptographic systems. - -### 9.2 Monitoring System - -The specification of the monitoring system is in progress. - -## References - -- [OP Stack Integration Specification](https://eng-wiki.espressosys.com/mainch36.html#x43-22900036) -- [Source Code Repository](https://github.com/EspressoSystems/optimism-espresso-integration) -- [Optimism Rollup Protocol Specification](https://specs.optimism.io/) -- [AWS Nitro Enclaves Documentation](https://docs.aws.amazon.com/enclaves/) - -**Document Version**: 1.1 -**Last Updated**: January 29, 2026 - diff --git a/espresso/docs/CELO_TESTNET_MIGRATION.md b/espresso/docs/CELO_TESTNET_MIGRATION.md deleted file mode 100644 index 07125806415..00000000000 --- a/espresso/docs/CELO_TESTNET_MIGRATION.md +++ /dev/null @@ -1,162 +0,0 @@ -# Celo Testnet Migration - -## Overview - -This document serves as the main collaboration tool between Celo Labs and Espresso Systems teams to agree on the migration process from Celo Testnet to its Espresso-integrated version. - -Currently this document contains questions and will evolve into a detailed guide describing the concrete steps of the migration. - ---- - -## Questions from Espresso to Celo - -### Big Picture - -#### Q1: What are Celo's goals that Espresso should be aware of? - -In particular, which Celo Testnet should we target for migration? - -**Response from Celo:** -- Public testing will happen on **Celo Sepolia** -- Testing progression: Local environment → Private testnet → Celo Sepolia (public) -- This migration will be deployed as part of a broader testnet upgrade - -#### Q2: Are there migration-related resources you can share with us? - -For example: scripts, documentation, or runbooks from previous upgrades. - -*Awaiting response from Celo.* - -#### Q3: Can Celo share SLAs on all services provided to users? - -It would be helpful to highlight any SLAs that are directly related to, or impacted by, the batch poster (e.g., finality guarantees, uptime commitments). - -*Awaiting response from Celo.* - ---- - -### Migration Implementation - -#### Q3.1: Hardfork Considerations - -**Response from Celo:** - -The migration to Espresso will be implemented as a **hardfork** because: -- Adding config options and derivation changes requires protocol-level modifications -- All nodes must upgrade simultaneously to maintain consensus - -**Questions:** -- What is the exact hardfork activation block/timestamp? -- What are the backwards compatibility requirements? -- What is the node upgrade coordination timeline? -- What settings and versions will be used for the local environment testing? -- What settings and versions will be used for the private testnet testing? - -#### Q3.2: Contract Deployment Strategy - -**Response from Celo:** - -For the new L1 contracts (BatchAuthenticator), Celo needs to determine: - -**Questions:** -- Can we deploy contracts before the hardfork activation? - - Preferred approach: Deploy contracts in advance, activate via hardfork - - Alternative: Deploy as part of hardfork logic (more complex) -- Are there any contract initialization dependencies on the hardfork? -- Do contracts need special permissions or ownership setup during deployment? - ---- - -### Support Model - -#### Q4: What are the deployment phases? - -**Response from Celo:** - -Testing and deployment will follow Celo's standard upgrade process: - -| Phase | Description | Duration | Participants | -|-------|-------------|----------|--------------| -| **Local Environment** | Local devnet testing | Temporary | Espresso & Celo engineers | -| **Private Testnet** | Private testnet run by Celo | Temporary | Espresso & Celo teams | -| **Celo Sepolia (Public)** | Public testnet open to community | Persistent | Espresso, Celo, and community | -| **Mainnet** | Production deployment | Permanent | Public | - -#### Q5: What reporting and logging does Celo have currently? - -- What alerts are automated? -- What automations should Espresso replicate for the batcher? - -*Awaiting response from Celo.* - -#### Q6: What incidents should one team vs both teams be responsible for? - -It would be helpful to identify: -- What errors require both teams to be on-call? -- When should Celo provide logs to Espresso? - -**Proposed Incident Matrix:** - -| Incident Type | Primary | Support | -|---------------|---------|---------| -| Batcher not posting batches | Espresso | Celo (if network issue) | -| op-node / op-geth issues | Celo | Espresso (if integration-related) | -| L1 contract issues | Both | Both | -| Chain liveness issues | Both | Both | - -*Awaiting response from Celo.* - -#### Q7: What are Celo's batch posting SLA expectations? - -For example: -- Expected batch posting interval (e.g., every 30 minutes)? -- Acceptable finality lag threshold? -- Uptime requirements (e.g., 99.9%)? - -*Awaiting response from Celo.* - -#### Q8: What is Celo's disaster recovery approach? - -- If the state is corrupted, does Celo capture snapshots of the rollup state that Espresso could use for recovery? -- If Celo loses a server, what happens? (This helps with our own testing.) - -*Awaiting response from Celo.* - ---- - -### Access Requirements - -#### Q9: What access does Espresso need from Celo? - -Espresso needs the following to operate the Espresso batcher: - -| Requirement | Description | -|-------------|-------------| -| Sequencer RPC URL | RPC access to the sequencer | -| Chain configuration | Chain config files for the rollup | -| Batcher configuration | Current `op-batcher` configuration | -| State directory access | Access to `op-node` state (if migrating existing state) | - -*Awaiting response from Celo.* - ---- - -## Questions from Celo to Espresso - -*Please add questions here.* - ---- - -## Resources - -### Espresso Integration -- [Source code (optimism-espresso-integration)](https://github.com/EspressoSystems/optimism-espresso-integration) -- [Local devnet configuration guide](./README_ESPRESSO_DEPLOY_CONFIG.md) - -### OP Stack References -- [OP Network Upgrades Guide](https://docs.optimism.io/op-stack/protocol/network-upgrades) -- [OP Upgrade 17 Notice](https://docs.optimism.io/notices/upgrade-17) - -### Celo References -- [Celo L2 Forum Post](https://forum.celo.org/t/celo-as-an-ethereum-l2-a-frontier-chain-for-global-impact/11376) -- [Jello Hardfork Announcement](https://forum.celo.org/t/introducing-the-jello-hardfork-op-succinct-lite-now-live-on-celo-sepolia/12603) From 4ef7b318c1f0b9d412a49120871d0095fd26fabf Mon Sep 17 00:00:00 2001 From: Philippe Camacho Date: Tue, 7 Apr 2026 17:05:56 -0400 Subject: [PATCH 3/3] Remove broken link. --- README_ESPRESSO.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/README_ESPRESSO.md b/README_ESPRESSO.md index dbc9a24d7f8..1e3d30860ab 100644 --- a/README_ESPRESSO.md +++ b/README_ESPRESSO.md @@ -549,12 +549,9 @@ Note that periodically we need to merge upstream changes in the `kona`, `celo-ko # Testnet Migration -We are working on a set of scripts to handle the migration from a Celo Testnet to a version integrated with Espresso. - -Some relevant documents: * [Documentation of configuration parameters](espresso/docs/README_ESPRESSO_DEPLOY_CONFIG.md) -* [Celo Testnet Migration Guide](espresso/docs/CELO_TESTNET_MIGRATION.md) (WIP) + ## Generating alloc.json file