5 ms·

>"It’s important to understand that this exploit was not a vulnerability in Ethereum or in Parity itself." I mean.... I guess. It's a feature of Ethereum, if w

>"It’s important to understand that this exploit was not a vulnerability in Ethereum or in Parity itself." I mean.... I guess. It's a feature of Ethereum, if we're going to weasel around.

formula1 9y ago
I think most developers know not to eval() Why would you execute arbitrary text in any other languages?
- pipermerriam 9y ago
  Your parallel is not an accurate one. One of the key and powerful features of the Ethereum Virtual Machine or, EVM, is the ability to delegate execution to external libraries. You can think of this much the same way you think of installing 3rd party libraries in your favorite programming language of choice. In the EVM you can write a "library" which performs some common functionality such as manipulation of date-time objects much like the `datetime` library in Python. Any other contract may then make use of this code simply by delegating execution to the deployed library address. This has inherent risks that every Ethereum developer should understand fully, but with that risk comes some incredible power and potential. There currently is no "Standard Library" for the EVM but it is looking very likely that it will be comprised of this type of contract. Slowly, overtime, these library contracts will be written and deployed to the network. There is work being done on using theorem solvers to mathematically prove that a contract satisfies certain properties which opens the door to a "provably correct" standard library. I know of no other computing environment or packaging system that has these properties. For me, it has been an enlightening subject and I feel like we've only just scratched the surface.
  - int_19h 9y ago
    A serious question: are the benefits really worth it? How much overhead would it be to just include the library code directly into the contracts instead (so that the whole thing can be verified as a single black box)?
    - buttershakes 9y ago
      Its not really worth it. Very over complicated. Really they just need to do code/data deduplication on chain somehow and forget about using contracts as libraries in this way.
    - pipermerriam 9y ago
      I think the answer to that question is extremely contextual and going to be very different for different applications. I also think that I'd like to point out that the idea of including the library code within the contract is untennable at a certain level as contracts currently have an upper limit on size which is determined by the block gas limit. It also doesn't make it any safer because it's still functionally the same as executing external code because it's the same code being executed.
  - bvrmn 9y ago
    The parallel is totally damn right. eval with an unverified user input. > _walletLibrary.delegatecall(msg.data) Dunno how much contracts in the wild have such brilliant feature.
lowpro 9y ago
I know I'm this situation the dev made a simple mistake, but I wonder if Ethereum is safe as a system assuming developers will make many mistakes, and those mistakes will happen more often as more complicated contracts are written. At some point I wonder if the idea of smart contracts is better than a traditional system, since they seem prone to developer error due to complexity.
- icelancer 9y ago
  >At some point I wonder if the idea of smart contracts is better than a traditional system, since they seem prone to developer error due to complexity. The idea is incredible. Groundbreaking. Honestly super interesting to me. The execution of them as law is... well, going about as expected. This is why the law doesn't actually work this way.
- hn_throwaway_99 9y ago
  > I know I'm this situation the dev made a simple mistake, but I wonder if Ethereum is safe as a system assuming developers will make many mistakes, and those mistakes will happen more often as more complicated contracts are written. This will probably come off as being assholish, but I honestly don't mean it to be: you should read the rest of the article. It actually covers this topic in depth and has good thoughts on this fundamental issue with smart contracts.
  - lowpro 9y ago
    Honestly I read the comments first, I enjoy and learn from HN comments often more than the original article. Thanks for pointing out I was missing context.
  - bastawhiz 9y ago
    The rest of the article amounts to a few points: - Humans make mistakes, the tools should have been better - The technology to make Ethereum safe doesn't really exist - We should work to make that technology exist - We should be happy this happened since it raises awareness about the problem > In the end, attacks like this are good for the community. They call you to your senses and force you to keep your eyes open. What?! Listen, just because Valgrind exists doesn't mean you can't accidentally write a C program with memory errors. Just because Rust protects against race conditions doesn't mean you can't have bugs in your threading code. We're not even close to a world where tools can offer amazing protection. > The developer here was Gavin Wood, one of the co-creators of Ethereum, and the inventor of Solidity, the smart contract programming language. The code was also reviewed by other Parity contributors. This is basically the highest standard of programming that exists in the Ethereum ecosystem. This was an error made by the best of the best, reviewed by the best of the best. The tools that will save us from this madness don't exist. What does this mean for Joe Developer? It means he's not going to build something that he keeps anything of value on. The author's cheery "we'll be stronger for this!" attitude completely neglects the obvious chilling effect that this is having. If the guy that invented the damn thing can't protect his $31 million dollars, why would I even try to build something that could manage even hundreds of dollars? And to that end, is it really better than a traditional system?

>"It’s important to understand that this exploit was not a vulnerability in Ethereum or in Parity itself." I mean.... I guess. It's a feature of Ethereum, if we're going to weasel around.

formula1 9y ago

I think most developers know not to eval() Why would you execute arbitrary text in any other languages?

pipermerriam 9y ago
Your parallel is not an accurate one. One of the key and powerful features of the Ethereum Virtual Machine or, EVM, is the ability to delegate execution to external libraries. You can think of this much the same way you think of installing 3rd party libraries in your favorite programming language of choice. In the EVM you can write a "library" which performs some common functionality such as manipulation of date-time objects much like the `datetime` library in Python. Any other contract may then make use of this code simply by delegating execution to the deployed library address. This has inherent risks that every Ethereum developer should understand fully, but with that risk comes some incredible power and potential. There currently is no "Standard Library" for the EVM but it is looking very likely that it will be comprised of this type of contract. Slowly, overtime, these library contracts will be written and deployed to the network. There is work being done on using theorem solvers to mathematically prove that a contract satisfies certain properties which opens the door to a "provably correct" standard library. I know of no other computing environment or packaging system that has these properties. For me, it has been an enlightening subject and I feel like we've only just scratched the surface.
- int_19h 9y ago
  A serious question: are the benefits really worth it? How much overhead would it be to just include the library code directly into the contracts instead (so that the whole thing can be verified as a single black box)?
  - buttershakes 9y ago
    Its not really worth it. Very over complicated. Really they just need to do code/data deduplication on chain somehow and forget about using contracts as libraries in this way.
  - pipermerriam 9y ago
    I think the answer to that question is extremely contextual and going to be very different for different applications. I also think that I'd like to point out that the idea of including the library code within the contract is untennable at a certain level as contracts currently have an upper limit on size which is determined by the block gas limit. It also doesn't make it any safer because it's still functionally the same as executing external code because it's the same code being executed.
- bvrmn 9y ago
  The parallel is totally damn right. eval with an unverified user input. > _walletLibrary.delegatecall(msg.data) Dunno how much contracts in the wild have such brilliant feature.

lowpro 9y ago

I know I'm this situation the dev made a simple mistake, but I wonder if Ethereum is safe as a system assuming developers will make many mistakes, and those mistakes will happen more often as more complicated contracts are written. At some point I wonder if the idea of smart contracts is better than a traditional system, since they seem prone to developer error due to complexity.

icelancer 9y ago
>At some point I wonder if the idea of smart contracts is better than a traditional system, since they seem prone to developer error due to complexity. The idea is incredible. Groundbreaking. Honestly super interesting to me. The execution of them as law is... well, going about as expected. This is why the law doesn't actually work this way.
hn_throwaway_99 9y ago
> I know I'm this situation the dev made a simple mistake, but I wonder if Ethereum is safe as a system assuming developers will make many mistakes, and those mistakes will happen more often as more complicated contracts are written. This will probably come off as being assholish, but I honestly don't mean it to be: you should read the rest of the article. It actually covers this topic in depth and has good thoughts on this fundamental issue with smart contracts.
- lowpro 9y ago
  Honestly I read the comments first, I enjoy and learn from HN comments often more than the original article. Thanks for pointing out I was missing context.
- bastawhiz 9y ago
  The rest of the article amounts to a few points: - Humans make mistakes, the tools should have been better - The technology to make Ethereum safe doesn't really exist - We should work to make that technology exist - We should be happy this happened since it raises awareness about the problem > In the end, attacks like this are good for the community. They call you to your senses and force you to keep your eyes open. What?! Listen, just because Valgrind exists doesn't mean you can't accidentally write a C program with memory errors. Just because Rust protects against race conditions doesn't mean you can't have bugs in your threading code. We're not even close to a world where tools can offer amazing protection. > The developer here was Gavin Wood, one of the co-creators of Ethereum, and the inventor of Solidity, the smart contract programming language. The code was also reviewed by other Parity contributors. This is basically the highest standard of programming that exists in the Ethereum ecosystem. This was an error made by the best of the best, reviewed by the best of the best. The tools that will save us from this madness don't exist. What does this mean for Joe Developer? It means he's not going to build something that he keeps anything of value on. The author's cheery "we'll be stronger for this!" attitude completely neglects the obvious chilling effect that this is having. If the guy that invented the damn thing can't protect his $31 million dollars, why would I even try to build something that could manage even hundreds of dollars? And to that end, is it really better than a traditional system?