# Ethereum Fusaka Audit Competition ## Prize Distribution and Scoring - **Total Prize Pool:** \$2,000,000 - **Primary Prize Pool:** \$1,975,000 - The prize distribution has 4 possible triggers: - If one or more valid low severity findings are found, the total pot size is \$50,000. - If one or more valid medium severity findings are found, the total pot size is \$200,000. - If one or more valid high severity findings are found, the total pot size is \$500,000. - If one or more valid critical severity findings are found, the total pot size is \$2,000,000. - \$25,000 of the prize pot is reserved for informational severity findings: - Each informational severity finding is capped at \$1,000. - Any remaining funds from this reserved pool will be added back to the primary prize pool. ## Scoring Mechanism ### Early Report Multiplier - For the first week of the competition, valid reports are provided with a 2x multiplier. - For the second week of the competition, valid reports are provided with a 1.5x multiplier. ### Point Calculation - A critical severity finding is worth 30 points. - A high severity finding is worth 10 points. - A medium severity finding is worth 5 points. - A low severity finding is worth 2 points. ### Live Fixes & Duplication - Given the nature and importance of the Ethereum protocol, all of the fixes will be made to the respective public repositories during the competition as soon as a valid finding is reported. - Duplicate findings will be considered as long as they are reported before the fixes/commits are made public. Any edits after the fix is made public will not be considered while judging these findings. ## Severity Definitions & Judging - This competition is measuring the severity a vulnerability has on the entire Ethereum network. - [Here](#Clients) you can find data on the network impact each client has on the Ethereum network. - The Ethereum Foundation’s Protocol Security team will assist in judging the findings and have the final word on all judging related decisions. - A finding may, if deemed relevant by the judges, have its severity upgraded from the definitions below (for example Medium -> High). - Unrelated findings cannot be chained together and are treated individually. ### Critical Severity Vulnerabilities that allow an attacker to slash more than 50% of validators, exploit an EIP/specification or client bug to easily create an infinite amount of ETH which is finalized by the network, steal ETH from all EOAs, burn ETH from all EOAs, or take down the entire network by sending a single malicious on-chain transaction that ends up crashing all clients. ### High Severity Vulnerabilities that allow an attacker to slash more than 33% of validators, trivially cause network splits affecting more than 33% of the network, or being able to bring down more than 33% of the network by sending a single network packet or an on-chain transaction. ### Medium Severity Vulnerabilities that allow an attacker to slash more than 1% of validators, trivially cause network splits affecting more than 5% of the network, or being able to bring down more than 5% of the network by sending a single network packet or an on-chain transaction. ### Low Severity Vulnerabilities that allow an attacker to slash more than 0.01% of validators, trivially cause network splits affecting at least 0.01% of the network, or being able to bring down more than 0.01% of the network by sending a single network packet or an on-chain transaction. ### Informational Severity Observations or recommendations regarding code quality, maintainability, or system architecture that do not present a direct security risk. These findings aim to provide insights for potential improvements rather than addressing an immediate vulnerability. Only applicable if the team decides to implement a change based on the report. ## Documentation - The [Fusaka Auditor Guide](https://notes.ethereum.org/@fredrik/fusaka-auditor-guide) contains relevant resources for the competition. ## Scope Only Fusaka specific code is in scope of this competition. Any vulnerabilities that are not specifically related to the upgrade are out of scope of the competition and should instead be submitted via the [Ethereum Foundation's Bug Bounty Program](https://bounty.ethereum.org). Items scheduled for future upgrades are not in scope. In the case where there is already an EIP that would mitigate an attack, the issue is a "known issue" and is not eligible. ### Specifications - [Consensus Specifications](https://github.com/ethereum/consensus-specs/tree/master/specs/fulu) - [Execution Specifications](https://github.com/ethereum/execution-specs/tree/forks/osaka/src/ethereum/osaka) ### EIPs - [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7594.md) - [EIP-7823: Set upper bounds for MODEXP](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7823.md) - [EIP-7825: Transaction Gas Limit Cap](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7825.md) - [EIP-7883: ModExp Gas Cost Increase](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7883.md) - [EIP-7892: Blob Parameter Only Hardforks](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7892.md) - [EIP-7917: Deterministic proposer lookahead](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7917.md) - [EIP-7918: Blob base fee bounded by execution cost](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7918.md) - [EIP-7934: RLP Execution Block Size Limit](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7934.md) - [EIP-7935: Set default gas limit to XX0M](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7935.md) - [EIP-7939: Count leading zeros (CLZ) opcode](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7939.md) - [EIP-7951: Precompile for secp256r1 Curve Support](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7951.md) - [EIP-7642: eth/69 - Drop pre-merge fields](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7642.md) - [EIP-7910: eth_config JSON-RPC Method](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7910.md) ### Clients #### Execution Clients | Client | Percentage | |:--------------------------------------------------------- | ----------:| | [Go Ethereum](https://github.com/ethereum/go-ethereum) | 41% | | [Nethermind](https://github.com/NethermindEth/nethermind) | 38% | | [Besu](https://github.com/hyperledger/besu) | 16% | | [Erigon](https://github.com/erigontech/erigon) | 3% | | [Reth](https://github.com/paradigmxyz/reth) | 2% | *Note*: Data provided by [clientdiversity.org](https://clientdiversity.org/). #### Consensus Clients | Client | Percentage | |:---------------------------------------------------- | ----------:| | [Lighthouse](https://github.com/sigp/lighthouse) | 42% | | [Prysm](https://github.com/prysmaticlabs/prysm) | 31% | | [Teku](https://github.com/Consensys/teku) | 21% | | [Nimbus](https://github.com/status-im/nimbus-eth2) | 6% | | [Lodestar](https://github.com/chainsafe/lodestar) | 1% | | [Grandine](https://github.com/grandinetech/grandine) | 0.02% | *Note*: Data provided by [Bloxroute](https://bloxroute.com) & [ultra sound relay](https://relay.ultrasound.money). Validator distributions were calculated by analyzing user-agent strings provided in relay requests. Results from relays are averaged, excluding unknown user-agent strings and [Vouch](https://www.attestant.io/posts/introducing-vouch/) validators. <!-- from user-agent strings in `SubmitBlindedBlock` requests over three days (20k slots). --> ### Build Instructions and POC - All required build instructions are documented within their respective repositories. - Mandatory POC rule applies for this competition. All submissions must have a POC at the time of submission. ### Out of scope - Typographical errors. - Non-upgrade specific vulnerabilities. - High-effort (sustained, CPU or bandwidth intensive) single-peer DoS attacks. - All TODO items referenced in any of the codebases are considered known issues. - Any issue related to an open issue or PR in the respective repository. ## Contact Us For any issues or concerns regarding this competition, please reach out to the Sherlock core team through the Sherlock Discord.