Step 6 / Ethereum & Shared Applications
When the program and the promise disagree.
The 2016 DAO failure shows why code, control, and human agreement are separate questions.
Imagine people put money into a shared fund. Members propose projects and vote. A program releases the money under agreed rules, rather than leaving every choice to one manager.
A real Ethereum project called The DAO tried a version of this in 2016. People contributed ETH and received tokens tied to participation in the fund.
The code had a serious flaw. After it was used to divert funds, people disagreed about what to do. The problem was no longer only a broken program. It was also a dispute about which shared rules to keep.
Paying before updating the balance.
Start with a small teaching example. A record says a user has one unit available to withdraw. The withdrawal program first sends the money. Only after sending does it lower the recorded balance.
That order creates a gap. The money has gone out, but the record still says the user has one unit. What if another request checks the balance during that gap?
The recipient can be another contract. When the withdrawal hands control to it, the recipient can call the withdrawal again before the first call finishes. The second call sees the old one-unit balance and may send money again.
Calling back into a program while an earlier call is still running is called reentrancy. Not every callback is unsafe. The danger here is that the second call can use a record that has not yet caught up with the first payment.
The real DAO exploit in June 2016 used a more complex route through the code. This model shows its important ordering problem; it is not a full replay of the attack. The code allowed a repeated action under conditions the designers did not intend.
A deliberately simplified callback model. The real DAO used more complex contract paths.
What the withdrawal model leaves out
The DAO’s affected process split funds into structures called child DAOs. It was not a normal cash-machine withdrawal. A waiting period limited immediate access to the diverted funds, leaving time for people to debate a response.
One defensive pattern is to check a request, update the record, and only then hand control to another contract. Programmers call it checks-effects-interactions.
Other protections can block unsafe repeated calls, and developers must also examine calls across different functions. Knowing the name of a protection is not enough. The actual contract still needs careful review.
People chose two different responses.
One group wanted the existing execution history to stand without a special recovery change. Their concern was about future rules: if this loss could be reversed by an exception, would influence decide which later losses were rescued?
Another group wanted an exceptional change to recover the affected funds. They saw the exploit as a grave failure in a young system and thought a coordinated response was justified.
On July 20, 2016, changed Ethereum rules moved affected funds to a recovery contract. Participants had to choose whether to use those rules.
Some continued the branch without that intervention. It became known as Ethereum Classic. The two branches share the earlier history, then follow different rules after the split.
One person did not remotely change every computer. Participants and services chose which software rules and chain to follow. Calling a branch “original” does not, by itself, decide which one someone should value or use.
Shared past, different adopted rules. Neither branch can force everyone to join it.
A program cannot settle every kind of permission.
The exploit is commonly called a hack even though it used actions the program could run. A program accepting an action does not show that people intended it, that it was harmless, or that the law allowed it.
A rulebook offers a useful comparison. The software defines which actions the computers accept. People still decide whether to keep those rules or adopt changed ones. This human process is called governance.
A major rule change can create a hard fork. People who adopt the change can follow a different chain from people who keep the older rules. The old software cannot automatically settle their disagreement for them.
The 2016 recovery does not promise that another loss will be rescued. Nor does this event prove that Bitcoin never changes rules or has never faced a protocol incident. Those claims need their own evidence.
For a user, check three things separately: the network’s rules, the app’s code, and the people who can change or intervene in either. An audit shows that someone reviewed code. It does not guarantee that the code is safe or that lost funds will be recovered.
The idea to keep
Many computers can faithfully run a flawed program. Fixing the code and deciding what to do about an earlier loss are different problems. The DAO history shows how disagreement over the response can split a shared history.