test: Add gas usage analysis for updateState function

GAS_ANALYSIS_REPORT.md

@@ -0,0 +1,105 @@
+# Gas Analysis Report: `updateState` Function in RegistryCoordinatorMimic
+
+## Executive Summary
+
+The `updateState` function in `RegistryCoordinatorMimic` **DOES exceed Ethereum block gas limits** under realistic AVS activity scenarios. This is a significant concern that requires immediate attention.
+
+## Test Results
+
+### Block Gas Limit
+- Ethereum Mainnet Block Gas Limit: **30,000,000 gas**
+
+### Key Findings
+
+#### 1. Operator Count Impact (with History Length = 10)
+| Operators | Gas Used | % of Block Limit | Status |
+|-----------|----------|------------------|---------|
+| 10 | 6,396,165 | 21% | ✅ Safe |
+| 50 | 29,649,662 | 98% | ⚠️ Critical |
+| 100 | 59,481,093 | **198%** | ❌ **Exceeds Limit** |
+| 200 | 121,574,342 | **405%** | ❌ **Exceeds Limit** |
+| 500 | 324,697,261 | **1082%** | ❌ **Exceeds Limit** |
+
+#### 2. History Length Impact (with 100 Operators)
+| History Length | Gas Used | % of Block Limit | Status |
+|----------------|----------|------------------|---------|
+| 10 | 59,166,791 | **197%** | ❌ **Exceeds Limit** |
+| 50 | 291,405,311 | **971%** | ❌ **Exceeds Limit** |
+
+#### 3. Component Breakdown (100 operators, 50 history length)
+- APK Updates only: 1,425,845 gas (0.5% of total)
+- Stake History only: 138,936,116 gas (46.6% of total)
+- Bitmap History only: 139,669,057 gas (46.8% of total)
+- Full update: 298,155,947 gas (100%)
+
+## Critical Threshold
+
+The function becomes unusable at:
+- **~50 operators** with minimal history (10 entries)
+- **Any operator count > 50** will exceed block gas limits
+
+## Risk Assessment
+
+### High Risk Scenarios
+1. **Current Design**: The function stores entire history for all operators in a single transaction
+2. **Linear Gas Growth**: Gas usage grows linearly with both operator count and history length
+3. **Realistic AVS**: Most AVS deployments will have >50 operators, making the current implementation unusable
+
+### Impact
+- AVS with more than 50 operators cannot update state on-chain
+- System becomes completely non-functional for medium to large operator sets
+- No graceful degradation - the function simply fails
+
+## Recommendations
+
+### Immediate Actions Required
+
+1. **Implement Incremental Updates** (High Priority)
+   - Don't pass entire history each time
+   - Only update changed/new entries
+   - Store a checkpoint and update from that point
+
+2. **Batch Processing**
+   - Split updates across multiple transactions
+   - Process N operators per transaction
+   - Implement a multi-step update process
+
+3. **State Compression**
+   - Consider storing only deltas instead of full history
+   - Implement merkle tree for historical data
+   - Store only recent history on-chain, archive old data
+
+4. **Optimize Storage Patterns**
+   - Review assembly usage for array length setting
+   - Consider packed storage for smaller data types
+   - Reduce redundant storage operations
+
+### Proposed Solution Architecture
+
+```solidity
+// Instead of updating everything at once:
+function updateStateIncremental(
+    uint256 fromOperatorIndex,
+    uint256 toOperatorIndex,
+    MiddlewareData calldata middlewareData,
+    bytes calldata proof
+) external onlyOwner {
+    // Update only a subset of operators
+    // Track progress in storage
+    // Allow multiple calls to complete full update
+}
+```
+
+## Conclusion
+
+The current implementation of `updateState` is **not production-ready** for realistic AVS deployments. With gas usage exceeding block limits at just 50 operators, this represents a critical blocker for mainnet deployment. Immediate refactoring to implement incremental updates is essential.
+
+## Test Reproduction
+
+To reproduce these results:
+```bash
+forge test --match-path test/RegistryCoordinatorMimicGas.t.sol -vv
+```
+
+---
+*Report generated: 2025-08-13*