12章 非中央集権型アプリケーション (DApp)
P.281〜
非中央集権型アプリケーション (decentralized application)
イーサリアムの創設者たちが初期から考えていること
「スマートコントラクトわーい！」で終わりではなく、Web を再発明するつもり
それで Web3 と呼んだりする
分散化 Decentralization
スマートコントラクト → ロジックと支払い機能を分散化
DApp → アプリケーションのすべてを分散化
対義語としての CApp (centralized application)
12.1 DAppとは何か
非中央集権化される対象
バックエンドソフトウェア (アプリケーションロジック)
フロントエンドソフトウェア
データストレージ
メッセージ通信
名前解決
DApp にするとなにがうれしいの？
耐久性が高まる
透明性が高まる
検閲耐性が高まる
現状、真の DApp はほとんどなくて、部分的に中央集権的に管理されている
本には「ほとんど」と書いてあって、じゃあいくつかはあるってことか？
将来的にはカジュアルに完全な DApp が動くようになるでしょう
12.1.1 バックエンド (スマートコントラクト)
これはつまりスマートコントラクトのこと
12.1.2 フロントエンド（Webユーザーインターフェイス）
ふつうの Web のフロントエンド
HTML / CSS / JavaScript で構成される
MetaMask 等のブラウザ拡張が間に入ることでバックエンドとつながる
web3.js
12.1.3 データストレージ
現状、ガスは高いしガスリミットは小さいしで、大量のデータの管理に向いていない
なのでオフチェーンのストレージがよく利用されている
12.1.3.1 IPFS
InterPlanetary File System (惑星間ファイルシステム)
非中央集権型
コンテントアドレッサブルストレージシステム
12.1.3.2 Swarm
IPFS に似ている
コンテントアドレッサブル P2P ストレージシステム
イーサリアムファンデーション製
Geth の一部としてつくられた
これも Swarm に保存されている
12.1.4 非中央集権型メッセージ通信プロトコル
いま我々が Web の通信として想像する中央集権的な通信ではなく、P2P のメッセージングプロトコル
最も注目すべきは Whisper
イーサリアムファンデーション製
Geth の一部としてつくられた
生い立ちが Swarm といっしょだね
12.2 基本的なDAppの例：オークションDApp
家、車、商標などの資産を表す「Deed (証書)」トークンを登録できる
そのトークンを出品すると、他の利用者が入札できるようになる
コンポーネント
ERC721 トークン (DeedRepository) を実装するスマートコントラクト
証書を売却するオークション (AuctionRepository) を実装するスマートコントラクト
web3.js
画像などの Assets を保存するための Swarm クライアント
オークションごとのチャットルームを作成する Whisper クライアント
12.2.1 オークションDApp：バックエンドスマートコントラクト
DeedRepository と AuctionRepository
12.2.1.1 DApp のガバナンス
コードを見るとわかる通り、オークションの DApp に特権ユーザはいない
実際に運用されているコントラクトは、部分的に権限を持たせた特権アカウントを用意していたりする
バグがあったときの対応のために使ったりする
特権アカウント、アリにするかナシにするかの判断は難しい
Bancor は特権アカウントを悪用されてひどいことになった
なかったらなかったで、何か問題が起きたときに眺めるしかできなくなる
12.2.2 オークションDApp：フロントエンドユーザーインターフェイス
素朴に Web フロントエンドだ
12.3 オークションDAppのさらなる非中央集権化
AuctionRepository は特権を排除してあるからマジでオープン
Assets は Swarm に保存されているから検閲も遮断もできない
ここからさらに非中央集権度を上げるには？
12.4 オークションDAppのSwarmへの格納
イーサリアムに保存するより効率的
中央集権的なストレージに保存するより高耐久性
12.4.1 Swarmの準備
インストール
これ 404 だった
これとか見るといいか？
はじめかた
これを見るといいか？
12.4.2 ファイルのSwamへのアップロード
https でアクセスできる Swarm のゲートウェイ
1 ファイルをアップロードしてそれを見る、ってだけだったらそんなに難しくない
けど、Web アプリケーションだと HTML から CSS を参照したり、複数ファイル間で相互に参照しあう
お互いにコンテントハッシュを知っていないと参照できないようだと扱いにくい
DApp をパッケージ化する方法がある
サンプルのオークションの DApp にもパッケージ化スクリプトがある
そうすると下記のような URL で DApp にアクセスできるようになる
bzz://ab164cf37dc10647e43a233486cdeffa8334b026e32a480dd9cbd020c12d4581 おしゃれなドメイン名でアクセスできる Web アプリと比べるとわかりにくくない？？？
12.5 ENS（Ethereum Name Service）
>世界最高のスマートコントラクトを設計したとしても、ユーザーインターフェイスが良くなければ、アクセスを集めることはできません。
それはそう
ENS は非中央集権的なアプローチをとる
12.5.1 ENSの歴史
Namecoin というのがある
通貨じゃないブロックチェーンアプリケーションのはじまり
初期リリースの Geth と C++ のイーサリアムクライアントには namereg コントラクトが組み込まれていた
今は使われていない
2016 年にニック・ジョンソンがイーサリアムファンデーションで働き始め、本格的な開発がスタートした
円周率の日 (3 月 14 日) のローンチに失敗したあと、2017 年のスターウォーズデー (5 月 4 日) にローンチされた
記念日のクセがすごい
12.5.2 ENSの仕様
EIP-137 : 基本機能の規定
EIP-162 :
.eth のオークションシステムの記述EIP-181 : アドレスの逆引き
設計理念は「サンドイッチ」
ちょっとなに言ってるかわかんないです
12.5.3 ボトムレイヤー：名前の所有者とリゾルバ
ERC137 によって定義され、巧みに書かれた 50 行未満のシンプルなコントラクト
そういうコードを書いて世に残したいものですね
>基本レイヤーの唯一の機能は、ノード所有者が自分のノードに関する情報(具体的にはリゾルバ、存続時間、所有権の移転)を設定し、新しいサブノードの所有者を作成できるようにする機能です。
12.5.4 中間レイヤー：.ethノード
今のところ利用できる TLD は
.eth のみ従来の DNS ドメインの所有者が、同じドメイン名を ENS で所有できるように作業が進行中
Ropsten テストネットで
.xyz だけがサポートされている現状 .eth ドメインはオークションシステムを介して分配される june29.eth ほしい 自分の
.eth ほしい g.eth 取れたらかっこいいほしい
>オークションシステムは複雑なコード(500 行以上)によって構築されており、ENS における初期の開発努力(およびバグ!)のほとんどはこの部分にありました。
12.5.5 トップレイヤー：証書
コインロッカーみたいな仕組みになっていて、入金して、名前の所有権を得て、権利を手放したらお金は戻ってくる
敷金礼金っぽさもある
実質無料？
12.5.6 名前の登録
https://mycrypto.com で ENS とやりとりできる
って書いてあるけど、本のスクリーンショットと画面がぜんぜん違ってよくわからなかった
https://app.ens.domains/ は使えそうだった
12.5.7 ENSの名前管理
https://manager.ens.domains/ のインターフェイスでやるとよい
サブドメインを設定したりできる
12.5.8 ENSリゾルバ
>1. ENS レジストリは、解決する名前のハッシュ値で呼び出される。レコードが存在する場合、レジストリはリゾルバのアドレスを返す
> 2. リゾルバは、要求されているリソースに適したメソッドを使用して呼び出される。リゾルバは要求された結果を返す
このように 2 段階にしてあることで、高い柔軟性を確保できる
12.5.9 Swarmハッシュ（コンテンツ）への名前解決
bzz://ab164cf37dc10647e43a233486cdeffa8334b026e32a480dd9cbd020c12d4581
→ bzz://auction.ethereumbook.eth/
12.6 AppからDAppへ
ここまでやったことのまとめが書いてあった
12.7 まとめ
>非中央集権型のアプリケーションは、創設者たちが最初期の設計のときから述べているように、イーサリアムビジョンの極致です。今日、多くのアプリケーションが「DApp」と呼ばれていますが、そのほとんどが完全には非中央集権化されていません。しかし、ほぼ完全に非中央集権化されたアプリケーションを構築することはすでに可能なのです。時間の経過とともに、技術がさらに成熟するにつれて、より多くのアプリケーションが非中央集権化され、より耐久性があり、検閲耐性を持ち、自由な Webを生み出すでしょう。
次章！