Ethereum stakeholders are set to secure their future and prevent a repeat of the June 17 attack as they are bound to decide on a DAO rescue fix.
On Tuesday June 21, Ethereum announced the release of DAO Rescue HotFix 1.2.8, with the critical Ethereum soft-fork update aimed to rescue the stolen DAO funds. The proposed solution of this release is to freeze all transactions trying to move any funds from The DAO or the child DAOs.
However, the rescue fix is still for the miners to decide on.
Miners have limited power
Speaking to Cointelegraph, Christopher Franko, President of Borderless Charity, thinks that what miners are most concerned about at the moment is what would protect their funds.
According to Franko, these miners could oppose blacklisting and hardfork, but may not have any choice if the development team can convince all exchanges to upgrade as they may run the risk of losing value for their newly-mined tokens.
He says:
“Exchanges are the thumbscrew of the crypto-community. Ironically, the Ethereum developers can essentially extort the miners by using their authority and influence.”
James Clayton, Co-Founder and Community Manager at Expanse, says his company would rather focus on how to prevent the situation experienced by The DAO from happening again.
Prevention by compartmentalization
Clayton describes the Expanse DAO as a system of parent and child divisions which are completely isolated from each other. Basically, says Clayton, there is the mother division which has three child divisions.
These divisions are named: the founders division, the collective division, and the board of directors division. Each child has the ability to submit an allowance proposal to its parent division. An allowance proposal which can only be sent to a child, if two-thirds of the siblings agree to the proposal.
Clayton illustrates it with the following example:
“Say there is a bad actor who creates a spending proposition with the collective division. The collective division is a direct democracy smart contract which has a balance of $1,000,000. A participant then submits a spending request but he knows of a spending loophole which will allow him to receive more than he should and he drains the collective of $1m. That’s a terrible thing as the community just lost $1m. The collective is now out of money, and all the other proposals can’t be funded anymore, resulting in complete mayhem. The only way this division can get more funding is if it submits an allowance proposal to the parent division, and the siblings agree to send more. But why would they spend more? That contract is inherently flawed. The whitepaper also outlines the need for an upgrade ability, so a contract can shed its old self to become new with updated codes. Contract versioning, but that’s another post for another time.”
Prevention by limits
Clayton explains the introduction of failsafes in the form of limits on the Expanse DAO which will check the activities of bad actors attempting to extort funds from The DAO.
Clayton says:
“Imagine now for a moment, there is a bad actor extorting funds from The DAO and somehow he controls two-thirds of the other divisions. So he can pass allowance proposals himself. That sounds like the worst case scenario. Indeed it would be hectic. The Expanse DAO will have failsafes in the form of limits - both time limits and amount limits. First of all, the child divisions can only request an allowance from their parents once a month as determined by the amount of blocks in a month, and secondly, only at a maximum rate of some percentage of the total of their parent’s balance. So, each time they successfully receive their allowance they lower the maximum amount they can receive next time. This adds buffers in place which gives the community time to react without having to soft fork or hard fork or spoon anything.”
In conclusion, Clayton makes it clear that the future remains unpredictable, but developers can only try and put out the safest, most well-thought out code possible.
Also, he says that with meticulous planning, and implemented failsafes like compartmentalization and limit constraints, the odds of successfully warding off unwanted behaviours which might compromise projects will increase significantly.