The Ethereum fork will take place in a matter of days. I recently skimmed through it, so here are the kinds of issues that I worry about with regard to the hard fork to come, as well as half-baked ideas related to the decentralized administration of the hard fork. This is a brain dump of sorts, so treat it as such. Not every potential problem turns into a real problem. I will scientifically lay everything I worry about on the table. If we can methodically prove to ourselves that they are not worth worrying about, then we are done. However, if you have a large open ETH position and cannot handle dispassionate discussion about possible problems, it's best to look elsewhere.

Ok, so let's delve into possible problems:

At the very highest level, the hard fork comprises the hard fork policy (which determines how people get remunerated), the client code (which implements the ethereum protocol in multiple different languages for different clients), and the refund contract (which takes over the ether balance of the old DAO, but leaves the old DAO intact).

The community itself determined the hard fork policy via a discussion process. I will take this as a given.

The intent of the hard fork policy sounds quite reasonable to me. I will regard all discussion of mechanisms in a policy document as suggestions -- the masses care about the outcome, not the means.

The hard fork policy leaves unaddressed the issue of what happens to the coins that are lost, abandoned or left unallocated in the trustee multisig contract. Laying out the charter of the trustees, so the expectations from them are specified down to every wei, is necessary.

The client code changes (geth and parity) seem very straightforward. This is one of the big advantages of a clean hard fork. The core implementation is easy to check, and the geth code I skimmed seems to have the right general shape.

That brings us to the new refund contract. It has three components that I want to treat separately: the refund engine, the token mechanism, and the enumeration and classification of affected child DAOs.

I have not looked into the code for enumerating and classifying the child DAOs at all. This work involves a modest amount of blockchain forensics, and some manual verification of tools for parsing the ethereum blockchain. I assume, based on second-hand reports of people who have checked its output, that this code works as intended.

The refund engine, in isolation from the token mechanism used to keep track of account balances, looks generally OK to me, but it is not written in a manner that I would consider best practice or defense in depth.

Here's the current code:

// Deployed on mainnet at 0xbf4ed7b27f1d666546e30d74d50d173d20bca754

contract DAO {

function balanceOf(address addr) returns (uint);

function transferFrom(address from, address to, uint balance) returns (bool);

uint public totalSupply;

}

contract WithdrawDAO {

DAO constant public mainDAO = DAO(0xbb9bc244d798123fde783fcc1c72d3bb8c189413);

address public trustee = 0xda4a4626d3e16e094de3225a751aab7128e96526;

function withdraw(){

uint balance = mainDAO.balanceOf(msg.sender);

if (!mainDAO.transferFrom(msg.sender, this, balance) || !msg.sender.send(balance))

throw;

}

function trusteeWithdraw() {

trustee.send((this.balance + mainDAO.balanceOf(this)) - mainDAO.totalSupply());

}

}

In particular, from least to worst:

I don't understand why the trustee address is not marked "constant". I realize that there is no code that can change the trustee address. But then why is the DAO address marked constant? Inconsistencies like this erode trust and telegraph that we have learned nothing from the DAO disaster. Document all intent and assumptions in the code, that's the right place to do it.

The trusteeWithdraw() function seems to be intended solely for the trustee multisig's use. So, it should have a function modifier that rejects calls unless they come from the trustee address. The lack of such modifiers is a cavalier coding practice that reminded me of the time when I sold my motorbike and bought a used car in grad school. I noticed that the air intake for the cabin was right behind the engine block, in a spot where any oil leak would turn into noxious fumes. I thought "wow, these German engineers are so good, so amazingly confident, that they purposefully put the intake in that spot, to show the world how convinced they are that the gaskets will never leak." So it was kind of funny (not) when my engine leaked oil and I ended up breathing noxious fumes until I had to give the car to a charity for the blind. Long story short, there is no room for this kind of cavalier behavior in a post-DAO world. Put the modifier there already.

The critical weakness of the refund engine is its dependence on the inviolability of the DAO's token management, discussed next.

The current implementation relies on the integrity of the old DAO's token management. I find this quite dangerous. Philosophically, if we were unrolling the hard fork solely because "a hacker took advantage of a small reentrancy bug," then it would make sense to rely on the old token accounting -- after all, the old DAO would be perfectly fine, save for one minor glitch, and we'd be fixing just that one minor glitch. But that's not true and that's not why I advocated a hard fork. In fact, this kind of case-by-case, narrow thinking is precisely what got us into trouble. I believe the hard fork is called for because the old DAO is bug-ridden at multiple levels. Consequently, my starting assumption, that we treat the entirety of the old DAO as untrustworthy, motivates a different strategy.

As a result, if I were devising the hard fork, I would freeze the DAO token balances at a certain block, and then build a list of refundable addresses based on the frozen balances. DAO tokens traded after the freeze point would have 0 redeemable value from the refund contract.

I made this suggestion to the folks working on the hard fork, but they favored the current approach instead. To be fair, the current approach is simple, requires no trust in a party who will perform the enumeration (it requires trust in the DAO token code instead, and a trustee for enumerating childDAOs, a simpler task), and permits trading of tokens until the final refund. But it is open to attacks that can manufacture DAO tokens. My suggestion does not rely on the old DAO at all, but its simplest implementation would probably rely on a trustee who will perform the enumeration.

I did not fight hard to get the hard fork folks adopt my approach, for three reasons: first, I do not know of an exploit that can create tokens in the main DAO and exploit this refund contract. Second, the practical form of my suggestion ends up relying on a trusted party to compute the balances -- and it is difficult to find such a party that will take on the responsibility for no compensation. Finally, if a high-profile Ethereum Dapp using basic patterns is unable to handle simple token creation and transfer, then a wakeup call is necessary anyway -- a failed hard fork would be quite dire, but survivable, maybe. Bonus reason: I do this stuff just because it's fun, in between real research. I said it once to the right people -- repeating it would stop being fun.

If we are going to instead push ahead with the current fork strategy that relies on The DAO's accounting of its tokens, it would be prudent to construct a proof that the token management of the current DAO is correct, and cannot be abused to issue spurious tokens.

There is, approximately, $115M at stake. This immediately creates a lucrative bug bounty, albeit for illegal gains: everyone has an interest in looking carefully at this code to find its flaws. Yet no one has any incentive to reveal what they find. There is no one who can offer $115M or even $11.5M to a hacker in monetary compensation. This should be quite worrying -- a bright hacker who identifies a flaw might choose to exercise the flaw and collect the cash, instead of letting people know. (Incidentally, this is true for Bitcoin as well. A coin without a substantial bug bounty is a vulnerable coin).

Regardless, it is possible to compete with even $115M in monetary compensation: people are generally nice and they value intangible assets much more than money. In particular, if the community commits to granting "uber-hero" status to anyone who identifies a bug in the hard fork, it might entice an idealistic person to avoid the hassle of laundering illegal gains. For instance, part of the uber-hero treatment would be an invite to Devcon2 to give a keynote. The nice thing about this is that it's almost free, and it also helps differentiate the ether community from others whose first reaction to any bug report is to deny and attack the researchers. And it's the only way of competing with a large pot of coins.

If the trustees do their jobs correctly, any bugs that affect the token accounting in the child DAOs ought to be inconsequential.

How likely is it that there are attacks against the token accounting mechanism in the main DAO? Not likely. But it's not impossible unless there is an impossibility proof. Since DAO tokens are being traded right now, the attack could already have surfaced. But if I were the attacker, I'd wait to unleash the attack when the tokens are redeemable for ether, so I can extract much more cash, instead of tanking the thin DAO token market. In any case, an impossibility proof is what's called for here.

There may be bytecode/EVM-level attacks that might enable one to raid the refund contract. It seems unlikely that there exist such bugs, but there could well be some. Low level bugs would affect much more than the refund contract. But because of the implicit bug bounty in the refund contract, we might see such a bug surface now, through this hard fork episode.

I have written about replay attacks. Following a fork, one can interact with a smart contract on one chain, and replay it on the other chain. For instance, I can play tic-tac-toe with you to a draw on one chain, replay your moves on the other chain, change my countermoves, and win. But these attacks extract only as much money as there exists on the minority chain, and help make it die out faster. In general, there may be vulnerable contracts out there that manage pre-fork money. Talk to an expert if you're writing or you have written a contract that handles large amounts of cash on how to make it secure against replay attacks.

The incentive structures are lined up for people to coalesce onto the new chain, with the economic majority, fairly quickly. If all players were maximizing ether value, we'd see the minority chain wither and die quickly. However, there are a large number of people who see Ethereum as a threat to other cryptocurrencies (for entirely flawed reasons) and want it to fail. Further, some people specifically want Ethereum's hard fork to fail. These folks might well subsidize mining on the minority fork for some time. If this were to happen, sit tight and do not panic because the predictions, made for rational parties, do not hold in the presence of economically irrational players subsidized exogeneously. Use the majority chain and ignore the minority chain's hashpower until the subsidizing party gives up or runs out of cash. Some people, especially in Bitcoin-land, play up the importance of mining power, mostly because they are thoroughly confused, as seen here and also here. The moment when there are no exchanges on the minority chain, it becomes a harmless testnet. Remember that miners are worthless without economic power, which comes from exchanges.

This is a comprehensive list of my concerns about the hard fork at the moment. Remember that not every concern points out a genuine problem: distributed systems researchers are, by nature, a paranoid bunch. As long as every concern is systematically evaluated, we will be able to ferret out all bugs and ensure an orderly fork. I expect most, if not all, of my concerns to be misplaced, and I would indeed be delighted if they were.

I hope this glimpse into how a distributed systems researcher thinks about issues is received in the spirit as intended. Note that I did something I don't often do in this post: I literally shared my fears, uncertainties and doubts. But uncertainty is precisely what drives good engineering, good system design and bug finding. And if the readers of this blog know one thing, it's this: distributed systems work only to the extent that they have a principled reason, a proof, for why they should do the things they should do. What they do on a sunny day, with the wind on their back and with nary an attacker in sight, is immaterial. I do not currently have a strong reason, a proof, to believe that this hard fork code would withstand an attacker as is, but I hope we can arrive at one before the fork.

At a higher level, I am convinced that the hard fork is the simplest path forward, that the risks are manageable, and, above all, I have full faith in the Ethereum community's ability to engage in civil, technical discussions to address potential problems. Ultimately, it is the communities that provide value to ink on paper or numbers on a ledger.

Follow Up

I circulated the draft of this post among some friends and received some feedback, for which I'm grateful.

Christoph Jentsch provided insightful commentary on a draft of this post, and pointed out the list of functions touched by the refund contract. Note, however, that even though the refund contract invokes only a subset of The DAO, it is implicitly reliant, through data-dependencies, on the correctness of the rest of the functions in The DAO that manipulate the data fields used in those functions. So the trusted computing base of the refund contract is substantially larger than the subset that Christoph has identified.

To my delight, Vitalik responded with a well-thought-out proof sketch for why the DAO token creation cannot be abused to generate fake DAO tokens. I'll let him chime in below with his proof sketch, if he so chooses. That responds to my call for a proof above. I still prefer my enumerated address technique, but I feel much better about the impending hard fork.

Coincidentally, a hard fork bug bounty was introduced today. And Christoph has pointed out that there is already a more general bug bounty in place. These are great developments.

http://hackingdistributed.com/egs/