EGS Garage with Chaz #6: Tackling Time Management on Ethereum
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 can be 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, #5.
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.
Managing time and expectations
Humans aren’t perfect and we make mistakes. And so, designing applications for humans comes with many considerations. When designing BridgeBurner, I always like to keep in mind that the application is meant to put financial social pressure on the user.
I want it to motivate them to keep the commitment, but not discourage them from making new commitments. The rules of the “game” should seem fair and allow for the right amount of wiggle room. Which is why the previously mentioned grace period to check in before the funds start burning is so important.
Schedules aren’t one size fits all
I figure there needs to be a window of time before checking in that is small enough where you can be a few minutes late and not be punished. But, not so large that it defeats the purpose of using the DApp in the first place.
In my mind, five minutes works, but ultimately the user should set the size of the window. This can simply be one more piece of information the host inputs into the contract or UI when creating the date invite.
Let’s explore a few ways I’m considering to measure time.
block.timestamp
I’m not sure how, but for the longest time I overlooked the fact that each Ethereum block has a timestamp. The timestamp is defined in the Solidity docs as a uint value that represents ‘current block timestamp as seconds since unix epoch.’ For those of you who don’t know the Unix epoch is the number of seconds that have elapsed since 00:00:00 Thursday, 1 January 1970, or rather Coordinated Universal Time (UTC), minus leap seconds. Essentially, all computers use this number to measure time in seconds and convert it to your local time.
If I wanted to add in a grace period using this method, I could require the host to input the time of the meeting and the amount of time they want for a grace period. Then, I’d program the user interface to convert both the date and the numbers of minutes in the grace period into Unix time.
Fix what doesn’t work
These values will most likely replace the start and end blocks associated with burning the funds. In order to accomplish this, I’ll have to change the way the contract burns funds. Right now, the contract uses blocks to measure time and calculates the amount to burn based on how many blocks have passed since the ‘start block’ determined by the host.
Switching from blocks to seconds is probably my best option for improving the user experience. Because right now, the host must provide the block time for when the meeting will start. This can be very confusing and hard to predict because blocks aren’t exactly consistent. A grace period would cover any instances of checking-in too early or too late based on the timestamp of the block that contains your transaction.
As with most things in blockchain, there are trade-offs to using this method. One downside to using this method is that the timestamp on the block isn’t infallible. These timestamps are provided by the miner and is supposedly the time the block was mined. Theoretically, a miner could manipulate this value. But to be honest, I don’t think this is an attack vector we need to worry about for the BridgeBurner.
xDai and the POA Network
I’ve always been a fan of Austin Griffith’s Burner Wallet which allows you to create a hot wallet on the fly. It’s built on the POA xDai chain which is an Ethereum sidechain denominated solely Dai. Being a sidechain, xDai has consistent block times of 5 seconds each. This could simplify part of the equation at the cost of on-chain transactions.
Moving off-chain has its ups and downs. BridgeBurner seems like a good fit for the fun spirit of onboarding and exploration around Burner Wallet. And, newcomers might better understand payments pegged to USD. I could even leverage Burner Wallet modules for BridgeBurner’s user interface. However, I would sacrifice access to any contract on the main network. Also, the user may find see the token bridge process as too many steps. I have to look more into how I’ll go about the UI before I reach a decision.
Using the POA Network might also help ensure the gas costs for using BridgeBurner are low. However when it comes to gas optimization, we’ll cross that bridge when we come to it.
Get it? Haha puns… If you hate puns, let me hear about it @ChazSchmidt on Twitter or in the Concourse Discord.
Thanks for reading!
