EOSCommunity.org Forums

EOS as Neutral Infrastructure

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;

  1. Realize the problem.
  2. Prepare and deploy mitigations for Dapps.
  3. Set up the new expectations to Dapps
  4. Reduce BPs God powers.
  5. 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.

  1. 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.

  2. 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 node (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;

  1. Remove the eosio.wrap contract and set the account to be unprivileged

  2. 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.

  3. 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.

10 Likes

I want to thank ÄŚrt and @arhag for his review and much-needed input :raised_hands:

This is a great proposal. Thanks for putting it forward, I really hope it gets taken up

1 Like

The process of getting invited to use the mitigations - I suppose it would be the group behind the msig that would do that. Such a group could provide smart contract certifications and require the contract to be open source, msiged itself and audited. Such a certification could provide some reputation for contracts that require instant liquidity even though they can’t participate in the time locks.

Having potentially multiple certification/protection groups that could back the recovery claim actions would be nice too. Some competition for these protection bodies, if Eos hosts multiple Eden communities you could imagine each such community offering those services to its members

Great suggestion.

In my opinion, this is an imperative. Regarding the logical reasoning behind the necessity of something like this, I very highly recommend watching this excellent presentation by Andreas Antonopoulous : Unstoppable Code: The Difference Between Can't and Won't - YouTube

We have implemented something a bit different, but which achieves the same goal on UX Network. We we call it eosio.freeze.

This is a feature which allows any account’s owner to mark their account as immutable.

An immutable account cannot have its keys or its code changed, even by a super majority of BPs (aka God mode).

Essentially, once an account is placed on this list, nodeos will treat any action modifying the account’s permissions or code as an invalid action, and will fork out.

This also requires a higher degree of participation into the network, ie: users / dapp developers / exchanges are encouraged to run their own nodes, and not depend on BPs infrastructure.

3 Likes

I agree. it’s a good suggestion.

1 Like

I agree, EOSio is not unstoppable code. I don’t care what you tell yourself to feel good about your investments i call it like i see it. I’ve come to this realization when BPs use their GOD Powers. This is what i was saying in the eos eden telegram group 3 days ago before I got kicked out for asking a simple question. and this was the question.

"Yes or No?
your are 1 or 3 of the top 21 Bps and the feds show up to top 15 Bps and want you to freeze account (A) worth $25million. for tax evasion or sanctions? would you comply.

Yes= (BPs God power) point of failure
No= your bullshiting unless you want to end up like John McAfee. I doubt any of to top BPs have spent 5min… in jail.
everyone is tough until they get punched in the face."

I’ve been here from the very begin of the chain and want to see nothing but good for this chain, but this GOD mode that BPs possesses makes eos not censorship resistant, not immutable, not a chain to continue to invest in, and your keys but not your cryptos. No one can change my Bitcoin keys, no miners can change my Decred keys, so if we give a few well connected BPs the power to do this when it benefit or affects them due to their mistakes, and would not / have not done this for other community members that have lost their life savings ( $120,000 back in Jan, 2019) we are going back to the old system where a few are in power and the rest of us are slaves. These are some reason eth members and other chains call us shitcoin, and takes us as a joke.

I say we completely get rid of this God mode ASAP. Thanks for your time and lets make this a real blockchain not some fake chain - that we could have built without a blockchain.
“Don’t give yourself POWER to stop unstoppable CODE.”

link to hacked account:

link to video about hacked account:

2 Likes

May require some finetuning but overall a good proposal

1 Like