Formal Verification of Smart Contracts for EEG Data Governance: A Case Study with Slither and Formal Specification
This paper demonstrates that while automated tools like Slither and Mythril effectively detect known vulnerability patterns, formal specification is essential for verifying logical correctness and ensuring safety in blockchain-based EEG data governance, as it uniquely identified a seeded array out-of-bounds vulnerability that automated tools missed.
Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine you are building a high-tech digital vault to store the brainwave recordings (EEG) of people trying to communicate with computers using only their thoughts. This vault is run by a "smart contract"—a piece of code on a blockchain that acts like an automated, unchangeable robot guard. Its job is to make sure no one steals the data, no one corrupts the records, and the system doesn't crash.
This paper is a safety inspection report for that robot guard. The researchers asked a simple but scary question: "If we build a flaw into the robot's logic, will the automatic security scanners find it?"
Here is the breakdown of their experiment, explained simply:
1. The Setup: The "Trap"
The researchers built a digital vault using real brainwave data (from a dataset called Kara-One, which contains 406 records from 6 people). To test the security, they didn't just wait for hackers to find bugs; they deliberately planted a bug themselves.
Think of it like a game of "Where's Waldo," but they hid a specific trap:
- The Trap: The robot guard was told to check a list of brainwave records. However, the code forgot to ask, "Is the number you are checking actually inside the list?"
- The Result: If someone asked the robot to check record #11, but the list only had 10 records, the robot would try to look at a non-existent record. In the digital world, this is like trying to open a door that doesn't exist; it causes the whole system to panic and crash.
2. The Three Security Guards
The researchers hired three different types of security guards to find this planted trap:
- Guard A (Slither): The Speedy Inspector. This tool scans the code very fast (in about 2 seconds) looking for a "Wanted Poster" of known bad habits (like leaving a door unlocked or letting strangers in). It's great at spotting common mistakes.
- Guard B (Mythril): The Simulator. This tool pretends to be a hacker, running millions of different scenarios in a computer simulation to see if it can break the system. It's thorough but takes longer (about 45 seconds).
- Guard C (Formal Specification): The Logic Detective. This isn't a machine; it's a human expert who writes down the rules of the game before the code is even run. They ask: "If the input is 11, and the list size is 10, does the math hold up?"
3. The Big Discovery
Here is what happened when they tested the planted trap:
- The Speedy Inspector (Slither) and the Simulator (Mythril) both FAILED. They looked at the code, ran their tests, and said, "Everything looks fine!" They missed the trap completely. Why? Because the trap wasn't a "known bad habit" (like an unlocked door); it was a logic error. The code looked syntactically correct, but the reasoning was broken. These tools are like spell-checkers; they catch typos, but they can't tell you if your sentence makes logical sense.
- The Logic Detective (Formal Specification) SUCCEEDED. By writing down the rules, the human expert immediately saw the missing rule: "You must check if the number is smaller than the list size." They caught the bug instantly.
4. The Real-World Test
The researchers didn't just stop at the trap. They also tested the system with the real brainwave data (the Kara-One dataset).
- They successfully stored 406 records on the blockchain.
- They verified 8 different safety rules (like "no duplicate IDs" and "timestamps must go forward").
- Result: The system worked perfectly for the real data, but only because the Logic Detective had already fixed the hidden trap that the automatic tools missed.
5. The Main Lesson: The "Defense-in-Depth" Strategy
The paper concludes that you cannot rely on just one type of security guard. You need a team approach, which they call a Defense-in-Depth Strategy:
- The Logic Detective (Formal Specification): You must use this for the most critical parts of the system (like medical data). It proves the math is right. It's slow and requires human effort, but it's the only way to catch "logical" bugs.
- The Speedy Inspector (Slither): Use this every time you make a change to the code (like a daily check-up). It's fast and catches the easy, common mistakes.
- The Simulator (Mythril): Use this right before you launch the system to double-check for specific hacker tricks.
The Bottom Line
If you are building a system to protect sensitive medical data (like brain scans), automated tools are necessary, but they are not enough. They are like a metal detector at an airport; they find knives and guns (known threats), but they won't find a bomb made of logic that the rules didn't account for.
To keep your digital vault safe, you need to combine the speed of machines with the deep thinking of human logic. As the paper says, for safety-critical medical applications, formal verification isn't an optional extra; it's a requirement.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.