Open
Conversation
- Implements new `storage-trie-brancher` scenario that replicates Python `deploy_deep_branches.py` functionality (See: ethereum/execution-specs#1937) - Enables deployment of contracts designed to create worst-case storage trie depth scenarios (See https://github.com/CPerezz/worst_case_miner/settings) - Automatically handles Nick's factory deployment if not present on network.
- Add loadDataFromPathOrURL helper function to load files from URLs or local paths - Support HTTP/HTTPS URLs for both --data-file and --contract-file flags - Download contract files to temp directory before compilation when using URLs - Add comprehensive YAML configuration examples to README - Document URL loading capabilities with examples This allows users to load deployment data and Solidity contracts from external sources like GitHub raw URLs or any HTTP server, enabling more flexible deployment workflows.
Remove all local JSON and Solidity files from the storage_trie_brancher scenario directory since the scenario now supports loading these files from external URLs (GitHub gists, repositories, or any HTTP server). Removed files: - All s*_acc*.json deployment data files - All depth_*.sol Solidity contract files - deployed_contracts.json output file - stubs.json test file Users should now load these files from external sources using the --data-file and --contract-file flags with HTTP/HTTPS URLs.
Major changes to support running in Docker containers: 1. Replaced Solidity compilation with direct bytecode loading: - Removed solc dependency (not available in Docker) - Added --bytecode flag to accept hex bytecode directly - Supports loading bytecode from string, file path, or URL - Removed --contract-file flag 2. Replaced file writing with structured logging: - Removed saveDeploymentInfo() that wrote to filesystem - Added logDeploymentInfo() that outputs to logs - Deployment summary logged at INFO level - Full deployment data available at DEBUG level with --log-txs - No dependency on scenario directory structure 3. Made data-file and bytecode required parameters: - Removed auto-detection logic that relied on file paths - Users must explicitly provide both parameters - Supports URLs for both data and bytecode 4. Fixed calculateCreate2Address to use factory address: - Now uses s.factoryAddress instead of hardcoded NickFactoryAddress - Correctly handles dynamic factory addresses 5. Updated documentation: - README examples now use --bytecode instead of --contract-file - Added examples for URL-based loading - Clarified required parameters These changes ensure the scenario works properly in containerized environments where only the spamoor binary is available.
…ark contracts This scenario deploys initcode contracts, CREATE2 factory contracts, and test contracts of various sizes (0.5, 1, 2, 5, 10, 24 KB) for EXTCODESIZE benchmarks. Features: - Deploys initcode contracts that generate bytecode of specific sizes using keccak256 expansion loops - Deploys CREATE2 factory contracts that use EXTCODECOPY to deploy contracts with unique bytecode - Supports parallel deployment using multiple wallets (default 50) - Dynamic gas calculation based on contract size and block gas limit - Outputs factory addresses in stubs.json format for execution-spec-tests - Supports pre-deployed addresses via YAML config
Feat/storage trie brancher scenario
Signed-off-by: CPerezz <37264926+CPerezz@users.noreply.github.com>
feat: add extcodesize_setup scenario for deploying EXTCODESIZE benchm…
The erc20_bloater scenario was losing progress (halving each restart) due to a semantic mismatch between the Solidity contract and Go code: - Contract's `nextStorageSlot` stores ADDRESS INDEX (count of addresses bloated) - Go code was treating this as SLOT COUNT (addresses × 2) This caused a destructive bug on restart: 1. Read address index X from contract 2. Treat X as slot count (wrong units) 3. Call buildBloatTx(..., X/2, ...) - dividing by SlotsPerBloatCycle 4. Contract sets nextStorageSlot = X/2 - permanently halving progress! Fix: - Rename `startSlot` → `nextAddressIndex` for clarity - Rename `targetSlots` → `targetAddresses` - Remove the /SlotsPerBloatCycle division when calling buildBloatTx - Fix progress calculations to properly convert addresses to bytes/GB Tested with Geth in dev mode: progress now correctly resumes instead of halving.
statebloat rebase
statebloat rebase 2
The funding and deployment phases had hardcoded MaxPending values (100 and 50 respectively), severely limiting throughput. With 50 wallets and 21k gas funding txs, only ~100 txs/block were possible despite blocks having capacity for ~1400. Add two new configurable options: - max_pending: directly control in-flight transaction count - filling_ratio: auto-compute max_pending from block gas limit (e.g. 0.5 targets 50% block utilization) Priority: max_pending > filling_ratio > hardcoded fallback.
statebload rebase 3
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
statebloat scenarios for perf-devnet-2 by @CPerezz