The Idea of Smart Contracts

# はじめに

最近、スマートコントラクトについて話す機会があったので、もう一度調べてみました。
そこで、スマートコントラクトが最初に登場した原文？を読みながら私自身なりの感想を書こうと思います。

スマートコントラクトは、1997年にNick Szabo（ニック　サボ）氏が最初に提言したとされています。
以下のリンクが元の文章とされています。

https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_idea.html

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

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


<details><summary>詳細を開くには←の▶を押下してください。</summary><div>
> The Idea of Smart Contracts

スマートコントラクトというアイデア

> Copyright (c) 1997 by Nick Szabo
> permission to redistribute without alteration hereby granted

著作権 (c) 1997年 ニック・サボ
変更なしで再配布することを許可します。


---


> What is the meaning and purpose of "security"? How does it relate the the relationships we have? I argue that the formalizations of our relationships -- especially contracts -- provide the blueprint for ideal security.

「セキュリティ」の意味と目的は何ですか？
それは私たちの関係とどのように関連していますか？
私たちの関係、**特に契約の形式化**は、理想的なセキュリティの青写真を提供すると私は主張します。

> Many kinds of contractual clauses (such as collateral, bonding, delineation of property rights, etc.) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive (if desired, sometimes prohibitively so) for the breacher. A canonical real-life example, which we might consider to be the primitive ancestor of smart contracts, is the humble vending machine. Within a limited amount of potential loss (the amount in the till should be less than the cost of breaching the mechanism), the machine takes in coins, and via a simple mechanism, which makes a freshman computer science problem in design with finite automata, dispense change and product according to the displayed price. The vending machine is a contract with bearer: anybody with coins can participate in an exchange with the vendor. The lockbox and other security mechanisms protect the stored coins and contents from attackers, sufficiently to allow profitable deployment of vending machines in a wide variety of areas.

多くの種類の契約条項（担保、担保、財産権の描写など）を、契約違反を高額にするように（必要に応じて、時には法外にそうするように）、私たちが扱うハードウェアおよびソフトウェアに組み込むことができます。 ）ブリーチャーのために。
スマートコントラクトの原始的な祖先であると私たちが考えるかもしれない標準的な実例は、謙虚な自動販売機です。
限られた量の潜在的な損失（の量はメカニズムを破るコストよりも少ないはずです）内で、マシンはコインを取り込み、単純なメカニズムを介して、有限オートマトンを使用した設計で1年生ののコンピュータサイエンスの問題を引き起こします。表示された価格に応じて変更と製品をディスペンスします。
自動販売機は無記名者との契約です。コインを持っている人は誰でもベンダーとの交換に参加できます。
ロックボックスやその他のセキュリティメカニズムは、保管されているコインやコンテンツを攻撃者から保護し、さまざまな分野で自動販売機を収益性の高い方法で展開できるようにします。

> Smart contracts go beyond the vending machine in proposing to embed contracts in all sorts of property that is valuable and controlled by digital means. Smart contracts reference that property in a dynamic, often proactively enforced form, and provide much better observation and verification where proactive measures must fall short.

スマートコントラクトは、自動販売機を超えて、価値があり、デジタル手段によって制御されるあらゆる種類の資産に契約を組み込むことを提案します。
スマートコントラクトは、動的で、多くの場合積極的に実施される形式でそのプロパティを参照し、積極的な対策が不十分である必要がある場合に、はるかに優れた観察と検証を提供します。

> As another example, consider a hypothetical digital security system for automobiles. The smart contract design strategy suggests that we successively refine security protocols to more fully embed in a property the contractual terms which deal with it. These protocols would give control of the cryptographic keys for operating the property to the person who rightfully owns that property, based on the terms of the contract. In the most straightforward implementation, the car can be rendered inoperable unless the proper challenge-response protocol is completed with its rightful owner, preventing theft.

別の例として、自動車用の架空のデジタルセキュリティシステムについて考えてみます。
スマートコントラクトの設計戦略は、セキュリティプロトコルを継続的に改良して、それを扱う契約条件をプロパティにさらに完全に組み込むことを提案しています。
これらのプロトコルは、契約の条件に基づいて、そのプロパティを正当に所有する人にプロパティを操作するための暗号化キーの制御を提供します。
最も簡単な実装では、適切なチャレンジ/レスポンスプロトコルが正当な所有者と一緒に完了しない限り、車は操作不能になり、盗難を防ぐことができます。

> If the car is being used to secure credit, strong security implemented in this traditional way would create a headache for the creditor - the repo man would no longer be able to confiscate a deadbeat's car. To redress this problem, we can create a smart lien protocol: if the owner fails to make payments, the smart contract invokes the lien protocol, which returns control of the car keys to the bank. This protocol might be much cheaper and more effective than a repo man. A further reification would provably remove the lien when the loan has been paid off, as well as account for hardship and operational exceptions. For example, it would be rude to revoke operation of the car while it's doing 75 down the freeway.

車が信用を確保するために使用されている場合、この伝統的な方法で実装された強力なセキュリティは、債権者にとって頭痛の種となります。買い戻し不動産人はもう怠け者の車を没収することができない。
この問題を解決するために、スマートな先取特権プロトコルを作成することができます。所有者が支払いを怠った場合、スマートコントラクトは先取特権プロトコルを起動し、車のキーの制御を銀行に返します。
このプロトコルは、買い戻し不動産人よりもはるかに安価で効果的かもしれない。さらなる先取特権の再設定は、ローンが完済されたときに先取特権を証明的に削除するだけでなく、苦難と運用上の例外を考慮することになるだろう。
例えば、高速道路を75で走っている間に運転を取り消すのは失礼にあたる。

> In this process of successive refinement we've gone from a crude security system to a reified contract:

このように次々と洗練されていく過程で、私たちは粗雑なセキュリティシステムから再契約へと進化していきます。

          (1) A lock to selectively let in the owner and 
              exlude third parties;
          (2) A back door to let in the creditor;
          (3a) Creditor back door switched on only upon nonpayment 
               for a certain period of time; and
          (3b) The final electronic payment permanently switches 
               off the back door.

　

          （1）所有者を選択的に受け入れ、第三者を排除するためのロック。
          （2）債権者を入れるためのバックドア。
          （3a）債権者のバックドアは、一定期間の滞納時にのみオンになります。そして
          （3b）最終的な電子決済は、バックドアを永久にオフにします。


> Mature security systems will be undertaking different behavior for different contracts. To continue with our example, if the automobile contract were a lease, the final payment would switch off leasee access; for purchase on credit, it would switch off creditor access. A security system, by successive redesign, increasingly approaches the logic of the contract which governs the rights and obligations covering the object, information, or computation being secured. Qualitatively different contractual terms, as well as technological differences in the property, give rise to the need for different protocols.

成熟したセキュリティシステムは、契約ごとに異なる動作をします。
この例を続けると、自動車契約がリースの場合、最終的な支払いによってリースのアクセスがオフになります。クレジットで購入する場合は、債権者のアクセスがオフになります。
セキュリティシステムは、継続的な再設計により、保護されているオブジェクト、情報、または計算をカバーする権利と義務を管理する契約のロジックにますます近づいています。
質的に異なる契約条件、およびプロパティの技術的な違いにより、異なるプロトコルが必要になります。

> (Derived from "Formalizing and Securing Relationships on Public Networks" , by Nick Szabo)

（ニック・サボによる「パブリックネットワーク上の関係の形式化と保護」から派生）

> A related article discusses a formal language for analyzing contracts and specifying smart contracts. 

関連記事では、コントラクトを分析してスマートコントラクトを指定するための正式な言語について説明しています。

</div></details>


# 感想（個人的意見）

難しい単語が多くて機械翻訳では上手く翻訳されていませんが、なんとか読み取ります。

まず、1997年にこの発想をしている事がすごいと思います。
今でこそ、全てがつながる未来を想像できますが・・・
ちなみに、１回この人の発表を聞いていますが、前評判どおり変な人でした。

現在のスマートコントラクトですが、ブロックチェーンと一心同体だと思っている人が多数いるような気がします。
この提言がされた時には、ブロックチェーンの元とされているSatoshi Nakamoto氏の"[Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf)"は発表されていません。
また、Satoshi Nakamoto氏のペーパーは、二重支払い防止に関するアイデアであり、スマートコントラクトについて言及されていません。
ただ、Nick Szabo氏がSatoshi Nakamotoではないのかと何度も言われている事も事実です。（本人は否定しています。）

自動販売機と自動車のローンについての例が出されています。

基本的には、現在広く知られているスマートコントラクトととしての流れについての説明や
ローンなどの場合は、ローンの支払いが済めば、契約を更新する必要があるとしています。
また、ローンの支払いが滞ると自動車を差し押さえ可能ですが、走行中に差し押さえ（自動停止）させて良いものか？
というような問題提起もしています。

スマートコントラクトの最初の提言では、以下の３点について論じられていると思います。

- 事前契約⇒イベント⇒契約の自動執行（基本的な考え方）
- 契約の更新・完了
- 契約執行の柔軟な対応


この時点において、ブロックチェーンとの関わりは無いように思えます。
支払いの方式として、ブロックチェーンの資産移転を利用した場合に親和性は生まれると思います。
だからといって、ブロックチェーンと一心同体にするのではなく、それぞれの役割に分けるべきだと思います。

---