Party Dapp at DevCon2 — Lessons learned
It’s been more than a week since the excitement of DevCon2 in Shanghai. There were a lot of exciting releases and announcement and I am sure that lots of Dapp developers spent months polishing their dapp (Distributed app) to release at DevCon2.
I just read the medium post of “Flight Delay Dapp — lessons learnt” and that inspired me to write my own experience of deploying a dapp in Ethereum mainnet during the DevCon2.
Table Of Contents
- BlockParty = Party in a blockchain with benefits
- DevCon2 in Shanghai = The future
- Security! Security! Security!
- Making Dapp more accessible
- Party is ON!
- After party stats and some security flaws.
- What’s next?
BlockParty = Party in a blockchain with benefits
I have been organising (semi) weekly Ethereum study group called “London Ethereum Codeup”. As an organiser of any free events, you always have “50% attendance” issue. You have limited capacity and your registration fills up within a day, yet your event is half empty because many people don’t turn up and don’t even bother cancelling the event.
To solve the problem, I created a Dapp called “BlockParty”. You pay small deposit when you register. You lose your deposit if you do not turn up. You will get your deposit back + we split the deposit of whom did not turn up.
DevCon2 in Shanghai = The future
I made an initial PoC(Proof of Concept) back in May and have deployed to testnet for 3 ~ 4 times for my CodeUp but never enforced the registration using my Dapp because most participants are still new to Ethereum and people did not even own Ether to pay deposit nor have never interacted with Dapp before.
I’ve been looking for an opportunity where majority of participants are fairly advanced users of Ethereum and do not have problem interacting with Dapp. At this moment, only such opportunity was DevCon2 so I targeted my development effort to make it production ready for DevCon2
Security! Security! Security!
I’ve known about Ethereum for just 6 months, and my entire experience was with the rise and fall of the DAO. I bought my first Ether through an exchange so that I can buy DAO, lost the majority of my asset when the DAO was hacked, then my first mainnet Dapp experience was to get my Ether back after the hard fork.
The whole experience turned me into paranoia towards deploying any smart contracts into production mainnet system. As a web developer working in an insurance company, I am fully aware of potential financial loss caused by my own bag. However, writing smart contracts takes this to a whole new level. Your code vulnerability can cause direct financial loss and you can track the whole transaction. Did you see Tim Coulter’s DAO Truffle where he replicated the exact steps of how THEDAO hack drained the fund from the contract?
The good news is that the DAO incident turned many Dapp developers attention into the smart contract security. I’ve usedOpen Zeppelin’s smart contract security patterns, fixed some of the security anti patterns, as well as writing my own bounty contract. This experience spawned another project of mine called Bountymax which I am hoping to cover in more detail in a separate blog post.
Making Dapp more accessible
The another side effect of the DAO hack was that using Dapp becomes a lot easier. When I first created the PoC back in April, MIST, the default Dapp browser provided by Ethereum foundation was not available, so each user had to startup a geth node with bunch of options like this.
geth — testnet — unlock 0 — rpc — rpcapi “eth,net,web3” — rpccorsdomain *
This is almost impossible for a non-technical user, but Mist allows each user to set access to their account per Dapp through their built in browser. To integrate your Dapp into Mist, all you have to do was to to use Web3 javascript provided via Mist. The code snippet is a bit like this.
if(typeof web3 !== ‘undefined’){ // eg: If accessed via mist
provider = web3.currentProvider; // Keep provider info given from mist `web3` object
web3 = new Web3; // Re-instantiate `web3` using `Web3` from Dapp
}else{
provider = new Web3.providers.HttpProvider(“http://localhost:8545");
let web3 = new Web3; // Define and instantiate `web3`
}Though Mist improved UX dramatically, users still suffered from syncing blockchain which could have taken hours.
That’s where MetaMask came in. MetaMask is a chrome extension that allows you to access blockchain node remotely provided by MetaMask. Unlike local geth node, the remote geth node may take a bit longer to respond, so MetaMask raises an error unless your Dapp code is written in asynchronous way.
Luckily I developed my Dapp using Truffle Web framework. Truffle uses EtherPudding which wraps the web3 API with promises. This means that your default way of interacting Dapp is already asynchronous. All I had to do was to wrap a few function calls (such as getting account info or contract balance) using my own Promise like this.
Now that you support MetaMask, interacting Dapp became easier than ever. So what else is left? One thing I was not happy about my Dapp is that it looks super empty if your Dapp is not connected into geth regardless of whether it’s connected locally nor remotely. My dapp is an event management dapp so it is important that participants can see not only the event info but also see who else has registered.
I initially implemented a hack to connect to Augur’s geth node as read only mode when the Dapp is not connected into any geth nodes. Obviously that is probably against the fair use of Augur’s resource so I recommend against doing so. Instead, I happened to receive an early invite to Infura so I changed the code in the last minute to connect to Infura.
The final part was to actually deploy the smart contract. Just before I was about to deploy, I suddenly realised that I had to handle against ETC replay attack. I initially thought ETC replay attack was something done by a malicious hacker but it was not. By default, any accounts which existed before hard fork have ETC as well as ETH after the hard fork. Any transaction made from ETC+ETH happens in both the ETH world as well as the ETC world.
Since my only account at that time had both ETC and ETH, and deploying a Dapp into both world may confuse participants (by having duplicate event pages with different participants). I had to spend a few evening figuring out how to split them so that I can deploy my contract from my ETH only account.
Party is ON!
Once the contract was ready, the next step was to find a perfect venue to host the first ever “BlockParty” event. Finding good venue in a place I’ve never been nor speak the language of was very hard. I had to find a place relatively easy from our venue (Hyatt on the bund), information available in English, and more importantly allowing me to book the table online. Luckily friend of mine who used to live there recommended me to a restaurant called Lost Heaven. In addition, the booking system allowed me to book only a table up to 10, which is the same number of our default max capacity of the BlockParty smart contract.
After securing the venue, I had to somehow announce and market the event. When I was first looking into it, there were no dedicated channel to talk about, so I asked Bob to open a gitter channel called devcon2social and spot was filled within a few days.
The dinner table was booked at 19:30 but I had a bit of problem. My flight arrival time was 16:30 which was very close to the start of the event. I had to rush a bit. I took Turkish Airline so I had to stop over at Istanbul airport for several hours. I met several other participants all heading to DevCon2. Interestingly one of the fellow traveller was also the participants of my BlockParty. His solution to my problem was also to buy the flight delay insurance (which I mentioned in the beginning) so that he can hedge the risk of losing the deposit he paid for my block party. Luckily for me, the flight arrived 20 minutes earlier so I gained a little bit of extra time though it was already 19:00 by the time I checked in.
One thing I overlooked was that how many few people not only don’t speak English in Shanghai but cannot read alphabet either. Because all my travel information was written in English, the cab driver kept refusing to give me a ride. In the end, I bumped into my co-traveller Jeff who lives in Taiwan and speaks fluent Chinese (Mandarin) so we managed to navigate taxi driver to the venue.
We were a bit late so more than half of people were already at the restaurant. We saw 3 people were still missing so we were excited (sorry) temporarily by the possibility of sharing the extra deposit. After waiting another 20 min, all the participants arrived. This is quite astonishing result given we were all a bunch of strangers visiting the city for the first time. We came from diverse range of countries, India, South Africa, France, UK, Taiwan, Sweden, Canada, and Argentina. Even though this was a small experiment, I can see the potential of my Dapp, using financial incentive for encouraging people to commit what they say they do.
After party stats and some security flaws.
We actually had 140 % attendance rate due to some party crashers. Because they did not register, that did not count. However I later found a bug which I call “Party Crasher bug”. The block party smart contract had a default of 10 as the max number of attendees. I created a function to adjust the number but I forgot to restrict the access to the contract owner. This means that these party crashers could be able to increase the maximum participants to sneak in once they come to the venue. Also the malicious user could lower the number to block more people participating in my event.
How much did the event cost? Here is the transactions of the whole event.
0.14562922 Ether (£1.5 or $1.95) was consumed as transaction fee (we did not take any commission so this was purely paid towards Ethereum miners). The contract owner consumed 0.112 (£1.16 or $1.5) Ether as transaction fee to create the contract (0.09 Ether), mark 10 participants as “attend”, then trigger “payout” event. Each participant had to pay about 0.03 Ether (£0.3 or $0.39) to register and withdraw.
As of this writing, there are still 2 people who have not withdrawn their deposit. I initially wrote a code so that the payout process is triggered by contract owner. This does not only incur more cost to contract owner but also a couple of my friend pointed out that this is a security contract anti pattern so I changed the code that each participant had to withdraw. Blockchain does not have any notification mechanism built in so you need to think about a way to contact user. Otherwise you wouldn’t know whether these 2 users decided not to withdraw or they cannot withdraw due to some bugs.
In our case, each user put their twitter handle as an identifier so it was easy to contact them. One of the reason why one of participants still haven’t withdrawn was because he registered while he was in his home country and he cannot withdraw until he goes back home.
Another learning for contract optimisation. The current contract forces contract owner to mark each participant as “attend”. This is not only time consuming but also incurs unnecessary transaction fee, so I should change the code to allow contract owners to mark as attend in a batch.
What’s next?
I created BlockParty to scratch my own itches so I am planning to use my Dapp to organise my own study group. The dapp is open sourced so you are more than welcome to clone and deploy on your own, though I must warn you that the codebase is still at super alpha phase and still in lack of robustness or features.
If you are not technical but up for using BlockParty at your local event or party, please let me know via my twitter account. I will let you know once it’s ready for the prime time. I think BlockParty is one of the first practical dapps anyone can use in everyday life. Have some Ether, organise awesome event, then have fun! No block, no party.
Special thanks to Jeff Lau for reviewing and editing this article.
