-
Notifications
You must be signed in to change notification settings - Fork 27
feat(state-bloat): cold balance + warm extcodesize #124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
weiihann
wants to merge
27
commits into
ethpandaops:master
Choose a base branch
from
weiihann:state-bloat/warm-extcodesize
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
feat(state-bloat): cold balance + warm extcodesize #124
weiihann
wants to merge
27
commits into
ethpandaops:master
from
weiihann:state-bloat/warm-extcodesize
Conversation
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
Includes the scenarios contemplated within statebloat as well as any extra data about them such as gas cost metrics.
This scenario deploys contracts that are exactly 24kB in size (EIP-170 limit) to maximize state growth while minimizing gas cost. 1. Generates a contract with exactly 24,576 bytes of runtime code 2. Deploys the contract using CREATE 3. Each deployment adds: - 24,576 bytes of runtime code - Account trie node - Total state growth: ~24.7kB per deployment - 32,000 gas for CREATE - 20,000 gas for new account - 200 gas per byte for code deposit (24,576 bytes) - Total: 4,967,200 gas per deployment
- Remove redundant throughput flag and consolidate to contracts-per-tx - Remove count flag and related code for cleaner interface - Update wallet count calculation to use contracts-per-tx - Keep only two deployment rate control methods: - contracts-per-tx: direct control of contracts per transaction - gas-per-block: calculate contracts based on target gas The scenario now runs indefinitely until stopped, with cleaner and more focused configuration options.
- Add validation to ensure contract deployments don't exceed block gas limit - Check both gas-per-block and contracts-per-tx against block gas limit - Add clear error messages when gas limits are exceeded - Move validation to Run() function to access context
- Introduce multiple test cases for contract deployment: using contracts per block, gas per block, and handling invalid configurations. - Update config opts to replace `contracts-per-tx` with `contracts-per-block` for better clarity. - Add error handling for scenarios where neither gas per block nor contracts per block is set.
- Refactor gas fee parameters to align with EIP-1559 standards. - Initialize wallet pool in the contract deployment test.
- Introduced setup and teardown for contract deployment tests. - Updated scenario options to include a maximum transactions limit. St we can test for a single tx at a time and shortening testing time.
…to max (EIP170) - Introduced multiple dummy functions in the StateBloatToken contract to artificially inflate bytecode size. - Updated ABI and binary files to reflect changes in the contract structure.
- Updated the contract deployment scenario to log deployed contract addresses and gas used. - Added functionality to write deployed addresses to a JSON file for easier tracking. - Removed gas-per-block validation and adjusted wallet count logic. - Improved README with instructions for running against a local Anvil node without Go tests.
…ction tracking - Introduced a batch deployment strategy that calculates the number of contracts fitting within the block gas limit. - Added detailed tracking for deployed contracts, including gas used and bytecode size, with structured loggin. - Improved nonce management and transaction retry logic.
… logging - Added functionality to save a mapping of private keys to contract addresses in a deployments.json file after each contract deployment. - Refactored the final summary logging to focus on the deployments.json file, removing the previous detailed contract saving logic. - imporved logging to provide insights into the total number of deployers and contracts processed.
…mprove transaction handling - Removed unused imports and redundant fields. - Simplified transaction processing by releasing locks earlier. - Improved logging for transaction sending and contract deployment confirmation. - Cleaned up nonce management by directly fetching the nonce from the client.
…djustment - Added functionality to dynamically adjust transaction fees based on current network conditions. - Implemented retry logic for transaction sending with exponential backoff for base fee errors.
…s_limit - Introduced BlockDeploymentStats struct to track deployment statistics per block, including contract count, total gas used, and total bytecode size. - Implemented real-time block monitoring for logging deployment summaries. - Updated contract bytecode size calculations to reflect actual deployed bytecode. - Adjusted transaction processing intervals for improved efficiency.
Signed-off-by: CPerezz <37264926+CPerezz@users.noreply.github.com>
…based rate limiting - Set MaxPending default to 100 to fix scenario hanging at startup (was 0, preventing any transactions) - Remove hardcoded 12-second block time assumption that caused deployments only every 2 blocks - Implement proper block-based rate limiting that waits for actual block changes - Set rate limit to 2x expected throughput for better network utilization - Send transactions at expected throughput rate per block instead of arbitrary delays
…nt scenario - Replace incorrect import 'scenariotypes' with 'scenario' package - Update ScenarioDescriptor to use correct scenario.Descriptor type - Fix Init method signature to match scenario.Scenario interface - Update wallet private key access to use GetWallet().GetPrivateKey() - Remove unused Config() method not part of the interface - Fix walletPool references in Init method
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
♨️ Cold BALANCE + Warm EXTCODESIZE
Abuse warm cost forcing small BALANCE cold reads in distinct places and then call warm EXTCODESIZE to all the 24kb contracts: This should be the way to make a client read the most amount of data from DB possible.
Prerequisites
Depends on #41.
The
contract-deployscenario must be run prior to running this scenario in order to deploy as many 24kB contracts as possible. With 45M gas limit, we will touch roughly 10k contracts, so the network must already have that many contracts already.How it works
BALANCEthenEXTCODESIZEon a list of addresses.deployments.jsonfile which is populated with contract addresses deployed with thecontract-deployscenario.pokeBatchdeployments.jsonfile doesn't have that many addresses, then it will start from the beginning once the end is reached.Usage
Run