4 ms·
As many people on this forum know first hand, it's very, very hard to write that's 'perfect'. I've had the chance to write some fairly technically complicated E
by bluejellybean 5y ago
As many people on this forum know first hand, it's very, very hard to write that's 'perfect'. I've had the chance to write some fairly technically complicated EVM code (on chain contract upgrades with some other admin features), even the simple lines need a plethora of testing and review. This was a few years ago, but it took myself and another engineer, start to finish a couple months of dedicated effort to write what amounted to something like 5 source files. You have to know how the code executes with extremely high confidence up and down the entire stack, this takes time even with seasoned people. We ended up going through a security review with a third-party team, this is big money to do, high five figures for what amounted to two weeks of code review and pen testing! The problem is, without this serious dedication ($$) to making sure it's as good as you can get, projects are doomed to blow up like this. Hell, who knows what happens in 6 months after release when some EVM level bug gets discovered and directly exposes a hole in your contact. This might be different now, but a lot of contracts back then didn't have anyway to upgrade from those security exploits!
So from my point of view, you have this massive upfront cost, that I suspect the vast majority of teams are not paying, and you also have the chance of success being very low. Where have we seen this before, home automation seems to ring a bell and we've seen the security horror show with that. I don't mean to be such a downer on these projects, but they're really difficult to get right and audit. And when we're talking about putting millions(90!) of dollars into a thing, I don't really want to rely on the goodwill of some hackers to give me my money back. I wish the general public understood the security aspects of these contracts more, but people seem to see these hacks, shrug to themselves thinking they'll get debugged and fixed like normal software, and then continue on in life.
Unfortunately people are going to get burned in crypto by lack of experience, lack of review, lack of investment, and pure and simple scams.
- naasking 5y agoSounds like introducing some formal methods would be a good way to reduce costs auditing and verification costs. I know there's some work in that area in the Ethereum ecosystem, but I'm surprising it isn't prioritized more.
- int_19h 5y agoCase in point. Here's the line of code that introduced a bug in a contract that was ultimately worth $32M: https://github.com/openethereum/parity-ethereum/blame/4c32177ef3f4521c663113749400f5a8b6f0e0d4/js/src/contracts/snippets/enhanced-wallet.sol#L216 https://github.com/openethereum/parity-ethereum/blame/4c3217... https://blog.openzeppelin.com/on-the-parity-wallet-multisig-hack-405a8c12e8f7/ https://blog.openzeppelin.com/on-the-parity-wallet-multisig-... If you look at the associated pull request, it added over 2K lines of code, and removed almost 1K, spread across 20 different files. 5 files have changed so much, GitHub doesn't even show their diff by default. It was reviewed by one person in a single day.