Part Two:
Beware the impossible smart contractHiding confidential dataAs I’ve written about previously, the biggest challenge in deploying blockchains is the radical transparency which they provide. For example, if ten banks set up a blockchain together, and two conduct a bilateral transaction, this will be immediately visible to the other eight. While there are various strategies for mitigating this problem, none beat the simplicity and efficiency of a centralized database, in which a trusted administrator has full control over who can see what.
Some people think that smart contracts can solve this problem. They start with the fact that each smart contract contains its own miniature database, over which it has full control. All read and write operations on this database are mediated by the contract’s code, making it impossible for one contract to read another’s data directly. (This tight coupling between data and code is called encapsulation, and is the foundation of the popular object-oriented programming paradigm.)
So if one smart contract can’t access another’s data, have we solved the problem of blockchain confidentiality? Does it make sense to talk of hiding information in a smart contract? Unfortunately, the answer is no. Because even if one smart contract can’t read another’s data, that data is still stored on every single node in the chain. For each blockchain participant, it’s in the memory or disk of a system which that participant completely controls. And there’s nothing to stop them reading the information from their own system, if and when they choose to do so.
Hiding data in a smart contract is about as secure as hiding it in the HTML code of a web page. Sure, regular web users won’t see it, because it’s not displayed in their browser window. But all it takes is for a web browser to add a ‘View Source’ function (as they all have), and the hidden information becomes universally visible. Similarly, for data hidden in smart contracts, all it takes is for someone to modify their blockchain software to display the contract’s full state, and all semblance of secrecy is lost. A half-decent programmer could do that in an hour or so.
What smart contracts are forWith so many things that smart contracts cannot do, one might ask what they’re actually for. But in order to answer this question, we need to go back to the fundamentals of blockchains themselves. To recap, a blockchain enables a database to be directly and safely shared by entities who do not trust each other, without requiring a central administrator. Blockchains enable data disintermediation, and this can lead to significant savings in complexity and cost.
Any database is modified via “transactions”, which contain a set of changes to that database which must succeed or fail as a whole. For example, in a financial ledger, a payment from Alice to Bob is represented by a transaction that (a) checks if Alice has sufficient funds, (b) deducts a quantity from Alice’s account, and (c) adds the same quantity to Bob’s.
In a regular centralized database, these transactions are created by a single trusted authority. By contrast, in a blockchain-driven shared database, transactions can be created by any of that blockchain’s users. And since these users do not fully trust each other, the database has to contain rules which restrict the transactions performed. For example, in a peer-to-peer financial ledger, each transaction must preserve the total quantity of funds, otherwise participants could freely give themselves as much money as they liked.
One can imagine various ways of expressing these rules, but for now there are two dominant paradigms, inspired by Bitcoin and Ethereum respectively. The Bitcoin method, which we might call “transaction constraints”, evaluates each transaction in terms of: (a) the database entries deleted by that transaction, and (b) the entries created. In a financial ledger, the rule states that the total quantity of funds in the deleted entries has to match the total in those created. (We consider the modification of an existing entry to be equivalent to deleting that entry and creating a new one in its place.)
The second paradigm, which comes from Ethereum, is smart contracts. This states that all modifications to a contract’s data must be performed by its code. (In the context of traditional databases, we can think of this as an enforced stored procedure.) To modify a contract’s data, blockchain users send requests to its code, which determines whether and how to fulfill those requests. As in this example, the smart contract for a financial ledger performs the same three tasks as the administrator of a centralized database: checking for sufficient funds, deducting from one account, and adding to another.
Both of these paradigms are effective, and each has its advantages and disadvantages, as I’ve discussed in depth previously. To summarize, Bitcoin-style transaction constraints provide superior concurrency and performance, while Ethereum-style smart contracts offer greater flexibility. So to return to the question of what smart contracts are for:
Smart contracts are for blockchain use cases which can’t be implemented with transaction constraints.
Given this criterion for using smart contracts, I’m yet to see a strong use case for permissioned blockchains which qualifies. All the compelling blockchain applications I know can be implemented with Bitcoin-style transactions, which can handle permissioning and general data storage, as well as asset creation, transfer, escrow, exchange and destruction. Nonetheless, new use cases are still appearing, and I wouldn’t be surprised if some do require the power of smart contracts. Or, at the very least, an extension of the Bitcoin paradigm.
Whatever the answer turns out to be, the key to remember is that smart contracts are simply one method for restricting the transactions performed in a database. This is undoubtedly a useful thing, and is essential to making that database safe for sharing. But smart contracts cannot do anything else, and they certainly cannot escape the boundaries of the database in which they reside.
Source:
https://www.linkedin.com/pulse/beware-impossible-smart-contract-gideon-greenspan?trk=hb_ntf_MEGAPHONE_ARTICLE_POST