Introduction

In cryptocurrency, smart contracts have traditionally been implemented as part of the consensus rules of some blockchain.

In particular, innovations (or “innovations” like the infamous Ethereum Meta-Bug of allowing Turing-completeness and thereby footguns) on smart contracting languages have often needed a blockchain to provide even just a minimal proof-of-concept. (I am not even referring to a minimal viable product here.)

Now, launching a new blockchain requires one of the following:

Creating your own token.
Becoming a sidechain reusing some existing token.

The former is prone to accusations that the point of the innovation is to pump the token rather than the token supporting the innovation. The latter requires, with current Bitcoin (early 2019), using a federation, which is essentially a joint custodian of the money in the mainchain.

This writeup, then, proposes an alternate method of creating a smart contract platform while requiring only basic functionality on some hosting blockchain, reusing the same token, without launching a separate blockchain, while reducing (but not eliminating) the custodian theft risk that federated sidechains have. Practical deployment will probably require a federation, but at least eliminates the creation of a very slow database.

Related Work

bit-thereum; it talks about oracles, with the strong implication that oracles are necessary for most expected smart contract usages. From a certain point of view, oracles, escrow services, and smart contract platforms as proposed under this mechanism, are all “the same” thing; only the oracle is expected to inspect the material world, whereas the smart contract platform need not do so. The “as long as everyone agrees” escape hatch seems to be new in this writeup, however.

Summary

We do not need to support a smart contract platform as part of consensus rules of a blockchain.
Practical deployments of this idea probably still require a federation.
This mechanism supports greater privacy than available on typical “improved smart contract” blockchains.
This mechanism allows all participants to consensually decide to switch to a different smart contract (for example, if a bug is found in a complex smart contract, it is possible to switch to a patched version) or even switch to a different smart contract platform.
Incoming improvements for SegWit v1, as expected as of April 2019, greatly improve this mechanism further.

Escrow Protocol

An escrow protocol is possible to implement using a 2-of-3 multisignature. The keys are the seller key, the buyer key, and the escrow key.

If the buyer and seller are able to come to an agreement on what happened, then they sign a transaction sending the tokens to the correct destination. However, if there is a dispute between them, the escrow service steps in and sorts out where the money should go to.

Generalizing this to a protocol with more than two participants aside from the escrow service, we find that there are two major branches:

Every participant agrees to the result without involving the escrow service.
One participant disagrees and brings in the escrow service to mediate.

For the two-participant case, a 2-of-3 multisignature is the optimum way to provide the above contract. For more than two participants, we can use a script which may be claimed with either of the below branches:

N-of-N multisignature, one key per participant.
OR, 2-of-2 multisignature, one key from escrow service, other key is shared key known to all participants but not the escrow service.

If every participant agrees, the first branch is taken. If a participant disagrees, they bring in the escrow service, which determines where the money should go, and then sign what the escrow service determines using the common key.

Smart Contract Platforms as Programmable Escrow Services

Smart contracts impose conditions on how a fund can be spent. In case of any dispute, the smart contract effectively decides how the fund gets spent.

A platform that can plausibly enforce a smart contract then works as an escrow that determines who controls the money according to the terms of the contract.

Thus a smart contract platform is a programmable escrow service.

Smart Contracts Unchained, or, Ethereum Blockchain Considered Extraneous

A smart contract platform, rather than implementing a completely new blockchain, can make use of an existing blockchain with simple smart contract functionality.

This is done by making the platform an escrow service with the above given simple smart contract.

The escrow service key is tweaked with a commitment to the contract that must be interpreted, using standard pay-to-contract protocols. For example, given the smart contract platform public key E, a smart contract serialization s, and a suitable cryptographic hash function h, the tweaked public key T is:

T = E + h(E | s) * G

Given the private key e of the escrow, the above has corresponding private key t = e + h((e * G) | s).

Given public keys P1...Pn of each of the n participant, and the common public key C known by all participants but not the smart contract platform, the script to pay to is:

OP_IF
  <n> <P1>...<Pn> <n>
OP_ELSE
  2 <T> <C> 2
OP_ENDIF
OP_CHECKMULTISIG

Each participant executes an interpreter of the smart contract language, and if all participants agree on the interpretation, sign with their participant keys. But if a participant diverges, they send the smart contract and any inputs required to the smart contract platform service. The smart contract platform service then signs using the tweaked key, and any participant can then add the common signature.

In order for the smart contract platform to be profitable, it is likely to extract a fee for each usage.

Tr*st, the five-letter curse word

The smart contract platform service cannot steal funds without the cooperation of at least one participant. Tr*st is still needed to an extent, but is reduced compared to a full custodian.

Tr*st issues can be mitigated, as in the federated sidechains case, by creating a federation that runs the smart contract platform. The federation member keys can be tweaked with the smart contract script as above, then use whatever multisignature scheme the federation judges reasonable.

For instance, a 9-of-12 federation smart contract platform might do:

OP_IF
  <n> <P1>...<Pn> <n>
OP_ELSE
  <C> OP_CHECKSIGVERIFY 9 <T1>...<T12> 12
OP_ENDIF
OP_CHECKMULTISIG

Benefits

This scheme massively increases privacy. If all participants agree (hopefully the common case) on the smart contract interpretation, then the smart contract platform never needs to learn about the details or even the existence of the contract. Contrast this to almost every blockchain implementation of an “improved” smart contract system, where the smart contract needs to be published onchain, publicly visible for all to see, greatly reducing privacy and fungibility.

Another benefit is that if the smart contract turns out to have a breaking bug, the participants can get together and agree to not enforce the contract, and instead spend the fund according to their off-contract agreement. For example, they can agree to a modified smart contract that has been bugfixed. Thus, buggy smart contracts do not require a blockchain rollback in order to fix, or even any interaction with the smart contract platform.

Yet another benefit is resilience to the disappearance of the smart contract platform. If the smart contract platform disappears, the participants can still execute the contract themselves, and if they agree, can sign a spend that still follows the smart contract in spite of the smart contract platform disappearing. If the code for the smart contract platform is open source, then a new smart contract platform implementation can be created, and the participants can agree to switch to the new smart contract platform implementation in much the same way they can switch from a buggy smart contract to a bugfixed one as in the previous benefit.

All these benefits arise from the first branch of the script: as long as everybody agrees, anything can be done, without asking the smart contract platform to enforce the contract committed to.

Participant-selected Federation

Currently, smart contract platforms implemented on federated sidechains indicate a fixed set of signatories as the federation.

However, this mechanism does not require a blockchain, and therefore does not require a monolithic set of rules that is agreed-upon by consensus of everyone using the platform.

In shorter sentences, this mechanism allows the participants to select the federation instead of a smart contract platform defining the federation.

If it is possible to advertise that one is willing to serve in a federation, participants in a smart contract may select the federation members and agree on how much is considered a sufficient quorum.

Improvements From Upcoming Bitcoin Innovations

Upcoming (as of mid-2019) improvements to Bitcoin greatly increase the power of the Smart Contracts Unchained technique.

MuSig and Schnorr-like Signatures

MuSig allows generation of threshold multisignature keys. This allows an m-of-n federation to provide only a single public key for smart contracts. In addition, the n-of-n multisignature of the participants can be compressed to a single public key.

Taproot

One branch of the script involves a simple n-of-n multisignature of the participants. The other branch is more complex as it involves a singlesignature and a threshold multisignature (if the smart contract platform is implemented as a federation). This is precisely the usecase that Taproot was designed for.

This massively increases privacy, because in the case where every participant agrees, nobody knows that the smart contract platform was even used.

`SIGHASH_NOINPUT`

Even if a participant disagrees, it is still best if the smart contract platform never learns which exact UTXO is being disputed. By signing with SIGHASH_NOINPUT, the smart contract platform does not need to know the transaction output being spent; it only needs to know the smart contract and the inputs to the smart contract, as well as the value of the UTXO being spent.

Now, if the signature created by the smart contract platform is used onchain, then the smart contract platform can simply scan the blockchain for the signature and learn the UTXO being spent.

However, the existence of this signature defining where the funds will go to, can then be used to convince participants to sign the same transaction using their participant keys. Since the UTXO is now spendable with the platform signature, participants cannot gain from refusing to sign, and can retain privacy from the smart contract platform by signing.

Modified Mechanism

The mechanism can then be modified so as to pay to a Taproot address. The Taproot public key is the n-of-n multisignature of all the participants, while the Taproot script is:

<T> OP_CHECKDLSVERIFY <C> OP_CHECKDLS

The T is a tweaked version of the federation-generated threshold multisignature public key, and C is a common key known by all the participants.

Conclusion

Federated sidechains like Rootstock are extraneous since their primary innovation is a smart contract platform. However, as we present here, it is possible for a federation to provide a smart contract platform without implementing something as inefficient as an entire new blockchain. Instead, the Bitcoin blockchain can be reused without modification. Further, the benefits in privacy and smart-contract-patching greatly bring to question whether even Ethereum, which is supposedly not controlled by a federation, is necessary or desirable.

Liquid, at least, provides confidential transactions and assets, which cannot be provided via this mechanism. However, its innovations to smart contracts, such as Simplicity and covenants, can be prototyped using this mechanism instead of on Liquid.

Bitcoin SCRIPT has many limitations, most of which exist in order to prevent block verification time from exploding. A simple smart contract platform that lifts those limitations can be useful, since this Smart Contracts Unchained means that verification time of Bitcoin SCRIPT is no longer an issue, as there is no blockchain needed to enforce the rules for the smart contract platform.

Addendum: Federated Permissioned Blockchains Are Better Implemented As Smart Contracts Unchained

Blockchain technology has become so much of a buzzword that strange constructions like “permissioned” blockchains have arisen.

Blockchains are slow databases which are primarily of use in coordinating large groups of people without prejudice. Permissioned blockchains have the bloat of blockchains, without the benefit of permissionlessness.

Often, transaction ordering in such blockchains is controlled by a fixed signer set, effectively a federation. Also very often, typical nodes are not expected to perform validation (due to the blockchain bloat), but are instead expected to leave transaction validation to the fixed signer set.

Such blockchains are better implemented using Smart Contracts Unchained as described here. The federation, rather than signing every block in an overly-restricted blockchain, instead signs transactions on the public Bitcoin blockchain only in the event of a dispute between the participants.

This has benefits over a permissioned blockchain:

Often, a permissioned blockchain is proposed to be used by an entire industry. The signatories are often large companies within that industry. However, the signatories end up knowing every transaction within the permissioned blockchain, a condition that strongly encourages the formation of cartels by the large companies, suppressing small competitors. The privacy-by-default of Smart Contracts Unchained prevents this.
When a signatory turns out to have engaged in malicious or destructive business practices, it is often impossible or impractical to remove them from the signatory set. An entire industry may be paralyzed by such an event, with participants finding it unpalatable to use the permissioned blockchain due to the malicious signatory, yet finding it difficult to engage in economic activity within the industry outside of the blockchain. Smart Contracts Unchained allows all participants in an industry-defined contract to agree to modify the federation themselves to remove such known-bad actors.
The contracts needed by commercial and industrial entities are often significantly more complex than the simple contracts supported by Bitcoin. This can easily lead to foot-shootings where a contract may have a subtle bug that cannot be easily found until deployment. Permissioned blockchains can handle widespread deployment of a buggy contract by rolling back the blockchain, but rollbacks are disruptive and may reverse time-sensitive transactions, leading to only being used in large-scale problems. Contracts that are not widely used but are buggy will often not warrant the disruption of the industry, and will simply be allowed to remain buggy. Smart Contracts Unchained allow the participants to switch contracts from a buggy to a bug-free version.

Private, permissioned blockchains have little to no practical use, and even if an industry might find that a standardized way of describing economic interactions to be potentially useful, such can be implemented using Smart Contracts Unchained technique.