Published
- 8 min read
Episode 5: Smart Contract Verification
Living in a Zero-Trust Society: My Strange Daily Life Being Overwhelmed by a WEB3.0 Fundamentalist Engineer / Can’t Use DApps Without Running a Full Node!
Note
This story is written with the assistance of generative AI for the purpose of making the Web3.0 world enjoyable to learn about. While we pay careful attention to the accuracy of technical information, we cannot guarantee that all content is completely accurate. Please use this as a supplementary learning tool and enjoy it with a relaxed mindset.
Characters
- I: A novice developer who recently transitioned from being a DTP operator to an engineer
- Mr. D: A Web3.0 fundamentalist in his mid-40s with extreme vigilance
Episode 5: “Smart Contract Verification”
Several days had passed since I finished setting up the hardware wallet and visited Mr. D’s home—his “sanctuary.” Following his instruction, “Never store your seed phrase digitally,” I wrote it down by hand, but even transcribing twelve English words without error was nerve‑wracking. In my DTP days, my job was to catch typos in printed material. Now, a single mistake could mean losing my assets. The difference in tension made me feel the harsh reality of the Web3.0 world.
I was slowly getting used to Web3.0, while also feeling overwhelmed by its depth and dangers. Mr. D’s extreme vigilance sometimes seemed laughable, but there was always a certain logic to his words. Then, another encrypted message arrived.
I’ll teach you smart‑contract verification.
Tomorrow, 1 PM at a certain cafe in Akihabara.
Same coordinates as last time.
Choose any contract on Etherscan in advance.
Don’t be reassured by the “Verified” badge.
I immediately opened my laptop and browsed smart contracts of popular DeFi projects on Etherscan. One liquidity‑pool contract for a decentralized exchange (DEX) caught my eye. It had many users and a good reputation on Twitter. It also had a “Verified” badge. Would this satisfy Mr. D? His words—“Don’t be reassured”—echoed in my mind, and an inexplicable unease spread in my chest.
The next day, I arrived at the cafe at the appointed time. As usual, the interior was dim. Mr. D sat at a table in the back with his laptop and a homemade device. Beside him was an unfamiliar black box. I thought it was his usual mobile router, but on closer look, it had a small antenna. Suspicious—too suspicious.
“You’re not late. Good.”
He checked his watch and nodded silently. I sat down and gave him the address of the contract I’d chosen. He glanced at it and snorted.
“A popular DEX? The choice of a fool. ‘It’s safe because everyone uses it’—that’s centralized blind faith.”
He took a sip of coffee and looked at me intently.
“Smart contracts are the heart of Web3.0. But there’s no guarantee they’ll behave correctly. The Etherscan ‘Verified’ badge is just decoration. It only means someone uploaded source code. Unless you confirm bytecode matches and ensure there’s no malicious code—by your own eyes—it’s meaningless.”
I started to object, “But if it’s open source, the community checks—” He cut me off coldly.
“Trust the community? Look at history: the 2008 financial crisis, Ponzi schemes, countless scams… Just because the masses believe it doesn’t make it true. Only code is fact.”
He opened his laptop and pulled up the contract’s Etherscan page.
“We’ll verify this contract line by line. You’re participating.”
Mr. D first downloaded the source code locally. Then he launched a clean environment and began installing the Solidity compiler (solc).
“Downloading prebuilt binaries is out of the question. Build from source. Where’s your guarantee no one tampered with it?”
He matched the compiler version to the contract’s pragma (0.8.10) and compiled the code. Meanwhile, I was about to take a bite of cake.
“Stop.” Mr. D suddenly raised his voice. “Did you analyze that cake’s ingredients before eating it?”
“Huh? I… just ordered it.”
“I’m joking,” he said, cracking a rare smile. “But you should be more cautious with digital assets than with that cake.”
He returned to the screen and compared the generated bytecode to what Etherscan showed.
“It matches. But don’t relax yet. Next, we read the internals.”
He scrolled through the Solidity code on screen and started quizzing me.
“Quiz: What’s a reentrancy attack?”
I rummaged through my memory. “Uh… when a function is called again recursively and funds can be withdrawn multiple times?”
“Mostly correct,” Mr. D allowed. A week ago, I couldn’t have answered. Thanks to his strict guidance, I felt I was finally beginning to understand this complex world—if only a little.
Mr. D pointed to a transfer‑related section. “They’re using call here. When calling external contracts, there’s a reentrancy risk. Check that a nonReentrant modifier is used.”
Following the code, I saw OpenZeppelin’s ReentrancyGuard imported and nonReentrant applied to the relevant function. Mr. D nodded in satisfaction, then quickly moved on.
“Next: overflow safeguards? Access control? Functions with owner privileges?”
His gaze fixed on functions with the onlyOwner modifier.
“This function lets the owner withdraw all funds. It says ‘for emergencies,’ but who defines an emergency? If the owner turns malicious, it’s over.”
I pushed back slightly. “But the project has a good reputation, and they say it was audited.”
“Reputation?” Mr. D sounded exasperated. “You trust something that vague? Audits are done by humans. Humans make mistakes—and some can be bought. Code is fact. Reputation is illusion.”
He gave me an assignment.
“Assume you deposit 10 ETH into this contract. Enumerate the risks. You have 30 minutes.”
Nervously, I started reading the code. With Mr. D’s guidance, I spotted several questionable points:
– withdraw gas cost is abnormally high, hinting at a potential intentional DoS vector.
– External library versions are old; known overflow vulnerabilities might not be patched.
– The owner uses an upgradeable proxy pattern and can change logic at any time.
Thirty minutes later, I reported back. “I’m concerned about the high gas usage and the proxy risk. Also, the old libraries…”
Mr. D actually smiled. “Not bad. But still naive. You’re underestimating how dangerous proxy patterns are. If the owner rewrites the logic, your 10 ETH can vanish in an instant.”
At that moment, an encrypted notification pinged on Mr. D’s phone. He glanced at it and his expression hardened.
“This contract… Apparently it was hacked this morning. The owner switched to a malicious implementation through the proxy and drained the funds.”
I nearly cried out but clapped a hand over my mouth. People at the next table glanced over suspiciously. With Mr. D’s black box and antenna‑equipped device, we already looked dubious. Even the staff were keeping an eye on us.
“Keep your voice down,” he murmured. “We are mere technicians. Don’t draw suspicion.”
I took a deep breath and calmed myself. “The contract I chose…”
“Coincidence,” he said coolly. “But this is reality. If you don’t verify, your assets can disappear in an instant. Consider yourself lucky there was no damage this time.”
A chill ran down my spine. For the first time, Mr. D’s extreme vigilance took on a painfully real meaning.
Draining his coffee, Mr. D delivered a final lesson.
“Smart contracts aren’t magic. They’re code written by humans. There are mistakes—and malice. Don’t trust the Etherscan ‘Verified’ badge or a project’s marketing. Only code you’ve verified with your own eyes is truth.”
He closed his laptop and added:
“You’re still a beginner. But don’t forget today. In the Web3.0 world, no one saves you. You must protect yourself.”
I gathered my courage to ask, “Mr. D… have you ever been a victim yourself?”
For a moment, his expression clouded. “That… is a story for another time.”
Changing the subject, he handed me a USB drive.
“Next, I’ll teach you about DeFi traps. This contains materials. Brace yourself.”
I accepted the USB and nodded. “Actually… I’ve been curious about a DeFi protocol advertising 30% APY…”
Mr. D’s eyes sharpened. “Thirty percent? And you think that comes without risk? Read the report on that so‑called 30% protocol inside the USB. You’ll see the dangers.”
Leaving those words behind, he exited the shop and disappeared into Akihabara’s crowds.
That night at home, I reopened the contract’s code. With the book “Fundamentals of Cryptography” I’d received from Mr. D, I resolved to relearn Solidity’s basics. The Etherscan contract page glowed on my screen. What had looked “safe enough” now seemed like an unknowable monster.
If I had deposited funds this morning… Just imagining it made my spine freeze. I felt ashamed for mocking Mr. D’s extreme caution. His words echoed in my head: “Only code is fact.”
I placed my hands on the keyboard—to take the first step toward verification. Back in my DTP days, I hunted typos in printed works. Now, I must train my eyes to spot the blind spots in code. A new craft to protect my life.
Tech Tips
Reentrancy Attack
An attack where an external contract calls back into the caller before state is safely updated, causing unintended behavior. For example, if a withdrawal function doesn’t update state before sending ETH, an attacker can repeatedly drain funds. Common mitigations include OpenZeppelin’s nonReentrant modifier and careful gas patterns.
Proxy Pattern
A design that enables upgradeable logic behind a stable proxy. It increases flexibility but introduces risks: if the owner turns malicious, they can switch to harmful logic and seize funds.
Integer Overflow
In older Solidity (< 0.8.0), arithmetic could overflow (e.g., 255 + 1 wrapping to 0). Modern compilers add checked arithmetic, and SafeMath or built‑ins mitigate this risk.
Next Episode Preview: “Episode 6: The Traps of DeFi”
Mr. D’s next lesson reveals hidden risks in DeFi. “Make money just by depositing into a liquidity pool? There’s no such sweet deal,” he warns. What shadows will he expose…?
End of Episode 5