The Tech Behind Eventivize Drops

Behind the Eventivize Drop App is a database that keeps track of how many drops each user has. However, it is not just any database - it is a full-fledged blockchain! Specifically, one based on the Cosmos blockchain, just like Binance Coin and Crypto.com.

But why are we using a blockchain at all? The intent is to spread responsibility for the reward mechanism between multiple parties - the event organizer, partners, artists, venues, and even merchants, such as food stall owners (for events IRL). Besides the myriad possibilities enabled by tokens, spreading ownership of the event (or part of it, at least) could result in interesting crowd behaviours.

Deploying chains on demand

Deploying a new blockchain is not meant to be easy — especially for a Cosmos blockchain. Deploying a new blockchain is not meant to be done often, and there is a lot of back and forth signing-and-verification of messages between several very responsible parties, usually heavily invested companies. Then once it's deployed, you keep it running indefinitely.

That’s not the case with Eventivize.. For each event, a new so-called "burner" chain is created, which, once it is over, can either be stopped or kept running to enable interesting interactions between subsequent events. The service that we created to orchestrate this is called LaunchControlD, and the chain that it launches is called LaunchPayload.

LaunchPayload

LaunchPayload is a standard Cosmos blockchain packaged in a Docker image with scripts or utilities that provide a standard interface for LaunchControlD to work with. There are two binaries of note:

launchpayloadd: the blockchain node that actually maintains the database and balances and guarantees fair behaviour. To spread responsibility for the event's drop mechanism across stakeholders, the stakeholders must generate their own validator accounts using launchpayloadcli and run this program with their validator account on their own computers.

launchpayloadcli: manages accounts and, when connected to launchpayloadd over the network, provides an interface for apps like the Eventivize Drop App to query and post transactions.

These programs can be run on different computers as well, although the computer running launchpayloadd should have launchpayloadcli to provide the validator account.

LaunchControlD

LaunchControlD is meant to be continuously run on a server, waiting for new requests to spin up new chains. Such requests can come in through the HTTP REST API or command line interface.

The request contains the stakeholders’ email addresses, the currency in question (always a "drop" in Eventivize's case), and the initial balances of each account.

Here's what an event request looks like in YAML:

---
owner: "owner@email.com"
token_symbol: "drop"

genesis_accounts:
  -
    name: "alice@apeunit.com"
    genesis_balance: "500drop,1000000evtx,100000000stake"
    validator: true
    faucet: false
  -
    name: "dropgiver"
    genesis_balance: "10000000000drop,10000000000evtx"
    validator: false
    faucet: true

LaunchControlD will then start as many virtual machines as there are validator accounts, invoke LaunchPayload to randomly generate the validator accounts and additional configuration, copy the configuration to each virtual machine, and tell the virtual machines to run everything.

The virtual machines may be deployed on the same machine as LaunchControlD (virtualbox) or provisioned elsewhere on any cloud service supported by docker-machine.

The astute reader may realize, "wait a minute, doesn't he who controls LaunchControlD have total control over the validator accounts, and thus, ownership of the event reward mechanism itself?"

Why, yes. Yes indeed. Evil smile.

Given our target audience (event organizers who don't care so much about the technical details), the overall unproven social effects of introducing a token into an event, and the delays that signing the genesis state and transmitting it back and forth between the event organizers, partners, artists, and even merchants would cause, we decided it was a worthy tradeoff.

An obvious improvement would be importing validator accounts generated by stakeholders, and creating a mechanism for these accounts to sign the genesis transaction together before making an event request. Should an event result in a particularly long-lived asset, a link to a more permanent chain could be established with IBC.

Conclusion

LaunchControl and LaunchPayload are still in their infancy, and there are many opportunities to improve. This is a first step to empower event organizers to build their ideas on top of decentralized technologies based on Cosmos SDK, making the power of Cosmos available to a whole new user group.

We at Unit 8 see opportunities in using burner chains, perhaps with custom Cosmos-SDK modules, to ride the current trend of decentralization, exploring exciting new social effects that arise from tokens that can be plugged into the crypto financial system.