II. Smart Contracts Embedded with Conflict Management?
Up until now trust has been a focal concept in cross-border commerce and in resolving disputes arising from it. However self-executing smart contracts already enable trustless contractual relationships. They completely obviate the need to place trust in any third party, be it the state, the market court, the ODR provider, the escrow service etc.
Whereas traditional currency operates by the authority of central banks and the credibility placed therein, cryptocurrencies achieve credibility by authenticating the ownership of currency by the technical protocol itself. The first and most famous example of blockchain technology is the Bitcoin cryptocurrency, which was invented and released as open source software by Satoshi Nakamoto in 2008. Bitcoin enabled the processing of online transactions without the need to resort to third-party intermediaries.
Cryptocurrencies bypass the claimed shortcomings of traditional financial institutions by including a cryptographically secure ledger, a blockchain of earlier transactions, which provides both information security and transparency. The ledger of past transactions is public and shared, and after being added no transaction can be altered or removed. A transaction can be added to the blockchain only when it includes a solution to a specific mathematical problem. These mathematical problems are designed to be computationally difficult and time-consuming to solve, but simple to verify. The process is decentralized and is provided by “miners”.
However, the legal discussion on cryptocurrencies has focused on questions of qualification and regulation, and smart contracts are still in the margin of this debate. In October 2015 the European Court of Justice stated in its preliminary ruling that Bitcoins are exempt from value added tax, which creates a correlation between the traditional and virtual currencies in the application of EU legislation. But until today cryptocurrency has elusive qualification within the legal framework. It’s not a currency, not a property, not commodity and so on.
Bitcoin infrastructure is given as an example of the scenario of low regulation, where public functions are outsourced beyond human intervention to computation with a high level of automation. Some predict that (blockchain-based) distributed trust networks could replace traditional legal authorities; others predict enforcement of decisions entrusted to decentralized government-like organizations that could be governed by software code.
Really blockchain is wider then only use in cryptocurrency. It can offer us other contract relationships. A smart contract is an automated software program built on a blockchain protocol for example Ethereum. One of the most interesting aspects of smart contracts is the possibility of self-enforcement: self-execution adopts the role of conflict prevention, as it limits the scope of potential disputes arising from the transaction. The contract executes its content not depending on willingness of the debtor to pay.
The future of smart contracts is still very much unclear. Their potential may become reality or then again some other application of software and law could become the mainstream solution. The task at hand for legal scientists is to map out the legal implications of blockchain architectures and to conceptualize them for future policy recommendations.
Self-executing contracts might significantly alter dispute resolution, although it is unlikely that disputes will disappear completely. Methods of resolving disputes will change and after will change the disputes themselves. All the legal information in such contracts will be converted in lines of code. The self-execution of smart contracts can be interpreted both as the execution of contractual obligations and as the mechanism for conflict prevention, depending on the chosen perspective.
Ethereum as one of the most popular blockchain systems for smart-contracts is based on the object-oriented programming language Solidity.
For example, Adeline as Bettor1 and Bob as Bettor2 place a bet of 100 ether about the weather in New York. Adeline believes that the temperature will be at least twenty-five degrees Celsius at 20:00 on Saturday evening. Bob predicts the temperature to only be fifteen degrees. They agree that the actual weather at the set time is verified using official weather reports that are provided by a third party. They create a smart contract and “deploy” it on the Ethereum blockchain. Both parties transfer money from their respective accounts and this money is then allocated by the contract to the winner. In a way, the smart contract serves the same purpose as procedural law in court proceedings: it defines the rules for resolving the difference of opinion between the parties.
An individual smart contract is a class and within the blockchain the contract is an instance. First, we define a data structure that belongs to the contract. The structure has no methods but only includes fields, and instances of it are used to hold data about the bettors. These fields are an address to an Ethereum account (address addr;), the temperature as a positive whole number (int8 temperature;), and the bet amount of the bettor (uint value;). Another field tells whether the bet has been allocated or not. If the variable is ‘yes’, it means that the bet has already been paid. Nobody except contract itself can change this variable.
Only the contract itself can determine whether the bet has ended. The parties cannot affect this and may only know that the bet has ended by following the bet end time or by receiving the payment due to the winner. After this, we introduce other variables to the contract. These include fields of the smart contract, of the class WeatherBet. We declare the fields of bettors (Bettor private bettor1; and Bettor private bettor2;), the bet end time (uint private betEndTime;), and the external source for verifying the temperature (TemperatureOracle private tempOracle;).
The contract can allow or not allow both parties to change bet or finish the contract before bet end time. After this we put a function which determines the result of contract depending of real weather.
Smart contracts, like any computation that takes place in the blockchain that changes the blockchain, are created by transactions. In order to change the blockchain, digital assets (in this case ether), must be sent to the smart contract. This means that each message sent to a contract requires a transfer of ether to be concluded. Simply put, a message is a transaction, a transaction is a message. That’s why we also need functions which make bets of both bettors and a transaction after bet. The last lines of code deal with the possibility that someone else, other than Adeline or Bob, has transferred money to this bet.
