Role in the System
The Assertion Enforcer operates inside the block production pipeline:- Receives candidate transactions from the block builder or sequencer
- Identifies which assertions apply to each transaction
- Invokes PhEVM to execute assertions against transaction states
- Returns validation results (valid/invalid) to the network
- Only valid transactions are included in blocks
Sidecar Architecture
As a sidecar, the Assertion Enforcer:- Operates independently from the main L2 infrastructure
- Integrates alongside block builders without changing core protocol rules
- Scales separately from the main network components
- Fails gracefully without affecting L2 operations
Validation Process
When a transaction arrives for validation, the Assertion Enforcer orchestrates the following process:Step-by-Step
- Identify Relevant Assertions: The Assertion Enforcer consults registry data (indexed from on-chain events) to find which assertions apply to the contracts the transaction interacts with
- Fetch Assertion Bytecode: Assertion bytecode is retrieved from internal cache (populated from Assertion DA when assertions are deployed)
- Simulate Transaction: The transaction is executed against pre-transaction state to produce the post-transaction state
-
Execute Assertions: PhEVM runs all relevant assertions with access to:
- The transaction itself
- Pre-transaction state (State1)
- Post-transaction state (State2)
-
Return Result:
- If any assertion reverts → transaction is invalid
- If all assertions pass → transaction is valid
Block Building Integration
The Assertion Enforcer integrates with block builders to ensure only valid transactions enter blocks:- Transactions that would violate assertions are dropped before block inclusion
- The block builder or sequencer receives clear valid/invalid signals
- Block production continues normally with validated transactions
Operational Expectations (Public)
- Non-invasive: Runs alongside existing block builders without changing consensus rules
- Deterministic: Results are based on on-chain state and assertion code only
- Staging support: Networks can validate assertions before enforcing them in production
- Transparent outcomes: Incidents are visible in the dApp and dashboard
Forced Inclusion Transactions
Forced inclusion transactions (such as L1→L2 deposits) require special handling since they must be included regardless of assertion results. The Credible Layer has mitigation pathways for these scenarios.We have developed a solution for forced inclusion transactions and are actively implementing it. Ask us about it!
Assertion Caching
To ensure high-performance validation, the Assertion Enforcer maintains an internal cache of assertion bytecode:- On deployment: When an assertion is deployed on-chain, the Assertion Enforcer detects the event and fetches bytecode from Assertion DA
- During validation: Assertions are loaded from cache. No network requests occur on the hot path.