This document contains a list of code Hotspots, these are places where I expect vulnerabilities to be found mostly focused around null pointer exceptions, parsing issues, or other vulnerabilities that focus on exploiting the logic and not the fundamental design of Gravity Bridge
The Orchestrator parses and relays events from Ethereum to the oracle. Parsing those events is handled by a parser in ethereum_events.rs. While this parser has some unit tests it is not fuzz tested. Any possibility of incorrect parsing here may result in an attack where deposits are faked, or less severely, the bridge is halted due to Oracle disagreements.
The attestation system in attestation.go and attestation_handler.go manages oracle events, by aggregating a number of claims made by validators into a single 'attestation' covering a given event. This, as well as the attestation_handler logic that covers all possible Oracle events are good places to look for logic flaws.
Gravity bridge performs many tasks at the end of each block. The EndBlocker contains the code for each of those tasks. Including slashing, pruning, and generating new validator set snapshots for Ethereum.
The valset creation spec is a good place to start for background here.
The PowerDiff function determines the difference in normalized voting power between two validator set snapshots. Logic errors in this function could result in too many validator set updates being created, or too few.
The batch creation spec is a good place to start for background here.
RemoveFromOutgoingPoolAndRefund allows a user to refund any Gravity bridge withdraw that has been created, but not yet removed from the transaction pool to place into a batch. It is totally safe to issue this refund as before a batch has been formed there's no possible way their transaction could have executed on Ethereum. That being said allowing transactions that are into batches to call this function would result in a double spend.
The batch creation spec is a good place to start for background here.
BuildOutgoingTXBatch builds transaction batches out of the on-chain transaction pool of withdraws to Ethereum. Transactions must successfully be removed from the index, included only once, and returned properly in OutgoingTxBatchExecuted
The batch creation spec is a good place to start for background here.
OutgoingTxBatchExecuted returns user transactions to the pool once the attestation_handler has processed an oracle event that would make it impossible for that batch to be executed.