EGS Garage with Chaz #5: Keep V1 of your Ethereum DApp simple
Welcome back to EGS Garage with Chaz, a journey through the process of building an Ethereum DApp from idea to deployment. This isn’t formal coding advice; it’s an open diary of my experience and what I’ve learned along the way. Smart contracts are hard – but far from impossible to learn if you’ve got the right mix of motivation and humility. I hope this series inspires you to give it a shot yourself. If you need to catch up, check out my past entries: #1, #2, #3, #4.
My first Ethereum DApp
BridgeBurner is a smart contract designed to put social and financial pressure on two parties to attend a meeting or other appointment set in a calendar. Let’s say you and a friend keep rescheduling a lunch together. You could use an Ethereum DApp built on BridgeBurner to put your money where your mouth is by putting down a deposit that’ll start burning if you don’t arrive on time.
New start, new problems
Having cut ties with my initial hastily stitched together draft, I was ready to start fresh. I literally went through Streams.sol line by line to determine what was essential to keep. As explained in my last post, I set out to replace the old Stream struct with one of my own named Date. Date keeps track of the participants, their deposits, their check-in statuses, and the terms for burning their deposit if they are late.
Surprise surprise! Soon enough realized I’d been a bit too ambitious with my first design of the Date struct. I’d wanted to allow multiple guests, but this caused problems I hadn’t counted on. I’d planned for the contract to record each participant’s deposit into a mapping called depositedShare. As you may know, mappings are a collection of pairs of keys and values; when you enter the key, you get the value. These mappings would use the participant’s address as the key, and the value would be the number of tokens that participant deposited.
But I quickly discovered that structuring the deposits like this wasn’t going to work the way I’d intended it to. Turns out that mappings in Solidity don’t work quite like the key value pair maps I was used to in other programming languages. I needed to do some more research, and setting BridgeBurner up for multiple guests was going to add more complexity overall.
Stick to what works
Ultimately, I decided to revise my plan by limiting the first version of BridgeBurner to just two participants: a host and a guest, for simplicity’s sake. I figured this could be the MVP, and I could increase the maximum number of participants in a later update. Cutting it down to two participants made the contract simpler and its functions easier to write.
For example, I no longer needed extra functions to crawl through the list of participant to verify their check-in statuses. Instead, all I had to do was add a step in the check-in function. If the host or guest calls the check-in function, that function determines if the other has already checked-in. If so, it redeems the deposit automatically.
New additions along the way
As I kept adding more to the Date struct, the getDate function – necessary for retrieving all the details of a date – kept growing. This function will allow the UI of the future Ethereum DApp to display the terms of a date to users. But I soon learned that functions cannot return more than 8 values. “Well, that’s easy enough to fix,” I thought. So I split it up into two functions.
I also added a cancelDate function, which allows the host to cancel if the guest never responds. It simply checks if the guest’s deposit is still zero. And if it is, the function then calls the redeem function to return the host’s deposit.
I still need to add a grace period to let users check in before the funds start burning. I’m exploring my options on how to take blocks and convert them into minutes. For example, I could have the UI calculate the number of blocks multiplied by the average block time. But like I said, I’m not sure how I’ll do it yet. So we’ll circle back to that later.
Putting the burn in BridgeBurner 🔥
When first deciding what the burn address should be, it completely slipped my mind that Ethereum addresses aren’t made up of just any old text. Ethereum addresses are in hexadecimal format, which only contains characters 0-9 and A-F. I also happened to learn that Ethereum addresses with proper capitalization are addresses with a checksum. The purpose of a checksum is to confirm you typed the address properly. So after looking at what letters I had to work with, I ended up going with a valid address: 0xbAd0000000000000000000000000000000000000.
I figure “bad” is simple and works because your money only goes there if you are a “bad friend” and you need to be punished. It’s not perfect. I’ll workshop it a bit.
Let me know if you have a better idea for the burn address! You can find me @ChazSchmidt on Twitter or in the Concourse Discord. I’d love to hear from anyone who’s going or has gone through the process of building an Ethereum DApp.
Thanks for reading!
