ETHDenver Recap
As a sponsor of the ETHDenver hackathon, BlockApps sent a few of us out West to build, learn, and hang out with the Ethereum community at large. Hackathons are inspiring, and this one was no exception. With five stories of hackers building applications in pursuit of a shared mission, our decentralized future felt inevitable.
The main takeaway from the event is that blockchain development is still in its infancy. Most dApps are just escrow contracts, which execute some business logic if certain conditions are met. During the hackathon, all escrow contracts were modified for novel use cases, such as governance and crowdfunding. Hackathon projects largely fell into the following categories:
Governance (DAO, crowdfunding) – contributions to a contract result in some level of ownership over contract logic. This is determined by variables like the size of an ownership stake or consensus among all token holders.
Static Storage (DRM, proof of ownership, chain of custody) – the EVM is used to store arbitrary pieces of data as 32-byte hashes. These apps are useful for proving irrefutable ownership of a piece of data at a certain date. This includes projects like proof of location and proof of ownership.
Token Collectibles (CryptoKitties, tokenized art) – contracts with metadata can represent one-of-a-kind assets on the blockchain.
The biggest hurdles in the development process were around error handling and deployment. With most developers using Truffle for their app deployment, many felt the error handling to be seriously ambiguous or non-existent. It’s very difficult to determine which opcode is causing an issue, which tends to make ‘truffle migrate’ read more like ‘truffle migrane.’ Traditional development tools like Heroku have spoiled us into thinking that blockchain deployments would be as easy – instead, developers must currently use Truffle or develop their own CI process.
In general, blockchain apps require developers to follow specific architectural constraints, which are not obvious at the outset. For example, any blockchain app requires that signatures and transaction mining be asynchronous, as a transaction hash can only be returned to the client after the transaction has been mined. These ‘gotcha’ moments serve as useful resources after the fact, but it doesn’t make it any easier to get an app up and running.
So, where does STRATO fit into all of this? Developers would have reduced their getting started time (time from start to functioning blockchain API) by using STRATO instead of the common Truffle/TestRPC deployments. In addition, developers could have used Cirrus to query the blockchain directly, which would allow them to search the state of contracts by name rather than address. This would be useful for looking at the state of similar contracts without knowing their individual addresses, as the state would be visible by code hash or contract name.
We’re on an exciting path to a decentralized future, and learning to develop blockchain apps is the best way to take part in this paradigm shift.
