One of the core and most fantastic features of blockchain infrastructures is the notion of smart contracts, also called self-executing contracts. This is what makes cryptocurrencies secure. Put simply, smart contracts do not need enforcement, or, in other words, they enforce themselves – exclusively due to the way they are drafted.
Every time that you use a cash machine, you are entering a contract with your bank. Your obligations are to provide a card and a pin. The bank’s obligations are to check the pin and give you money.
This contract has a number of enforcement flaws. You can use a stolen card. The ATM might have been skimmed. Or it can just eat your card, leaving you with no card and no cash. The bank’s software could be buggy and take more money from your account than it gave to you. In other words, there exist a number of situations where you or your bank may fail to fulfill its part of the contract, with the violation needed to be escalated to authorities outside the contract (e.g. a bank teller or the police force).
Smart contracts are not threatened by flaws like this. They just work, by their design. In Bitcoin, there is no way to forge a transaction, or to fool someone into the content of your wallet, because the environment provides a secure way to verify every single transaction via a so-called distributed ledger, which works in a mathematically proven way.
While commonly associated with blockchain technologies, smart contracts may actually come in a variety of forms and shapes. Most of Internet security protocols rely on them in one way or another. For example, Diffie-Hellman key exchange algorithm is a typical smart contract, even though the term itself was introduced much later than the algorithm. You can’t obtain the shared key without following the contract. If you violate the protocol, you’ll end up with a wrong key, so the need to get the correct key enforces you to implement and perform the protocol correctly.
Ironically, (or logically) Internet protocols suck heavily in the functions not covered by the self-enforcing logic. This is particularly annoying for protocols which are supposed to provide communication security. I think I won’t be mistaken if I say that a weakly implemented certificate validation routine in SSL/TLS is the weakest point of a huge number of the protocol deployments, having a potential of bringing in much bigger troubles than BEAST, POODLE and Heartbleed combined. Many, many times I watched developers neglecting this important compound of the protocol, by either bypassing the certificate validation entirely, or using simplified routines not providing adequate protection. Many times I pointed that out to them, and very few bothered to do anything to fix it.
This flaw continues into TLS 1.3*, with the certificate validation compound keeping its role as a standalone external module with the only purpose to tell ’yes’ or ‘no’ to the main protocol implementation when asked. Needless to say, it is very tempting to implement this module as a hard-coded ‘yes’ to avoid bothering with the validation altogether and have the project up-and-running right here, right now, especially if you are under time and budget pressure.
Designing the certificate validation routine into the protocol in the form of a self-enforcing contract would have done a great job in increasing its security. There would be no way for TLS implementers to cheat by avoiding the validation procedure or implementing it in a wrong/simplified way. The validation module would either work right, or cause the whole secure negotiation to fail.
To be fair, this is easier said than done. Designing a robust self-executing contract requires a deep knowledge of maths and formal logic, as well as cryptography. Decent level of knowledge of the application area of the contract is also quite essential. Ultimately, a proper self-executing contract is a high-grade cryptographic algorithm, and as such is subject to all the relevant strength implications. A good smart contract should be capable of proving its correctness and cryptographic strength formally, which is a good piece of challenge for inventors.
Still, despite the challenges, self-enforcing contracts are set to take a major part in our society. They do a great job by removing the whole surface for wrongdoing, fraud, and human error, and bringing in simplicity and convenience – and this is something that a lot of our typical everyday scenarios need.
Just to make you sure that the next generation ATM never eats your card.
(*) Strictly speaking, this is not a flaw of TLS as a protocol (as the standard thoughtfully transfers all responsibility for handling certificate validation properly to the implementers), but this fact doesn’t make TLS environments any more secure.
Picture credit: Pixabay
