Smart contract developers not really focused on security. Who knew? "Smart contracts," which consist of self-executing code on a blockchain, are not nearly as smart as the label suggests. They are at least as error-prone as any other software, where historically the error rate has been about one bug per hundred lines of code. And they may be shoddier still due to disinterest in security among …
It's very unfair to say these projects are all Ponzi Schemes. The ecosystem is far more diverse than that, incorporating Pyramid Schemes, Rug-Pulls, classic Pump-And-Dump scams and traditional fraud. Pretty much any trick a nineteenth century swindler might have tried before financial regulations were put into place to protect people is likely to be alive and well in the Wild West of Web3.
After looking at the Decentralized finance apps for over a year, I have come to the conclusion that the code is about as buggy as any other application code.
Moreover, being decentralized is a boon to hackers.
Security practices don’t exist.
Reporting issues come back with: prove to that a bug can be exploited. The better approach is to ensure each block is secure and consistent.
The thing is that making this much money gets into the programmers head and they think they are Supermen.
TBH, the bit that scares me isn't so much the bugs and security holes so much as the fact that the entire model is predicated around a pretense that they don't happen.
Bugs are going to bug, but with smart contracts there is no way for a human to intervene and set things straight.
So some unknown developer knocks out a contract over a bottle of wine, sets it live before passing out, and it's effects on anyone who interacts with it are immutable (outside of a blockchain fork).
Considering the sums involved with crypto, it's beyond irresponsible, but often gets mis-stated as being a feature
I had the necessary skills to hack a crypto currency. I'd only do it once, I swear. 130MM, I'd only HAVE to do it once. I'd even claim the profits on my income taxes as "crypto currency profits." The FBI never caught Al Capone, the IRS did, so as long as the tax man gets his cut I'd be golden.
> It's BS coming right from the Marketing department.
Obviously it is. Would you believe something called "genius contract"? No, because it's clearly too pretentious to be really true*. "Smart" sounds a little less pretentious and thus can pass under the radar.
* Except for clients of a certain fruity firm, who are clearly impervious to sarcasm...
It would be interesting to see what the overlap is between Smart Contract authors and the Hackers who take advantage of the bugs involved.
Probably, the authors dont do the hacking directly, but all it takes is a bit of a discussion about what sort of bugs can be found and suddenly you have an active exploit.
Seems like it would be a profitable little sideline... But then maybe I'm just overly cynical about anything crypto. I know the old expression "Don't attribute to Malice what can be equally attributed to Stupidity", but when it comes to everything Cryptocurrency/NFT/Smart Contracts, the opposite seems significantly more likely...
The managerial mindset which is so often
"I want this software out the door yesterday"
"QA / rigorous tests take too long & don't add enough value"
"If that was a minor change no need to run the QA tests / test suite again"
"Security enhancements, put that on the "nice to have" to do list"
.. etc...
Plus worth mentioning that the average programmer might not have the same mind set as a vuln tester in knowing what approaches to take to spot potential vulnerabilities in their code.
"I want this software out the door yesterday"
This mind set doesn't just pertain to software development. I once worked in an organisation that had a 'fast track' change control option for 'standard changes' that bypassed the normal discussion and scrutiny. On the 'standard changes' list were all firewall rule changes, and that was an IT department (tech) decision.
Are bugs in the contract code even the main problem? The Beanstalk heist, for instance, was accomplished by gaming the system. If the code is bug-free but the system can be subverted simply by throwing a large amount of virtual money at it by way of a flash loan then the system has no security.
It's not just a matter of doing things right, you also have to do the right things.
> the system has no security
Why should it? You can't let ugly materialistic considerations sully a "cool" concept: Hipsters don't care about security, all they care about is being (and remaining!) hip. Security is for the timid and the uncool.
If you keep that in mind everything becomes obvious.
Having read
https://www.theregister.com/2022/04/18/beanstalk_loses_182m_flash_loan/
I am amazed that an anonymous person can get a loan of $1*Bn* for a couple of days.
This may see a bit 'newbie' ... but how does this self-executing code self-execute.
Sounds like the code is embedded in the blockchain (data) - not clear how that code is actually 'run'
Guessing that there is a server somewhere that takes inputs - one of which is the blockchain - and conditionally does things based on other inputs.
What could go wrong.
They interviewed developers with less than 2 years experience?
Maybe it's because I do have 25+ years of commodity trading systems development experience, but IMHO nobody with less than 10 years of experience of developing financial systems should be developing 'SMART' contracts.
I've nosed around quite a few of these firms a couple of years back. As far as I can tell, having 20 years of experience (and a MA in mathematics, and a decade of test experience) is some sort of disqualifier to be considered by these companies--so with your ten, you probably won't get the chance to look at such a document.
""Given the recent rise of smart contract projects (e.g., decentralized finance) and their associated security attacks, providing better educational materials and tool support especially for novice developers is paramount " [emphasis added]
I suspect that what is really paramount is not assigning such important development tasks to novices.
I suspect that what is really paramount is not assigning such important development tasks to novices.
Programmer Wanted.
Must have 10 years experience developing for the Ethereum blockchain.
Salary and other fungible compensation negotiable.
/s.
(Ethereum was released 7 years ago.....)
"Must have 10 years experience developing for the Ethereum blockchain."
Not at all. The reality should be:
"must be able to demonstrate substantial experience in programming robustly and securely, regardless of implementation language".
The idea that secure programming is primarily language or context dependent is fundamentally wrong and must be abandoned. Secure programming derives from a way of approaching the development process - an engineering as opposed to 'coding' mind set. Different languages and contexts merely vary in how security is implemented. They don't intrude on the universal essential principles.
Sadly the engineering mind set is hardly touched on by software development training - either not mentioned at all or maybe in passing, or as an optional module at the end of the course, once insecure habits have already been engrained.
So, three years after Etherium was released, I was looking for work. I decided to looking into the blockchain space. Etherium was getting a lot of attention, so I read the whitepaper, including the specification of the VM. Then I started yelling at the air.
No one with significant experience in integer computations, bug hunting, or microprocessor design would okay a VM where there is no checked add or checked subtract.
No one with any sense of humility at all would create a VM where the cheapest instruction costs one gas.
Part of what I was yelling was that there would be a MAJOR hack caused by integer overflow. Of course, there already had been (Etherium had been out for three years.) Look up the Etherium fork.
--
Don't blame the programmers when the underlying VM is so garbage.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
