“`html
Numerous notions that we advocate in Ethereum territory might appear remarkably advanced, and at times, even intimidating. We discuss the so-called “smart contracts” that operate autonomously without any necessity or potential for human interference or engagement, individuals forming Skynet-esque “decentralized autonomous organizations” that exist entirely in the cloud, yet manage significant financial power and can motivate individuals to undertake tangible actions in the physical realm, decentralized “mathematical law”, and an apparently idealistic pursuit to establish a genuinely trustless society. For the unacquainted individual, particularly those unfamiliar with even the basic concept of Bitcoin, grasping how these phenomena are feasible, and why they might be deemed advantageous, can be challenging. The aim of this series will be to analyze these concepts thoroughly, elucidating precisely what we intend by each, examining its characteristics, benefits, and drawbacks.
The inaugural entry of the series will focus on the so-called “smart contracts”. Smart contracts represent a notion that has existed for several decades but was significantly popularized under its current terminology by Nick Szabo in 2005. Essentially, the definition of a smart contract is straightforward: a smart contract is a contract that enforces itself. In contrast to a traditional contract, which is a document (or more recently, a PDF file) that implicitly petitions a judge to compel a party to transfer funds (or other assets) to another party under specified conditions, a smart contract is a software application that can be executed on hardware automatically fulfilling those conditions. Nick Szabo illustrates this with the example of a vending machine:
A quintessential real-world instance, which we might see as the primitive predecessor of smart contracts, is the simple vending machine. With a restricted potential loss (the cash in the register should be lesser than the cost of circumventing the mechanism), the machine accepts coins, and through a basic mechanism, akin to a freshman computer science challenge in constructing finite automata, dispenses change and items based on the indicated price. The vending machine constitutes a contract with the bearer: anyone possessing coins can engage in a transaction with the vendor. The lockbox and other protective mechanisms safeguard the stored coins and items from intruders, sufficiently enabling the profitable operation of vending machines in diverse locations.
Smart contracts apply this idea to, well, many domains. We can have intelligent financial contracts that automatically manage funds based on specified formulas and terms, intelligent domain name sale agreements that hand over the domain to the first person who submits $200, possibly even intelligent insurance contracts that regulate bank accounts and automatically disburse payments based on data from a trusted source (or various sources) regarding real-world occurrences.
Smart Property
At this juncture, however, a pertinent question surfaces: how will these contracts be enforced? Just as traditional contracts hold no value unless backed by a judicial authority with legal enforcement, smart contracts must be “connected” to some system to genuinely possess the capacity to operate. The most apparent, and oldest, solution is hardware, also referred to as “smart property”. Nick Szabo’s vending machine serves as the canonical illustration. Within the vending machine exists a form of proto-smart-contract, encompassing a set of computer code resembling the following:
if button_pressed == “Coca Cola” and money_inserted >= 1.75:
release(“Coca Cola”)
return_change(money_inserted – 1.75)
else if button_pressed == “Aquafina Water” and money_inserted >= 1.25:
release(“Aquafina Water”)
return_change(money_inserted – 1.25)
else if …
The contract has four “hooks” connecting it to the external environment: the button_pressed and money_inserted variables serve as inputs, while the release and return_change commands act as outputs. All four depend on hardware, although our focus is primarily on the latter three since human input is generally considered a minor issue. Should the contract operate on a 2007 Android phone, it would be ineffective; the Android device lacks the capability to determine the amount of money inserted into a slot, and certainly cannot dispense Coca Cola bottles or return change. Conversely, on a vending machine, the contract carries some “force,” supported by the machine’s internal Coca Cola stock and its physical security that prevents individuals from simply taking Coca Cola without adhering to the contractual rules.
Another, more advanced application of smart property is rental vehicles: envision a scenario where individuals possess their unique private keys on a smartphone, and there exists a vehicle that, when you transfer $100 to a specific address, automatically commences responding to commands signed with your private key for a day. The same principle can be extended to residences. If that seems implausible, consider that office buildings are largely smart property already: access is governed by access cards, and the determination of which (if any) doors each card can unlock is established by a piece of code linked to a database. If the organization has a human resources system that autonomously processes employment contracts and activates new employees’ access cards, then that employment contract is, to some degree, a smart contract.
Smart Money and Factum Society
However, physical property is quite restricted in its functionality. Physical items have a limited degree of security, making it impractical to engage in anything intriguing with more than a few tens of thousands of dollars in a smart-property configuration. Ultimately, the most captivating contracts involve the transfer of funds. But how can we effectively make that work? Presently, we are essentially unable to. We can, in theory, provide contracts with access details to our bank accounts, enabling the contract to transfer money under certain conditions, but the dilemma is that this type of contract is not truly “self-enforcing.” The individual creating the contract can always turn off the contract just before payment is required, deplete their bank account, or even simply alter the password to the account. Ultimately, no matter how the contract is integrated into the system, someone holds the ability to deactivate it.
What could be the solution? Ultimately, the response is one that may appear radical within the context of our broader society, yet is already quite familiar in the realm of Bitcoin: we need a new form of currency. Thus far, the evolution of money has experienced three phases: commodity money, commodity-backed money, and fiat money. Commodity
“`money is straightforward: it’s currency that holds worth because it simultaneously acts as a good with some “intrinsic” utility. Gold and silver serve as exemplary illustrations, and in more conventional societies, we also find tea, salt (note on etymology: this is the origin of the term “salary”), seashells, and similar items. Following that was commodity-backed currency—banks issuing notes that retain value because they can be exchanged for gold. Ultimately, we arrived at fiat currency. The “fiat” in “fiat currency” is akin to that of “fiat lux“; however, instead of the deity proclaiming “let there be light,” it is the federal government declaring “let there be money”. The currency’s worth primarily stems from the government that produces it accepting that currency, and exclusively that currency, as payment for taxes and fees, along with various other legal entitlements.
With Bitcoin, though, we encounter a novel form of currency: factum currency. The distinction between fiat currency and factum currency is this: while fiat currency is created and upheld by a government (or, in theory, some other type of authority) producing it, factum currency simply exists. Factum currency is essentially an accounting ledger, accompanied by a few guidelines on how that ledger can be modified, and that currency is recognized among that set of participants who choose to accept it. Bitcoin signifies the initial instance, but there are additional examples. For instance, one could adopt an alternative guideline, specifying that only bitcoins originating from a certain “genesis transaction” contribute to the ledger; this is referred to as “colored coins,” and is likewise a variant of factum currency (unless those colored coins are fiat or commodity-backed).
The core promise of factum currency, indeed, lies exactly in its compatibility with smart contracts. The principal issue with smart contracts is enforcement: if a contract stipulates sending
This represents an even more revolutionary advancement than initially perceived; through factum currency, we have devised a method for contracts, and potentially for law in its entirety, to function and be operative, without depending on any enforcement mechanism whatsoever. Seeking a $100 penalty for littering? Then establish a currency so that you possess 100 fewer units if you litter, and persuade individuals to accept it. That specific instance may seem far-fetched and quite impractical without several significant caveats, which we will examine shortly, but it illustrates the overarching concept, and numerous more practical examples of this principle can indeed be implemented.
Just How Intelligent Are Smart Contracts?
Smart contracts are undoubtedly quite adept for various financial applications, or generally for any type of transactions between two differing factum assets. One instance is a domain name sale; a domain, such as google.com, represents a factum asset, as it is supported by a database on a server that only carries significance due to our acceptance, and currency can clearly also be factum. At present, selling a domain involves a complex process that frequently necessitates specialized services; in the future, you may be able to consolidate a sale proposal into a smart contract and place it on the blockchain, where if anyone accepts it, both parties to the transaction will execute automatically – no potential forof deception involved. Revisiting the realm of currencies, decentralized exchange serves as another illustration, and we can also engage in financial agreements such as hedging and leveraged trading.
Nevertheless, there are scenarios where smart contracts fall short. Take, for instance, the instance of an employment agreement: A commits to perform a specific task for B in return for the payment of X units of currency C. The payment component is straightforward to convert into a smart contract. Conversely, there is a facet that poses more difficulty: confirming that the work was indeed completed. If the task is in the tangible world, this becomes virtually impossible, as blockchains lack means to access the physical environment. Even in the case of a website, the issue of quality assessment persists; while computer programs can leverage machine learning algorithms to evaluate such traits quite effectively in certain scenarios, it remains tremendously challenging to accomplish this in a public contract without the risk of employees “manipulating the system.” At times, a society governed by algorithms simply doesn’t suffice.
Fortunately, there exists a reasonable solution that can amalgamate the strengths of both approaches: judges. A judge in a conventional court possesses nearly limitless authority to act as they see fit, and the process of adjudication does not possess an especially effective interface; individuals must file a lawsuit, endure a considerable wait for a trial, and ultimately, the judge renders a judgment that is enforced by the legal system—far from a model of rapid efficiency. Private arbitration frequently proves to be more cost-effective and swifter than court proceedings; however, the issues remain the same. Judges in a factum realm, by contrast, differ significantly. A smart contract for employment could appear as follows:
if says(B,”A completed the job”) or says(J,”A completed the job”):
send(200, A)
else if says(A,”A did not complete the job”) or says(J,”A did not complete the job”):
send(200, B)
says is a signature verification algorithm; says(P,T) essentially verifies if someone has submitted a message containing text T along with a digital signature that is authenticated using P’s public key. So how does this agreement function? Initially, the employer would deposit 200 currency units into the contract, where they would remain in escrow. In the majority of situations, both employer and employee are truthful, so either A withdraws and returns the funds to B by signing a message stating “A did not complete the job,” or A fulfills the task, B confirms A’s completion of the job, and the agreement releases the funds to A. However, if A completes the job, and B contests this, then it falls to judge J to determine whether A completed the job or not.
It is important to note that J’s authority is meticulously defined; all J is permitted to do is declare whether A completed the job or not. A more complex contract may also allow J to make judgments within a spectrum between the two endpoints. J is not authorized to assert that A is entitled to 600 currency units, nor that the entire arrangement is unlawful and J should receive the 200 units, or anything else beyond the explicitly established confines. Furthermore, J’s authority is reinforced by factum— the contract incorporates J’s public key, and thus the funds are automatically directed to A or B based on the stipulated parameters. The agreement can even necessitate statements from 2 out of 3 judges or designate distinct judges to evaluate different aspects of the work, with the contract autonomously assigning B’s work a quality score based on those evaluations. Any contract can seamlessly incorporate any judge in precisely the manner they desire, whether to assess the veracity of a specific fact, provide a measurement of some variable, or act as one of the participants facilitating the arrangement.
How will this surpass the existing system? In essence, what this introduces is “judges as a service.” Currently, to become a “judge,” one must be employed by a private arbitration firm or government court, or establish their own. In a cryptographically empowered factum law framework, being a judge merely requires possessing a public key and a computer with internet connectivity. As contrary as it may sound, not all judges need to possess extensive legal knowledge. Certain judges may specialize, for instance, in determining whether or not a product was dispatched accurately (ideally, this would be managed by the postal system). Other judges might verify the fulfillment of employment agreements. Still, others would appraise damages for insurance contracts. It would be the responsibility of the contract creator to integrate judges of each category at the appropriate points within the contract, and the segments of the contract that can be articulated solely through computer code will be.
And that encapsulates everything.
The following section of this series will explore the notion of trust, and what cryptographers and advocates of Bitcoin truly intend when they refer to constructing a “trust-free” society.
