One of the design challenges we faced when deciding to create Augur was, which tools should we utilize to build it?
Many programmers like to start from scratch. To do this would entail forking Bitcoin, modifying it to include all the transactions required for Augur, and then merge mining it with Bitcoin. Jack and I built a project called Sidecoin back in September and October; it basically allowed you to bootstrap a new block chain by copying Bitcoin’s unspent transactions (read: balances) for each address and putting them in the first block of the new block chain. This seems like an easy task from a programming standpoint, all you have to do is write a function to allow people to cryptographically prove that they own the Bitcoin corresponding to a certain address and then allow them to claim their Bitcoin. You also need to store this list of unspent transactions in the first block (there are more advanced ways of doing this using SPV proofs, but we stuck to the simplest route first for a proof of concept).
It turns out that Bitcoin’s codebase isn’t really that well written: if you modify one thing, it breaks quite a few others. Generally, a well abstracted codebase would allow you to modify something without breaking a bunch of other things; instead, Bitcoin is tightly coupled. What should have been a simple weekend project ended up taking a couple months to get everything working (including tests passing with flying colors). Building from scratch tends to not work out very well, especially when there are better alternatives, a great example of this is Netscape (http://www.joelonsoftware.com/articles/fog0000000069.html).
Another possible way to implement Augur would be to write a Serpent (one of Ethereum’s programming languages) contract on Counterparty. There are a few problems with building on Counterparty though. They don’t have any definite plans to support sidechains (which means we couldn’t sidechain Bitcoin over to buy and sell event outcomes in our platform). However, another possibility would be to use the Counterparty “Bitcoin” asset, but that’s been removed due to regulatory concerns. A final option is to issue a Counterparty asset from within our contract and then allow users to buy it with a fixed exchange rate of one Satoshi on Bitcoin to one Satoshi on our platform, except Counterparty doesn’t allow that. I don’t have anything against Counterparty (in fact, I own some), but these limitations combined with poor storage capabilities on their network leave us with one more contender.
I didn’t really like Ethereum at first. It seemed convoluted and too complicated. They had over three clients in different programming languages. There wasn’t any way to use Bitcoin on the platform, plus it had an inflationary currency (not good if you’re used to holding something like say Bitcoin). As I read more into it, I realized I was wrong; having three clients is a good idea in my opinion because it limits bugs. Bitcoin’s protocol has many bugs that likely wouldn’t exist if people had to communicate across different clients and languages from day one; they would have been discovered much quicker. I asked Vitalik whether Ethereum had any intentions of implementing sidechains when they come out, and he assured me as soon as they were ready he’d put a team on it. There’s also the ability to do decentralized exchanges using smart contracts, and the inflationary aspect is good because Ethereum isn’t a competitor to Bitcoin. Ether isn’t supposed to be used like Bitcoin: it’s a method of paying for computations on the Ethereum network. If it’s inflationary, then computations will hopefully stay cheap (which is good for us)!
So, I realized we couldn’t just write off Ethereum, as I looked into it deeper I discovered quite a few more gems that make it the right choice to utilize to build Augur. With Ethereum, we don’t have to deal with low-level networking or security, that all falls under the Ethereum project’s purview (which has many more resources than we do at the moment)! Of course, we still have security concerns within our contracts and our protocol, but it severely limits the scope. It’s also much simpler than say building on Bitcoin core; we can write smart contracts in a programming language like Serpent or Solidity and compile down to EVM opcodes (which are also much more robust than Bitcoin’s opcodes). Finally, building on Ethereum allows extremely quick iterations: instead of taking weeks or months to make small changes we can make and test them within days. This means we can build our software faster and improve upon it quicker than any other method, which after enough iterations, allows us to build the best possible platform for prediction markets.
