At BQTX, we’re all about smart contracts. That’s part of the reason why we built our platform on the Ethereum blockchain. Smart contracts solve a bunch of problems.
Still, like any other technological solution, it can’t solve a problem without creating a cascade of other issues that need to be solved. So I’d like to take a moment and offer some context about BQTX’s approach if, for no other reason, it provides you with some assurance that we have thought out — and continue to monitor — these challenges.
There are basically two categories in which smart contracts need to catch up to the market. First, they need to mature technologically. Second, they must establish themselves as enforceable from a legal and regulatory standpoint.
Technological issues
Most immediately, the blockchain space is running into the technological limits of smart contracts. But before we examine those, I like what Jimmy Song had to say about the term itself being a misnomer.
“The use of the word ‘smart’ implies that these contracts have some innate intelligence. They don’t,” blogged the famous-on-blockchain software architect. “The smart part of the contract is in not needing the other party’s cooperation to execute the agreement. Instead of having to kick out the renters that aren’t paying, a ‘smart’ contract would lock the non-paying renters out of their apartment.”
Song sagaciously points out that smart contracts, though associated with Ethereum, are actually doable on the Bitcoin chain and, in fact, are older than Bitcoin.
“The difference between Bitcoin’s smart contract language and Ethereum’s is that Ethereum’s is [that Ethereum’s] allows for more complicated contracts at the expense of making them more difficult to analyze,” he says. “There are some significant consequences of complexity. While complex contracts can allow for more complicated situations, a complex contract is also very difficult to secure. ... With smart contracts, security means handling every possible way in which a contract could get executed and making sure that the contract does what the authors intend.”
More on that in a moment, when we talk about what happened with the Distributed Autonomous Organization. Meantime, Song points out a couple other inconsistencies that make smart contracts based on ERC20 and ERC721 problematic. The first is that, although the goal is trustless execution, smart contracts almost always involve a centralized authority at this stage. That leads to another issue: the disconnect between the digital world and the real one. As blockchain enthusiasts, we all aspire to a world where every physical thing has a digital proxy, but we’re not there yet. Thus, there’s no guarantee that a smart contract to, say, buy a car is going to magically put the keys in your hand. Being on the advantageous side of a securities or fiat foreign exchange deal via a smart contract could have the same effect as a small-claims court judgment in your favor: The judge says you’re entitled to the money, but good luck collecting.
Until that pie-in-the-sky day comes and there’s a 1:1 match between everything physical and everything digital, deadbeats will continue to be a problem in both worlds.
On his blog, Jimmy Song posted this meme ironically. He didn’t mean it. In the text, he repeatedly puts the word “smart” in quotes.
CMSWire ran an article last year that summed up a lot of the negative end-user experience.
“The danger of smart contracts that many programmers fall victim to ... is that smart contracts are read sequentially and if a critical piece is missing, the contract won’t run,” Erika Morphy writes. “But perhaps more significantly, smart contracts are not necessarily secure, again depending on the programming. This may come as a surprise to anyone who has heard that one of blockchain’s advantages is its security.”
She cites the DAO hack, Ethereum’s original sin, as the first evidence of this. Still, I would take a more nuanced view. There was nothing wrong with the code on that one. Code is law on the blockchain and, in that example, the law had a loophole that someone could exploit. Since the dawn of contract law, ambiguous contract terms have been interpreted against the interest of whoever wrote it, and that’s exactly what happened. Someone was stupid and lost a lot of money but, ultimately, the enforceability of the DAO smart contract was a feature, not a bug.
That said, her broader point is valid: That immutability is not always a good thing. Morphy goes on to mention the work being done by Simform Solutions and other developers to craft smart contracts that can, under mutually agreed-to conditions, be altered after they go live.
But these are ongoing issues. The technological glitch that’s been getting the most attention recently is what’s come to be called the overflow error. Blockgeeks has a great article about it, albeit a fairly technobabbly one. To boil it down for the business-side audience, it stems from a mathematical limit to the number of digits that Solidity — Ethereum’s smart contract script — can handle. If it’s exceeded, there can be more than one value that resolves the contract. In other words, a poorly coded contract — or a nefariously coded one — creates a loophole that can be exploited by either an opportunist or a full-on bad actor. An underflow error, in which the number of digits is somehow negative, could have the same effect. According to Blockgeeks, incidentally, underflows are more likely than overflows.
Clearly, the tech has to mature. Over the past year or so, roll-your-own smart contracting has yielded to a modular approach. That, I believe will add more consistency and interoperability than all the ERCs anyone would care to submit.
Legal issues
Once all the technological hurdles are surmounted, though, there comes the not insignificant issue of legal and compliance lag.
You can’t entirely blame the courts and the regulators. Of course, we crypto enthusiasts love to infer some agency problem: We’re disrupting money, so we’re disrupting governments and banks, so we’re basically smacking the teat out of both the legal profession and the civil service.
And I’m not saying that’s not a factor, but it’s neither the only one or the most proximate.
There are reasons why contracts are written on paper. You can correct paper. You can amend paper. You can examine paper for intent and the relative power of the counterparties. And, ultimately, you can stick paper in a shredder and pretend that it never existed.
But, as Morphy reports, implied expectations, unforeseen circumstances and good faith or lack thereof are all difficult to model in code. Until we solve that on this end, there will be a very real distinction between voidable paper contracts and immutable smart contracts — and some very good reasons to go with the former rather than the latter.
There’s some good news on this front, though. The legal profession appears to be sympathetic and engaged with the blockchain space, even if the courts and regulatory agencies are still in various stages of catching up. The blog of the American Bar Association provides an illustrative example.
“Historically, we have relied on established institutions such as banks and government to authenticate transactions — to verify that the people with whom we are transacting are really who they claim to be. The institutions act as middlemen to build trust between two parties that are transacting with each other. However, these institutions are not incorruptible,” writes Tsui S. Ng, an attorney with the New York City Department of Education whom, one would think, has more pressing concerns than serving as a crypto apologist. “At times, they have become victims of foul play by external or internal actors. In fact, it can be risky to consolidate trust into one institution because it creates a single point of failure.”
Ng’s ABA post starts from this burning-platform use case and proceeds with a solid layperson’s primer on how smart contracts on the blockchain can mitigate the problem. She even touches on technical issues that might arise from broader scalability challenges related to network speeds. But then she cuts to the chase about what’s scaring off adoption from a legal perspective. Smart contracts, Ng, writes, “are still primarily written in code and not easily readable by the average lawyer. Tools will have to be developed to bridge the usability gap.”
She doesn’t hazard a guess what those tools might look like, and I won’t either. Still, her summation is indisputable: It’s up to the lawyers to learn more about the technology.
“Transactional lawyers may wish to learn more about the technical aspects of their future ‘smart contract’ to ensure that it aligns with their client’s wishes and goals,” according to Ng. “In the future, litigation attorneys may no longer be litigating the ‘four-corners’ of the contract, but rather expanding into the intent of the code.”
How do we fit in?
Just as lawyers need to learn more about code, smart contract developers ought to learn more about the law.
I’m personally committed to reducing the daylight between these two fields, and I assure you that the BQTX team will be leaders rather than free riders when it comes to building the necessary bridges. We will certainly be looking into how an audit function can be added — on request and with as little obtrusion as possible.
What makes this challenge possible is that most the crypto world, including BQT, crafts its smart contracts on one platform: the Ethereum chain. No matter which country you’re in, one smart contract will look much like another.
What makes it hard, though, is that there are roughly 200 different sovereign jurisdictions in the world, not to mention any number of regional and municipal venues. It’s hard enough getting any two of them to take the same view of a standard purchase of imported goods, let alone what we’ve all been cooking up on GitHub.
It’s fortunate, then, that the main use case for smart contracts today is the decentralized trading of cryptocurrencies among sophisticated market players. It falls to us at BQTX and across the dex space to provide a worldwide proof of concept for smart contracts. Once we’ve demonstrated that they work here, we can roll them out everywhere. That’ll mean more inherent value for cryptocurrencies — ETH in particular but there’s bound to be a spillover effect — and that’ll be good for us all.
Edward is an Ernst and Young Entrepreneur of the Year Finalist, Blockchain Enthusiast and visionary behind many successful organizations. An avid entrepreneur, Edward has a knack for designing distinctive business models complemented with superior technology to deliver unparalleled service and profitability. Edward also has been advising and consulting for various successful Blockchain technology and ICO projects and recently launched his own BQT.IO P2P exchange helping traders connect with each other to leverage their crypto assets.
BQT.IO has been in development since March 2017 and its ICO launched September 18. The information can be found online at BQT.IO, on Telegram @BQTCommunity and on Twitter as @bqt_ico.