Seeing how security and actual software
engineering often comes as an afterthought, instead of serving as a fundamental requirement, it comes to very little surprise to be honest. I guess that's the downside of the comparably low entry level when it comes to developing crypto related software (as opposed to, say, traditional finance, military and aircraft applications).
Properly handling immutable, decentralized transactions is
hard and mistakes are costly without recourse. Even moreso when it comes to smart contracts. It seems like a lot of companies and developers haven't yet fully fathomed the implications of what processing irreversible scripts and transactions really means.
I mean...
There was a bug on Bitgrail where if you placed two orders you got double balance added to your account. You could then withdraw while the orders were up and steal the coins. You had negative balance in the end but you could just make a new account.
What the. Actual. Fuck. That would be bad enough in traditional finance or actually
any online application that handles money. But in crypto such a bug becomes fatal.
The cryptocurrency most commonly associated with catastrophic bugs is ethereum. Thats not due to its underlying code, but on account of the smart contracts that can be built on top of the ethereum framework.
Here's the next thing. Granted, if Solidity where more strict and rigorous its developer base would likely be much much smaller. Nonetheless I'd argue that such strictness would be required to allow somewhat reliable smart contracts. With Solidity it may not be a code issue, but it's definitely a design issue. I don't follow Ethereum all that much, so I might be missing parts of the big picture, but what I always ask myself is: If blockchain veterans such as the Ethereum development team is unable to design a sound smart contract platform, how can we expect blockchain rookies -- which is what most of us are, given how young crypto is -- to implement reliable smart contracts on that very same platform?
Sorry if this post comes off as ranty, I guess irresponsible code just kind of grinds my gears.
I wholeheartedly agree with you. I couldn't believe that there was apparently a
client-side JavaScript exploit on that Bitgrail exchange, where that was the only check it had to verifying an accounts balance!?! Seriously, code that runs in someone's web browser, wtf? That type of foolishness wouldn't make the cut for a web game, to say nothing of financial transactions of real value.
In my view, best-practices standards are needed for security and code audits. There are many attempts at this out there, it needs to be pulled together, structured and maintained like RFC or BIP standards are, and proliferated through the field. Especially considering we are dealing with a rapidly evolving technology, these standards need to be maintained on an ongoing basis. I know the steps I take to lock down a server today in 2018 are different in quite a few ways than they were in 2014, for example.
My organization is going to be looking at this issue because it's a real problem that needs some coordinated focus. We're conducting our launch fundraiser right now with an Ethereum ERC20 token, but I have real concerns with the stability of that platform moving forward. A deep dive is in order with some consultations with the gurus before I make any long-term decision I'll live to regret on platforms. In some ways it's a shame, the Ethereum platform does seem good "on paper", but has some real flaws that need to be met before I would place the kind of trust in it that you do to a financial institution.
If a bank lost $500M in a year, people would be in jail! (Well, maybe not here in the U.S., but only because the banks own our government [for now]). But who would bank with a company that was so careless with funds it has custodial control over?
I might sound ranty back, but it's only because it's so outrageous.
Best regards,
Ben