3 ms·

I've said on a few forums that when I first basically just glanced at Solidity, the language for Ethereum, just scanning through the spec, I found a good 4 or 5

by jerf 4y ago

I've said on a few forums that when I first basically just glanced at Solidity, the language for Ethereum, just scanning through the spec, I found a good 4 or 5 things instantly wrong with it for such an important use case, some of which have gone on to be the root cause of serious hacks. I've only scanned over this, but this is a lot closer to something I'd expect for contracts. As a simple for instance, integer overflow aborts. You can quibble with whether that's exactly what it should do (especially since it seems aborts can't be recovered, which means a contract that starts aborting is basically dead?), but in a blockchain contract what it definitely shouldn't do is simply wrap around without any error or signal or something that says "hey, this is pretty suspicious". Not endorsing this, haven't studied it that deeply, but it at least passes the "does scanning over it reveal a ton of problems immediately?" test.

samatman 4y ago
If this combines with transactional semantics, which is table stakes for a language like this, then yes, any exceptional state which isn't accounted for should be equivalent to nothing whatsoever happening over the entire state change the contract was enacting. If only Solidity worked that way. But I guess databases weren't an important thing to study.
- jerf 4y ago
  It was more the complete inability to catch aborts that caught my eye. Aborting strikes me as a good enough default, but I might like to be able to recover from something bad happening. In the particular case of math you can still write a plus that detects whether it would overflow first, but in general catching aborts seems like a good bit of functionality. Personally, if I were writing a serious language like this I'd consider turning all + operations into things that return two results, one for the result and one for if it succeeded. Do it Go-style, do it with a Result type, I don't much care. The point is just that in the context of something like this, bringing it to the programmer's attention that + is not a safe operation on every usage is probably worth it. I reluctantly concede it is overkill in normal languages, but if there is ever a time to bite that bullet and make them do a full Result-style unpacking on every arithmetic operation, it's here.

by jerf 4y ago

samatman 4y ago

If this combines with transactional semantics, which is table stakes for a language like this, then yes, any exceptional state which isn't accounted for should be equivalent to nothing whatsoever happening over the entire state change the contract was enacting. If only Solidity worked that way. But I guess databases weren't an important thing to study.

jerf 4y ago
It was more the complete inability to catch aborts that caught my eye. Aborting strikes me as a good enough default, but I might like to be able to recover from something bad happening. In the particular case of math you can still write a plus that detects whether it would overflow first, but in general catching aborts seems like a good bit of functionality. Personally, if I were writing a serious language like this I'd consider turning all + operations into things that return two results, one for the result and one for if it succeeded. Do it Go-style, do it with a Result type, I don't much care. The point is just that in the context of something like this, bringing it to the programmer's attention that + is not a safe operation on every usage is probably worth it. I reluctantly concede it is overkill in normal languages, but if there is ever a time to bite that bullet and make them do a full Result-style unpacking on every arithmetic operation, it's here.