Fraud Detection
Help secure Habtor by checking for Operator Fraud
Checking Habtor Mainnet for Fraud
Fraud Detector
The Fraud-Detector repo (habtor_community/fraud-detector) contains docker scripts and python source code for running a Verifier, a DTL (data transport layer), and a fraud-detector service.
0. Concepts
The Fraud-Detector repo allows you to:
Run your own Habtor L2 Geth on your computer. In this case, geth will run in its
Verifiermode. InVerifiermode, geth will sync from L1 and use the transaction data from the L1 contracts to compute what the state roots should be, if the operator is honest.A separate service, the fraud-detector, can then be used to discover potential fraud. Briefly, the fraud detection process consists of requesting a state root from Habtor Mainnet and requesting a state root from your Verifier. If those state roots match, then, the operator has been honest. If they do not match, then, that might be due to fraud, or, could also indicate indexing or timestamp errors, or chain configuration errors.
The central idea is that if two (or more) systems look at the same transactions, then they should all generate the same state roots. If they don't, then there is a problem somewhere. Fundamentally, the security of rollups has little to do with math or cryptography - rather, security arises from the operator publicly depositing transactions and their corresponding state roots, and then, having many independent nodes check those data for possible discrepancies.
1. Errors and State Root Mismatches in the Habtor Mainnet
For the first 10 blocks, the chainID was set (incorrectly) to 89 rather than 899. Therefore, the EIP155 signatures fail for those blocks, and the Verifier cannot sync those blocks. This has been addressed by setting the L1_MAINNET_DEPLOYMENT_BLOCK to 10 blocks past the zero block.
There is one state root mismatch at L2 block 155, arising from a two second discrepancy in a timestamp, that was ultimately caused by a too-small setting for the number of confirmations (DATA_TRANSPORT_LAYER__CONFIRMATIONS). This value was therefore increased to 4. The 2 second block 155 timestamp discrepancy has been addressed in a custom docker image (
omgx/data-transport-layer:rc1.0-surgery).
2. What do when you discover a state root mismatch
Congratulations! The security of the L2 depends on community monitoring of the operator's actions. If you have discovered a state root mismatch, please file a GitHub issue (https://github.com/habtorcom/optimism-v2/issues). We should have a good response / clarification for you quickly. In the future, with the Habtor governance token, additional mechanisms will be released to incentivize and reward community monitoring of the Habtor Network.
3. Running the Fraud Detector, the Verifier, and the Data Transport Layer (DTL)
Requirements: you will need a command line and Docker. Before filing GitHub issues, please make sure Docker is installed and running.
Open a terminal window. First, clone the project and install needed dependencies:
Then, add your Infura key to habtor_community/fraud-detector/deployments/mainnet/env. If you do not have an Infura key, you can obtain one for free from Infura.
Next, navigate to habtor_community/fraud-detector and build the needed Docker images:
You may need to create the default docker network:
Finally, spin up the Fraud Detector and other neccessary services (the Verifier L2 Geth and the Data Transport Layer)
The system will start and the Verifier L2 Geth will begin to sync with the Habtor L2 via data it deposited into the core Habtor contracts on BSC Mainnet. The sync process can take 1/2 hour to complete. During the sync process, you will see the Verifier gradually catch up with the Habtor L2:
When the Verifier L2 Geth has caught up, you will see it follow along with the Habtor L2 Geth:
At that point, the Fraud Detector can compare the public state roots (deposited into Ethereum Mainnet by Habtor Network) with the state roots that you have computed:
If all three of these roots agree, Habtor Mainnet has been operating truthfully up to that block. If the Fraud-Detector finds a mismatch, it will log that problem for you. Once the Fraud-Detector has checked all the historical state roots, it will wait for new blocks to be written by Habtor Mainnet and check those:
Last updated