You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Programmers make mistakes and cause bugs which can affect large sums of money (In centralized systems it’s relatively easy to take a rollback decision and the damage is diminished)
The risk:
People will lose faith in Ethereum when more cases like Parity’s loss of 500k Ether will occur (They’ll be afraid of losing their money when trusted services make such huge mistakes)
The solution:
Enabling a secure hook in a smart contract which will redirect execution to a substitute smart contract which will get activated when the following conditions are met:
The contract owner has activated the hook
The community has consensus on the substitute smart contract presented by the contract owner
Though a fork will be needed to add this mechanism to the system, No fork is needed when requesting to activate a hook. If at least 51% of the community votes for the substitute contract, it is added to the chain, and the replaced contract redirects to the substitute
This solution still doesn’t solve the case when someone else is able to take ownership of the contract, but it could solve many other critical bugs cases.
The text was updated successfully, but these errors were encountered:
This could be quite beneficial for the commercially minded prototypers/experimenters, but i wonder to what extent the 51% requirement actually matters for individual contract addresses? I'm sure that's a silly question, but could zero knowledge -type proofs be used as well in this back-up process? Just wondering
The problem:
Programmers make mistakes and cause bugs which can affect large sums of money (In centralized systems it’s relatively easy to take a rollback decision and the damage is diminished)
The risk:
People will lose faith in Ethereum when more cases like Parity’s loss of 500k Ether will occur (They’ll be afraid of losing their money when trusted services make such huge mistakes)
The solution:
Enabling a secure hook in a smart contract which will redirect execution to a substitute smart contract which will get activated when the following conditions are met:
The contract owner has activated the hook
The community has consensus on the substitute smart contract presented by the contract owner
Though a fork will be needed to add this mechanism to the system, No fork is needed when requesting to activate a hook. If at least 51% of the community votes for the substitute contract, it is added to the chain, and the replaced contract redirects to the substitute
This solution still doesn’t solve the case when someone else is able to take ownership of the contract, but it could solve many other critical bugs cases.
The text was updated successfully, but these errors were encountered: