Smart Contracts Unchained

はじめに

スマートコントラクトについてブロックチェーンを専門にやっていない人達に向けて、話させていただいたが、全く手ごたえがなく、質疑応答をしていて、ほとんどの人がブロックチェーンとスマートコントラクトは一心同体だと思っている事を痛感し、もしかして私の方が間違っているのか！？と悩んでいた時に以下のツイートを見ました。

リンク先の文章について、共感する箇所がいくつかあったので感想を書こうと思います。

※：上記文章は、かなり偏った発言（要は悪口）が多くありますが、私自身そこに共感しているわけではありません、あくまでスマートコントラクトとしての考え方について共感した箇所についての感想となります。

翻訳は、Google翻訳とかDeepl翻訳とか使います。

原文＋機械翻訳をちょっと直したもの

詳細を開くには←の▶を押下してください。

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.

前者は、イノベーションのポイントがイノベーションをサポートするトークンではなく、トークンをポンピングすることであると非難される傾向があります。 後者は、現在のビットコイン（2019年初頭）では、基本的にメインチェーンのお金の共同カストディアンであるフェデレーションを使用する必要があります。

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.

• ブロックチェーンのコンセンサスルールの一部としてスマートコントラクトプラットフォームをサポートする必要はありません。

• このアイデアの実際の展開には、おそらくまだフェデレーションが必要です。

• このメカニズムは、一般的な「改善されたスマートコントラクト」ブロックチェーンで利用可能なものよりも高いプライバシーをサポートします。

• このメカニズムにより、すべての参加者が合意に基づいて別のスマートコントラクトに切り替えることを決定できます（たとえば、複雑なスマートコントラクトでバグが見つかった場合、パッチを適用したバージョンに切り替えることができます）、または別のスマートコントラクトプラットフォームに切り替えることもできます 。

• 2019年4月の時点で予想される、SegWit v1の今後の改善により、このメカニズムがさらに大幅に改善されます。

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.

エスクロープロトコルは、2-of-3マルチシグニチャを使用して実装できます。 キーは、売り手キー、買い手キー、およびエスクローキーです。

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:

これをエスクローサービス以外に2人以上の参加者がいるプロトコルに一般化すると、2つの主要なブランチがあることがわかります。

1. Every participant agrees to the result without involving the escrow service.

1. One participant disagrees and brings in the escrow service to mediate.

2. すべての参加者は、エスクローサービスを伴わずに結果に同意します。

3. 1人の参加者が同意せず、調停のためにエスクローサービスを導入します。

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:

2人の参加者の場合、上記の契約を提供するには、2-of-3マルチシグニチャが最適な方法です。 3人以上の参加者の場合、以下のブランチのいずれかで要求される可能性のあるスクリプトを使用できます。

1. N-of-N multisignature, one key per participant.

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

2. N-of-Nマルチシグニチャ、参加者ごとに1つのキー。

3. または、2-of-2マルチシグニチャ、エスクローサービスからの1つのキー、他のキーはすべての参加者に知られているがエスクローサービスには知られていない共有キーです。

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:

エスクローサービスキーは、標準の契約支払いプロトコルを使用して、解釈する必要のある契約へのコミットメントで調整されます。 たとえば、スマートコントラクトプラットフォームの公開鍵 E、スマートコントラクトのシリアルデータ s、および適切な暗号化ハッシュ関数 hが与えられた場合、微調整された公開鍵 Tは次のようになります。

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).

エスクローの秘密鍵 e が与えられると、上記には対応する秘密鍵 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:

n人の参加者それぞれの公開鍵 P1...Pn と、スマートコントラクトプラットフォームではなくすべての参加者が知っている共通の公開鍵C が与えられた場合、支払うスクリプトは次のとおりです。

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

Tr*st,、5文字の冒とく的な言葉

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.

スマートコントラクトプラットフォームサービスは、少なくとも1人の参加者の協力なしに資金を盗むことはできません。 Tr*stはまだある程度必要ですが、完全なカストディアンと比較すると削減されています。

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.

フェデレーションサイドチェーンの場合のように、スマートコントラクトプラットフォームを実行するフェデレーションを作成することで、Tr*stの問題を軽減できます。 フェデレーションメンバーのキーは、上記のスマートコントラクトスクリプトで微調整してから、フェデレーションが妥当と判断したマルチシグニチャスキームを使用できます。

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

たとえば、9-of-12フェデレーションスマートコントラクトプラットフォームは次のことを実行できます。

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.

もう1つの利点は、スマートコントラクトに重大なバグがあることが判明した場合、参加者が集まって契約を執行しないことに同意し、代わりに契約外の合意に従って資金を使うことができることです。 たとえば、バグ修正された変更されたスマートコントラクトに同意できます。 したがって、バグのあるスマートコントラクトは、修正するためにブロックチェーンのロールバックを必要とせず、スマートコントラクトプラットフォームとの相互作用さえも必要としません。

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.

ビットコインの今後の（2019年半ばの時点での）改善により、スマートコントラクトの非連鎖技術の能力が大幅に向上します。

MuSig and Schnorr-like Signatures

MuSigおよびSchnorrのような署名

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.

MuSigを使用すると、しきい値マルチシグニチャキーを生成できます。 これにより、m-of-nフェデレーションはスマートコントラクトに単一の公開鍵のみを提供できます。 さらに、参加者のn-of-nマルチシグニチャを単一の公開鍵に圧縮できます。

Taproot

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.

スクリプトの1つのブランチには、参加者の単純なn-of-nマルチシグニチャが含まれます。 もう1つのブランチは、シングルシグニチャとしきい値マルチシグニチャを含むため、より複雑です（スマートコントラクトプラットフォームがフェデレーションとして実装されている場合）。 これはまさにTaprootが設計されたユースケースです。

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.

参加者が同意しない場合でも、スマートコントラクトプラットフォームがどの正確なUTXOが争われているかを決して学習しないことが最善です。 SIGHASH_NOINPUT で署名することにより、スマートコントラクトプラットフォームは、使用されているトランザクション出力を知る必要がありません。 スマートコントラクトとスマートコントラクトへの入力、および使用されているUTXOの値を知る必要があるだけです。

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.

これで、スマートコントラクトプラットフォームによって作成された署名がオンチェーンで使用されている場合、スマートコントラクトプラットフォームはブロックチェーンをスキャンして署名を探し、使用されているUTXOを学習できます。

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.

ただし、資金の行き先を定義するこの署名の存在を使用して、参加者に参加者キーを使用して同じトランザクションに署名するように説得することができます。 UTXOはプラットフォーム署名で使用できるようになったため、参加者は署名を拒否することで利益を得ることができず、署名することでスマートコントラクトプラットフォームからプライバシーを保持できます。

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:

次に、Taprootアドレスに支払うようにメカニズムを変更できます。 Taproot公開鍵は、すべての参加者のn-of-nマルチシグニチャですが、Taprootスクリプトは次のとおりです。

<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.

T は、フェデレーションによって生成されたしきい値マルチシグニチャ公開鍵の微調整バージョンであり、Cはすべての参加者に知られている共通鍵です。

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.

Rootstockのようなフェデレーションサイドチェーンは、その主要なイノベーションがスマートコントラクトプラットフォームであるため、無関係です。 ただし、ここで紹介するように、フェデレーションは、新しいブロックチェーン全体のように非効率的なものを実装することなく、スマートコントラクトプラットフォームを提供することができます。 代わりに、ビットコインブロックチェーンは変更せずに再利用できます。 さらに、プライバシーとスマートコントラクトパッチの利点は、おそらく連邦によって管理されていないイーサリアムでさえ必要であるか望ましいかどうかに大きな疑問を投げかけます。

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.

Liquidは、少なくとも、このメカニズムでは提供できない機密のトランザクションと資産を提供します。 ただし、Simplicityやコベナンツなどのスマートコントラクトに対するイノベーションは、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.

ビットコインスクリプトには多くの制限があり、そのほとんどはブロック検証時間が爆発するのを防ぐために存在します。 このスマートコントラクトアンチェインドは、スマートコントラクトプラットフォームのルールを適用するためにブロックチェーンが必要ないため、ビットコインSCRIPTの検証時間が問題にならないことを意味するため、これらの制限を解除するシンプルなスマートコントラクトプラットフォームが役立ちます。

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.

このようなブロックチェーンは、ここで説明するように、Smart ContractsUnchainedを使用してより適切に実装されます。 フェデレーションは、過度に制限されたブロックチェーン内のすべてのブロックに署名するのではなく、参加者間で紛争が発生した場合にのみ、パブリックビットコインブロックチェーン上のトランザクションに署名します。

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.

• 多くの場合、許可されたブロックチェーンは業界全体で使用することが提案されています。署名者は、多くの場合、その業界内の大企業です。ただし、署名者は、許可されたブロックチェーン内のすべてのトランザクションを知ることになります。これは、大企業によるカルテルの形成を強く奨励し、小規模な競合他社を抑制する条件です。 Smart Contracts Unchainedのデフォルトのプライバシーは、これを防ぎます。

• 署名者が悪意のあるまたは破壊的な商慣行に従事していることが判明した場合、署名者セットからそれらを削除することは不可能または非現実的であることがよくあります。業界全体がこのようなイベントによって麻痺する可能性があり、参加者は悪意のある署名者のために許可されたブロックチェーンを使用することは不快であると感じますが、ブロックチェーン外の業界内で経済活動に従事することは困難です。 Smart Contracts Unchainedを使用すると、業界で定義された契約のすべての参加者が、フェデレーション自体を変更して、そのような既知の悪意のあるアクターを削除することに同意できます。

• 商業および産業エンティティが必要とする契約は、ビットコインがサポートする単純な契約よりもはるかに複雑であることがよくあります。これは、契約に微妙なバグがあり、展開するまで簡単に見つけることができないというフットシューティングに簡単につながる可能性があります。許可されたブロックチェーンは、ブロックチェーンをロールバックすることでバグのあるコントラクトの広範な展開を処理できますが、ロールバックは混乱を招き、時間に敏感なトランザクションを元に戻す可能性があり、大規模な問題でのみ使用されます。広く使用されていないがバグのある契約は、多くの場合、業界の混乱を保証せず、単にバグのあるままでいることが許可されます。 Smart Contracts Unchainedを使用すると、参加者は契約をバグのあるバージョンからバグのないバージョンに切り替えることができます。

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.

プライベートで許可されたブロックチェーンは、実用性がほとんどないかまったくありません。業界が経済的相互作用を説明する標準化された方法が潜在的に有用であると判断した場合でも、スマートコントラクトアンチェーン技術を使用して実装できます。

© 2019 ZmnSCPxj. Released under CC-BY.

感想（個人的な意見）

簡単にまとめると、スマートコントラクトプラットフォームを作って、ブロックチェーンと連携したほうが良いということだと思います。

もちろん、ブロックチェーンのスクリプトや、公開鍵方式で使用される暗号技術というものを利用しますが、実際の契約は、ブロックチェーンがサポートする機能よりも複雑である為、それ専用のスマートコントラクトプラットフォームが必要になると考えられるからです。

ただ、上記文章には記載されていないと思いますが、スマートコントラクトプラットフォームを作る上で考えるべきものがいくつかあると思います。

• セキュリティ
• プライバシー
• 秘密鍵の管理（ウォレット）
• など

---