Copyleft Currents

Check out FOSSA’s video on my recent talk.

Check out my latest article. Hot off the presses (and 100% human-written).

I am thrilled to announce that, with generous support from Mozilla and the Apache Foundation, we have officially launched FOSSDA, the Free and Open Source Stories Digital Archive. It’s time to tell the story of the free and open source movement! This project is now officially underway, thanks to all those who have helped make it happen.

Press release here.

Marc Andreessen famously said that software is eating the world. But the latest and greatest software trend–generative AI–is in danger of being swallowed up by copyright law. Like a cruise ship heading for a scary iceberg, AI is in trouble, and the problems are mostly below the surface. 

We now have a pair of lawsuits claiming that GitHub’s Copilot model is stealing open source code from its authors, and that companies using Stable Diffusion or other models (including Sta­bil­ity AI, DeviantArt, and Mid­jour­ney) are stealing images from visual artists. Both lawsuits are being prosecuted by Matthew Butterick (best known as the author of Typography for Lawyers) along with the Joseph Saveri Law Firm, a class action firm.

The Co-Pilot lawsuit is widely touted in the press as a copyright infringement case, but in fact it doesn’t claim copyright infringement. It does claim a litany of other wrongs based on torts like removal of copyright information, breach of contract, and fraud. The Stable Diffusion suit is in fact a copyright infringement suit. More importantly, and sadly, these lawsuits are probably a bellwether of more to come. 

The Co-Pilot suit is ostensibly being brought in the name of all open source programmers. Yes, that’s right, people crusading in the name of open source–a movement intended to promote freedom to use source code–are now claiming that a neural network, designed to save programmers the onus of re-inventing the wheel when they need code to perform programming tasks, is de facto unlawful. The open source movement is wonderful in many ways, but its tendency to engage in legal maximalism to “protect” open source is sometimes disappointing.

The Stable Diffusion suit alleges copyright infringement, stating that, “The resulting image is necessarily a derivative work, because it is generated exclusively from a combination of the conditioning data and the latent images, all of which are copies of copyrighted images. It is, in short, a 21st-century collage tool.” That characterization is the essence and conclusion  of the lawsuit, and one with which many AI designers would disagree.

So, all neural network developers, get ready for the lawyers, because they are coming to get you. 

Fair Use or “Fair & Ethical”?

The crux of the problem is that US copyright law, despite many landmark cases, still gives us little or no guidance on how copyright applies to the defense of fair use. The Oracle v. Google case, the biggest fair use case of this century, ambled on a lengthy and astonishingly expensive road to a Supreme Court decision. As Larry Lessig famously quipped, “fair use is the right to hire a lawyer,” and the Supremes proved that true by issuing an opinion that provided little guidance outside of the specific facts of the case. 

However you may feel about Google, it’s lucky that Google has the determination and resources to have spent astronomical legal fees defending the right of fair use–from books, to thumbnail photos, to news headlines, to software interface specifications. Users of the web benefit from that. If the AI industry avoids this iceberg, it will be partly because of Google’s historical unwillingness to roll over on fair use cases.

Let’s hope Microsoft (which funded OpenAI and owns GITHUB) has the Google-like intestinal fortitude and money to win this battle. But if Oracle v. Google is any measure, the answer might not come for 10 years, by which time the neural network industry may have been litigated out of existence–or worse yet, limited to those large players who can fund an expensive legal defense. For startups, having a lawsuit hanging over their heads is usually a death knell, between expensive legal bills siphoning off their development resources, and investors shying away from the risk.

Tell Me What You Want, What You Really, Really Want

One perplexing aspect of the lawsuits–and likely all that will follow in its footsteps–is what best practices the plaintiffs actually would want the AI industry to adopt going forward. Butterick says his class action cases are “another step toward mak­ing AI fair & eth­i­cal for every­one.” But other than netting a hefty fee for the lawyers who bring the suit, what is the endgame, exactly? 

Both lawsuits ask for permanent injunctive relief, which would essentially shut down the use of the accused models, but that is part of the playbook for litigation and probably not the result they would prefer. And even for most people who sympathize with the lawsuits, that is not the preferred endgame. Though there are lots of memes out there about Skynet, most people do not want AI to shut down, and if they do, it’s not because of copyright law.

One possible best practice would be to allow authors to specifically opt out of use of their output for ML training. (In fact, Stability has suggested this approach.) This type of approach can work when technical development bumps up against the limits of copyright law. For example, there is a “do not index” mechanism (robots.txt) for web sites that is broadly honored by large scale search engines. But such a convention would have a prodigious backlog to tag, and also, for software authors, prohibiting ML training would be antithetical to the Open Source Definition. So that probably won’t work.

Another possibility is compensation for those who wrote the original material used to train the models. Over the years, there have been various attempts to compensate authors for numerous and small contributions to copyrightable works. This is primarily an information problem, and those who try to solve it usually propose a blockchain based approach, lest payment transaction costs outweigh the compensation. None has been successful yet.

Even if there were a technical solution to the information problem, it would be difficult to allocate compensation to a broad set of creators in a fair way. In the music business, there are artists’ rights organizations like ASCAP and BMI that amalgamate the power to grant blanket music performance licenses to consumers of music, like restaurants that play music over their sound systems. In fact, these rights amalgamation organizations enjoy a limited safe harbor from antitrust law, because they facilitate what would otherwise require millions of small, individual licensing deals. 

But this will not work for generative AI. Performance rights organizations reward their authors roughly according to the popularity of their songs. For generative AI, it would be functionally impossible to track which work had been used, because the output is not, in fact, a copy of the original, nor even a collage–but a new work synthesized from a model trained using the original work. If compensation is not tracked to the images actually used, then we would likely see a spate of garbage images being thrown into the mix to grab some of the proceeds. It would be easier to set up a grant fund for artists generally than to track the contributions among millions of artists to a single AI-generated image.

The problem is that neural network models, and their outputs, are not copies of the original works. They are a set of probabilities (weights) that are trained based on thousands or even millions of data points. And at least as of now, it is not possible to look at ML output and determine which inputs, nodes and weights created it. ML, for now, is mostly a “black box” whose inputs and outputs are impossible to connect. In fact, the lack of reproducibility of ML has already been tagged as a social issue: if you build a model that discriminates in its output, how do you audit it? Eventually, the ML industry may solve this problem, but for now, it means there is a usually disconnect between the inputs and outputs, and that probably means that copying could never be  inferred in a way that could reliably allocate compensation to the authors of inputs. That, in turn, should mean there is no copyright infringement, but the lawsuits posit otherwise.

Moreover, there is a notice problem. Each of the lawsuits alleges a claim under the Digital Millennium Copyright Act (DMCA) 17 USC §1202(c) of the DMCA) (“CMI”), which prohibits removal of copyright information such as copyright notices. But even assuming that some license notice, or copyright notice, would have to be communicated whenever an AI output was generated, how exactly would that happen? Would each resulting image require thousands or millions of notices? Even now, conventional users of open source code struggle greatly with management and delivery of license notices–anyone who has worked on open source compliance knows how difficult that can be. But these lawsuits make that problem look like child’s play.

If AI Dies, Who Wins?

Both of the Butterick suits are being brought as class actions–a type of lawsuit popularized in the US and still relatively unusual elsewhere. You may have gotten notices from class action lawyers asking you to opt in to a settlement class to which you belong. If you’re like me, you toss them out, because your reward for joining the class will probably be a coupon or a princely settlement of $20.

And so, who benefits from class action suits? Well, class action lawyers. When you hear that a class action suit has resulted in $6 million in damages, the lawyers probably get about $2 million (one-third). Because a class can consist of thousands of members (or in the case of the Butterick suits, probably millions), the damages allocated to the individual class members can be tiny indeed. Sometimes, the lawyers actually get bigger payouts than all the plaintiffs combined. The US class action model has been strongly criticized for being a vehicle for enrichment of plaintiff’s lawyers that provides relatively little real compensation to the plaintiffs they represent. Class action proponents use populist rhetoric and anecdotes to justify their suits, but empirical studies are relatively few, and sometimes, damning. (See for example: https://instituteforlegalreform.com/research/do-class-actions-benefit-class-members/ and https://www.tortreform.com/news/study-class-action-lawyers-often-take-more-money-from-settlements-than-class-members/) 

Don’t Die

If the AI industry is to survive, we need a clear legal rule that neural networks, and the outputs they produce, are not presumed to be copies of the data used to train them. Otherwise, the entire industry will be plagued with lawsuits that will stifle innovation and only enrich plaintiff’s lawyers. Matthew Butterick has stated that these lawsuits are an attempt to set a precedent in favor of artists, because the law is unclear. Lack of clarity causes people to act conservatively to avoid liability, and that stifles innovation. Given that the courts are unlikely to come up with a common-law rule in this decade, clarity probably needs to come in the form of a legislative amendment to the copyright law. Unless it comes soon, the generative AI industry may be in trouble.

It’s unclear whether Butterick’s suits are mostly a publicity stunt and a ploy for the plaintiff’s lawyers to make a windfall, or a selfless attempt to provide equity for authors, or somewhere in between. But one thing is sure: they will spark a cottage industry for plaintiff’s lawyers, cause crippling expenses for AI developers, and thwart innovation in the generative AI field. As the tech industry celebrates the frothy emergence of machine learning in a time of economic doom and gloom, let’s hope this nascent field doesn’t sink because of the copyright iceberg looming ahead.

Note: Since I started preparing this article for publication yesterday, an additional case was threatened in London by Getty Images regarding Stability AI. Because Getty is the single owner of so many images, and outside the US, this is not a class action suit, and may be more likely to result in a settlement. 

Update February 6, 2023: The other shoe drops: Getty filed a complaint in Delaware against Stability AI.

Also, this blog post is a personal opinion, and nothing I have written here should be attributed to any of the parties involved.

A bill was recently introduced in the US Senate, entitled the Securing Open Source Software Act of 2022.

I don’t usually write much about pending legislation, because it often does not ever become law, or changes substantially before it becomes law. This bill is unlikely to be passed this year because of its timing. But it has a few interesting characteristics.

• It is a bipartisan bill, introduced by Gary Peters (D-Mich.) and Rob Portman (R-Ohio, both members of the Senate Homeland Security Committee.
• It defines both “open source software” and “open source software community.”
• It focuses on requirements for software bills of materials (SBOMs), and security concerns, drafting on the Executive Order, from earlier this year, about software security Executive Order on Improving the Nation’s Cybersecurity (EO 14028).
• It establishes “the duties of the Director of the Cybersecurity and Infrastructure Security Agency regarding open source software security” and requires the Director to regularly assess open source software used by the federal government. So it establishes a process, more than substance.

If I had to guess, I would say the bill seems likely to pass in some form, next year. If it does, it’s unclear exactly how it will interact with the recent EO. Also, improved security assessment is good for all software, not just open source — open source security breaches get a lot of press, but all software has potential security issues, and the government should be concerned about its use of proprietary software as well. Finally, to the extent new law establishes requirements for government, or even other customers of software, the private market is mostly ahead of these requirements already. Most software vendors know that customers are already very demanding regarding security requirements. The effect of new law could be to normalize those market demands in private sectors and government — but we will have to wait and see.

About a year ago, I wrote about a copyright case involving fireworks firing codes. This case did not get a lot of attention at the time, and it was yet another example of a plaintiff using copyright law as unexploded ordinance (if you will forgive the pun) to harass its competitors, rather than to protect works of authorship.

Fortunately, the Third Circuit recently vacated a prior injunction in the case, for lack of likelihood of success on the merits, and remanded to the district court with an order to to dismiss the claim with prejudice.

The court analyzed the copyright protection of both Pyrotechnics’ digital message format, and the digital messages created with it. The opinion linked above provides interesting detail on how the messages worked.

The court said, “Pyrotechnics’s digital message format is an uncopyrightable idea and the individual digital messages described in the [copyright registration] are insufficiently original to qualify for copyright protection.” Regarding the message format, it concluded:

Pyrotechnics admits that there is no way for the control panel to communicate with the field module without using the digital message format. Because there are no other “means of achieving the [protocol’s] desired purpose” of communicating with the devices, the digital message format must be part of the uncopyrightable idea and not a protectable expression.

Citing Whelan, 797 F.2d at 1236.

As to the messages using the format, the court said, “The digital message format provides rules for constructing messages with particular meanings, and individual messages are generated by applying those rules mechanically.” Because there was insufficient human creativity in creating the format, the messages were not protected by copyright. It further noted that even assuming the messages were creatively produced, there was no creativity in the structure, and ordering, because “using leading header bytes for synchronization and a trailing byte as a cyclic redundancy check are standard communication practices, not creative sequencing.” The court relied on its prior decision in Southco, Inc. v. Kanebridge, 390 F.3d 276, 282 (3d Cir. 2004) (en banc), regarding a numbering system for fasteners, from which the court drew many parallels.

Fighting a David vs. Goliath Copyright Battle

I got a chance to correspond with the owner of FireTEK. Here is what he had to say about the case:

How did you become interested in fireworks systems? How did you learn to engineer them?
The first time I was in the backstage of a fireworks display it was with my system. I started this project because someone asked me if I could do this kind of system to control fireworks, in 2009. I said no a few times, but he insisted, so I decided to try to do it. But then he decided he did not need the system anymore. Also, I had hired some people to do the work, but they quit. So I started researching and learning, and did almost everything myself, and then I became passionate about developing and innovating.

Even though the project started with a lot of problems, now I could see almost all the problems I had, and that helped me make a better product. For example, a main component went out of production and I was forced to find a replacement, but the replacement I found was even better. Because I could not afford someone to do the project, I was forced to learn myself. Even this copyright trial was a learning experience, and a good thing in the end.

Copyright cases can be complicated. What encouraged you to fight the claim?
I run a very small company in Romania. Maybe the plaintiff thought I would not be able to defend myself, but that was not true. This was a difficult and expensive case for me to defend. I was also concerned that, because I was outside the US, I would not get justice from a US court. I knew I had the law on my side, but I didn’t know whether that meant I would win. I kept going, though, because this is my business and I need to protect it.

What do you think tipped the case in your favor?
To be honest I thought it would be an easy win at first, from what I have read about copyright and compatibility. I don’t think the district judge understood the differences between my product and theirs. It seemed to me that the district court opinion mostly copied the plaintiff briefs. That opnion never mentioned my main argument under 17 USC 102(b) and US Supreme court decision in Baker v. Selden. Furthermore, the district court found the work equivalent to an object code and found fixation even though one of the authors clearly states it is “not source code that resides in a computer or in a microprocessor somewhere.” The deposit material for the plaintiff’s copyright was just a simple text created after infringement from memory of someone which was not even listed as author and which briefly describes the protocol.The judge in the appeal understood this. That opinion shows the judge studied it carefully. But I don’t think the district court understood it though I found that hard to believe.

After reading the district court opinion and some other rulings made against me, I was feeling as the main character “The Trial” by Kafka.

What advice do you have for small businesses fighting legal claims?
It will not be an easy fight, but if you know you are right, go to fight. Very important in my case was my involvement in the strategy, briefs, arguments, and of course learning from mistakes. You know your case better than your attorney, so you should read, understand and correct the mistakes your attorney may write in the briefs.

What is next for you in your business?
Even though I won this case my goal is not to get clients with cheaper compatible products. I try to innovate and convince them to buy my product because of all it offers. The compatibility is only an argument to convince the potential client to try my product, because I know they can not switch so easily to another product. It is like you have an entire company which runs a CRM software and you decide to switch to another one if it has some advantages but you find out the cost of the switch is much higher if there is no compatibility to migrate databases for example.

Congratulations to FireTEK for winning a battle against copyright maximalism, just in time for Independence Day!

Here are my latest musings about why open source is so much like ESG — both in legal risk assessment and investment consideration.

On May 13, 2022, the US District Court of the Central District of California issued a decision in Software Freedom Conservancy v. Vizio.

For more about the initial complaint see my previous post. In brief, SFC had sued Vizio in California state court, alleging that a violation of GPL was a breach of contract, and seeking declaratory judgment and specific performance (release of source code). SFC is not the author of the GPL code at issue, and the authors of the code are not party to the suit.

The issue in the removal motion was whether there was federal jurisdiction, sufficient to shift the lawsuit from state court to federal court. Federal courts in the US have exclusive subject matter jurisdiction over copyright claims, and diversity jurisdiction over other claims that are between parties in different states, and where damages are sought in excess of $75,000. 28 USC § 1332. But SFC’s complaint was neither a copyright infringement claim nor a claim for damages. This neatly avoided federal subject matter or diversity jurisdiction. The court said, “There is no dispute that SFC’s complaint alleges only state law claims, and the Parties agree that the action is removable only if SFC’s claims are completely preempted.”

The remaining question was whether the state law claims were pre-empted by copyright law. Preemption is a legal doctrine that reserves certain kinds of matter to the exclusive regulation of federal law. Under 17 USC 301a, federal law clearly pre-empts all claims that are within the scope of copyright law. Here, however, the court said the state law claim pled by SFC was different from a copyright claim. Therefore, the court in this case did not take jurisdiction over the matter away from the state court.

To support its preemption argument, Vizio argued unsuccessfully (relying on MDC v. Blizzard) that all violations of license conditions should only result in copyright infringement claims. But that was converse logic. MDC was about what cannot be a copyright claim, not what must be one.

Through the Looking Glass

The parties’ positions were unusual, because defendants generally prefer defending contract claims to copyright claims. Open source enforcers almost always bring the actions as copyright claims rather than (or in addition to) contract claims. Copyright generally affords more generous remedies than state law contract claims, including the possibility of statutory damages. Also, injunction is often available as a remedy under copyright law, but rarely under contract. So, SFC v. Vizio is an anomaly, where the plaintiff argued for contract claims and the defendant argued for copyright claims.

Moreover, there is a history of open source licensing pundits theorizing that open source licenses are “not contracts.” It has long been my view that this theory was misplaced. (I think, originally, that theory was intended to avoid contract formation arguments under the law of the 1990s, which arguments were largely sidelined in 1996 by the ProCD case (86 F.3d 1447 (7th Cir. 1996). But I am reading between the lines there.) GPL2 famously says, “You are not required to accept this License, since you have not signed it.” But the existence of a contract depends on the facts surrounding contract formation, and not so much on what the document says. It is more accurate to say that open source licenses need not be contracts to be enforceable, because violating their conditions provides the basis for a copyright infringement claim, as clearly established in US law, mainly under Jacobsen v. Katzer. Contract claims are therefore usually a belt-and-suspenders tactic in open source enforcement.

The law has never clearly articulated the answer to the “license or contract” question, but Jacobsen v. Katzer suggested contract claims were possible, as did Artifex v. Hancom. So in sum, there is case law saying copyright claims are possible, but none saying contract claims are impossible.

Neither a Win Nor a Loss, Yet

Some open source advocates are celebrating, but that celebration is probably premature. This result does not mean the federal court is saying there is a valid state contract claim, or that the remedy sought is available, only that there is no basis for federal jurisdiction.

Assuming the ruling stands and the case goes back to state court, there are a few possibilities:

• there is a state law claim for which the remedies sought are available
• there is a state law claim but the remedies sought are not available
• there is no sustainable state law claim

SFC still has a lot of bridges to cross–the highest and widest being the availability of specific performance as a remedy for breach of contract. Most legal commentators have long believed there is no basis for such a remedy under licenses like GPL, only damages for breach. And while injunctions are often available for copyright infringement, those injunctions are negative injunctions–orders to cease and desist using the infringed material. Specific performance, sometimes called a positive injunction, is a very rare remedy under contract law, and a court forcing a technology company to disclose proprietary information due to a breach of contract is virtually unheard of. Courts tend to order people to stop doing things, not to do them. The reason for this is deeply woven into our notions of civil liberty, granting courts only limited powers. Injunctive relief is an exceptional remedy, because it impinges on civil liberty. Courts can order you to go to prison (for crimes) or pay money (for torts), but they don’t usually order you to do much else. That’s in part because they don’t have the resources to police positive injunctions. When you read in the news about a court ordering someone to do something, it is usually part of a negotiated settlement or consent decree.

This begs the question of what will happen to open source adoption if SFC is successful. The resulting risk of everyone–not just authors–having authority to sue for enforcement of GPL may significantly disrupt the open source ecosystem. Back in the late 1990s, companies were extremely reluctant to use GPL code (like Linux) due to the perceived legal risks–which were in part trumpeted as FUD by anti-open-source actors like Microsoft. But over the years, the tech industry grew comfortable that the only risk of lawsuits was from authors, and most authors preferred informal enforcement to legal process. That process of acclimation took decades. A change in this assumption could cause companies to stop using the GPL software they have grown comfortable using over the years, and it’s not clear that would be a win for the open source ecosystem.

Welcome to another installation of me teaching myself about crypto by writing about it! In past posts, I have discussed topics like Bitcoin mining and proof-of-stake. I’m not an expert on crypto, but I like learning about technology, and these posts are an attempt to share what I have learned at a level that is not too basic, but not too advanced, for readers who are curious, like me. Actually, this topic has a lot to do with contract law, so I am more comfortable writing about it than those prior posts.

The thing I hear repeatedly about smart contracts is that they are neither smart nor contracts. Let’s figure out why people say that, and whether it is correct.

What is a Smart Contract?

A smart contract is a transaction that executes automatically on a blockchain, according to a set of programmatic rules. The most commons kinds of smart contracts today are trading, investing, lending, and borrowing–financial transactions. Also, non-fungible tokens (NFTs) are created via a minting process embodied in a smart contract.

The term smart contract was coined by Nick Szabo in 1998. He wanted to apply the principles of distributed ledgers to executing transactions.

Not all blockchains support smart contracts. The most popular one that does is Ethereum. On Ethereum, smart contracts are executed via the Ethereum Virtual Machine (EVM). The EVM is isolated, in the sense that it has no access to network, file system or other processes on which the blockchain is running. That is important so that bugs in smart contracts cannot affect the entire blockchain, or other transactions.

Smart contracts, like any logic, are written in a programming language. The most common one is a statically-typed language called Solidity. Other languages, like Rust and Javascript, are used, but Solidity is specifically for smart contracts.

Are they Smart?

Not in the lay sense. The quintessential example of a smart contract, suggested by Szabo, is a vending machine. If you put in the money, and press a selection button, the snack drops down. That is not very smart, but it is automatic, and eliminates the need for a human to fulfill the transaction on the seller side.

Smart contracts are smart in that they are self-executing without human intervention. In contrast, traditional legal contracts are almost always promises to do things in the future, so they need to be performed by humans, and tracked, to be sure the parties actually perform them.

Actually, smart contracts are usually nowhere near as complicated as most traditional written contracts, which often have pages of terms and conditions. At this point, smart contracts contain rules that are “fairly rudimentary.” Here is an example of a simple smart contract:

This example creates an Ether wallet. As you can see, the language looks similar to C++. The first lines of the program name the license for the code, and the language it is written in. The program logic after that is quite simple. There are many other examples here.

Smart contracts work because the EVM can send a transaction from one account to another account, and that transaction can include binary data (the payload) and Ether (the cryptocurrency). If the receiving account contains logic (the smart contract), that logic is executed with the payload as input data.

To execute a smart contract requires the payment of a transaction fee, called a gas fee. (Because it’s Ether.) A smart contract that is more complex will cost more gas to execute. The maximum gas price is set by the creator of the transaction. If the authorized gas is insufficient, the transaction will not execute. If some gas is left after the execution, it is refunded to the creator.

You can see some examples of smart contracts on Ethereum here.

Are they Contracts?

Yes, but the bar for formation of a contract is pretty low. And smart contracts are usually not what lawyers call executory contracts. Under law, a contract is formed when there is an offer, acceptance, and consideration (an exchange of value). Once the contract is formed, the parties must perform the terms of the contract, and until they are done performing, the contract is called an executory contract.

Smart contracts are often touted has having the advantage of not requiring a third party to authorize them. But in fact, in most modern economies, traditional contracts do not require a third party to authorize them, exactly. Or perhaps only by implication, because parties perform contracts because of the threat of a third party’s involvement. If one party to a contract breaches, the other party can sue for damages, and a neutral third party (like a court or arbitrator) can enforce the contract, based on contract law. But most contracts are never litigated. So, while traditional contracts can be executed between the parties with no third party intervention, the more accurate accurate distinction is to say that smart contracts are concluded on the blockchain with no additional human effort.

Smart contracts happen immediately–or at least, as soon as the blockchain can process them. Of course, traditional contracts can be executed quickly, too. If you walk up to a fruit stand, hand over a dollar and take an apple, that’s a contract, and it executes immediately. But those kinds of contracts are not usually written in advance.

Unlike traditional contracts, smart contracts are transparent and irreversible, because they execute on a blockchain. Everyone can see the smart contract if they look at the blockchain. In contrast, the terms of traditional contracts are often confidential, and they can be amended or voided by the parties.

Also, traditional contracts are rarely pseudonymous. In fact, it’s important, in a traditional contract, to clearly identify the parties–which is why we include corporate names, addresses, and other identifying information when we define parties in a contract. That’s to help enforce the contract against the right person, if necessary. But blockchain transactions are by definition pseudonymous. The contracting parties do not have to know each other’s true identities. Depending on your viewpoint, this is a benefit or a drawback.

Smart contracts can stand on their own, or be paired with a traditional contract and execute only some of its provisions. For lawyers who are accustomed to traditional contracts, it may be easier to think of a smart contract as the execution of an escrow or a closing process. Money is paid upon the occurrence of a specific trigger. And like escrow agents, smart contracts need specific and unambiguous direction as to what is to be done to effectuate the transaction. And complicated instructions are generally not a good idea.

Like traditional contracts, smart contracts can suffer from ambiguity or “bugs.” Any program can fail to account for contingencies in the real world. But smart contracts are mostly quite simple, at this point. In comparison, traditional contracts are complicated, and the reason people hire lawyers to write them is that they need lawyers to consider the myriad things that can go wrong, and whether and how to account for them in the contract.

What’s Next for Smart Contracts?

First of all, they will not be replacing traditional contracts any time soon. But they may make inroads into replacing escrows or closing processes. However, pseudonymous contracting is probably insufficient for some transactions, such as when the parties have know-your-customer (KYC) requirements or require complex closing conditions.

The applications of smart contracts are likely to to expand over time. While today, smart contracts mostly involve payments and similar financial transactions, they are already being used for investment transactions, automated asset management, and self-paying loans. In the future, they might be used to establish pseudonymous digital identities, transfer assets such as land title, manage capitalization tables, verify supply chains, or conduct public elections.

It’s also likely that new blockchains will support smart contracts. The market for different blockchains and cryptocurrencies is highly competitive, and the additional functionality of smart contracts can help make a blockchain more popular.

More Resources

Here are some additional resources, if you want to learn more about smart contracts:

• Ethereum and smart contracts
• Solidity tutorial
• Lots of ideas about the use of smart contracts
• Cryptokitties smart contracts

In a prior post I wrote about the basics of blockchain and proof-of-work Bitcoin mining. One topic omitted from that post was the alternative consensus mechanism, proof-of-stake. Last week, the EU turned down a proposal purporting to outlaw the use of proof-of-work cryptocurrencies in the EU. Also, Ethereum–the world’s second most popular crypto blockchain–is in the process of moving from proof-of-work to proof-of-stake. So this week, I am looking at the difference between these methods of consensus, and why proof-of-stake is likely to eclipse proof-of-work in the future.

Problems with Proof of Work

The main problems with proof-of-work are that it requires a great deal of power, as well as specialized computing equipment. Power requirements are an environmental problem, and specialized equipment is an access problem–particularly during a time when semiconductors are in short supply. If you want to know more about how proof-of-work mining happens, take a look at my last post.

But proof-of-work is also designed to have a limited throughput and pace. New blocks on Bitcoin are designed to be created about once every 10 minutes, and that means transactions take 10 minutes to happen. That may sound fast, but in the world of globalized currency exchange, it is not fast enough for everyday transactions.

These, and other concerns about proof-of-work, have led cryptocurrency communities to consider an alternative called proof-of-stake.

What is Proof of Stake?

Proof-of-stake is a method of reaching consensus on the validity of new blocks in a blockchain. Adding new blocks must happen via consensus because blockchains are distributed databases with no central authority to certify them. Proof-of-stake validates new blocks via a process known as staking. Staking is similar to voting, but because different validators can stake different amounts, voting power is not equally distributed among validators. In this way, it’s more like the way voting works in corporate shares than in democratic elections.

As with proof-of-work, proof-of-stake consensus is a two-step process. First, validators compete to propose a new block based on the transactions in the queue to be cleared. Then, once a validator wins the right to propose the new block, all the validators must reach consensus that the new block is correct.

In a proof-of-stake system, any validator can propose to add a new block to add to the blockchain, and must choose the amount of coins to stake. There is a minimum stake required, like an ante to play a round of poker. (Ethereum’s new proof-of-stake system will require a minimum stake of 32 ETH, which is about $3,000 as of this writing in March 2022.) The system chooses a validator at random to propose the new block, but the random choice is weighted by the amount of coins staked by each validator. This means those offering a larger stake are more likely to win the validating competition. The winning validator then proposes a new block to add to the chain.

All validators are responsible for attesting the blocks created by other validators. When the minimum required validators attest that the block is accurate, the block is added to the chain. (For ETH, the approval of 128 validators will be necessary to validate a new block.) The winning validator then adds the block and populates it to the nodes on the blockchain, and the system moves on to the next block.

Any validator who proposes a bad transaction or block would be slashed, meaning the validator would forfeit the stake. Also validators will lose their entire stake if they later attempt a 51% attack to the validity of the chain. This means validators have a high incentive to maintain the blockchain and protect its integrity. Validators can also be penalized for failing to fulfill their validating duty for other validators, but these penalties are relatively smaller.

Why is Proof of Stake Important?

Every technology needs a killer app, and for proof-of-work, Bitcoin was the killer app. But there are lots of cryptocurrencies these days, and each has its own rules and validation requirements. The killer app for proof-of-stake is likely to be Ethereum. Ethereum is different from Bitcoin in many ways. Ethereum is capable of executing smart contracts, and significantly, is the main blockchain on which NFTs are minted and sold.

Ethereum is currently mined via proof-of-work, but is in the process of transition to validation via proof-of-stake. It will do this as part of its lengthy 2.0 release process, and initial efforts to make the change have been ongoing for some time now.

Which is Better, Proof-of-Work or Proof-of-Stake?

Keep in mind that the purpose of each consensus paradigm is to create scarcity of the minted currencies, and ensure the integrity of the blockchain. That means the consensus requirements must provide incentives for participants to validate, and disincentives for validators to corrupt the blockchain. (For a tutorial on different consensus mechanisms, here is a good video.) Here is how the two methods compare:

• Security. There seem to be differing opinions as to which method is more secure to avoid 51% attacks or spoofed chains. But most of the opinions I found say proof-of-stake is better, because the risks for validators of violating the rules are higher, so the expected costs of an attack will outweigh the expected benefits. Others call proof-of-work more secure. So, it seems the jury is still out on this point. Proof-of-work is battle-tested via its current use in Bitcoin and Ethereum. Proof-of-stake is at a more experimental stage, though some cryptocurrencies already use it.
• Speed. Proof-of-stake is potentially faster. Blockchains like the one for Bitcoin are designed to create new blocks about every ten minutes. This is actually so slow, in computing terms, that it’s considered a reason why Bitcoin is not suitable for everyday transactions. Ethereum’s current proof-of-work pace is much faster than this, due to its different design, but all proof-of-work systems are limited by the time it takes to mine the block. Moreover, proof-of-stake architectures enable a technique called sharding, which allows the blockchain to be split into shard chains, each of which is capable of processing blocks in parallel. This increases the potential speed of proof-of-stake systems.
• Environmental Impact. Proof-of-stake consumes much less energy. Staking doesn’t require the extensive computing resources of proof-of-work, which is specifically designed to be difficult and expensive to do.
• Barriers to Entry. Proof-of-stake can be viewed as having lower barriers to entry, because the minimum stake is less than the cost of equipment required to successfully perform proof-of-work. However, each system favors validators with more resources, who are more likely to win the rewards for validation.
• Concentration. Proof-of-stake can more easily become concentrated. Validators with the most can afford to risk more, and thereby get more rewards. However, proof-of-work has also become concentrated, as currently more than half the mining rewards for both Bitcoin and Ethereum are won by a few mining pools. So the relative level of concentration remains to be seen.

The EU Proposal

The EU recently considered a proposal to create a broad legislative framework for digital assets. The Markets in Crypto Assets (MiCA) proposal was a detailed plan for regulating crypto in the EU. Among many other topics, it sought to prohibit those in the EU from using proof-of-work currencies. That element of the proposal was highly controversial, given the two most popular cryptocurrencies still use a proof-of-work consensus. As soon as the proposal was made, cryptocurrency advocates started lobbying against it. On March 14, 2022, the EU Parliament voted against the proposal. However, EU is expected to create a revised proposal by January 2025.

Regardless of the ultimate success of a revised EU proposal, and whether it includes a ban on proof-of-work cryptocurrencies, the existence of this plank in the proposal shows that the winds are changing. Environmentalist criticism of the power requirements for proof-of-work have been eroding the reputation of cryptocurrencies, already tarnished for enabling illegal transactions such as ransomware. If Ethereum’s new proof-of-stake is successful, it seems likely to eclipse proof-of-work as the consensus mechanism of choice for new cryptocurrencies.