GeoDB’s Reward System: the why and how
A brief explanation of our incentive system
TL; DR: the rewards emitted in our current testnet are run by experimental software that is still prone to errors. This is why we do testnets, since blockchain technology can be sometimes really challenging to get right. We are working hard to get all issues fixed on the go before our mainnet is launched. Thank you for your patience and stay tuned!
Greetings to our dearest community! Here is to hoping you are all doing well in these trying times. We are back again with a new post for you to enjoy what we are most passionate about, blockchain technology! Worry not though, we understand that this subject can be a bit dense sometimes, so this will be a brief explanation in layman’s terms so that everyone can have a really nice time and learn something new today.
So, as most of you already know, one of the pillars in GeoDB’s ecosystem is the incentivized provision of data by the user (you!). We know that nowadays, data is a prevalent protagonist in defining our current economic trends and developments, that we are the generators of that data, and that the market is currently monopolized by a very small amount of companies profusely profiting from it (namely, the GAFA team: Google, Apple, Facebook, Amazon), which gives us room for some improvements in the distribution of that wealth and overall, the fairness of the big data markets.
GeoDB’s solution borrows blockchain’s power to achieve such objectives and goals. Blockchain is a disruptive technology in regards to the way that it makes heavy, centralized powers to shift to the edge: that is the birth of the Decentralized Autonomous Organizations or DAOs. One of the areas in which we do lean on the blockchain is in the distribution of our economic incentives, by means of our token. But as we strive to decentralize the very form of distribution itself, we have to rely on some traditional (i.e. centralized) approaches so that our ecosystem keeps advancing as a whole: enter the rewards emitter system, a piece of software that allows us to compensate with GEOs to our current data uploaders base!
GeoDB borrows blockchain’s power to achieve fairness in the big data markets
Rewards emitter
However, such a piece of software must be carefully crafted, as attack vectors are not to be taken lightly. We are operating in the Ethereum blockchain, a public, permissionless blockchain where operations cannot be reverted once they have been issued to the network.
What’s the problem here? There is a huge amount of economic value locked up in the rewards pool. This pool must leak the $GEO Tokens in a smooth way, following our defined supply curve. The distribution must be performed automatically in a supervised way, taking into account that if there is a single private key that manages this, and this key is compromised, the attacker could decide to drain the entire pool in a single swipe.
Our whole token pool is right now in the custody of a multisignature wallet, the reason is easy to understand: if they were in the custody of a classic, single-signature wallet as the one you have, it would only take the theft of the private key to gain access to our complete incentives pool, effectively taking control away from us of the incentives system, and giving it to the thief.
When we go live, the multisignature wallet will relinquish the ownership of the token pool, and give it to an automatic system (the rewards emitter), capable of distributing the rewards stored in the pool depending on the data delivered by our users.
Desirable features
The most important feature of this system is that it avoids “single points of failure”, or in other words: components that if compromised, might destroy the whole system. The rewards emitter is a kind of smart-contract multisignature wallet with some automations and rules built into it. Let us take a look into desirable rules to protect ourselves from bad actors:
- Multisignature: needed to make it so that in order to have a reward, multiple observers reach consensus in the existence of provided data. Why? Because if one or more observers were compromised, they would not be able to freely steal their tokens.
Consensus mechanism between all observers
- Time constrained: the contract must follow the emission curve, giving away a fixed amount of tokens in a pack (block) that depends on the time when the data was uploaded. The reason? Even if a majority of the observers were compromised and the attacker could game our system to take tokens from the rewards pool, he would not be able to do so for a long time before we notice, and thus the damage done would be highly reduced.
Minimization of potential damage against compromises
- Cold-wallet protected: as the last defense if something was terribly wrong with this smart contract, we have a cold wallet to pause it and revoke any privileges over the rewards pool.
Cold or multisignature wallet to pause emissions in case something went wrong
The design of this system is not trivial, as there are multiple concurrent processes in need of synchronization to keep things running smoothly.
Sometimes, the observers we set up cannot agree on what they observe: they might have different views on how or when the data was uploaded, the value of the data and its corresponding reward, who must be rewarded first, etc.
Other times, the emitter is overwhelmed by the number of users that are uploading data at the same time, and when trying to reward them all, the number of transactions is higher than what a blockchain can hold (remember, currently Ethereum can throughput around 15 transactions per second).
These events might stall the contract and require manual intervention from our team to keep things going. All of this when we do not have to debug our current set of tools: blockchain is still in its infancy, so more often than not we run into cryptic errors, malfunctioning libraries, and a plethora of hidden evils that make debugging our software a bit harder than usual. Remember that we are currently in a test network, so we are working hard to redesign and review our approaches so that these issues do not occur when the time to launch our mainnet comes.
Conclusion
To sum it up: albeit a simple idea, our rewards emission system is still a (loved) child that has a lot of room for improvement and growth. We sincerely apologize for the stalls and wanted to thank you for your patience. Things will become more stable over time, you can count on that! Have fun and stay tuned!
The GeoDB Team.
