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
All Interstate changes are in the README.md and the `/slasher` folder which has been renamed from `/example` all other files are the same as source: https://github.com/eth-fabric/urc/blob/main/src/Registry.sol
2
+
3
+
Notes for auditors: We would additionally prefer to have MIN_COLLATERAL Field here https://github.com/interstate-labs/urc/blob/main/src/Registry.sol#L21 set to 0 to allow operators to default to restaking only if they wish.
4
+
5
+
These contracts allow a validator to register collateral and enable proposer commitments, a subset of Interstate's functionality. Native Ether or a restaking protocol can be used as collateral. We support Karak, Eigenlayer, and Symbiotic
- Significantly reduces storage costs and barriers to entry
6
+
- Keys can be stored in an extension contract
7
+
8
+
**Cons**:
9
+
- Harder to verify directly on-chain (requires submitting merkle proof)
10
+
11
+
**Current Implementation**:
12
+
13
+
Instead of saving validator public keys on-chain, the `register()` function merkleizes the `Registrations` and saves the root hash to the `commitments` mapping. This allows anyone verify whether a validator is opted-in and their collateral without storing the public key on-chain. This optimization reduces storage costs from `48 bytes` per validator to a constant `32 bytes` per batch of validators.
14
+
15
+
16
+
## Batching Operators
17
+
**Pros**:
18
+
- Reduces gas costs
19
+
- Collateral is shared across all validators in the batch (efficient for big 🐋)
20
+
21
+
**Cons**:
22
+
- Collateral is shared across all validators in the batch (inefficient for small 🐟)
23
+
24
+
**Current Implementation**:
25
+
26
+
The current implementation batches `N` validators per operator into a single `register()` call. This reduces gas costs by minimizing function calls and storage. The implication is that the Ether collateral is shared across all validators in the batch. However, since block proposals must happen sequentially, the collateral only needs to apply to a single validator at a time.
27
+
28
+
29
+
## Don't verify BLS signatures at registration time
30
+
31
+
**Pros**:
32
+
- Reduces gas costs
33
+
34
+
**Cons**:
35
+
- Valid registrations must wait for the fraud proof window to pass
36
+
- Introduces a minimum collateral requirement
37
+
38
+
**Current Implementation**:
39
+
40
+
Even post-Pectra upgrade, BLS precompiles are still expensive and would need to be called per validator. To avoid this, the current implementation optimistically accepts BLS signatures at registration time. Before the `FRAUD_PROOF_WINDOW` elapses, anyone can pay the gas to run the BLS signature verification on-chain and claim `MIN_COLLATERAL` from the operator as an incentive.
41
+
42
+
## Don't use bytecode to slash
43
+
To opt-in to preconfs, operators will commit to slashing conditions by signing off-chain `DelegationMessages`. To support general slashing logic, the initial idea was to have operators commit to a bytecode hash. Upon slashing, the URC would deploy and execute the corresponding bytecode. The return value of the function call is the amount of GWEI to be slashed from the operator's collateral.
44
+
45
+
**Pros of bytecode**:
46
+
- Elegant design
47
+
- Universal
48
+
49
+
**Cons of bytecode**:
50
+
- Executing bytecode requires first deploying it which eats into the gas limit or using lower-level languages like [Huff](https://docs.huff.sh/get-started/overview/)
51
+
- The approach cannot be used for stateful slashing logic, e.g., fraud proofs
52
+
- Bytecode is not easily verified/readable
53
+
54
+
**Current Implementation**:
55
+
56
+
Over several discussions, we decided replace bytecode commitments with slashing contract commitments. The bytecode approach supports universal slashing logic by encoding it directly as EVM logic or by deploying ZK-verification logic. However, the main motivator against using bytecode is that it does not allow for stateful slashing logic. For example, any protocol wishing to implement fraud proofs for their slashing logic would be incompatible with the bytecode approach. This is because the fraud proof game would need to be played over multiple rounds, implying it saves intermediate state.
57
+
58
+
In the current implementation, proposers commit to an arbitrary contract address which is expected to support a general purpose interface: `slash(bytes inputs)`. Similarly to the bytecode approach, the return value of the `slash(bytes inputs)` function is the amount of GWEI to be slashed.
59
+
60
+
This approach has the following benefits:
61
+
- Each `Slasher` contract only needs to be deployed once and can be verified on-chain.
62
+
- Arbitrary stateful logic can be executed on the `Slasher`. (e.g., a fraud proof game is played ahead of time and then calling `slash(bytes inputs)` returns the slashing outcome)
63
+
- Supports arbitrarily complex slashing logic, even existing restaking protocols
64
+
- Can support the execution of arbitrary bytecode by deploying a dedicated `Slasher` contract
0 commit comments