4 ms·

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 anot

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.

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.