What We Learned from Our First Ethereum Project

Kevin Mulcrone
TerrapinTicketing
Published in
4 min readAug 22, 2017

--

This past weekend Michael Reeder and I won the HackCincy 2017 for our project Terrapin Ticketing.

Terrapin is a live event ticketing platform that leverages the Ethereum blockchain to issue, buy, sell, transfer, and verify ticket authenticity and ownership.

HackCincy is a hackathon hosted at Union Hall and organized by employees of some of Cincinnati’s most established startups and BigCos that focuses on technical creativity. Teams of up to 5 developers had 24 hours to work on a project to be judged on its technical creativity.

Below is more technical Ethereum related topics that we learned over the weekend that are worth mentioning. If you are interested in learning more about developing on Ethereum, I highly recommend checking out Jordan Leigh’s Ethereum series on Decypher.tv as a starting point or shooting me an email. I love talking about this stuff.

Introduction

We wrote our code in a language called Solidity which is a popular contract-oriented, high-level language whose syntax is similar to that of JavaScript. Serpent is another high-level programming language used to write Ethereum contracts that looks like Python but was recently discovered to have numerous vulnerabilities in it.

There are some more technical hurdles to setting up Ethereum projects like understanding how a blockchain works, how Ether (ETH) functions and interacts with it, the significance of addresses, what ABIs are, and deploying and managing contracts.

But hey, if we managed to figure it out, you can too!

Some technical take aways from this weekend…

Contracts Aren’t Complicated
I think a lot of people get intimidated by the notion of smart contracts in Ethereum. There is definitely a learning curve involved with “thinking in Ethereum” but the actual code itself isn’t that complicated. Here is an example of our buyTicket() contract:

function buyTicket() payable {
if (owner != publisher) throw; // ensure ticket is available
if (msg.value < price) throw; // ensure enough ether was sent
if (!publisher.send(msg.value)) // send ether to ticket issuer
throw;
owner = msg.sender; // set new owner
}

Truffle is Awesome
I think the biggest take away from the weekend is that Truffle is an incredibly powerful framework for building Ethereum applications on. It takes care of the compilation, linking, and deployment process of smart contracts and allows for testing the contracts you’ve written. When we first began playing around with Ethereum smart contracts a few months ago, this tool didn’t exist (or we weren’t aware of it) and forced us to spend a lot of development time doing the “dirty work” of Ethereum instead of writing good code.

Watch Your Versions
We ran into some weird (and frustrating) issues initially because we didn’t pay close attention to which version of the Web3 npm module we were using. Truffle uses Web3 version 0.x.x and we were using 1.x.x on our front end. This meant that certain function calls had a different structure on our backend (Truffle and therefore 0.x.x) than our frontend (which used the updated Web3 1.x.x):

// utility functions
web3.fromWei() // 0.x.x
web3.utils.fromWei() // 1.0.0
// calling methods
contract.myMethod() // 0.x.x
contract.methods.myMethod().call() // 1.0.0
// calling `constant` methods
contract.getOwner.call() // 0.x.x
contract.methods.getOwner().call() // 1.0.0
// accessing public variables
contract.owner.call() // 0.x.x
contract.methods.owner.call() // 1.0.0

Lists Are Hard
One thing we struggled with was managing lists in Ethereum. Because of the 24 hour time restriction and because Solidity is a very primitive programming language (in comparison to Javascript), managing groups of things whether they be events or tickets is hard. Because it is on a blockchain and not central database, arrays cannot hold structs so there is a lot of iterating through arrays to find addresses of other arrays to return contracts that return objects held in arrays.

Yeah…that was not fun to write nor the most efficient way to get that data, but it worked for the hackathon. We are going to look into how to better way to manage lists on the blockchain for future versions.

Thanks to Danny Kelly for throwing this together for us

Conclusion

Our goal going into HackCincy was to work on the Terrapin Ticketing idea that we have been developing for the past few months, sit down and build a working prototype, and gather feedback from other developers and the #StartupCincy community about it.

We think we succeeded in the first part of that goal, but we would love any feedback you may have about our idea. You can reach me via email at KayBeSee@gmail.com or on Twitter at @KayBeSee.

I intend on writing a more in-depth blog post in the near future about what is wrong with the current state of live event ticketing and how it can be solved using blockchain technology. Be on the look out for that in the coming month!

--

--