How to make EOS a Neutral Infrastructure for all Dapps
EOSX Vault hack and subsequent nulling of 253 accounts using eosio.wrap privileged account presented EOS Dapps as a two-tier system; the one well connected, with owners able to coordinate the BlockProducers multisig, and others Dapps unable to provide the same level of service. This violates the principle of Neutral Infrastructure for Dapps to operate on.
Regardless of your opinion on the need to save EOSX pool depositors, I hope I can convince you this cannot become our new status quo, and the timely changes are needed.
The only way to remove this two-tier system is the removal of the BPs’ ability to use privileged accounts to execute permission bypass.
Just opening up the process doesn’t guarantee you other bps would care to check your Dapp case, or that coordination would be employed on 3rd party Dapps the same as it was in the EOSX vault hack.
Since part of the community is convinced removal of Block Producer god powers would leave the community defenseless, I want to propose mitigation steps that can be used by most dapps equally first and removal of privileges second.
Overview of the steps;
- Realize the problem.
- Prepare and deploy mitigations for Dapps.
- Set up the new expectations to Dapps
- Reduce BPs God powers.
- Congratulate yourself, EOS is now a proper public blockchain!
A more detailed explanation of the steps follows. Keep in mind this is just an example proposal, and some goals could possibly be achieved differently/better/easier. The proposal is trying to propose minimal changes to satisfy the goals of making EOS a Neutral Infrastructure for all Dapps.
1. Realize the problem
Realize the problem BPs god powers are creating, and seek/champion the fixes. It can’t be overstated how crucial is that (Eden?) community keeps driving the process to completion. We already had initiatives that went nowhere, and this is how we end up here in the first place. People willing to help only have a limited amount of drive they can employ to fix problems so deep in the EOS codebase.
2. Prepare and deploy mitigations
We propose a Time Vault. It’s based on an idea from the Token Settlement Contract but tries to be as minimalistic as feasible. There are many possible variations with even more functionality, but ultimately the solution needs to very simple so Dapps can deploy and reason correctly about parameters they can set. It’s also important that it fits right into many of the current Dapps.
The goal is to commit a specific (usually dapp) account to a delay of 2-7 days. The account commit action can only be reversed by recovery permission (which includes its 1-month delay).
Once the tokens are committed to a delay, there are 2 more permissions needed. Delay Claim and Recovery.
-
Delay Claim permission
1-month Delay Claim permissions, which can be used every 2 months (to limit damage and allow tokens to escape if those keys are leaked). The same authority that can call Delay Claim action can also update the permission on the same action. -
Recovery Claim permission
Is able to spend those coins to any alternative address one month after authorizing it (to limit possible abuse). The same authority that can call Recovery Claim action can also update the permission on the same action, change a base delay in days, plus remove/release the account commit (one month after authorizing it).
A typical setup for a Dapp would look like this; commit an account to delay. Then go set up Delay Claim permission. That would typically be given to the operators that can identify the problem is real in the 2-7 days - usually developers/operators of the contract. With a low barrier to activate it- low or even no multisig depending on the importance of the contract.
Dapp account owners would also define recovery permissions; usually, give it to BPs multisig (opt-in!) and possibly some Eden authority or the multisig of trusted people in the ecosystem.
Important to know for point 4. - BPs multisig (eosio) can also force any account into a delay, and also use 1-month Delay Claim permissions. Recovery one is opt-in. Once god powers are removed, this becomes the main backstop for the system contract hacks. Recovery itself would demand opt-in consensus from all nodes (read under 4.2)
3. Set up the new expectations for Dapps
Existing Dapps get invited to use the new mitigations. The ones who don’t get a community message that BPs won’t (or couldn’t) bail them out anymore. Wallets set up a checkmark indicating to users which Dapp is protected/mitigated. It’s important to note that not all Dapps would be able to mitigate. Some rely on instant liquidity in and out, and those would have to explain to their users that if the exploit is found, they are on their own. This would lead to fewer people providing liquidity to these Dapps, but to higher yield compensating them for the risk.
4. Reduce BPs God powers
…to temporary 1-month Delay Claim only.
Steps suggested;
-
Remove the eosio.wrap contract and set the account to be unprivileged
-
add in the node software the ability to allow (or not) the upgrade of specific system contracts and update blockchain state. The mechanism should expand the current consensus upgrade protocol introduced in eosio 1.8 to allow nodes to decide which system contract to upgrade to and what state is allowed to be changed. I.e. nodes signaling hash of contract wasm and a hash of mutating state. System contract should introduce new action e.g. updatestate, through which the new DB state can be set.
In practice, the nodes approving the state change and the upgrade of the system contract will fork off from the rest of the network not approving the proposed changes. -
Further broke up system contracts to limit dependencies on the privileged accounts. The system contracts tend to be monolithic now because inter-contract communication is made difficult and is not very efficient. Adding support in the protocol to enable efficient synchronous calls between contracts would improve the composability of smart contracts on EOS and perhaps allow the system contracts to be rewritten in a more modular way. This would be ongoing work.
5. Congratulate yourself, EOS is now a proper public blockchain!
BPs can’t use God’s powers anymore, but they can still force specific accounts into 30 days eos delay of withdrawal (1 time only). If the abuse is strong enough, all network participants get asked to update the nodes and undergo the hardfork- which can include removal of the tokens.
Hardfork means all the nodes need to opt-in to such action, and offers a much higher standard to reach consensus than just coordinated bp multisig, thus making sure EOS becomes a neutral infrastructure for all Dapps.
