Hello!
This is a great PIP in general and I’m all for pushing boundaries. I have some concerns around witnesses and their overhead costs. I have made some assumptions on what these proof will entail, if this premise is wrong, then no need to read rest of the doc.
- Trie Node Proofs: Cryptographic proofs of state trie portions accessed during execution
- Account Data: State information for accounts accessed during block execution
- Storage Proofs: Evidence of storage slot values for contract interactions
- Code Witnesses: Contract bytecode accessed during execution
- Proof Metadata: Information to organize and verify witness components
Concerns:
- The exact composition of witnesses is not explicitly defined, can we get a breakdown of what these witnesses will contain?
- Different implementations could significantly vary in size and complexity
- Witness format standardisation would be required for interoperability
The write up assumes witnesses would rely on:
- Merkle Patricia Tries: Current standard in Ethereum/Polygon, with proofs consisting of sibling nodes along paths from leaf to root
- Hash Functions: Keccak-256 for consistency with existing EVM infrastructure
- Potential Future Upgrades: Verkle tries or other vector commitment schemes
Witness Generation Process
The assumed witness generation process includes:
- State Access Tracking: VEBloP tracks all state accesses during execution
- Trie Node Collection: Relevant trie nodes are collected for each access
- Proof Construction: Cryptographic proofs are constructed for each state element
- Witness Compilation: All proofs are compiled into a structured format
- Witness Propagation: Distribution alongside blocks via dedicated protocol
Concerns:
- State access tracking adds computational overhead to block production
- Proof construction is computationally intensive and may become a bottleneck
- The process assumes deterministic execution paths, which may not hold for all EVM operations
- Witness generation must be perfectly synchronized with execution to avoid inconsistencies
Caching and Transaction Pattern Concerns
Caching Effectiveness
The analysis assumes witness caching could reduce witness size by ~40-60%, but this depends heavily on transaction patterns:
Concerns:
- Temporal Locality Assumption: Caching assumes transactions access recently used state
- Contract Popularity Skew: Effectiveness varies based on contract usage distribution
- Changing Patterns: DeFi trends, NFT mints, or other activity spikes can invalidate caching assumptions
- Cache Invalidation: State changes require careful cache invalidation strategies
- Cache Size Limits: Memory constraints limit cache effectiveness for validators
Transaction Type Distribution
The analysis assumes a transaction mix of 70% simple transfers, 25% token transfers, and 5% complex DeFi:
Concerns:
- Evolving Usage Patterns: This distribution may not hold over time
- DeFi Complexity Growth: Increasing complexity of DeFi protocols may increase witness sizes
- New Contract Types: Novel contract patterns may have unpredictable witness requirements
- MEV Transactions: MEV-related transactions often access many storage slots, generating larger witnesses
State Access Patterns
Concerns:
- Hot Spots: Certain state elements (popular tokens, liquidity pools) may be accessed frequently
- State Growth: As state grows, witness sizes for accessing “cold” state increase
- Cross-Contract Interactions: Complex transactions touching multiple contracts generate larger witnesses
- Storage Layout: Contract storage layout significantly impacts witness size
Network and Propagation Concerns
Bandwidth Requirements
The analysis estimates 200-500 Mbps bandwidth requirements for unoptimized witnesses:
Concerns:
- Geographic Disparities: Validators in regions with limited bandwidth may be disadvantaged
- Network Congestion: Peak network usage may cause propagation delays
- ISP Limitations: Data caps or throttling could affect validator participation
- Cost Barriers: High bandwidth requirements increase operational costs
Propagation Strategies
Concerns:
- Gossip Protocol Efficiency: Standard gossip protocols may be inefficient for large witnesses
- Network Topology: Suboptimal network topology could increase propagation times
- Propagation Failures: Partial witness propagation could lead to validation failures
- Prioritization: Lack of witness part prioritization could delay critical validation
Computational Concerns
Generation Overhead
Concerns:
- CPU Intensity: Witness generation adds ~50-75% overhead to block production
- Memory Usage: Tracking state access requires significant memory
- Parallelization Challenges: Some aspects of witness generation are difficult to parallelize
- Hardware Requirements: May necessitate specialized hardware for VEBloPs
Verification Costs
Concerns:
- Verification Time Variability: Complex transactions require more verification time
- Proof Verification Overhead: Cryptographic verification adds significant CPU load
- Batching Inefficiencies: Verification may not scale linearly with transaction count
- Resource Competition: Verification competes with other validator tasks
Consensus Impact Concerns
Finality Time
Concerns:
- Witness Propagation Delay: Large witnesses add ~400-600ms to propagation time
- Verification Bottlenecks: Witness verification may become the critical path for finality
- Timeout Parameters: Consensus timeouts may need adjustment for witness overhead
- Liveness Risk: Excessive delays could trigger unnecessary view changes/leader rotations
Security Implications
Concerns:
- Validator Participation: Bandwidth/computational requirements may reduce validator set
- Centralization Pressure: Only well-resourced entities may be able to serve as VEBloPs
- New Attack Vectors: Witness-specific DoS attacks become possible
- Censorship Resistance: Witness overhead could weaken forced transaction mechanisms
Possible Alternative Approach
ZK-Based State Validation
- Replace explicit witnesses with zero-knowledge proofs of state access
- VEBloP generates ZK proofs that transactions were executed correctly
- Validators verify compact ZK proofs instead of re-executing with witnesses
- Leverage and utilise latest Succint breakthrough of SP1 HyperCube block verification (https://x.com/succinctlabs/status/1924845712921264562?s=46)
Benefits:
- Dramatically reduced witness size
- Constant-size proofs regardless of transaction complexity
- Potential privacy benefits
Overall, I love the proposal and we should push ahead with consensus change to bring Polygon PoS in line with latest gen of DLT ecosystems.