You are viewing a single comment's thread from:
RE: Eosio.wrap (eosio.sudo) demystified
Excellent write up. Do you have some examples of how this will be used?
I started a conversation back in July about this functionality, and I'm still not clear exactly how it would be used.
Currently, 15/21 block producers can already change an account's keys or modify an account's contract at the request of ECAF or an account's owner.
Has any this been done yet on EOS and are there people wanting something to be done like this now?
I wonder if we need to get our governance system in place first (referendum voting to approve a constitution which clarifies the role of arbitration, etc) before we make tools easier for BPs to use which have the potential of... well... messing something up. :)
Thoughts?
An example would be the EOS 911 accounts. Users that can prove with an Ethereum transaction that they lost their EOS key can request a key change from ECAF or directly from block producers. Many users have requested this specific service and my guess is this will become the first use case.
I see this as another tool just like the referendum that will be needed for governance. It doesn't add new functionalities, but simplifies an existing one and makes it more transparent. Every action actually taken with this tool will still have to be approved by BPs.
Thanks for the reply. It still seems a bit odd to me to build a tool to make a process easier when that process hasn't been used at all yet. Are there actions related to the EOS 911 accounts that are on pause right now, waiting for this? If not, then I guess my question still stands. It worries me a bit based on lack of voter engagement (75% of token holders still aren't voting) so that a small number of people with a large number of tokens could vote in BPs they control and use functionality like this to quickly (and easily) do bad things.
if somebody votes in 15/21 bad BPs and runs an attack on the network we are screwed no matter what system we have in place. There aren't any specific actions on hold because of this right now though, no. The most immediate use case would be for blacklisting keys, we could do so more effectively instead of the current fragile system.
Thanks for the reply. I agree, if someone was well-coordinated enough for an attack, they would most likely also be ready with signed transactions to do whatever it is they wanted to do (steal people's money, reset account keys, etc)
Could you elaborate a bit more on the better blacklisting solution? I've known the blacklist approach is temporary (and very fragile) and an all-or-nothing approach which doesn't really follow other DPoS 2/3+1 approaches. How would EOSIO.WRAP improve this?
Members of eosdacserver like myself have voiced our concerns, but we did go ahead and approve the proposal to create the account.
We could blacklist by changing their keys to unusable values. The account would be inaccessible to everyone, the action wouldn't require constant vigilance from all producers, and 15/21 producers would be able to execute the action.
Makes sense. Blowing away the keys on an account would definitely nuke it out. I imagine the blockchain world will go crazy the first time this happens. The real question is if we're ready for a truly governed blockchain.
Thanks for the replies.