12章非中央集権型アプリケーション (DApp)

P.281〜

非中央集権型アプリケーション (decentralized application)

イーサリアムの創設者たちが初期から考えていること

「スマートコントラクトわーい！」で終わりではなく、Web を再発明するつもり

それで Web3 と呼んだりする

分散化 Decentralization

スマートコントラクト → ロジックと支払い機能を分散化

DApp → アプリケーションのすべてを分散化

対義語としての CApp (centralized application)

https://gyazo.com/1308445124d4b5e841cac469c15633b1

12.1　DAppとは何か

非中央集権化される対象

バックエンドソフトウェア (アプリケーションロジック)

フロントエンドソフトウェア

データストレージ

メッセージ通信

名前解決

DApp にするとなにがうれしいの？

耐久性が高まる

透明性が高まる

検閲耐性が高まる

現状、真の DApp はほとんどなくて、部分的に中央集権的に管理されている

本には「ほとんど」と書いてあって、じゃあいくつかはあるってことか？june29.icon

将来的にはカジュアルに完全な 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 (惑星間ファイルシステム)

非中央集権型

コンテントアドレッサブルストレージシステム

https://ipfs.io

12.1.3.2 Swarm

IPFS に似ている

コンテントアドレッサブル P2P ストレージシステム

イーサリアムファンデーション製

Geth の一部としてつくられた

https://swarm-gateways.net/bzz:/theswarm.eth/

これも Swarm に保存されている

12.1.4　非中央集権型メッセージ通信プロトコル

いま我々が Web の通信として想像する中央集権的な通信ではなく、P2P のメッセージングプロトコル

最も注目すべきは Whisper

https://github.com/ethereum/wiki/wiki/Whisper

イーサリアムファンデーション製

Geth の一部としてつくられた

生い立ちが Swarm といっしょだね june29.icon

12.2　基本的なDAppの例：オークションDApp

家、車、商標などの資産を表す「Deed (証書)」トークンを登録できる

そのトークンを出品すると、他の利用者が入札できるようになる

コンポーネント

ERC721 トークン (DeedRepository) を実装するスマートコントラクト

証書を売却するオークション (AuctionRepository) を実装するスマートコントラクト

Vue.js と Vuetify を使用した Web のフロントエンド

web3.js

画像などの Assets を保存するための Swarm クライアント

オークションごとのチャットルームを作成する Whisper クライアント

ソースコード https://github.com/ethereumbook/ethereumbook/tree/develop/code/auction_dapp

https://gyazo.com/a30a1e7e8ee1de7a63315e4694a510ac

12.2.1　オークションDApp：バックエンドスマートコントラクト

DeedRepository と AuctionRepository

https://github.com/ethereumbook/ethereumbook/tree/develop/code/auction_dapp/backend/contracts

12.2.1.1 DApp のガバナンス

コードを見るとわかる通り、オークションの DApp に特権ユーザはいない

実際に運用されているコントラクトは、部分的に権限を持たせた特権アカウントを用意していたりする

バグがあったときの対応のために使ったりする

特権アカウント、アリにするかナシにするかの判断は難しい

Bancor は特権アカウントを悪用されてひどいことになった

なかったらなかったで、何か問題が起きたときに眺めるしかできなくなる

12.2.2　オークションDApp：フロントエンドユーザーインターフェイス

https://github.com/ethereumbook/ethereumbook/tree/develop/code/auction_dapp/frontend

素朴に Web フロントエンドだ june29.icon

https://gyazo.com/cb65eae5027bd941b41a1b57d84ba649

12.3　オークションDAppのさらなる非中央集権化

AuctionRepository は特権を排除してあるからマジでオープン

Assets は Swarm に保存されているから検閲も遮断もできない

ここからさらに非中央集権度を上げるには？

すべてのコードを Swarm や IPFS に保存する

ENS を使用して DApp に名前で参照してアクセスする

12.4　オークションDAppのSwarmへの格納

サンプルの DApp は、各オークションの画像を Swarm に保存している

イーサリアムに保存するより効率的

中央集権的なストレージに保存するより高耐久性

12.4.1　Swarmの準備

インストール

https://swarm-guide.readthedocs.io/en/latest/installation.html

これ 404 だった june29.icon

https://github.com/ethersphere/swarm-guide/blob/master/contents/installation.rst

これとか見るといいか？june29.icon

はじめかた

https://github.com/ethersphere/swarm-guide/blob/master/contents/gettingstarted.rst

これを見るといいか？june29.icon

12.4.2　ファイルのSwamへのアップロード

https でアクセスできる Swarm のゲートウェイ

https://swarm-gateways.net/

1 ファイルをアップロードしてそれを見る、ってだけだったらそんなに難しくない

けど、Web アプリケーションだと HTML から CSS を参照したり、複数ファイル間で相互に参照しあう

お互いにコンテントハッシュを知っていないと参照できないようだと扱いにくい

DApp をパッケージ化する方法がある

サンプルのオークションの DApp にもパッケージ化スクリプトがある

パッケージ化して DApp をひとかたまりとして Swarm にアップロードできる

そうすると下記のような URL で DApp にアクセスできるようになる

bzz://ab164cf37dc10647e43a233486cdeffa8334b026e32a480dd9cbd020c12d4581

おしゃれなドメイン名でアクセスできる Web アプリと比べるとわかりにくくない？？？

12.5　ENS（Ethereum Name Service）

世界最高のスマートコントラクトを設計したとしても、ユーザーインターフェイスが良くなければ、アクセスを集めることはできません。

それはそう june29.icon

Web でいう DNS の役割を務めるのが ENS

ENS は非中央集権的なアプローチをとる

ENS も DApp

DApp の役に立つ DApp

12.5.1　ENSの歴史

Namecoin というのがある

通貨じゃないブロックチェーンアプリケーションのはじまり

初期リリースの Geth と C++ のイーサリアムクライアントには namereg コントラクトが組み込まれていた

今は使われていない

2016 年にニック・ジョンソンがイーサリアムファンデーションで働き始め、本格的な開発がスタートした

円周率の日 (3 月 14 日) のローンチに失敗したあと、2017 年のスターウォーズデー (5 月 4 日) にローンチされた

記念日のクセがすごい june29.icon

12.5.2　ENSの仕様

EIP-137 : 基本機能の規定

EIP-162 : .eth のオークションシステムの記述

EIP-181 : アドレスの逆引き

設計理念は「サンドイッチ」

ちょっとなに言ってるかわかんないです june29.icon

12.5.3　ボトムレイヤー：名前の所有者とリゾルバ

ERC137 によって定義され、巧みに書かれた 50 行未満のシンプルなコントラクト

そういうコードを書いて世に残したいものですね june29.icon

基本レイヤーの唯一の機能は、ノード所有者が自分のノードに関する情報(具体的にはリゾルバ、存続時間、所有権の移転)を設定し、新しいサブノードの所有者を作成できるようにする機能です。

12.5.4　中間レイヤー：.ethノード

今のところ利用できる TLD は .eth のみ

従来の DNS ドメインの所有者が、同じドメイン名を ENS で所有できるように作業が進行中

Ropsten テストネットで .xyz だけがサポートされている現状

.eth ドメインはオークションシステムを介して分配される

june29.eth ほしい june29.icon

自分の.ethほしいkurotaky.icon

g.eth 取れたらかっこいいkurotaky.icon

ほしいakht.icon

オークションシステムは複雑なコード(500 行以上)によって構築されており、ENS における初期の開発努力(およびバグ!)のほとんどはこの部分にありました。

12.5.5　トップレイヤー：証書

コインロッカーみたいな仕組みになっていて、入金して、名前の所有権を得て、権利を手放したらお金は戻ってくる

敷金礼金っぽさもある june29.icon

実質無料？june29.icon

12.5.6　名前の登録

https://gyazo.com/0c1094f9462a391213174d8cd8dee7f2

https://mycrypto.com で ENS とやりとりできる

って書いてあるけど、本のスクリーンショットと画面がぜんぜん違ってよくわからなかった june29.icon

https://app.ens.domains/ は使えそうだった june29.icon

https://gyazo.com/68ccb5666a1e8075681ddefb0b0d96b8

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へ

ここまでやったことのまとめが書いてあった june29.icon

12.7　まとめ

非中央集権型のアプリケーションは、創設者たちが最初期の設計のときから述べているように、イーサリアムビジョンの極致です。今日、多くのアプリケーションが「DApp」と呼ばれていますが、そのほとんどが完全には非中央集権化されていません。しかし、ほぼ完全に非中央集権化されたアプリケーションを構築することはすでに可能なのです。時間の経過とともに、技術がさらに成熟するにつれて、より多くのアプリケーションが非中央集権化され、より耐久性があり、検閲耐性を持ち、自由な Webを生み出すでしょう。

hr.icon

次章！

13章イーサリアム仮想マシン(EVM)