The Ethereum Blockchain and Smart Contracts
There are many blockchains in existence. While the Bitcoin blockchain is the most well-known, it is the Ethereum blockchain that is most commonly used for smart contracts. Like the Bitcoin blockchain, Ethereum has its own digital currency known as the Ether. Ethereum uses a slightly more complex system to manage accounts and balances in the account, but Ether transactions nonetheless look very similar to Bitcoin transactions. But unlike the Bitcoin blockchain, Ethereum was designed from the beginning with the ability to execute complex scripts (programming code) that can be embedded into the blockchain. In other words, instead of just holding data, the blockchain contains code that can perform calculations, store data, and change the ownership of Ether.
Smart contracts are generally written a high-level programming language and then compiled down to a bytecode (such as the Ethereum Virtual Machine, or EVM, bytecode) and then stored on the blockchain. Each contract is therefore stored in binary code, and interaction with a contract is made through a public ABI (similar to an API but on the binary level). Smart contracts can have both short-term memory and long-term storage to hold data related to the contract. Smart contracts can also initiate other transactions, such as the transfer of Ether from one account to another.
All smart contracts are stored in the blockchain, which is public and available at every node of the network. There are benefits to this public access, as the inner workings of the contract are laid open for all observers. Provably fair gambling contracts, such as sports betting contracts, provide assurance to users that they know how winners are calculated and how odds are paid out. One advantage that is also a disadvantage is that bugs can more easily be discovered in publicly accessible code. However, because contracts that have been saved in the blockchain are immutable, it can be difficult or impossible to fix any bugs that are discovered.
Smart Contracts and Gas
In addition, every node on the network is required to execute the code of the smart contract whenever it is triggered. If there are a thousand nodes on the Ethereum network, and you have a smart contract that pays your brother 1 Ether, every one of the thousand nodes will execute the same smart contract to determine that your brother should get paid. This is obviously not computationally efficient.
Each contract must pay for this computing power by providing “gas” for the transaction. Every computational step in a contract costs gas for performance. Interaction with a contract usually includes a pre-paid gas amount—if the computation of the interaction exceeds this pre-paid amount the contract is killed. While gas is purchased in Ethers, the price varies according to demand. To have a smart contract transaction accepted by a miner for placement into a new block, a bid price for the required gas is submitted along with the transaction. The miner can then accept whichever transactions they desire for inclusion in their generated block. These bids also include a “gas limit,” which is the maximum amount of gas the sender is willing to spend on a transaction.
The monetary costs for any significant computation are very high. One researcher found that a certain task performed on the Ethereum blockchain would use $26 in gas charges but would cost 6x10-8 dollars on an Amazon web platform (or 400 million time as much on Ethereum). Blockchains also charge for data storage on the blockchain, with Etherium charging 20,070 gas to store 32 bytes.
Gas prices (which are set in Ether) can vary as much or more that the value of Ether. On May 1, 2022 (the date of an important Bored Ape land sale), the gas cost for a typical transaction (including a simple 32 byte storage of data) was almost $200. Less than three months later, this cost is under $2.
To avoid such charges for computation and data storage, most complex smart contracts move data storage and complex complications off the blockchain. Off-blockchain storage is verified by computing a hash and storing the hash on the blockchain. This blending of on-blockchain steps and off-blockchain steps complicates the programming of smart contracts, but it generally remains possible to ensure the integrity of such data and computations steps using the blockchain.
The Code is Law
Many proponents of smart contracts have argued that the public nature and immutability of the smart contract means that the legal system is no longer necessary for these transactions. Since “the code is law,” there can be no legal disputes over the terms of the agreement. All parties that agreed to participate in the smart contract have agreed to be bound by the automatic performance of the contract. Once the contract is entered into, there is no longer a requirement to trust the other party. There is no ability to alter the contract, or to change one’s mind on a smart contract. This is the beauty and simplicity inherent in smart contracts—it is “trustless” and removes the need for trusted middlemen. Furthermore, if the code is the law, there is no more need for lawyers.
Not surprisingly, most of these proponents are not lawyers. Lawyers have instead asked questions like “are smart contracts even contracts?” The answer to this question should, of course, be based on standard contract law principles of offer, acceptance, and consideration. Where these elements are present, smart contracts can be considered enforceable legal contracts.
While some states have passed “smart contract legislation,” the legislation does not automatically turn blockchain smart contracts into binding contracts. Rather, the legislation simply states that a binding contract does not become invalid merely because the contract includes a smart contract term.
Hence, in reality, most smart contracts today are merely terms within, or mechanisms for the performance of, a standard legal agreement. Even in the absence of clarifying state legislation, there is no reason to believe that an enforceable contract that requires parties to abide by the computations and determinations of a smart contract is unenforceable.
However, pure smart contracts do exist. The clearest examples of these are Decentralized Autonomous Organizations, or "DAOs", which are discussed in a separate page.
The Oracle Problem
One example of a recent startup that focused on using smart contracts is Robomed. Robomed started in Russia as a way to pay for medical appointments using digital currencies. The system used smart contracts as a way to ensure that standard medical practices are used during the procedure. Patients can request a medical appointment from a clinic that accepts Robomed referrals and payment. The patient requests a procedure or a treatment through a web interface. The smart contract is the responsible for identifying specific steps that the doctor should perform to meet the needs of the patient. These steps are identified using a database of standard medical practices. The doctor then must verify that all of the steps have been performed. If the doctor fails to so indicate, the smart contract will not release payment to the clinic. If the doctor has performed all of the specified steps, the smart contract will release the digital currency payment to the clinic.
One obvious limitation with the Robomed smart contract is that the physician/clinic being paid is the same individual responsible for confirming to the smart contract that all of the steps have been performed. This is a common problem in smart contracts—who is responsible for providing the inputs necessary to trigger conditional performance within the contract, and can that actor be trusted. As others have noticed, the need to trust third parties to provide truthful data to a smart contract makes it difficult to call smart contracts “trustless.”
Conceptually, the linkage between the smart contract and the real world is accomplished by using an accepted “Oracle.” An Oracle is someone that can provide trusted data. Oracles can also be trusted to perform any real-word task that is prompted by the smart contract. The need to trust such a party or entity is often referred to as “Oracle Problem” in smart contracts. For example, if a smart contract requires 36 monthly payments before ownership of a real-world asset is transferred, some party or mechanism must exist to ensure that legal transfer of the asset occurs after the smart contract confirms that all of the payments have been made. Even if the asset has been digitized or “tokenized” so that the ownership of the asset is now embodied in a token that exists on the blockchain, some type of Oracle is required to ensure that transfer of that digital asset has legal effect in the jurisdiction where the asset is located.
In practice, smart contracts frequently use data sources and software that resides outside of the blockchain as their Oracle. Fizzy, for example, is a European company that utilizes a smart contract to provide flight delay and cancellation insurance. After purchasing an airplane ticket, a user can purchase flight insurance up to five days before the flight through a website. An internal algorithm at the website determines the cost of the insurance. If the user purchases the policy, this fact will be embodied in the smart contract. The smart contract uses an external but well-respected flight status database as its Oracle to determine when a flight has landed (or if it were canceled). If the flight were canceled or delayed more than two hours, the smart contract will indicate that payment should be made to the customer. At the present time, financial aspects of the transactions are performed in Euros outside of the smart contract using external programming and public payment networks. In the future, however, payments in Ether will be accepted, which means that the purchase of the insurance and the payment to customers will be entirely within the domain of the smart contract. But in no event will the smart contract be able to function autonomously without the Oracle providing the smart contract with real-world flight data.