A few weeks ago, we wrote about our initial experimentation with Ethereum and our thoughts on what it means for founders using Blockchain technology. We had put together too much material for one blog post at that time, so we’d like to follow up now with some other findings along with more example contracts we’ve been experimenting with.
Developer Adoption of Ethereum
We mentioned in our post a few weeks ago that we’re excited by strong early adoption of Ethereum by developers, and we wanted to provide some data to quantify this adoption a bit further. We took a look at Github’s open data set to see how many repositories containing “Ethereum” or “Solidity” in their name have been created over time:
We see that developer interest in Ethereum is growing at a significant pace. However, there’s still plenty of room for growth left; Ethereum’s developer adoption when measured by total repositories created is still more than an order of magnitude less than Bitcoin’s:
More contract examples
We also experimented with encoding more complex logic into some contracts, mostly based on publicly available examples with some simple modification. As we went deeper into this, we found Solidity to be very easy to work with. The Solidity documentation is thorough and has some nice guides to get started. We decided to highlight two further contract examples that show some interesting areas of Ethereum’s functionality, and where there is still room for improvement.
(Note: To run these contracts, you need to set up Ethereum locally and familiarize yourself with the compilation toolchain and CLI tools as described here. This article does not cover how to run a contract or get set up with Ethereum.)
Coin flip
The first example, which is widely available, is a coin flipping contract; if you send it a payment, there is a 50% chance you will lose it and a 50% chance you get double the payment returned to you. We’ll also reuse the “mortal” contract base type from last time:
contract mortal {
/* Define variable owner of the type address*/
address owner; /* this function is executed at initialization and sets the owner of the contract */
function mortal() { owner = msg.sender; } /* Function to recover the funds on the contract */
function kill() { if (msg.sender == owner) suicide(owner); }
}contract coinflip is mortal {
function() {
var bet = msg.value;
var flip = block.timestamp; // semirandom (more below)
if (flip % 2 == 0)
return;
else
msg.sender.send(2 * bet);
}
}
Once the contract is running, you can place bets by sending it currency: `eth.sendTransaction({from: eth.accounts[0], to: CONTRACT_ADDRESS, value: web3.toWei(0.01, “ether”)}) `
Reading this contract, it is very easy to see how the odds work and that the outcomes are fair. If the contract does not have enough money in its balance to pay back a sender when they win, it will keep their money regardless of the outcome. An approach like this could be trivially extended to replicate many casino games like Roulette, Craps, or others based on probabilistically varying random outcomes. Anyone can play by sending a payment to the address for the contract (mine is at 0x121d30ecf48b11edd651249a3a110f48d42ba710).
(I sent 100 Finney to initially fund the contract, and bet 10 Finney afterward. Because I won my bet (the transaction time was odd), the overall balance of the contract is 90 instead of 100).
One important thing to note here is the use of the block timestamp as a source of randomness. This is not a truly random number; miners can directly control this in the blocks they mine, which could let them swing odds in their favor. This gets at a bigger issue in Ethereum; because contracts have to run consistently across all nodes, it isn’t possible for Ethereum to natively support secure random numbers. Many folks have proposed different solutions to this issue, such as creating other contracts that can provide randomness or having participants submit random numbers when placing bets (in competitive games like poker, if at least one participant does not collude with everyone else the outcome will still be fair). However, there is no foolproof way to defend from the case where 100% of participants collude. For games like poker this shouldn’t matter; if all participants are colluding they could only take money from each other. However, more complex products dependent on true randomness would be difficult to build with Ethereum.
Now that this contract is running, I’d also like to cover how a contract’s code can be retrieved and reviewed by using the contract’s address. If you open up the address your contract was mined at in Etherchain, you can see all the publicly available information about that contract on the blockchain. My coinflip contract was mined at 0x121d30ecf48b11edd651249a3a110f48d42ba710.
You can verify that my contract (or your own) runs the same code listed above by compiling the contract in the Solidity web compiler and comparing the bytecode pane on the right to the bytecode that lives on the blockchain (found in the “code” tab on Etherchain page for the contract). However, reverse engineering a contract’s code to understand what it’s doing is a quite bit more difficult; some experience with basic assembly code is necessary, along with good annotations of jump addresses in disassembled code. A whole separate blog post could be written covering that alone, so I won’t cover it here. The knowledge required to reverse engineer contracts means that only a small number of folks will be able to do that, so for products where transparency is particularly important it would be prudent to publish the Solidity code used to generate a contract somewhere.
Altcoins
Another compelling use case many have talked about using Ethereum for is alternative tokens and currencies. We recently released details on our own internal ledger, called Edgecoin, which very neatly fits this use case. We built Edgecoin by forking the Litecoin codebase with some simple modification, but would have strongly considered using Ethereum if Frontier was available at the time.
The contract below, lifted directly from the Solidity documentation, creates a basic currency with whole-number units and ledger of balances:
contract Coin {
// The keyword “public” makes those variables
// readable from outside.
address public minter;
mapping (address => uint) public balances; // Events allow light clients to react on
// changes efficiently.
event Sent(address from, address to, uint amount); // This is the constructor whose code is
// run only when the contract is created.
function Coin() {
minter = msg.sender;
}
function mint(address receiver, uint amount) {
if (msg.sender != minter) return;
balances[receiver] += amount;
} function send(address receiver, uint amount) {
if (balances[msg.sender] < amount) return;
balances[msg.sender] -= amount;
balances[receiver] += amount;
Sent(msg.sender, receiver, amount);
}
}
You should be able to get a basic idea of how this contract works by reading the code above. The Solidity documentation has a very thorough explanation of how it works, so I won’t replicate that here, but I would like to point out how easy it would be to extend this simple currency with nearly any functionality you might want. Starting out with Ethereum would give you the freedom to extend your currency in future.
Concluding thoughts
If you’re able to understand these contracts and follow the tutorial in our previous article, you should be well-prepared to dive deeper into Ethereum’s many other use cases. If you’re interested in exploring further, I would recommend starting with Ethereum’s excellent documentation and perhaps looking at how decentralized applications can be built on Ethereum using web technologies.
And as always, if you’re a founder at a company using blockchain technology, we’d love to chat!
