You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
**Motivation:**
The `AllocationManager` contract was hitting the 24KB bytecode size
limit, which would have blocked deployment. We needed a solution to
reduce the contract size while maintaining backwards compatibility with
existing integrations that call view functions on `AllocationManager`.
**Modifications:**
- Created a new `SplitContractMixin` that uses a fallback to delegate
unmatched function calls via `delegatecall` to a secondary contract
- Split `AllocationManager` into two contracts: the main contract
handles state-mutating operations, while `AllocationManagerView` handles
all read-only view functions
- Both contracts inherit from `AllocationManagerStorage` to share the
same storage layout, enabling the view contract to read from the main
contract's storage
- Updated `AllocationManager` constructor to accept and store the
`AllocationManagerView` address
- Modified all deployment scripts (devnet, local, integration) to deploy
both proxies and implementations
- Updated `ExistingDeploymentParser`, test harnesses, and
unit/integration tests to work with the split architecture
**Result:**
- The `AllocationManager` is now about ~ 4.8KB under the 24KB limit with
room to grow.
- The `AllocationManagerView` contract has 16KB of available space for
future view functions.
TODO: Add a ci check (I don't have privs but the code is written
locally)
1) Get list of all contracts ending in View.sol in the repo.
2) Use forge inspect abi and check all mutability fields == view|pure.
3) Basic search over the file to see if sstore or delegatecall is used
on a for additional sanity.
---------
Co-authored-by: eigenmikem <[email protected]>
@@ -29,11 +30,58 @@ The `AllocationManager` manages AVS metadata registration, registration and dere
29
30
30
31
The `AllocationManager's` responsibilities are broken down into the following concepts:
31
32
33
+
*[Contract Architecture](#contract-architecture)
32
34
*[AVS Metadata](#avs-metadata)
33
35
*[Operator Sets](#operator-sets)
34
36
*[Allocations and Slashing](#allocations-and-slashing)
35
37
*[Config](#config)
36
38
39
+
## Contract Architecture
40
+
41
+
The `AllocationManager` uses a **split contract pattern** implemented via the `SplitContractMixin` to address EVM contract size limitations while maintaining full backwards compatibility.
- Inherits from `SplitContractMixin` which provides delegation capabilities
55
+
- Delegates all view function calls to the separate view contract
56
+
- Maintains the same external interface as a monolithic contract
57
+
58
+
**View Contract (`AllocationManagerView`):**
59
+
- Contains all read-only view functions
60
+
- Shares the same storage layout as the main contract using `layout at 151` directive
61
+
- Implements the same `IAllocationManagerView` interface
62
+
63
+
### Rationale
64
+
65
+
**Codesize Optimization:**
66
+
- The EVM has a contract size limit of 24KB (24,576 bytes) for deployed contracts
67
+
- Complex contracts like `AllocationManager` with extensive functionality can exceed this limit
68
+
- By splitting view functions into a separate contract, the main contract stays under the size limit
69
+
- This allows for more comprehensive functionality without compromising deployability
70
+
71
+
**Backwards Compatibility:**
72
+
- The external interface remains identical to a monolithic contract
73
+
- All existing integrations continue to work without modification
74
+
- View functions are transparently delegated using `_delegateView()`
75
+
- No breaking changes to the ABI or function signatures
76
+
77
+
**Implementation Details:**
78
+
- View functions in the main contract use `_delegateView(viewImplementation)` to delegate calls.
79
+
- The `viewImplementation` address is set during construction and stored as an immutable variable.
80
+
- The `_delegateView()` function conveniently indicates which calls are intended to be delegated as view functions, but it does not enforce this at the EVM level; rather, it signals intended usage and expected behavior to the user or integrator.
81
+
- Both contracts are aligned in storage layout, so all state variables are accessible as intended.
82
+
83
+
This pattern is especially useful for complex contracts that require a comprehensive set of view functions while maintaining the ability to perform state mutations. It helps keep contracts deployable within EVM bytecode limits, while making clear which functions are for data retrieval.
84
+
37
85
## Parameterization
38
86
39
87
*`ALLOCATION_CONFIGURATION_DELAY`: The delay in blocks before allocations take effect.
0 commit comments