Hey there, I'm Teo, tech lead at Fight Out. In our fast paced team, not unlike the Octagon, things get said, thrown around, spun around, brought up high, and knocked down low… My job is to settle and collect some of that gold dust and cast it into something tangible yet malleable, solid yet iterable.
From the very beginning, the fact that Fight Out was going to cater for an MMA audience presented a set of fresh tech and design challenges. Each of the following ideas reveal interesting challenges that have inspired our product direction over the past months.
People want to train like the pros and they want to be rewarded for it.
Before standing a chance to earn anything significant, many move-to-earn platforms (not naming any names) hook in users by first convincing them to spend on NFTs. We decided to tread a different path and observe the challenges associated with actually measuring people’s efforts so that we can reward them fairly.
People want to train with the pros.
Mainly a scale and content delivery problem already solved by readily available tech. But how do you make the content immersive and give it the same feel and intensity as a UFC event?
People want a sense of community and excitement.
What do most MMA fans do during the weekend?… Exactly. It is perfectly logical to use the sense of anticipation for the UFC events to bring fans together and put their knowledge of their favourite fighters to the test.
People want to own a part of the platform.
We want to be invested in an awesome product’s success. The advent of NFTs and blockchain technology has made it possible to offer users a unique sense of ownership and investment through crypto-backed assets. Currently, this space is laden with security flaws, poor user experience, and outright scams.
Over the coming months we will be exploring some solutions to these problems. You should most likely expect some rant articles coming up about Sports APIs, rough 3rd party integrations, and Serverless deployment woes.
In that vein, let’s go back to the nerdy bit.
Our first block in the road has been future proofing our app for a decentralised computing network (I don’t particularly like calling it Web3). One of the biggest barriers to entry for many users is the exceedingly janky user experience of establishing an identity (creating an ETH account anyone?), creating a wallet, and transacting crypto.
To be able to begin unpicking the user experience challenges, we need to first simplify some terms that developers and tech folk often use interchangeably. This has been a pet peeve of mine over the past while and would like to set it straight once and for all:
An Ethereum Account is not the same as a Crypto Wallet. It even says that in the official ethereum.org documentation.
You can think of an Account as a mathematical hash that has always existed, but a user has happened to discover its private / public key pair. This needs a little unpacking. The way we “create” the public address known as an Ethereum Account is by first randomly generating a 32 byte array (this is known as the private key and we never give this away to anyone), computing a public key using the ECDSA algorithm, then putting the last 20 bytes of that through a hash function called the Keccak-256 hash. Please reach out to me if you’ve got an explanation of what a “sponge function” is, I’m still trying to figure that out. Let’s further unpack public / private key pairs and hash functions below.
Now what on earth is a private and public key and why is it also known as an asymmetric key pair? Practically speaking, the private key is meant to be kept safe as you would your house key, while the public key is for handing it out to the world. But why would you hand out the public key to the world? In cryptography, we are able to encrypt or sign a piece of data with one key (lock with your private key) and decrypt or verify it with another (unlock with the public key). The purpose of signing something is that the authority and identity of the person signing it can be easily verified by anyone without allowing everyone to impersonate them.
A hash function is a type of function that takes an input and produces a fixed-size output, which can be easily represented as a hexadecimal string (numbers 0-9 and letters a-f AKA 16 characters). The output is created in a way that is deterministic, meaning that the same input will always produce the same output. A good hash function will make it very, very (…) unlikely that two different inputs will produce the same output. Indeed, that is why they used the badass Keccak-256 function to produce the public address of an Ethereum Account.
Let’s take a brief closer look at a Wallet, I promise it’s much easier to grasp than the above:
A Wallet is an interface that allows you to behave on the Ethereum blockchain. It allows us to use an Ethereum Account to interact with websites featuring decentralised functionality, to transact cryptocurrency, or to call a method from a smart contract on-chain. It is also the layer that connects the Account owner to the website or app providing the decentralised functionality.
Remember, it is important to understand what these tools are and how they work at a high level before dashing straight into making use of them.
That’s exactly what we’re doing, trying to understand the whole problem of decentralised ownership before building for it. Currently we’ve got a transparent solution for allowing people to easily use an Ethereum Account on our application under wraps and have successfully tested it. In a nutshell, it involves a Multi Party Computation (MPC) platform that we integrated and “Sign in with X”, but I’ll keep the details for next time.
That has been a lot to digest, so let’s leave the dust to settle for a bit, and next time, I will take you through how we’re smoothing out some of the rocky user journey resulting from the above challenges.
Thanks for reading, with all the marketing jargon and community discussions going on, we feel it’s important you understand there is serious product development being undertaken. I’ll update you soon!