Questions about eosio.sudo for discussion.

A block producer has proposed a transaction which would create the eosio.sudo account which could then later be used to implement the eosio.sudo contract as described here:

https://github.com/EOSIO/eos/tree/master/contracts/eosio.sudo

I could not find much discussion about this very important idea, so I'd like to start a thread here. I'll add my own questions as a comment below to start off the discussion.

eosDAC Launch Team
@lukestokes on Twitter and Steemit

Comments

  • lukestokeslukestokes Posts: 14 Jr. Member - 1/5 EOS Tokens
    1. What problem does eosio.sudo solve?
    2. What are some real-world examples for how esio.sudo will be used?
    3. Since eosio.sudo was introduced on June 27 and depends on 1.0.8, it is new code for the EOSIO blockchain. Was it part of the original intent and is therefore a "fix" for something which was delivered incomplete or is it something new requiring a referendum vote?
    4. Do enough block producers, token holders, EOS dapp developers, exchanges, and other invested parties sufficiently understand the power of the eosio.sudo account and all the ways it could potentially be used by 15 block producers?

    eosDAC Launch Team
    @lukestokes on Twitter and Steemit

  • abourgetabourget Posts: 5 Brand New

    I think eosio.sudo solves the subjective blacklisting issue, to get started.

    If any ruling of ECAF requires freezing of accounts, refunds, or any other order that requires interfering with the normal authorization process, we need eosio.sudo to be able to execute them.

    No sudo, no enforcement of constitution.

  • abourgetabourget Posts: 5 Brand New

    The power it grants: eosio.sudo allows 15/21 elected BPs to pass a transaction on behalf of someone else, by skipping auth checks.

  • andybetsandybets Posts: 2 Brand New

    Is a transaction carried out on behalf of another account using sudo indistinguishable from it being done by the true account? I'm hoping not.

  • robrigorobrigo Posts: 6 Brand New

    eosio.sudo and rmvproducer are two "superpowers" that I believe should be discussed and publicized further. At the very least, it should be publicly known when these types of actions are intended to be used.

    @andybets said:
    Is a transaction carried out on behalf of another account using sudo indistinguishable from it being done by the true account? I'm hoping not.

    One distinction is who signed it, since the transaction has at least 15 BP signatures.

    Rob Konsdorf
    @robrigo
    EOS Detroit
    https://eosdetroit.io

  • lukestokeslukestokes Posts: 14 Jr. Member - 1/5 EOS Tokens

    @abourget said:
    No sudo, no enforcement of constitution.

    Since there's a new constitution being proposed which doesn't mention ECAF and is clear about what is and isn't included:

    Ricardian contractual terms that cannot be enforced by properly functioning code are beyond the scope of the producers authority to evaluate and enforce.

    I tend to think this eosio.sudo power to "freeze accounts, refunds, or any other order that requires interfering with the normal authorization process" may not even be a thing under this new constitution.

    Since accepting the constitution requires a referendum and the existing constitution was never agreed to, I personally think we should tread very carefully when it comes anything mentioned in the existing constitution that is not supported by the new constitution.

    For my questions, here are some personal answers as they stand now.

    1. Unclear. It may attempt to give powers a new constitution would not allow anyway, making the account and contract not needed (and unconstitutional).
    2. The only examples I can come up with seem to not fit the new constitution unless there's a situation where a contract is broken (i.e. does not fit the intent of the Ricardian Contract) in such a way as it needs to be frozen. I can't imagine why the contract owner would be unable to do so, unless they nulled out the private key to make the contract immutable. In that case, I could see an eosio.sudo being useful.
    3. It sounds to me like it requires a referendum, just like the constitution. That would imply, to me, that until this is in place, malfunctioning code can not be frozen by block producers. The enforced rules for governance should be in place before the tools for governance.
    4. I don't think so. Before we create a powerful tool like this, I would prefer a large educational campaign and a referendum vote to ensure this is what people really want out of EOSIO.

    eosDAC Launch Team
    @lukestokes on Twitter and Steemit

  • andybetsandybets Posts: 2 Brand New
    edited July 6

    @robrigo said:
    One distinction is who signed it, since the transaction has at least 15 BP signatures.

    Thanks. For some reason I didn't see that the actions:authorization would be different too.

  • HyDRosHyDRos Posts: 1 Brand New

    @lukestokes I think for the time being we need to be able to enforce the current constitution and Block Producer agreement..

  • tanishtanish Posts: 4 Brand New

    Could eos.sudo help a dapplication perhaps the dapplication arbitration forum to bypass the authority/BPs to stop transaction or freeze accounts?

  • lukestokeslukestokes Posts: 14 Jr. Member - 1/5 EOS Tokens

    @HyDRos said:
    @lukestokes I think for the time being we need to be able to enforce the current constitution and Block Producer agreement..

    Enforce it how? It seems to me, the community, including Dan/Block One, (and the wider cryptocurrency community in general) responded very negatively to the blacklist approach to freezing accounts. Even ECAF put a header up on their site saying they would not deal with cases of lost keys related to the ETH to EOSIO shift.

    It's unclear to me how this power would be used in a good way (even under the current constitution) in a way that wouldn't ultimately damage EOS more.

    eosDAC Launch Team
    @lukestokes on Twitter and Steemit

  • lukestokeslukestokes Posts: 14 Jr. Member - 1/5 EOS Tokens

    @tanish said:
    Could eos.sudo help a dapplication perhaps the dapplication arbitration forum to bypass the authority/BPs to stop transaction or freeze accounts?

    Only a 2/3+1 majority of the top voted BPs would be able to execute a sudo transaction.

    eosDAC Launch Team
    @lukestokes on Twitter and Steemit

  • k26drk26dr Posts: 2 Brand New

    Reposting my thought from the EOS Mainnet BPs chat here:

    I think ECAF/arbitration should be included in the eosio.sudo process. Give their key a weight of 21, each of the BPs a weight of 1, and set the threshold to 36. the ECAF account itself should be a multisig between each arbitrator. When would we ever be changing an owner key or taking any sudo action without ECAF? We shouldn't be.

    also there should be specific restrictions. instead of a general exec, I would prefer to see a chownerkey function that does nothing but change the owner key of an account. Is there any use case we've determined for sudo so far other than changing owner keys?

  • k26drk26dr Posts: 2 Brand New

    Adding ECAF to the eosio.sudo multisig would have the added benefit that a single whale with the ability to vote in 15 of their own producers temporarily could not use sudo powers. They would have to compromise ECAF as well.

  • lukestokeslukestokes Posts: 14 Jr. Member - 1/5 EOS Tokens

    Interesting idea, @k26dr Do you have any concerns that this might weaken how DPOS itself functions? Given so much power to ECAF members which have no skin in the game (such as token holders do) concerns me quite a bit. That said, the way you've outlined it does make sense since you still need the 15 BPs, but you also need ECAF to agree. That makes sense as that is the intention for how something like sudo is used, as far as I can understand. I'm also wondering if it would be possible to not have specific solutions, not just a generic solution. By that I mean, a specific transaction with specific rules to make specific changes as agreed to by ECAF and the BPs and the token holders and submit that as an msig. I don't know if that's possible without a sudo account, but that seems to be the ideal approach. Another option would be to require a unanimous decision to use sudo to raise the bar for an attach vector, but even then, I don't really like it much as it gives too much generic as you said.

    eosDAC Launch Team
    @lukestokes on Twitter and Steemit

  • abourgetabourget Posts: 5 Brand New

    Even with eosio.sudo loaded.. any transaction would still need 15/21 approval.. sudo doesn't do a dime, until some txs are proposed therein.

  • lukestokeslukestokes Posts: 14 Jr. Member - 1/5 EOS Tokens

    @abourget said:
    Even with eosio.sudo loaded.. any transaction would still need 15/21 approval.. sudo doesn't do a dime, until some txs are proposed therein.

    I get that, but it's a bit like saying "a nuclear weapon doesn't do anything until you enter the launch codes and hit the red button."

    If having a sudo account is a dangerous thing because of the potential for it to be used in very bad ways, then we should consider that carefully before moving forward. One example of a potential security concern I heard was if someone had enough staked EOS to quickly vote in 15 sock puppet accounts as BPs (and with the current low voter turnout of 30%, that's not outside of the realm of possibility), they could essentially vote themselves in, quickly do something bad with sudo, and then vote themselves out again. This could be as damaging to EOS as the DAO hack was for ETH which created ETC.

    Without clarity on exactly how the sudo account will be used or what will govern it, I'm currently thinking its quite a dangerous tool. Maybe not as much as a nuke, but still something we should consider very carefully if we even want as an option.

    @abourget what are some example txs you can imagine (i.e. what would they do) and how would they come about (as in, who would propose them)? Also, would version 1.0 or 2.0 of the constitution impact how it is used, in your opinion?

    eosDAC Launch Team
    @lukestokes on Twitter and Steemit

  • abourgetabourget Posts: 5 Brand New

    @lukestokes said:
    [...] One example of a potential security concern I heard was if someone had enough staked EOS to quickly vote in 15 sock puppet accounts as BPs (and with the current low voter turnout of 30%, that's not outside of the realm of possibility), they could essentially vote themselves in, quickly do something bad with sudo, and then vote themselves out again. This could be as damaging to EOS as the DAO hack was for ETH which created ETC.

    This is simply a misunderstanding. The EOS blockchain provides a privileged flag that makes an account skip auth checks. That's a baked-in feature, it's part of the design.. sudo is just a facility around this feature.

    Adding sudo is a matter of signing a single transaction with ~7 actions: newaccount and friends, plus setcode and setabi.

    If someone were to vote 15 BPs into place (which is an extreme scenario), then they can inject sudo and any other action in the very same transaction .. it's game over already. Not injecting sudo gives zero protection against that vector, which again, is the crux of DPoS.

    Though, if there's an emergency that requires quick action, and BPs haven't injected sudo , they might be unable to do the right thing in a timely fashion.

    We still need to review transactions that attempt to use sudo, and still need 2/3+1 approvals for those to go through.

  • lukestokeslukestokes Posts: 14 Jr. Member - 1/5 EOS Tokens

    @abourget said:
    unable to do the right thing in a timely fashion.

    Can you give some examples of what the right thing might be? I'm still not clear on how sudo would ever be used correctly by BPs, especially given the current constitutional flux we're in.

    I do hear your point that an attacker could also include the addition of the sudo powers as part of that scenario anyway, so that does make sense to me.

    eosDAC Launch Team
    @lukestokes on Twitter and Steemit

Sign In or Register to comment.