What is the ideal level of decentralization?
In crypto, decentralization is often an either/or topic. This cryptocurrency is decentralized because it uses proof-of-work! This cryptocurrency has nodes all over the world, therefore it’s decentralized!
These statements speak of what we personally value more than anything. Decentralization is complex. We can’t even think of it as layers of deeper and deeper decentralization; it’s more like choosing between the branches of a spider web.
Some aspects of decentralization make things easier. Many other aspects result in more overhead. Picking the right branches is crucial, lest the complexity balloons into so much inefficiency your creation grinds to a halt.
Hence why most DApps still rely on centralized hosting for their websites and centralized node providers like Infura to query web 3.0 data.
Many successful DApps also keep a high level of centralization in their smart contracts:
- Compound.finance has a single administrator key, which could drain the whole contract of funds through tweaking certain parameters.
- MakerDAO uses centralized oracles for their price feeds, which they could change at will, forcing liquidations.
Sometimes, attack vectors are subtle:
- The Parity wallet hack happened because the contract used for the library handling every Parity wallet was destroyable. Taking out that contract killed all Parity wallets at once.
- In EtherGoo, the owner had the ability to upload new units to the game, an apparently innocuous change. However, the owner could have uploaded new units with sky-high production levels and drained the pot before anyone could react.
Now, it’s important to note MakerDAO has been running successfully for years. Compound.Finance is securing $45MM worth of crypto assets. EtherGoo went through a few months of gameplay before activity quieted down organically, without the developer abusing his power.
Monetary rewards are big incentives, but they aren’t the only incentives. Beyond morality, how much money do you *truly* need? Developers might be more inclined to build a product in the spotlight, rather than “die in India while doing charity work”.
To circle around, there’s a significant gap between a fully centralized exchange like QuadrigaCX and a decentralized app with centralized components.
When you put your money in an exchange, you’re really giving all the power to the owner.
In contrast, DApps tend to give you custody of your funds and exit at will. The systemic risk is different — and it’s easy to argue: lower.
So there’s a point to partial decentralization. Take the proposed layout of Eggforce in EWW #5, where we will pool bankroll money into Compound.Finance and fund the prize pool with the generated interest. With decentralization, each participant can put their money in *and* take their money out at will. The coins are immediately invested by calling the Compound.Finance smart contract, and interest starts accruing the next minute.
If we were to try to do the same thing with the traditional banking system, it’d be a mess of bank wires back and forth lasting days, to a common investment account perhaps tied to the stock market or real estate. That investment would be highly illiquid, so participants couldn’t exit so easily. Dividends would be paid out only every quarter or year, so the prize pool couldn’t be funded for a long, long while.
To put it plainly, it wouldn’t work. The proposed Eggforce model is one use case where at least one aspect of decentralization is critical.
From that point, we can consider what other aspects of decentralization are essential — and what other aspects add too much overhead for too little benefits.
Previous snail games attempted to push fully decentralized contracts. Don’t trust me, trust the code.
This has some good properties, but ultimately, trust is still necessary even in a fully trustless environment.
Whether the game will pick up steam, whether the team has what it takes to push it to the next level. There’s an inevitable element of trust in the people involved.
That’s before we consider only a minority of users read the code. Those who do might or might not pay attention to every little detail of the implementation. Between potential bugs and possible disguised exit functions, trust in the developers is still required.
The lofty ideal of opensourced DApps goes like this: those who can read code act as watchmen, and will warn the community if there’s something amiss. This is how the Compound.Finance article linked above came to exist.
But for that ideal system to happen, any DApp must first experience a level of success that guarantees enough pairs of eyes are looking at the contract.
Ergo, trust is key.
Decentralized Autonomous Organisations
I originally wanted to make Eggforce a DAO.
The word might sound complex, but it’s a deceptively simple idea.
Let players vote on game rules. Let players vote on fund distribution. Let players vote on EVERYTHING.
And make it all trustless, onchain — that’s the “DAO” part. Each player would get voting shares proportional to how much they spent. The more financially invested you’d be, the bigger say you’d have.
Every player has their own idea to improve the games they love. A governance DAO would let anyone influence Eggforce the way they see fit.
In a game where people compete for money, this would also have the interesting property of creating a “meta-game” above the game itself: you could win by having the best strategy… or you could win by voting to change the rules in your favor!
Thing is… DAOs are hard.
Onchain voting is fraught with difficulties.
For starters, think 51% attacks. Even cryptocurrencies with multi-million marketcaps have to worry about that.
In a small DApp, it’s plausible for someone to see they can acquire 51% of the votes, then vote everything their way.
You can solve this problem in various ways. Perhaps you implement a rising price curve to make sure nobody buys their way in one fell swoop. Perhaps you have a time delay on vote resolution, during which people can take their principal out if they feel deceived. Perhaps you use quadratic voting so large voters don’t have a disproportionate influence. Perhaps you let the developer or the community have a veto right.
All of these solutions come with their drawbacks. Not the least of which comes from the added complexity to the system.
What should be a simple Yes/No vote becomes a cumbersome patchwork of balances and checks. Every edge case need to be thought of.
This is no easy task: we’re notoriously bad at predicting the unpredictable.
In defense of humility
A cursory historical look at DAOs will give you THE DAO, back in 2016.
I encourage you to read that Wikipedia article.
In short, this original DAO on Ethereum pooled $150MM worth of ETH amongst thousands of investors.
At the time, this was a staggering 14% of Ethereum’s marketcap.
What happened next?
It got hacked.
A vulnerability was found, and some unknown person who we will name “daxaren” siphoned all the ether out of that contract.
Having one hacker hold 14% of the supply struck some people as rather… questionable for the future of Ethereum. It was quickly decided to fork the network and undo the damage.
Hence, we’ve got Ethereum Classic which is the original chain where daxaren owns millions and millions of ETC. Then there’s Ethereum, the forked chain we know and love because ETH went to $1400 once and we all live in the hope it will climb back there one day.
Obviously, the DAO hack didn’t do much for the image of DAOs as a whole.
The community moved to the much safer concept of ICOs instead. With ICOs, at least you know right away your money is lost.
All wounds heal with time. And so in 2019, we’re seeing a resurgence of DAOs.
The new DAOs are (understandably) more careful in their assumptions. Let’s look at Moloch DAO, current darling of cryptotwitter.
Moloch DAO features two functions: first, it signals to the world those crazy Ethereum kids were Satanists all along. Second, it lets people vote on distributing funds to a specific ETH address.
That’s it, for the onchain part!
In practice, Moloch DAO doesn’t just give money to *random* addresses, but to proposals fitting the DAO’s idea of public goods. Still, an accepted proposal comes down to sending ETH in bulk to the person responsible. Everything else happens offchain.
Moloch DAO has one final characteristic: participants can “ragequit” at will. A ragequit lets you cash out your voting shares.
To recap, modern DAOs aim to be simple, and to keep you in control of your money.
And yet… Even “simple” isn’t necessarily foolproof.
To join Moloch DAO, new members are supposed to pledge a certain amount of ETH to the DAO.
However, a current member of Moloch DAO made a smart contract delegating his voting shares, for a price.
You could buy these voting shares, then use them to vote yourself in. Bypassing the normal process, through a decentralized bribe!
Unlike the DAO, this Moloch DAO bribe attack wasn’t a catastrophic incident. The “hackers” are known; they work to prod the system, in order to make it better.
But it’s a good insight into the difficulty of safeguarding onchain voting from every possible attack.
Now comes a moment of personal reflection.
If talented teams of expert programmers struggle to make simple DAOs foolproof… Is it reasonable to build a complex DAO for Eggforce governance?
Are the benefits worth the risks?
Let’s go with probably not.
“Decentralize everything” has allure. It’s hard to let go that ideal.
Still, it’s better to start small and grow from there. Elaborate systems for community governance become questionable if the community is 3 and a half people strong.
Let’s make Eggforce fun. Then let’s make it fun to govern the future of Eggforce.
THE (ROUGH) PLAN (SO FAR)
Eggforce will work as two smart contracts: one deployed on Ethereum, and one deployed on xDai chain.
We’ll call the Ethereum Eggforce contract BANKROLL, and the xDai Eggforce contract GAME.
The Ethereum BANKROLL contract will be permanent, in charge of the bankroll.
Investors can fund that bankroll and receive tokens in exchange (probably at a 1:1 ratio. Send 1 DAI, get 1 EGG.)
The DAI sent is automatically lent into Compound.Finance, and starts earning interest.
Investors can get their principal back at will. When they do that, the BANKROLL contract calls the “withdraw” function from the Compound.Finance smart contract, then assigns the DAI to the investor, then the investor can withdraw it back to their wallet.
This is all trustless, thanks to smart contract interoperability. Nobody will be able to touch the investor’s principal, except themself.
The xDai GAME contract will be temporary. This is where the game itself will be played.
For each new “game round”, a new smart contract will be deployed — with new adjustements and features the community might desire.
The interest accrued from the BANKROLL will be sent to this new GAME contract.
Because Ethereum and xDai are different chains, and because setting up interchain bridges is a significant undertaking, this operation of withdrawing interest -> converting Dai to xDai ->sending xDai to the GAME contract will be done manually, by yours truly.
In the GAME contract, this xDai ends up in the prize pool. The prize pool is distributed at the end of a predefined time period for this game round.
(Rounds will likely last one month. One month is a good stretch to let interest accrue for prize pools, and it’s also a good amount of time to reflect on game mechanics, develop new features and implement changes for the next version of the GAME contract. Ultimately, round duration will be up to the community.)
This prize pool will be spread automatically by the smart contract, so once again this is trustless. Players don’t have to worry about anyone stealing the prize pool.
In the GAME contract, some upgrades and features might require xDai. The xDai players spend will be saved in a separate chest.
Then, that chest can be converted to Dai and sent to the BANKROLL contract, where it will be invested on Compound. This action will also raise the EGG price proportionally, which is how investors profit.
For example: imagine the BANKROLL contract starts at 1 EGG for 1 DAI. 5 000 DAI are invested into Compound. 5 000 EGG are distributed.
The GAME contract receives 100 xDAI during the first round. Those xDAI are converted and sent to the BANKROLL contract, and automatically invested into Compound.
The BANKROLL now has 5 100 DAI invested into Compound. If an investor decides to trade his EGG back to DAI, he’ll receive 5 100 / 5 000 = 1.02 DAI per EGG.
Summary:
- BANKROLL deposits and withdrawals are trustless
- GAME prize pool pays out in a trustless manner
- BANKROLL to GAME as well as GAME to BANKROLL requires trust in the developer named snailking.
Now, consider the interest generated month to month should be under <1% (if we assume 10% APR for DAI lending on Compound.Finance.)
This means that if the dastardly snailking decides to play some shenanigans with the interest, investors would see it happening and react in consequence. This minimal sum of interest might be lost, but investors could withdraw their principal immediately.
And snailking would be forced to run away in shame, never bugging anyone with his weird egg-related games ever again.
On the GAME to BANKROLL side, it stands to reason the collective sum invested by players shouldn’t exceed the monthly interest too much. The same considerations as above apply.
In short, we minimize custodian risk by making it economically unsound for the developer to behave maliciously.
(In plain English, though I may be pseudonymous, I’m not going to ruin my reputation to exitscam $2.)
Let’s end this behemoth post here. Next week, we’ll look at the dangers of centralization and describe some new design paradigms for Eggforce.
We might even talk about the game itself! Now doesn’t that fill you with unbearable joy and happiness?
Feel free to share your excitement on Twitter or Discord. I’m always listening. And watching you. While you sleep.
