【東京大学ブロックチェーン公開講座第9週】Solidity開発の概要
本記事は、2024年東京大学ブロックチェーン公開講座の9つ目のレポートです。
【東京大学ブロックチェーン公開講座第1週】ブロックチェーン概論
【東京大学ブロックチェーン公開講座第2週】ビットコイン①
【東京大学ブロックチェーン公開講座第3週】ビットコイン②
【東京大学ブロックチェーン公開講座第4週】ビットコイン③
【東京大学ブロックチェーン公開講座第5週】イーサリアム①
【東京大学ブロックチェーン公開講座第6週】イーサリアム②
【東京大学ブロックチェーン公開講座第7週】イーサリアム③
【東京大学ブロックチェーン公開講座第8週】イーサリアム④
【東京大学ブロックチェーン公開講座第9週】Solidity開発の概要（本記事）
なお、本記事は講座の要約ではなく、講座のポイントを抽出しつつ、筆者の理解や考察を添えてアウトプットしたものとなります。講座内容との差異や筆者の主張（オレンジ背景）が含まれます。
スマートコントラクト概要
スマートコントラクトとは
ブロックチェーン上にアップロードできるプログラムの処理系（実行環境）と、そのための高級プログラミング言語（つまり総称）。スマートコントラクトは以下2種類に分類できる。
| Type | Description | Example |
|---|---|---|
| UTXO | エンドユーザーがトランザクションの前後状態を計算してメッセージを送る | Bitcoin, Plasma（EthereumのLayer2） |
| VM | エンドユーザーは実行対象のプログラムとインプットを送り、ブロックチェーン上のVMが状態を計算する | Ethereum |
VM型スマートコントラクトだけができることは以下2点。
- コントラクトが第一級市民として設計されている（アカウントモデルがUTXOと異なる）
- 前状態を指定せずにトランザクションを実行できる（同時に実行しても後状態の矛盾が起こらない）
EVM
スマートコントラクトの処理系の特徴は以下。
- opcodes（命令の列）をよみとってスマコンを保存したり実行したりする（Solidityで書いたコードをコンパイルしてopcodesにする）
- 32bytesずつのバイナリを仮想メモリや仮想ストレージに保存するスタック型のプログラム
- 1コントラクトの最大プログラムサイズが24.576KB（極めて小さい）
- 1トランザクションで3000万ガスまで処理できる
パトリシアマークルツリーにはコントラクトアドレスが列挙されており、その下に
ガスの制約から大きなデータは物理的に保存できない。代わりにデータ自体はIPFS（分散型ストレージ）に配置し、スマートコントラクトではそのID（CID）を保存する、といった手法がとられる（NFTなど）。
また、以下のようなクセがある。
- EOAからしかトランザクションを発生させられない（スマコンによる定期実行はできない）
- 決定性（冪等性、同じInputを渡したら必ず同じOutputを返す）のあるコードしか書けない（外部への通信ができない、オラクルが必要）
- ログインという概念がない（署名検証による認証）
- 32bytesのデータを基本単位としたバイナリプログラミング（計算機資源, Stack too deep, ガスの制約）
スマートコントラクトとセキュリティ
仕様・実装の両方がセキュアでなければならない（実際には難しい）。
そのモデルが成立するためのassumption（前提）を利用者に明示することで安全にシステムを利用してもらうことが可能。また、攻撃者モデル（誰がどんな攻撃をし得るか）の定義は必須。
コントラクトの脆弱性を検出するサービス
| Type | Abstract | Fee | Auditor |
|---|---|---|---|
| ファーム（OpenZeppelin） | 専門事業者への依頼 | 低〜高 | 数人 |
| コンテスト（Code4rena） | 不特定多数の監査人 | 中〜高 | 数十〜数百人 |
| バウンティ（Immunefi） | 深刻度に応じた賞金 | 0〜高 | 0〜数百人 |
スマートコントラクトと法制度
金融周りの法制度
| Type | Description | Funds |
|---|---|---|
| 銀行（銀行業） | 現金を預かり、銀行口座に数値を記録。銀行が残高を更新する権利をもつ。 | 現金を運用できる |
| Fintechスタートアップ（資金移動業） | サーバーで残高管理し、銀行口座で決済を完了。運営者はサーバーの値を更新する権利をもつ。 | 預かり金の運用は制限されている |
| スマートコントラクト | システムの残高=保有現金。自分以外が残高を更新することも運用することもできない。 | 自分（秘密鍵の保持者）のみ |
銀行も資金移動業もサーバー上のデータで残高を扱っており、そのデータをお互いにやりとりすることで決済を完了している。一方、スマートコントラクトは現物（資金そのもの）が行き交っていることになる。
また、税法についてもスマートコントラクトの設計ごとに実質的な解釈が必要。税務的に不確実な場合、税率が高い方を想定しておく。
スマコンのDevOps
- Upgradeability: スマコンは改ざん不可能だが、セキュリティの向上や法令改正に従うために必要になる更新可能性を実現する仕組み
- Cloneability: テンプレートをもとに複数のコントラクトを作成できる（低コスト）仕組み
いずれもProxyパターンをつかって実現されるが、両方を併せ持ったコントラクトを作るのは難しい。
MetaContract
低コストで保守性の高いスマコンを開発するためのUCS(ERC7546)ベースのフレームワーク。コンセプトは以下。
- Ethereum = meta contractの集合
- meta contract = bundleの集合
- bundle（1つのスマコン） = schema * (function)^q
- schema = (vertical domain)^p
- vertical domain = A struct tree in a strage
cloneやsetAdminなど汎用的な関数を標準関数として提供（OpenZeppelinのような感じ）。独自の関数を追加することもできる。これらの関数をVertical DomainごとにまとめたものをBundleという。テストのしやすさ（State Fuzzing）やTDDを考慮。
Indexer Auth Generator（開発中）ができると、The Graph（インデクサー）ハンドラの実装が不要になる。
第9回ここまで
Discussion