Recently, we had the privilege of hosting Dave Hoover (Red Squirrel) for our latest 8th Light University Meetup event. The purpose of Dave’s talk was to provide an introduction to smart contract development for developers coming from a more conventional background. He went over how developing against a blockchain differs from developing against a traditional database, and suggested some of the ways that Ethereum in particular opens up novel opportunities and challenges for folks looking to build the next great (d)app. It was an awesome talk, and we were happy to have so many folks come out and join us. For those who couldn’t make it, here’s a quick recap of some of the topics Dave covered.
Why Bother?
One question that immediately presents itself with any new technology is: Should I really learn this? With supposedly novel tools emerging seemingly everyday, it’s easy to get fatigued if you’re constantly trying to keep up with the latest new thing. Add to that the wealth of underappreciated features built into older and arguably more reliable systems, and it can become easy to dismiss whatever’s catching the headlines of today as a fad that will pass.
Dave made a strong case that it wouldn’t be wise to dismiss blockchain technologies along those lines. Drawing an analogy to the popularity of mobile phones outside of the United States in the 1990s, he proposed that blockchain technologies might first make their utility obvious in the places where existing infrastructure is most poor—since those who already have access to relatively reliable technology have little reason to switch to something new. Early adopters might come from places where existing payments infrastructure is most cumbersome and least reliable, but if it works then the rest of the world will have good reason to catch up.
This is admittedly a pretty hopeful vision, but one that’s difficult to rule out. We’ve already seen an explosion of interest in the space since the release of Satoshi’s white paper, and there’s little reason to doubt that folks will keep tinkering with and improving upon existing blockchain systems into the foreseeable future. What’s more, as a decentralized “world computer,” a blockchain like Ethereum has the possibility of supporting systems that are less prone to censorship and manipulation by centralized entities.
What's Different?
Smart contracts in Ethereum are typically written in Solidity. For a programmer who’s already picked up several languages over the course of a career, adding one more might seem pretty straightforward. And, in many ways, that’s true. If you’re comfortable with a language like C++ or Java, you could probably get a decent idea of what’s happening in a given smart contract by looking at the code—even without lengthy formal study of Solidity in particular. However, there are some novel challenges that come up in reasoning through Solidity code because of the blockchain ecosystem's atypical execution environment.
For example, blockchain transactions are executed asynchronously. If you decide to interact with a smart contract, you send out a transaction that executes operations in the code. But those executions are not completed until your transaction is picked up by other nodes and mined into a block. Depending on factors like network activity and how much you’re willing to pay in transaction fees, it could be minutes or hours before the state change you initiated is confirmed by the network and reflected on the smart contract’s storage data.
Beyond asynchronous execution, there is also the challenge of transaction finality. Even if a given miner chooses to include your transaction in a block, there is no guarantee that the miner’s block will ultimately remain on the blockchain. Another miner halfway across the world might produce a different block at the same (or a similar) point in time, and the network might ultimately decide to build future work on top of the chain that includes this competing block (without your transaction!). In this case, you might have to wait for your transaction to be included in another block even after it initially appeared to have made it onto the chain.
These challenges do not disable the overall functioning of the system, but they do introduce novel challenges from a UX standpoint. How do you communicate to users that you understand that they have initiated an interaction with your application, but are awaiting confirmation that the change is valid and accepted by the network? In an era where traditional web applications are trimming milliseconds of latency to hold users’ attention, these sorts of scenarios need to be understood and addressed early in the process by smart contract developers.
Where To Begin?
For those up to the challenge of writing applications that run on the Ethereum blockchain, Dave flagged a few different resources to help begin the journey. Cryptozombies, for example, is a fun and interactive tutorial that helps bring you up to speed with writing code in Solidity. As with any other programming language, Solidity’s technical documentation is also a valuable resource for getting up to speed with the tools. This will help you lay the foundations for developing what would conventionally be known as back-end code running on the Ethereum blockchain: the smart contracts.
For those who are interested in focusing on the front-end—either for their own smart contracts or to play with one already deployed to the blockchain—the web3.js Ethereum JavaScript API is an indispensable resource. It provides a really nice interface for programmatically interacting with smart contracts (and the blockchain more generally) from your browser. And the Truffle development environment brings everything together, enabling you to write and test code for an entire blockchain application.1
Above and beyond the technical know-how involved in creating blockchain applications, it’s also helpful to dive deeper into the purposes and intentions driving the Ethereum community. For this, Dave suggested that folks check out the Ethereum White Paper and the classic post Programmable Blockchains in Context2. These resources provide a solid overview of what the Ethereum blockchain is attempting to do, how it intervenes in the broader blockchain ecosystem, and where things might be headed looking forward.
Finally, tools like Etherscan and EthGasStation provide a real-time window into what’s happening on the blockchain, enabling you to explore the history and current state of smart contracts and the network at large.3
Conclusion
We really appreciated having Dave come out to speak with us about programming on the Ethereum blockchain. And from the size of our audience, it was clear that many in the Chicago software development community were as well! Even though there’s a lot that goes into getting really comfortable writing and deploying your own smart contracts to the Ethereum mainnet, we walked away with a good understanding of how to get started and why we should be interested in doing so. Hopefully this summary provides a useful overview for those who couldn’t make it, and we’d love to see you at any of our 8th Light University Meetup events in the future!
If you'd like to learn more and talk about how 8th Light can help your business leverage blockchain technologies, check out our new Blockchain page!
1 Here at 8th Light we’re big fans of test-driven development. But even if you don’t feel as strongly as we do, you’ll definitely want to test your Solidity code. Once it’s deployed, it’s immutable—fixing a bug means deploying a new contract.
2 I might also add the Ethereum Yellow Paper as a really helpful technical specification for understanding what’s happening inside the Ethereum Virtual Machine (EVM).
3 Infura is another really valuable resource in this department, providing access to blockchain data for those either not running their own node or running a node with data pruning.