There’s a lot going on in the world of decentralized networking and not just the daily rollercoaster ride of the cryptocurrency markets. A decade after the mysterious Satoshi Nakamoto first unleashed Bitcoin on an unsuspecting world, the blockchain has grown and branched out and now a thousand flowers blossom, some of them rather peculiar blooms indeed.
Look around and you’ll see that blockchains are apparently the answer to every problem. From replacing the global banking system to guaranteeing the provenance of diamonds to paying your dentist – there’s a blockchain for that.
Overhyped they may be, but blockchains actually are a big deal and they will get bigger. Their potential for secure ‘trustless’ interchange is too great to ignore and once the silliness has died down inevitably some serious use cases will emerge.
Blockchain-based smart contracts present a unique risk, and companies should be wary of deploying them for anything with serious real-world repercussions. That’s according to code verification and programming language expert Grigore Rosu, professor of computer science at the Univerity of Illinois.
Smart contracts are small programs coded on top of a blockchain that runs automatically as soon as conditions are right. An example might be an insurance payout after extreme weather, or a machine ordering its own consumables once stocks decline to a certain level.
Nothing new in that, you might say, but smart contracts have the potential for automating such conditions-based transactions on a massive scale, removing the need for a trusted human third party, even in white-collar sectors such as law and finance.
Smart contracts are immutable; they’re validated by multiple parties and can’t be changed or corrupted. This is at once their strength and their weakness.
Incorruptible programs are great until they get Hacked!
“There are two big problems with smart contracts,” said Rosu. “One is that the code is public so you can work out how to attack it. Secondly, once you have a smart contract – that’s it. It deploys and you cannot change it. So if you find a bug you can’t fix it, you have to deploy a different version of the contract in a different account and exchange it with the old one which is a very heavy process.”
He points to the example of the now-defunct cryptocurrency Beautycoin (BEC), which was killed off by a so-called batch overflow attack in April.
Two attackers, presumably having studied the code and spotted an eventuality the designers hadn’t thought of, initiated simultaneous transactions using input parameters chosen to create a sort of feedback loop. Unprepared, the smart contract went beserk, generating tokens that were ostensibly worth more than five octodecillion dollars (five and eighty zeros). While no-one had to pay back that impossible sum, the coin was dead and worryingly it took two days for the hack to even be discovered.
Blockchain enthusiasts, it seems, suffer from a form of myopia; because of all that energy burned in proof of work they believe their beloved innovation is all but impregnable. But it turns out cryptocurrencies – which are after all basically just transactions stored on a blockchain – are plagued by glitches, as the number of crypto exchange hacks makes clear.
Recently, MIT researcher Corey Fields discovered a flaw in the signature verification code that would have been fatal to Bitcoin Cash had it been exploited. “The threat of software bugs is severely underestimated in the cryptocurrency world,” he said.
Bugs and vulnerabilities can pop up all over the place, including the code of the smart contract itself, the programming language it’s written in and the compiler that translates that code into the machine-readable language.
“I’m scared because these languages are not very well designed. If a language is poorly designed then as a developer of smart contracts on a blockchain you may struggle to understand what your program actually does, and then the compiler can add its own bugs, and then the program itself may have bugs such as buffer overflow and all sorts of programming language-specific errors,” Rosu said.
“Compilers also have bugs, and if you understand how the compiler works as a hacker you can exploit those.”
Human verifiers are worthless in this regard since a flawed compiler produces corruptions in the bytecode, which is only really readable by machines.
However, there are proven mathematical means of verifying the ‘correctness’ of the machine code. While time-consuming, these techniques can be applied to smart contracts since they tend to consist of just a couple of hundred lines of code. Indeed, for the sake of us all, they should be said Rosu, who came up with the K-framework described as a ‘rewrite-based executable semantic framework in which programming languages, type systems, and formal analysis tools can be defined using configurations, computations, and rules”, fifteen years ago (It should be pointed out that Ruso has a vested interest here. His K-framework has been monetised via a business spun out of the University of Illinois called Runtime Verification).
While a smart contract might take two weeks to audit mathematically at the bytecode level and more complex code such as the CASPER consensus algorithm six months, most of that time is spent in specifying what the code is meant to do, said Rosu.
“If you make a mistake in the specification level then no matter what you do the proof is meaningless because the specification was wrong.”
Given the complex mix of ethical and technical considerations, the specification of algorithms will require intensive human input for the foreseeable future. Coding, on the other hand, could perhaps be better done by machines. For safe smart contracts, the ultimate aim should be schematic-based compilation, or code that generates itself automatically based on what it’s supposed to do, Rosu said.
Partner with Khanna Security Solution PVT LTD. to identify vulnerabilities, reduce risk, and grow your business. Our security experts provide custom-tailored solutions with a high level of transparency. You build it. We’ll secure it.