1

I've seen a particular code style, where after any "critical" state modification operation, a check is done in order to assess the true good result of the operation.

Something like:

uint _count = currentStruct.count--;
assert(currentStruct.count == --_count); 
// check and revert if something is strange

or

currentStruct.level = 0;
assert(currentStruct.level == 0);

or

currentStruct.level = externalContract.zerosCurrentLevel();
assert(currentStruct.level == 0);

where those operations are to be considered critical because either they are:

  1. very costly in terms of possible manipulation;
  2. depending on the results of some external contracts deployed elsewhere
  3. and so on.

Is this a justified way of code, or it is simply redundant? And if it be justified, why and when?

==== after comments ====

After that both goodvibration and Rob constructively commented, I precise that, as far as I understood, the problem were not to check for overflow, but for proper EVM context execution of the operation to be checked. It was said to me that it is not clear today what will be an attack tomorrow and that checking whatever critical (for double spending for instance, or to avoid reentrancy attacks) can avoid future problems. In that sense even if today it is not clear why they are checking, tomorrow they should discover that their code in not attack-able by some new attack... this is the declared rationale.

  • 2
    Only the last one looks like it has a good reason for an assertion, because your code is guaranteed to execute in a synchronous manner. – goodvibration Apr 1 '19 at 14:55
  • 1
    It strikes me as proceeding without confidence or clarity about what needs to be checked. I can think of other possibilities. Maybe it is not the final golden code. Maybe they are peppering the code with trivial assertions to help a code analyzer double-check their understanding. It's weird. The first one, for example, would use SafeMath (or similar logic) to watch out for underflow, which it does not do. It implies that the author doesn't have a firm grasp of dangers worthy of checking. – Rob Hitchens Apr 1 '19 at 16:52
  • As far as I understood, the problem were not to check for overflow, but for proper EVM context execution of the operation to be checked. It was said to me that it is not clear today what will be an attack tomorrow and that checking whatever critical (for double spending for instance, or to avoid reentrancy attacks) can avoid future problems. In that sense even if today it is not clear why they are checking, tomorrow they should discover that their code in not attack-able by some new attack... this is the rationale. – Rick Park Apr 1 '19 at 17:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.