One Billion Deals On Smart Contracts

Introduction

In this article I’m covering the use of smart contracts for automatic execution of deals, enabling all parties to agree to predefined transaction conditions in order for them to be executed later automatically. The sum of money being transferred is not the issue here — the data surrounding the deal, defining its outcome, is more important. We don’t often think about it, but even a simple purchase of goods is in fact a complex deal depending on many parameters. You can verify this statement simply by examining a shop receipt. Even lending a sum of money to your friend implies an unspoken agreement of a reasonable time frame to return the money, meaning that the process is once more accompanied by additional data. This is why cryptocurrencies without smart contracts fail to establish the necessary requirements for deal processing.

Smart contracts are pieces of code specifically tailored to deal processing, although it’s often argued that current systems in place are more than adequate. In this article, I’d like to demonstrate some properties of blockchain solutions from a developer’s viewpoint. I will deliberately not discuss the topics of volatility or current market conditions, scam cases and other non-technical issues. I’m neither a trader nor an investor, and couldn’t care less about the price of BTC, so please refrain from discussing these and ICO-related topics in the comments section.

I’ll also describe the shortcomings of smart contracts and DApps, some of which are quite prominent. This is exactly what makes smart contracts unsuitable for a wide range of tasks. We’ll discuss the costs of ownership and maintenance, security and development of systems of smart contracts and DApps for automation of deals, among other things. Let us try to answer the title question of the article — how close are we to a billion deals on smart contracts and is it a realistic number we can actually reach?

I will speak of modern blockchains, such as Ethereum, EOS or Neo, their forks and smart contracts deployed on them, of the process of development of such contracts, their deployments and maintenance. Any of these blockchain networks allow a user to set up a small program (smart contract) which will process various events generated by the network users. Each of the events is, technically speaking, a transaction; generated and signed by a user. For any of these events, users pay a small fee to a block producer, who processes the transaction, executes the smart contract code, receives a result and adds it to the next block being formed. Every event can carry a certain amount of cryptocurrency, which can be sent to the balance of a smart contract, and can then be utilized according to its code. Every event triggers a subprogram (function) from the contract. You should already know the basics, otherwise you wouldn’t be reading the article, would you?

It’s seemingly easy to achieve a billion deals, as any transaction on a decentralized network implies the transfer of rights of ownership of data from one address to another. In other words — a deal. To give another example, a crypto remittance looks this way — “Hey, miners. How about I pay one of you X coins for you to transfer my ownership of Y coins to Ivan on blockchain?” The code that checks certain conditions, and as a result transfers the ownership, is called a “contract”, and it does have a lot of similarities with a regular deal: “If verified by a valid signature, the transaction passes on the rights to X bitcoins from address 1 to address 2”. To re-iterate this — any crypto transaction using UTXO (as in the case with BTC), is the result of a typical deal (contract) in which the sender (presenting his digital signature) transfers his rights for the output of the transaction to another network user.

Legally smart contracts are compared to regular agreements, and not without reason. From a non-technical perspective, we’re interested in seeing a billion deals not as technical concept, but as defined by lawyers — deals of consequence to the real world, which automatically excludes such transactions as, for instance, the ever-present airdrops. Smart contracts have a long way to go before replacing the offline tools we use today. I’ll describe the technical advantages of such solutions in detail in order to evaluate the cases where the use of such systems is justified, as well as cases where the developers’ promises must be taken with a pinch of salt.

DApps, Smart Contracts and Automatization

Deploying a smart contract on a blockchain network means outsourcing the processing of deals. If you show a smart contract on your site, its address will be the thing users see and interact with, as everything else they’ll do on their own in the browser. If need be, you can manage your accounts in a centralized way and redefine the contracts’ conditions, but it will happen without a dedicated admin dashboard, as authorization only requires your own public key. In its current state, the Ethereum and EOS infrastructure has matured enough to allow for the creation of fully-featured DApps, consisting of a core (a few code lines defining the logic of interaction with smart contracts) and a set of blockchain smart contracts.

The limited functionality of such systems that can’t access external data sources or make sudden changes to the internal logic, makes it a perfect fit for deals where one or more parties agree to a transaction without mutual trust and have only pre-verified facts pertaining to the deal to record.

Smart contract code can be compared to a stored procedures widely using in any modern SQL database, widely employed in FinTech. The code of a such stored procedure in question is transparent and open for inspection, with any modification recorded on blockchain. Every transaction requires a valid digital signature, allowing it to use a centralized or decentralized scheme of identity verification. As such, any of the following is made redundant:

• Registered and verified (among other things — via SMS) accounts database
• Code for integration with banking systems
• Database and transaction log backups
• DDoS protection
• Some other specific and obsolete heaps of code

So, let’s take a look on some aspects of DApps, and try to conclude — are they ready to billions of automated deals or not?

Cost of Ownership

One of the key advantages of decentralized systems is the low cost of maintenance of an IT system. It’s a huge advantage from a business perspective. A company can maintain a set of smart contracts to provide the same services as conventional IT systems would allow, but at a lower cost and with a higher level of security. The concept of microservices independently serving a certain purpose, as opposed to one massive all-in-one application, is predominant in the modern IT sphere. One massive service with tons of code becomes difficult to manage and over time, loses flexibility and have very high cost of ownership. “Microservices” approach requires highly-coordinated management of numerous hubs and stimulates companies to adopt cloud services, since the cloud is the go-to solution for smaller services. This is as opposed to servers, mining farms and technical problems that may arise. Cloud services provide out-of-the-box UI allowing it to manage a large number of small servers, which helps to pinpoint errors, control every system and scale it easily.

Decentralized networks and smart contracts make the outsourcing options described above even more viable. Block producers are the ones responsible for maintenance, as it is in their best interest to keep the network running without a hitch. Hacking or overloading such a network is possible only in the early stages of its development due to bugs and critical oversights in its design. However, the same applies for centralized systems — massive hacking attempts are observed in both cases. If we compare two software solutions and inherently consider their level of security equal, then the one deployed on blockchain will still provide an increased level of resistance to various network issues and a high level of reliability. Fail-safe systems are something that require a very costly infrastructure, like with centralized solutions. This is why, at the end of the day, a smart contract-based solution is financially viable for business owners.

In addition, pricing mechanisms underlying transactions in process are more flexible than service plans of cloud providers. It’s not necessarily a more fair mechanism as block producers (miners) can, in theory, enter a mutual agreement (as can cloud service providers). In the first case though, the pricing is transparent and auditable, which incentivizes miners to avoid entering into cartel agreements, as such behaviour can have a detrimental effect on the whole blockchain network and a further detrimental effect on all of its participants. These facts allow us to conclude that pricing for computational resources and the processing outsourcing of deals on blockchain should be more favourable to businesses than that of centralized cloud service providers.

Simplicity has a lot of benefits in terms of security, a great expenditure of centralized service providers. We’ll discuss security in detail further down, but let’s keep in mind that all the main safety mechanisms are already built into decentralized systems, being integral parts of it, so a business owner only pays for deployment of his code on blockchain and doesn’t have to bear any costs to protect his database, web server, infrastructure separately.

Rightfully the costs of ownership of smart contracts go first among the advantages of decentralized systems. Smart contract regulated deals present a cheap means of transaction, fulfilling all the requirements — security, transparency, enforceability. In these terms, no other solution can compete against smart contracts and these advantages will be a great driver towards achieving the milestone of a billion deals.

Security and reliability

The next point to cover is related to security and the reliability of systems. At the core of any platform for automated deals, centralized or decentralized) resides the user authentication and authorization subsystem. This subsystem, developed with all safety standards in mind, still has an inherent flaw. It processes and stores private user data, leakage of which leads to a drastic decrease of security level. For instance, even though banks do not store CVC codes of plastic cards, access to other sensitive data opens possibilities of social engineering attacks or brute-force attempts. The leak of a database with password hashes, even if reinforced by encryption and single-use authorisation, compromises the overall system nonetheless, because any disclosure of critical data can lead to successful attack, it’s not only data in database but also its structure or statistical properties for stealed data. No centralized system can completely work around this potential problem, as from a technical point of view, such systems use a storage of “shared secrets”.

We’ve already enumerated some bulks of code made redundant by smart contracts and if you review them again, you’ll see that all of these are critical for security. Therefore, security needs only to be provided exclusively on the client side. It is sufficient to protect the workplaces of key employees (which is common practice nowadays already) by providing a reasonable level of security and making the IT security job a lot easier not just in prevention, but in hacking cases investigations as well. Speaking of the so-called “51% attack” relating to blockchains, let’s not forget the fact that in centralized systems, devastating attacks can be performed by one person. So yes, you can even refer to it as the “1% attack” if you so wish.

It’s necessary to admit that decentralized software is still in the beta version and has certain persisting security issues, but this can be said about any system in the early stages of development. At the end of the day the removal of weak points from which critical data can be stolen or MITM attack can be performed, ends up having an overall positive effect on security. Deals conducted via one-time smart contracts or a related system — problems with access to the contract, division of rights, transaction validation and irreversibility of executed lines of code — are completely solved on the side of blockchain and smart contracts. In circumstances when basic cryptocurrencies are used, any cold storage provides a better level of security than any centralized system possibly can, as it simply does not have as many vulnerabilities that the latter has.

Speaking of the perspectives of adoption of even more secure systems, decentralization provides a whole lot of opportunities for development — namely, zero-knowledge protocols. Such protocols allow the outsourcing of confidential processes and calculations, essentially transforming decentralized networks into supercomputers, able to process great amounts of private data without compromising security. As of now, such systems are complex and inefficient, practically unusable for real use cases. The same could be said about the internet and cryptography in general. Centralized systems don’t have a lot of perspectives for development, apart from an increase in sheer processing power, resulting in higher CPU, RAM, storage and parallel computing capacity.

The fact that from now on security can only get better in decentralized systems constitutes yet another argument in favour of smart contracts working towards the achievement of one billion deals.

Ease of Porting and Compatibility

Compatibility should in theory be a non-issue, as data exchange systems already moved towards this goal quite some time ago. A lot of unified standards exist, such as JSON, XML and YAML that facilitate the transfer of structured data between heterogeneous services. This fact, however, does not ensure compatibility, as different companies present different requirements to the data itself, which may lead to discrepancies in the way it’s transferred, validated or treated. Open source code and smart contracts logic help eliminate this problem. In decentralized systems code is executed in a strictly deterministic way on all particiapnts’ machines, not allowing for discrepancies and variations in data treatment. Strange as it is, it appears that, in general, smart contracts are far more “centralized” than one huge database with thousands of replicas and .

Another important thing to remember about decentralized systems is the fact that their code is always open. There is no point in hiding the code which is openly used by any entity on a network, where every transaction can be replicated in detail. The Kerckhoffs principle of cryptography, which in a well-protected cryptographic system has the algorithm at its base, must not be kept secret, but be readily available to anyone. It allows any well-informed blockchain developer to perform thorough testing of any solution under development and ensure its compatibility. The programming languages must be verified, which is a simple task in such a deterministic environment as block processing and blockchain transactions.

Deals between multiple parties are significantly better suited to smart contracts than to any centralized systems. This is because all the necessary underlying tools are openly accessible and can be used in any web-based system without the need to register or purchase expensive software solutions, define rules and terms of use — all of these things are now in the past. A lot of large companies changed to a SaaS (Software-as-a-Service) model and this business model works great with smart contracts, allowing them to implement even the most complex subscription models with maximum transparency to any user.

There are, as one may suspect, problems that transpire in connection with real-life cases. The platforms under development keep transforming all the time and compatibility they present can’t be compared yet to well-established data-oriented companies. However, in the long term, blockchain can, and certainly will, provide unified standards for smart contracts, and back them up by high rates of adoption and block producing community.

Development and Operation

In relation to development and operation, everything is not as successful as in terms of security and compatibility. A publicly verifiable execution of smart-contract code, transparent and verifiable history of every line of code can’t be taken for free. Solutions based upon smart contracts primarily depend on the properties of the virtual machine that executes their code. The main properties of a virtual machine are:

1. Deterministic execution. The ability to produce exactly the same output from the same input regardless of the platform, CPU or memory type, workload or exceptions in execution. Even in cases of errors and misbehaviour of participants.
2. Resource limitations. A block producer has to limit the amount of resources dedicated to execution of a smart contract, as he can not afford to “freeze up” when performing a single transaction, and risking the chance of not forming a block in time.

These properties determine the specifics of smart-contract development. Smart contracts are somewhat close to well-optimized C++ objects, where every method performs a limited amount of operations, trying to avoid cycles, complex branching and other bottlenecks with non-constant execution time. Any operations forcing different results on various hardware configurations are explicitly forbidden in a virtual machine. Here are the examples of limitations imposed by the problems described above:

• Any cycle needs to have a cap on iterations or a cap on max number of objects iterated
• Aggregation of data from a large number of entities is not allowed
• No floating point operations
• No effective iterators for mappings (associative arrays). Any group operations require auxiliary data structures (e.g. reverse index array for goal-seeking mapping keys)
• All variables and functions’ code is kept in contract storage: memory organized by key-value principle (in order for memory to possess the determinacy property as well)
• any undefined behaviour leads to deterministic error or constant value

The development of smart contracts involves a lot of low-level programming, even though the most widespread programming language for smart contracts (Solidity) seems like a JavaScript. In practice though, it’s a low-level access instrument with very strict types, low amount of primitives, compilable to a very limited set of instructions. During the process of development the need arises to again implement a lot of algorithms already built into other programming languages. The use of libraries is also limited, due to the fact that libraries are similar to contracts, and suffer from the same limitations.

In addition to the low-level limitations and problems in connection to the virtual machine, smart contract development has a number of other peculiarities, stemming from the blockchain architecture in general, for instance:

• It’s not possible to completely rely on current time, block’s hash, order of transactions or any other block producer-controlled parameters
• The only data operable by smart contracts is the balance of addresses of parties to it, current time (not completely reliable, as mentioned above) and contract’s own data
• Access to the contract cannot be limited, rendering defense from spam or bots impossible
• All types of resources are strictly limited, including CPU, memory, storage, network. Including the code itself, for example bytecode with size over a certain low amount cannot be deployed

This adds to the fact that modifications to correct errors in smart contracts can be quite costly. In theory, the final resort may sometimes be hardforking the whole blockchain. In reality, various versions of contracts can co-exist (via the use of proxy-contracts), but in any case these procedures unnecessarily complicate maintenance, while a simple software update to the code in a centralized system appears to be quite simple.

These facts lead us to the conclusion that in terms of development, smart contract-based solutions are costly and complicated. Only two major blockchains currently have a complete ecosystem for developers — Ethereum and, to a lesser extent, EOS. Smart contract development hasn’t yet gathered a large enough community or worked out any best practices. There is a lot of work to be done if a billion transactions are ever to be made on smart contracts, but steps towards it are taken every day and there is considerable progress being made.

Performance and Quality of Service

One of the favourite topics of discussion among blockchain enthusiasts is TPS (transactions per second). It’s believed that decentralized solutions are inferior in this regard to centralized services, which operate at thousands of transactions per second. However, without a context or specific cases, the discussion is pointless. First off, when speaking about TPS, it’s important to define what a transaction is, define when it is considered finished and define rules of measurement of TPS. Only then can the different systems be compared. VISA outputs are judged to be about 2500 TPS — simple money remittances. If money is transferred between accounts within one company, a simple spreadsheet database can sustain heavy workloads, as far as simple balance updates are concerned. When speaking of transfers between different systems, an entirely different approach is required. Do these 2500 TPS allow for failed or incomplete transactions? If, due to some business logic discrepancy, money is withdrawn from VISA but isn’t credited to MasterCard, how should the time of this transaction be calculated? Should a SWIFT transaction be considered completed if it can be reversed by a regulator within 24 hours?

I do not claim that smart contract solutions are faster. Quite the opposite! They are in fact slower than their centralized counterparts. However, in terms of complexity, the length of links a transaction has to make, while conforming to certain security standards, are not as complex as VISA transactions. They are far more complex than smart contract transactions. Even the most simple bank money transfer must go through a local gateway, queue for processing, be processed, queue for regulator’s approval, be approved, invoke database update and wait for it to be replicated. This is all while being ready to roll-back within the next 24 hours.

A smart contract transaction is subject to one queue, with one of the block producers and one ledger update with replication. While retaining the same capability as a bank, an entity can easily bypass all the intermediary steps, while still controlling the logic of the operations via smart contracts. This is without the need to authenticate and protect the transaction at any of the intermediary hubs.

In the case of smart contracts, another factor comes into play — the market. Blockchain ecosystems, consisting of many participants, can be subjects to serious volatility, even higher than that of banking systems with centralized governance. Fees can grow, performance may slump and controlling it all is next to impossible.

In the long term, the advantages of transparent processing should outweigh those of centralized software solutions, but now it’s isn’t anything other than a weak spot.

User Experience

Some people argue that users struggle with private keys, seed phrases and all the crypto stuff. I believe the issue is blown out of proportion and that it’s only a temporary problem. Nowadays, you can hardly find a person who’s never used passwords, never reset his e-mail access etc. People are more than capable, given the proper motivation, to adopt the software required to deal with crypto products, and it doesn’t even require any specific or deep knowledge to comprehend. The concept of private and public keys is easy to grasp, as proven by my experience of teaching it.

Responsibility for one’s private data is a completely separate issue. Losing one’s private key is something that can’t happen in a real deal, but can spell disaster for a smart contract deal. In the real world, the situation is easier to correct retroactively, as things can be amended and easily rewritten. Smart contracts leave no room for error(unless specific error handling was implemented in the contract’s logic). It’s a users’ duty to keep track of their own accounts, and manage them without losing or breaking anything. In the absence of centralized services ready to help reset the password, or customer support, it’s all on the users shoulders in the case of blockchain.

That is quite a challenge for a user, in contrast with their ability to reset access to centralized systems, even if mechanisms weren’t always in place for that. Many people abandon all thought of using blockchain upon realization that it requires some special software or knowledge. With our services, that equates to about 80% of users. There is no direct way around this problem. There is no way around generating digital signature on the client’s side, as no other party is responsible for doing it. It may take the industry ten years or more to shape the tools for critical private data management to match the best practices used in web services these days.

Conclusion

Summing it all up, smart contracts allow users to settle deals with low costs, simplify interconnectivity and improve safety and security by moving critical actions to the client’s side. They require the users to take full responsibility for their keys. They just can’t work as fast as centralized solutions and can’t boast a developed ecosystem, unlike regular web software solutions.

In the long run, I keep faith in decentralized solutions, and don’t see any alternatives to them in a world where people want to be independent economic agents. If humanity stands for honest competition in economy, equal opportunity for everyone and real personal digital rights, it has to work towards adoption of decentralized software, a process comparable in magnitude to moving from monarchy to democracy. This is an ambitious undertaking both for users and developers, which will inevitably lead to abandoning many old ways and re-inventing them.

So, will it all work? And will we see the coveted 1 billion transactions soon? I believe the answers to those questions are — yes and no. Blockchain will work, but it will take some time: 5–10 years or even longer. The core advantages of processing software are indisputably better in decentralized solutions, but for those to really make an impact, a lot of people have to put in lots of work, which normally doesn’t happen outside of global crisis situations. The likes of which no one in his right mind would wish upon the world.