5 ms·

I'll never forget this pull request. Just having these two `internal` keywords there would have saved $150 million dollars. https://github.com/paritytech/pari

I'll never forget this pull request. Just having these two `internal` keywords there would have saved $150 million dollars. https://github.com/paritytech/parity/pull/6102/files#diff-8ea4aa7c2ba715c683bc764337f51585 https://github.com/paritytech/parity/pull/6102/files#diff-8e... A lot of people think "smart contracts" are inherently insecure. I personally believe that most of the "hacks" were very preventable, if those who had written the code slowed down to think about what they were doing.

zitterbewegung 9y ago
From the article they address your point. https://dasp.co/#item-10 https://dasp.co/#item-10 A lot of "hacks" are preventable in hindsight though. I think the real issue is that we are just beginning to secure smart contracts and its more about the process than the person who made a mistake. The tooling for Solidity is alright but most of the EVM and the languages associated with it are in their infancy. Formal Verification might be a solution here but we also have to consider the developer ergonomics of writing secure smart contract code.
- deleted 9y ago
  [deleted]
CJefferson 9y ago
This reminds me of 'Poya-Yoke', which is (as I understand it) about making accidents less likely by design. Functions should be carefully chosen to be externally visible, so why not make internal the default. When designing contracts, the language should be making every possible effort to be safe by design.
- jjallen 9y ago
  Totally agree about making `internal` the default visibility for Solidity/EVM functions. Should also require visibility to be declared (right now just compiler warnings happen).
- pmoriarty 9y ago
  Related to this is the maxim to "make it easy to do the right thing, and difficult to do the wrong thing". When applied to programming, a first step towards that could be as simple as using a safer language, where it's more difficult to shoot oneself in the foot, and where all sorts of errors are prevented by default.
cortesoft 9y ago
Every single mistake in the world is preventable under your definition, though; every single mistake has an alternative action that was a non-mistake, and if only the people had thought more and chosen the non-mistake course of action the mistake would have been prevented. If a ‘mistake’ has no alternative that would have prevented it, it is no longer a mistake and it is instead a tragedy. This doesn’t help us prevent the mistake in the future, though. You can’t prevent bugs and vulnerabilities in code by just mandating that everyone think more before acting. This is why we have a rule during our learning reviews at work following an incident that the action item can’t be, “be more careful next time.” That is not an action item, that is magical thinking. We have a saying at my work - “plan for a world where we are just as stupid tomorrow as we are today”
- thaumasiotes 9y ago
  > every single mistake has an alternative action that was a non-mistake This is only true for a very narrow view of what a "mistake" is. Classical tragedy is more inclined to the view that in some situations, there will be at least one mistake somewhere no matter what choices people make. In a more contemporary source, there's an episode of Friends in which the backstory is that, years ago, Phoebe married a gay ice dancer so that he could get a green card, and also because she was secretly in love with him. He comes back to ask for a divorce because he's learned that he isn't gay after all and he's fallen in love with another girl. This is painful for Phoebe, and she asks "Do you think, if you'd realized you weren't gay earlier, that we could have..." "Never mind, I don't think there's any answer you could give that would make me feel better."
specialist 9y ago
How wrong am I to equate "smart contracts" with a general purpose protocol negotiation thingie? Like TLS handshakes, but with code vs a spec? Or like a two party constraint satisfaction solver?
- jobigoud 9y ago
  A smart contract can have persistent state, so it's more than just code it's also data. You can have a notion of users and privileges baked in the contract for example.
ssdd 9y ago
Its mostly these minute details that gets overlooked during code reviews which leads to bigger problems. Bigger design mistakes rarely happen.

zitterbewegung 9y ago

From the article they address your point. https://dasp.co/#item-10 https://dasp.co/#item-10 A lot of "hacks" are preventable in hindsight though. I think the real issue is that we are just beginning to secure smart contracts and its more about the process than the person who made a mistake. The tooling for Solidity is alright but most of the EVM and the languages associated with it are in their infancy. Formal Verification might be a solution here but we also have to consider the developer ergonomics of writing secure smart contract code.

deleted 9y ago
[deleted]

CJefferson 9y ago

This reminds me of 'Poya-Yoke', which is (as I understand it) about making accidents less likely by design. Functions should be carefully chosen to be externally visible, so why not make internal the default. When designing contracts, the language should be making every possible effort to be safe by design.

jjallen 9y ago
Totally agree about making `internal` the default visibility for Solidity/EVM functions. Should also require visibility to be declared (right now just compiler warnings happen).
pmoriarty 9y ago
Related to this is the maxim to "make it easy to do the right thing, and difficult to do the wrong thing". When applied to programming, a first step towards that could be as simple as using a safer language, where it's more difficult to shoot oneself in the foot, and where all sorts of errors are prevented by default.

cortesoft 9y ago

Every single mistake in the world is preventable under your definition, though; every single mistake has an alternative action that was a non-mistake, and if only the people had thought more and chosen the non-mistake course of action the mistake would have been prevented. If a ‘mistake’ has no alternative that would have prevented it, it is no longer a mistake and it is instead a tragedy. This doesn’t help us prevent the mistake in the future, though. You can’t prevent bugs and vulnerabilities in code by just mandating that everyone think more before acting. This is why we have a rule during our learning reviews at work following an incident that the action item can’t be, “be more careful next time.” That is not an action item, that is magical thinking. We have a saying at my work - “plan for a world where we are just as stupid tomorrow as we are today”

thaumasiotes 9y ago
> every single mistake has an alternative action that was a non-mistake This is only true for a very narrow view of what a "mistake" is. Classical tragedy is more inclined to the view that in some situations, there will be at least one mistake somewhere no matter what choices people make. In a more contemporary source, there's an episode of Friends in which the backstory is that, years ago, Phoebe married a gay ice dancer so that he could get a green card, and also because she was secretly in love with him. He comes back to ask for a divorce because he's learned that he isn't gay after all and he's fallen in love with another girl. This is painful for Phoebe, and she asks "Do you think, if you'd realized you weren't gay earlier, that we could have..." "Never mind, I don't think there's any answer you could give that would make me feel better."

specialist 9y ago

How wrong am I to equate "smart contracts" with a general purpose protocol negotiation thingie? Like TLS handshakes, but with code vs a spec? Or like a two party constraint satisfaction solver?

jobigoud 9y ago
A smart contract can have persistent state, so it's more than just code it's also data. You can have a notion of users and privileges baked in the contract for example.

ssdd 9y ago

Its mostly these minute details that gets overlooked during code reviews which leads to bigger problems. Bigger design mistakes rarely happen.