3 ms·

These kind of mistakes should not be possible in smart contracts if they are to become more mainstream. There has to be layers upon layers of defence built in t

by _pdp_ 5y ago

These kind of mistakes should not be possible in smart contracts if they are to become more mainstream. There has to be layers upon layers of defence built in to protect against common pitfalls. It is crazy that a single line can cause so much damage.

tankenmate 5y ago
Crypto pen testers will become a thing; plenty of central banks are making noises about starting blockchains.
ethanbond 5y ago
Maybe we could create a system to adjudicate such failures? ;)
jacoblambda 5y ago
There are better tools for this, they just aren't in common use unfortunately. Had this been written in Glow, both this bug and the bug that followed where another 7M was stolen would have been compile errors. This is just the consequence of people developing code in languages that provide little to no protection against their various footguns. At the very least we should expect to see some additional tool on top of the language that can reason about the correction of the code.
- ZephyrBlu 5y ago
  How would those bugs have been compile errors in Glow? I'm unfamiliar with it, but that sounds interesting.
  - jacoblambda 5y ago
    Had this contract been written in idiomatic glow, it would have been structured as a state machine and transitions would be forced to be explicit. You could specify invariants on the states as well as constrain the behaviour of the transitions. In this case the transition would have moved the SM out of the initialised state which would have precluded the ability to re-initialise the contract/state machine. Attempting to invoke said re-initialisation would cause a compile error. You could write the contract in such a way that would still allow this however it would be evident that something is amiss as it would be incredibly un-idiomatic and awkward. In the other case, the function had an implicit constraint that the value was within a certain bounds. The contract made no effort to check these bounds. With Glow you would have specified the constraints on the inputs and the interaction with the contract would be denied if the input for the function was outside those constrained bounds. This would be a compile error and possibly also a runtime check in the case of malicious actors ignoring bounds. I'm not sure how necessary the runtime check would be (as I'd have to check how the smart contract generation is set up) but at the very least the exploit would not have been able to occur.
paulpauper 5y ago
Then they will never become mainstream
chrisco255 5y ago
There's a lot of forks of existing code out there. Some of the people using the existing forked code don't understand how it really works, because they didn't write it and didn't bother to study it in detail. This is especially common on the Binance Smart Chain, which itself is a fork of Ethereum. The pitfalls will continue to happen, because it is a completely open system. The best, most audited and long-lived projects will rise to the top over time. But there will be a long tail of total flops or projects that get exploited in some way along the way. It is the Wild West, but you should understand that if you put your money into a smart contract, you are risking those funds. It's a powerful abstract, but with great power comes great responsibility. Do due diligence, don't invest a lot into new projects, have more faith in the ones that have held up over the long haul, and buy insurance when you can.

by _pdp_ 5y ago

tankenmate 5y ago

Crypto pen testers will become a thing; plenty of central banks are making noises about starting blockchains.

ethanbond 5y ago

Maybe we could create a system to adjudicate such failures? ;)

jacoblambda 5y ago

There are better tools for this, they just aren't in common use unfortunately. Had this been written in Glow, both this bug and the bug that followed where another 7M was stolen would have been compile errors. This is just the consequence of people developing code in languages that provide little to no protection against their various footguns. At the very least we should expect to see some additional tool on top of the language that can reason about the correction of the code.

ZephyrBlu 5y ago
How would those bugs have been compile errors in Glow? I'm unfamiliar with it, but that sounds interesting.
- jacoblambda 5y ago
  Had this contract been written in idiomatic glow, it would have been structured as a state machine and transitions would be forced to be explicit. You could specify invariants on the states as well as constrain the behaviour of the transitions. In this case the transition would have moved the SM out of the initialised state which would have precluded the ability to re-initialise the contract/state machine. Attempting to invoke said re-initialisation would cause a compile error. You could write the contract in such a way that would still allow this however it would be evident that something is amiss as it would be incredibly un-idiomatic and awkward. In the other case, the function had an implicit constraint that the value was within a certain bounds. The contract made no effort to check these bounds. With Glow you would have specified the constraints on the inputs and the interaction with the contract would be denied if the input for the function was outside those constrained bounds. This would be a compile error and possibly also a runtime check in the case of malicious actors ignoring bounds. I'm not sure how necessary the runtime check would be (as I'd have to check how the smart contract generation is set up) but at the very least the exploit would not have been able to occur.

paulpauper 5y ago

Then they will never become mainstream

chrisco255 5y ago

There's a lot of forks of existing code out there. Some of the people using the existing forked code don't understand how it really works, because they didn't write it and didn't bother to study it in detail. This is especially common on the Binance Smart Chain, which itself is a fork of Ethereum. The pitfalls will continue to happen, because it is a completely open system. The best, most audited and long-lived projects will rise to the top over time. But there will be a long tail of total flops or projects that get exploited in some way along the way. It is the Wild West, but you should understand that if you put your money into a smart contract, you are risking those funds. It's a powerful abstract, but with great power comes great responsibility. Do due diligence, don't invest a lot into new projects, have more faith in the ones that have held up over the long haul, and buy insurance when you can.