Ever since the Slockit DAO hack, some if not most ethereum smart contracts have used a fail safe mechanism that is actually very vulnerable and not very fail safe.
Ethereum is Turing complete. So you can code everything and anything in a smart contract. That includes something like do everything the code says, but not if a private key signs to tell you otherwise.
This fail safe mechanism or backdoor was found necessary after a bug in the Slockit DAO drained the smart contract. An understanding thus was reached that smart-contracts need some oversight.
The problem is that such oversight can go very wrong because if you have access to the private key, you now have control of the smart contract.
An example of this was shown recently after someone managed to buy many Oyster tokens at the ICO price as was allowed by the smart contract under the only director or is owner function.
Oyster token backdoor, November 2018.
We can see here that the smart contract owner can re-open the ICO . Why this function was coded is not very clear. The smart contract allowed the owner to basically remove this function, but the owner never did so.
FunFair, another dapp, is accused of allowing the owner or in this case the controller to reverse token transactions and to print tokens out of thin air.A representative from FunFair says :
“This is neither a bug, nor a vulnerability. It is an upgrade mechanic. If we didn’t have this mechanism we would never be able to add functionality to the token. We would also not be able to address real bugs and vulnerabilities in the contracts if they were to be discovered.”
FunFair backdoor, November 2018.
FunFair is sort of doing what is kind of established practice and they’re far from the only one to have such overriding mechanism.
As such, they do not stand out for any particular criticism, but only as an example of what many may consider as both a bug and a vulnerability.
The vulnerability being of course that the owner can go rogue or can be hacked. Meaning there is a great degree of trust required.
Arguably, such added requirement is not necessary. The SlockitDAO did fail and there are lessons from that including that fail safe mechanisms are necessary. The fail safe mechanism, however, doesn’t have to be one private key because that too has failed and will fail.
“DAOs are the most important application of blockchain.
Only through DAOs we will be able to develop, launch and maintain the decentralized infrastructure we want to create.
They replace the last central point: Us.They are coming.”
So says Stefan George, an eth dev at Gnosis. He might not mean what we do, but basically the fail safe mechanism can be all the token holders themselves.
Instead of having one private key, you can have a vote of all token holders. That’s not a perfect mechanism, it has its own problems, but it is a lot more perfect than any other mechanism.
You can have a function for example to say something like everything applies unless 51% of token holders say it doesn’t.
The obvious question there is what happens if the hacker manages to gain a lot of tokens through a bug or otherwise. One answer being that you give different weight to tokens based on time of transfer.
As stated ethereum is Turing complete, so you can have all sorts of algorithms to say for example if address moved x% of tokens in the past week or whatever then it is discounted or has only 1/10 the weight of if address is “old.”
So bringing the days destroyed concept to vote weighing which could address this specific concern.
That wouldn’t be easy to implement and as everything created by intellect it probably has its own problems. Eventually, however, a template could arise where through time a certain trustless set of code is established as a fail safe mechanism.
The current very lazy solution might be excusable because this space is still just a toddler, but it isn’t a safe solution and it isn’t a workable solution except for temporarily. It is actually a problem.
Another lazy solution might be to have this isowner control, but after x blocks or once the median time of blocks is a year from now, then isowner control is removed.
As appealing as that sounds, one can also see it as the worst of both worlds. The owner has however much time to go rogue or be hacked and if he/she isn’t, then you’re left with no fail safe mechanism or a way to upgrade the contract.
Obviously for some cases that might be desirable. We might perhaps not want a holders vote and whatever politics that might come with it for certain smart contracts. We might perhaps want it to be set in stone, bugs and all.
On the other hand, for some smart contracts some human oversight might be desirable perhaps indefinitely. Having such oversight in just one human, or more probably in a chopped private key Shamir Secret style, can have its own problems.
While if it is a well designed voting algorithm that automatically acts based on the vote results, then the problem of bugs and hacks might be solved overall.
Designing such algorithm is a different matter, but it is probably coming as it is desirable from manny angles to not have a single point of failure.
Copyrights Trustnodes.com
