Crypto OS
Non-Technical Crypto OS第2段階 · ブロックチェーン経済

第9章 · Smart Contractは何を変えたのか

ルール自体がソフトウェアになると、何が起こるでしょうか?

この章を 3D で体験する →
練習する能力
Protocol LiteracyMental Model
実践
ブロックエクスプローラーでソース検証済みのコントラクトを開き、owner とアップグレード入口を見つける。
AI Lab
AI に見慣れないコントラクトの主要な 3 関数を説明させ、見落とした権限リスクを自分で見つける。

現実の問題

部屋を借り、家賃3か月分の保証金を払いました。

契約には、契約終了時に損傷がなければ、3日以内に全額返すと明記されています。

終了の日、大家は壁に釘の穴があるから800元、台所の特別清掃で600元引くと言います。次の入居者から入金されるまで現金がないので、さらに待つよう言います。

手元の契約は一文字も変わっていません。しかし、実行するのは大家です。

仲裁や裁判に進めます。勝ったとしても、時間と労力を含め、2,000元のために割に合うでしょうか?

この構造は見た目以上に普遍的です。大半の契約の問題は、書き方の曖昧さより、利害を持つ誰かが実行することにあります。 社会は仲介、預託先、公証人、裁判所を作りました。どの層も料金を取り、その層自体を信頼する必要があります。

では、実行にも人が不要になったらどうでしょうか?

思考実験

自動販売機から始めます。

3元入れてボタンを押すと、コーラが落ちます。店員も交渉も、今日は機嫌が悪いという言い訳もありません。ルールも実行も機械の中です。

この機械を思考実験に広げ、条件を順に追加します。

第1段階、ルールを公開する。 誰でも内部の配線図を見て、3元入れると本当にコーラが出て、空の缶ではないと確認できます。メーカーを信じず、自分で見られます。

第2段階、誰でもつなげる。 出口を別の機械の投入口につなぐ人が現れます。6元入れると、最初の機械がコーラを出し、二つ目が映画のチケットに交換します。二人の所有者は知り合いでも提携相手でもなく、許可も不要です。

三人目が見て、さらに三つ目をつなぎます。誰も設計していなかった処理の流れが生まれました。

第3段階、設置後は鍵がない。 機械は溶接され、メーカー自身も開けません。

これは最大の長所であり、最大のリスクでもあります。夜中にこっそりルールを変える人がおらず、今日の配線図は10年後も同じです。一方、ゼロを書き忘れ、3元のコーラを0.3元にしていたら、その誤りも永久に残り、中身がなくなるまで続きます。

第4段階、メーカーが裏口の鍵を残す。 修理できるよう、裏蓋を開ける鍵を持っています。

すると別のものになります。鍵がある限り、誰も変更できないという約束には、鍵を持つ人を除くという条件が付きます。

ここで考えてください。第3段階と第4段階のどちらに、保証金を預けたいですか?

あなたが決める

2,000元の保証金をこの機械に預けます。3か月後に自動返金し、その間に大家が異議を申し立て、あなたも同意した場合は、合意した金額で分配するだけのルールです。

四つの版があります。

結果を観察する

四つは同じ交換を示します。

ルールをソフトウェアに渡すと、誰の利害にも依存しない実行を得る代わりに、間違えても実行されます。

問いはすぐ、相手が約束を破るかどうかから、ルールは正しいか、誰が変えられるかへ移ります。

新旧のルールを比べます。

紙の契約ソフトウェアのルール
誰が実行するか当事者か第三者チェーンが自動実行
いつ実行するか誰かの開始、同意、確認が必要条件を満たしたとき
利害があるかあるない
間違えたら解釈、交渉、法的手続きが可能そのまま実行
他人がつないで使えるか双方の同意が必要誰でも直接呼べる
変更できるか双方が署名すれば可能最初に鍵を残したか次第

最後の行が本当の分かれ目で、最も標語にされやすい部分です。

改ざん不可能性はスイッチではなく、連続的な幅です。 現実のオンチェーンルールは次のどこかに位置します。

位置変更できる人信じる必要があること
全く変更できない誰もいない元のコードが正しい
複数の同意が必要で、数日後に有効集団。事前に見える待機期間中に退出できる
複数の同意で即時有効集団結託せず、鍵を同時に失わない
一つのアドレスが随時変更可能一人その人と秘密鍵の安全

大半の人は最初を使うと思い、実際には3番目や4番目を使っています。この章のLabで、自分の目で一度確認します。

モデルを作る

モデル1:チェーンは状態機械

チェーン全体を、一つの仕事だけ行う機械と考えます。

  1. 現在の状態
  2. 取引が入る
  3. ルールに従って計算
  4. 新しい状態
すべてのチェーンがこの循環です。違いは第3段階のルールの豊かさだけです。

これでBitcoinとEthereumの違いを説明できます。

扱えるルール書く人結果
Bitcoin主に、そのお金を使えるか、誰へ使うかプロトコル自体。コミュニティが極めて慎重に変更プログラム可能なお金
Ethereum誰でも載せたプログラムで、任意のデータを記録・変更誰でも、いつでも、許可不要プログラム可能な状態

この一文が核心です。

Bitcoinはプログラム可能なお金、Ethereumはプログラム可能な状態です。

強さより、誰がルールを書くかの違いです。Bitcoinはルールをプロトコル層に残すので変更に何年もかかります。Ethereumは誰にでも開き、新しい資産、市場、組織を定義できます。同時に、誰でも欠陥や悪意のあるルールを配置できます。

モデル2:互いにつなげられるルール

二つ目の変化はさらに深く、白書の最初のページには書かれていません。

すべて同じチェーン上で公開され、誰でも直接呼べるので、積み木のように、許可なく互いにつなげられます。

貸借ルールが取引ルールを呼んで清算し、新製品が初日から既存の流動性すべてにつながり、ある人の作品を面識のない人が大きなシステムに組み込めます。

従来の金融で数十年かかった種類の製品が、数年で育つ理由です。事故が伝染する理由でもあります。

自分の安全は、依存するルールの鎖の最も弱い部分で決まります。 その一部の名前を聞いたことすらないかもしれません。

モデル3:更新権限に関する四つの問い

どのオンチェーンルールでも、順番を変えずに尋ねます。

  1. 変更できる人はいるか? 入口を探すか、ないと確認します。
  2. 誰か? 一つのアドレス、集団、ガバナンス投票のどれか?
  3. いつ有効になるか? ユーザーが退出できる待機期間はあるか?
  4. 変更に気付けるか? イベント、告知、監視はあるか?

前半は多くの人が尋ね、後半はほぼ尋ねません。後半こそ、事故の際に退出できるか決めます。

何と呼ぶか

スマートコントラクトSmart Contract

チェーン上に配置され、既定のルールに従って自動実行されるプログラムです。

名前には二つの誤解があります。知的でも、法律上の契約でもありません。溶接された自動販売機に近いものです。条件を満たせば実行し、意図を理解せず、判断も解釈もしません。

明確な境界があります。チェーン上のデータしか読めません。 壁に釘の穴があるかは分かりません。現実の情報は外から与える必要があり、第24章で独立したリスクとして扱います。

状態機械State Machine

現在の状態 + 入力 = 新しい状態、という循環です。

最も簡単な理解のモデルです。チェーンは単なるデータベースではなく、各計算を全員が検証できる機械です。 同じルールと入力を動かせば同じ結果になり、記帳係を信頼しなくてよいことの技術的な根拠になります。

コンポーザビリティComposability

ルールが別のルールを直接呼べることです。許可、業務提携、インターフェース接続の交渉は不要です。

革新が速い根本の理由であり、リスクの伝染が速い根本の理由です。二つは同じ性質です。

プロトコルを見る際、外部ルールへの依存を10分余分に図にする価値があります。聞いたことのないもののリスクを負っていると気付くでしょう。

不変性Immutability

配置後にルールを変更できない性質です。

覚えるべきは、スイッチではなく連続的な幅であることです。不変をうたうコントラクトでも、中核の論理を置き換える入口があれば、言葉だけの不変性です。

Labで宣伝を信じず、自分で入口を探す理由です。

アップグレード可能性Upgradeability

用意した仕組みでコントラクトの論理を置き換える能力です。

欠陥ではなく取捨選択です。変更できなければバグを直せず、変更できれば悪用の入口ができます。 比較的成熟した方法は、複数の同意と公開の待機期間を組み合わせる折衷です。

マルチシグ管理と書いてあれば、人数、各人の身元、鍵の保存場所、タイムロックの有無をさらに尋ねます。四つを尋ねて初めて、誰が変えられるか本当に分かります。

実践

実践実際のコントラクトを開き、所有者と更新の入口を探す任意のブロックエクスプローラー0元。閲覧のみです。ウォレットを接続しないでください

全作業が読み取りです。どのページでもウォレットを接続せず、署名もしないでください。 公開されたソースを見るだけです。

ソースが検証済みのコントラクトを探します。 知っているプロトコルのアドレスをエクスプローラーで開き、ソースページへ進みます。

読めるコードでなく16進のバイトコードなら、ソースが公開検証されていません。それ自体が重要な発見です。記録し、別のものを選びます。

所有者を探します。 読み取りインターフェースのowner、adminなどを探し、返るアドレスを記録します。

そのアドレスを開き、通常のアドレスかマルチシグかを見ます。マルチシグなら何人の署名が必要か調べます。通常はページで確認できます。

更新の入口を探します。 プロキシか確認します。implementation項目、別のコントラクトを指すアドレス、エクスプローラーのプロキシ表示などが手掛かりです。

実際の論理コントラクトを見つけ、アドレスと、そのアドレスを置き換える権限のある人を記録します。

タイムロックを探します。 所有者がタイムロックのコントラクトなら、遅延の設定を読みます。提案から有効化まで何時間待つでしょうか?

最も価値ある欄です。 待機期間があれば変更前に退出でき、なければ1件の取引でルールが変わります。

表を完成し、判断を一文書きます。

問い調べた結果
ソースは公開検証済みか
所有者の種類(単一アドレス / マルチシグ / ガバナンス)
マルチシグなら何人中何人か
更新の入口があるか
タイムロックの有無と遅延
変更に気付けるか

最後の判断です。所有者が明日、最悪の操作をしたら何を失いますか?

未発見の欄を飛ばさないでください。誰が変えられるか分からないこと自体が結論です。

AI Lab

AI LabAIに未知のコントラクトを説明させ、触れなかった権限リスクを探すLevel 2 · AI Copilot

前のLabのソースをAIへ渡します。

これはチェーン上に配置されたコントラクトのソースです。三つ行ってください。

1. 中核となる関数を三つ選び、それぞれ誰が呼べるか、何の状態を変えるか、
   どの前提条件を満たす必要があるか説明する。

2. 権限制限のある関数をすべて列挙し、制限するコード行を示す。

3. 呼び出す外部コントラクトのアドレスまたはインターフェースをすべて列挙する。

ルール:渡したソースだけに基づいて答える。ない情報は「ソースに記載なし」と書き、
同種のプロトコルの一般的な方法で補わない。

回答後、説明の正誤だけでなく、抜けた種類の情報を探してください。

この課題では安定した傾向があります。コードが何をするかの説明は得意でも、誰に何を許すかの指摘は苦手です。 管理者だけが呼べる関数を詳しく説明しても、その管理者の身元、鍵の場所、1件で置き換えられるかは尋ねません。

よく抜ける五つを探します。

  1. 任意のアドレスへ資金を移せる関数があるか
  2. 重要な設定(手数料率、上限、価格源)を変える関数があるか
  3. 所有者を移せるか、受取側の確認が必要か
  4. 一時停止できるか、停止中にユーザーが資産を戻せるか
  5. 外部データはどこから来て、誰が変更できるか

見つけるたび、最悪の場合に何が起こるかを書きます。第24章で完全なリスクモデルになります。

AI の回答後、自分で必ず検証すること

  • 説明した関数を、同名のソースで見つけられるか
  • アクセス制御、つまり特定のアドレスだけが呼べる関数に触れているか
  • 更新の入口を探したか。プロキシを最終的な論理と誤認していないか
  • 所有者だけが呼べるという場合、所有者が何か調べたか
  • 外部依存を列挙したか。他のどのコントラクトを呼ぶか
  • 監査済みを安全と扱っていないか。監査報告の時期と範囲は何か
  • 標準実装なのでリスクはないと言った箇所は、自分で再読する

実例

コントラクトの欠陥でチェーンが分裂する2016年

集めた多額の資金をオンチェーンルールで管理するプロジェクトで、論理の欠陥を使って資金を継続的に引き出す人が現れました。

ルール自体は正常に実行されました。攻撃者はシステムへ侵入せず、書かれたルール通りに操作を続けただけです。 溶接した機械の最も怖い点です。誤ったルールも忠実に実行します。

最後はチェーンの履歴を変更し、コミュニティは二つのチェーンへ分裂しました。それ以来、コードが法だという標語は、完全には実現していません。

鍵を奪うと、資金をすべて奪える近年、複数回

大きな損失の原因が欠陥ではなく、更新可能なコントラクトの管理鍵の流出だった事件があります。フィッシングメール、侵害された開発機材、退職者の持つバックアップなどです。

攻撃者は論理コントラクトを自分のものへ替え、1回の呼び出しで資金を空にします。

こうした事故にはコントラクト監査報告は役立ちません。監査されたコードは一行も間違っていないからです。監査が扱うのはコードで、鍵の保管ではありません。

バグを発見しても、何もできない継続的に発生

理念から完全に更新不可を選ぶプロトコルもあります。致命的ではなくても損失を生み続ける欠陥を見つけると、できるのはユーザーへ自主退出を呼び掛け、資金が少しずつ取られるのを見ることだけです。

不変性のもう一面です。間違った選択とは限りませんが、配置前からコードが正しいことを要求します。複雑なシステムでは極めて難しい条件です。

一つのデータ源の異常で、無関係なプロトコルが同時に損をする複数回発生

複数のプロトコルが同じ外部価格源に依存しました。激しい変動中に誤った価格を示すと、全プロトコルがその価格で清算しました。

互いに提携関係はなく、ユーザーも相手の存在をほぼ知りません。

コンポーザビリティの接続は、稼ぐときはネットワーク効果、事故では伝染経路です。 第24章で独立したリスクとして扱います。

変数を一つ変える

もしすべてのコントラクトを更新不可にし、一行も変えられなくする

鍵の流出リスクが消え、誰が変更できるかという問いもなくなります。

代償は業界全体の改良方法の書き換えです。配置前の検証費用が極めて高く、機能変更には再配置とユーザー・資金の移行が必要です。移行自体が大きなリスクになります。

現実的には、公開できるものが減り、公開したものではバグの損失が大きくなります。

もしすべての更新に7日間の公開待機期間を設ける

この章で示せる最も実用的な提案に近いものです。

更新権限を消さず、反応する時間がない状態を、退出できる7日間へ変えます。悪意ある更新が、1件の取引から全員に見える告知になります。

代償は緊急対応の遅さです。重大な欠陥でも修理に7日待ちます。現実では通常、日常の変更はタイムロック、緊急停止は別の権限にします。 すると問いは、停止権限を誰が持ち、停止中に出金できるかへ変わります。

もしソースを公開せず、バイトコードだけ残せる

配置者は論理と裏口を隠せます。

面白いことに、チェーン自体は使えます。取引記録は公開されたままで、資金の行き先も見えます。しかし事前判断の能力を失い、事後追跡だけが残ります。

ソース検証済みという小さな印の本当の価値です。正しいコードを保証せず、自分で見る機会を保証します。

もし他人のコントラクトを呼ぶには、事前の許可が必要になる

コンポーザビリティが消えます。新しいプロトコルは既存の流動性へ直接つなげず、従来の業界と同様、一社ずつ提携を交渉して接続します。

利点は明確で、リスクの伝染経路が切れ、依存先を把握できます。

欠点も明確です。ここ数年の大半の革新は、許可なくつなげられる性質の上にあります。 閉じれば、インターフェースの使いにくい従来の金融システムになります。

持ち帰る問い

1
どんな問題を解決するか?

スマートコントラクトが解くのは、実行する人に利害がある問題です。契約の曖昧さの問題ではありません。

用途を見る際、争いは実行で起きるのか、現実の判断で起きるのか尋ねます。後者は解けず、壁の釘の穴は永遠に分かりません。

2
なぜブロックチェーンが必要なのか?

具体的な答えがあります。誰の利害にも依存せず、ルールを実行したいからです。

会社がルールを決めて実行し、ユーザーも納得しているなら、サーバーで十分です。オンチェーン化は費用とリスクを増やすだけです。

9
誰がリスクを負うか?

組み合わせられる環境では、問いが難しくなります。依存するすべての部分のリスクを負います。

依存を描くことが正しい答え方です。このプロトコルは誰を呼び、その相手は誰を呼ぶか。描けないなら、何を負うか分かっていません。

18
どの判断に人の関与を残すべきか?

更新権限は、この業界の人が関与する仕組みです。

完全に消せばバグを直せず、完全に開けば資産が一人の秘密鍵に依存します。現在のおおよその合意は、介入を残し、複数の同意、公開の待機期間、監視できる痕跡を加えることです。

第34章でAI Agentのウォレット権限を設計するとき、ほぼ同じ形で再登場します。

章末チェック

要点

ビットコインはプログラム可能なお金、イーサリアムはプログラム可能な状態だ。

この章の実践課題を終えたらチェックしてください進捗をすべて見る

このページの内容