Supreme Information Freedom

Decentralized Applications を作ろう!

マスタリング・イーサリアム

イーサリアムの仕組みを勉強してみたいと思います。

教科書として「マスタリング・イーサリアム」という本を読んでみます。

 

マスタリング・イーサリアム ―スマートコントラクトとDAppの構築
 

 

 

目次

本書への賛辞

日本語版への推薦文

はじめに

用語集

 

1章イーサリアムとは何か?

  1.1 ビットコインとの比較
  1.2 ブロックチェーンの構成要素
  1.3 イーサリアムの誕生
  1.4 イーサリアムの4つの開発段階
  1.5 イーサリアム:汎用ブロックチェーン
  1.6 イーサリアムの構成要素
    1.6.1 参考文献
  1.7 イーサリアムチューリング完全
    1.7.1 「仕様」としてのチューリング完全
    1.7.2 チューリング完全性の意味
  1.8 汎用ブロックチェーンから非中央集権型アプリケーション(DApp)へ
  1.9 インターネットの第3世代
  1.10 イーサリアムの開発カルチャー
  1.11 なぜイーサリアムを学ぶのか?
  1.12 本書で学べること

 

2章イーサリアムの基礎

  2.1 イーサの通貨単位
  2.2 イーサリアムウォレットの選択
  2.3 管理と責任
  2.4 MetaMask入門
    2.4.1 ウォレットの作成
    2.4.2 ネットワークを切り替える
    2.4.3 テスト用イーサを入手する
    2.4.4 MetaMaskからイーサを送金する
    2.4.5 アドレスのトランザクション履歴の確認
  2.5 ワールドコンピュータ入門
  2.6 外部所有アカウント(EOA)とコントラクト
  2.7 シンプルなコントラクト:テスト用イーサファウセット
  2.8 ファウセットコントラクトのコンパイル
  2.9 ブロックチェーン上でのコントラクトの作成
  2.10 コントラクトとのやり取り
    2.10.1 ブロックエクスプローラコントラクトアドレスを表示する
    2.10.2 コントラクトへの入金
    2.10.3 コントラクトからの引き出し
  2.11 まとめ

 

3章イーサリアムクライアント

  3.1 イーサリアムネットワーク
    3.1.1 フルノードを建てるべきか
    3.1.2 フルノードの長所と短所
    3.1.3 パブリックテストネットの長所と短所
    3.1.4 ローカルブロックチェーンシミュレーションの長所と短所
  3.2 イーサリアムクライアントの実行
    3.2.1 フルノードのハードウェア要件
    3.2.2 クライアント(ノード)の構築と実行のためのソフトウェア要件
    3.2.3 Parity
    3.2.4 Go-Ethereum(Geth)
  3.3 イーサリアムベースのブロックチェーンの初回同期
    3.3.1 GethまたはParityの起動
    3.3.2 JSON-RPCインターフェイス
  3.4 リモートイーサリアムクライアント
    3.4.1 モバイル(スマートフォン)ウォレット
    3.4.2 ブラウザウォレット
  3.5 まとめ

 

4章暗号化

  4.1 鍵とアドレス
  4.2 公開鍵暗号と暗号通貨
  4.3 秘密鍵
    4.3.1 無作為な数字から秘密鍵を生成する
  4.4 公開鍵
    4.4.1 楕円曲線暗号の解説
    4.4.2 楕円曲線演算
    4.4.3 公開鍵の生成
    4.4.4 楕円曲線ライブラリ
  4.5 暗号ハッシュ関数
    4.5.1 イーサリアムの暗号ハッシュ関数:Keccak-256
    4.5.2 どのハッシュ関数を使用しているのか
  4.6 イーサリアムアドレス
    4.6.1 イーサリアムアドレスフォーマット
    4.6.2 ICAP(Internet Content Adaptation Protocol)
    4.6.3 大文字を使用するチェックサム付き16進数エンコーディング(EIP-55)
    4.6.4 EIP-55でエンコードされたアドレスのエラーを検出する
  4.7 まとめ

 

5章ウォレット

  5.1 ウォレット技術の概要
    5.1.1 非決定性(ランダム)ウォレット
    5.1.2 決定性(シード)ウォレット
    5.1.3 階層的決定性(HD)ウォレット(BIP-32/BIP-44)
    5.1.4 シードとニーモニックコード(BIP-39)
  5.2 ウォレットのベストプラクティス
    5.2.1 ニーモニックコードワード(BIP-39)
    5.2.2 シードからのHDウォレット生成
    5.2.3 HDウォレット(BIP-32)とPath(BIP-43/44)
  5.3 まとめ

 

6章トランザクション

  6.1 トランザクションの構造
  6.2 トランザクションナンス
    6.2.1 ナンスの追跡
    6.2.2 ナンスの差異、複製したナンスと承認
    6.2.3 並行処理、トランザクションの生成、ナンス
  6.3 トランザクションガス
  6.4 トランザクション受信者
  6.5 トランザクションのバリューとデータ
    6.5.1 バリューをEOAとコントラクトに送信する
    6.5.2 データペイロードをEOAやコントラクトに送信する
  6.6 特別なトランザクションコントラクト作成
  6.7 デジタル署名
    6.7.1 楕円曲線デジタル署名アルゴリズム
    6.7.2 デジタル署名の仕組み
    6.7.3 署名の検証
    6.7.4 ECDSAの数学
    6.7.5 トランザクションの署名
    6.7.6 生トランザクションの作成と署名
    6.7.7 EIP-155による生トランザクションの作成
  6.8 署名プレフィックス値(v)と公開鍵リカバリ
  6.9 署名と送信の分離(オフライン署名)
  6.10 トランザクションの伝播
  6.11 ブロックチェーンへのレコーディング
  6.12 複数署名(マルチシグ)トランザクション
  6.13 まとめ

 

7章スマートコントラクトとSolidity

  7.1 スマートコントラクトとは何か?
  7.2 スマートコントラクトのライフサイクル
  7.3 イーサリアム高級言語の紹介
  7.4 Solidityでのスマートコントラクトの作成
    7.4.1 Solidityのバージョンの選択
    7.4.2 ダウンロードとインストール
    7.4.3 開発環境
    7.4.4 シンプルなSolidityプログラムを書く
    7.4.5 Solidityコンパイラ(solc)を使ってコンパイルする
  7.5 イーサリアムコントラクトABI
    7.5.1 Solidityコンパイラと言語バージョンの選択
  7.6 Solidityを使ったプログラミング
    7.6.1 データ型
    7.6.2 定義済みのグローバル変数とグローバル関数
    7.6.3 コントラクトの定義
    7.6.4 関数
    7.6.5 コントラクトのコンストラクタとセルフディストラク
    7.6.6 コンストラクタとセルフディストラクトをファウセットコントラクトに追加する
    7.6.7 関数修飾子
    7.6.8 コントラクトの継承
    7.6.9 エラーハンドリング:assert、require、revert
    7.6.10 イベント
    7.6.11 他のコントラクトを呼び出す:send、call、callcode、delegatecall
  7.7 ガスに関する検討事項
    7.7.1 動的サイズの配列を避ける
    7.7.2 他のコントラクトへの呼び出しを避ける
    7.7.3 ガス費用の見積もり
  7.8 まとめ

 

8章スマートコントラクトとVyper

  8.1 脆弱性とVyper
  8.2 Solidityとの比較
    8.2.1 修飾子
    8.2.2 クラスの継承
    8.2.3 インラインアセンブリ
    8.2.4 関数のオーバーロード
    8.2.5 変数の型キャスト
    8.2.6 事前条件と事後条件
  8.3 デコレータ
  8.4 関数と変数の順序
  8.5 コンパイル
  8.6 コンパイラレベルでのオーバーフローエラーに対する保護
  8.7 データの読み書き
  8.8 まとめ

 

9章スマートコントラクトセキュリティ

  9.1 セキュリティのベストプラクティス
  9.2 セキュリティリスクとアンチパターン
  9.3 リエントランシー
    9.3.1 脆弱性
    9.3.2 予防テクニック
    9.3.3 実例:The DAO
  9.4 算術オーバーフロー/アンダーフロー
    9.4.1 脆弱性
    9.4.2 予防テクニック
    9.4.3 実例:PoWHCとバッチトランスファーオーバーフロー(CVE-2018-10999)
  9.5 予期せぬイーサ
    9.5.1 脆弱性
    9.5.2 予防テクニック
    9.5.3 さらなる例
  9.6 DELEGATECALL
    9.6.1 脆弱性
    9.6.2 予防テクニック
    9.6.3 実例:パリティマルチシグウォレット(2度目のハック)
  9.7 デフォルトの可視性
    9.7.1 脆弱性
    9.7.2 予防テクニック
    9.7.3 実例:パリティマルチシグウォレット(最初のハック)
  9.8 エントロピーイリュージョン
    9.8.1 脆弱性
    9.8.2 予防テクニック
    9.8.3 実例:PRNGコントラクト
  9.9 外部コントラクトの参照
    9.9.1 脆弱性
    9.9.2 予防テクニック
    9.9.3 実例:リエントランシーハニーポット
  9.10 ショートアドレス/パラメータ攻撃
    9.10.1 脆弱性
    9.10.2 予防テクニック
  9.11 未チェックのCALL戻り値
    9.11.1 脆弱性
    9.11.2 予防テクニック
    9.11.3 実例:EtherPotとKing of the Ether
  9.12 競合状態/フロントランニング
    9.12.1 脆弱性
    9.12.2 予防テクニック
    9.12.3 実例:ERC20とBancor
  9.13 サービス拒否(DoS
    9.13.1 脆弱性
    9.13.1 予防テクニック
    9.13.2 実例:GovernMental
  9.14 ブロックタイムスタンプ操作
    9.14.1 脆弱性
    9.14.2 予防テクニック
    9.14.3 実例:GovernMental
  9.15 慎重なコンストラク
    9.15.1 脆弱性
    9.15.2 予防テクニック
    9.15.3 実例:Rubixi
  9.16 未初期化ストレージポインタ
    9.16.1 脆弱性
    9.16.2 予防テクニック
    9.16.3 実例:OpenAddressLotteryとCryptoRouletteハニーポット
  9.17 浮動小数点数と精度
    9.17.1 脆弱性
    9.17.2 予防テクニック
    9.17.3 実例:Ethstick
  9.18 Tx.Origin認証
    9.18.1 脆弱性
    9.18.2 予防テクニック
  9.19 コントラクトライブラリ
  9.20 まとめ

 

10章 トーク

  10.1 トークンの使用方法
  10.2 トークンとファンジビリティ(代替可能性)
  10.3 カウンターパーティリスク
  10.4 トークンと内在性
  10.5 トークンの使用:ユーティリティとエクイティ
    10.5.1 「それはアヒルです」
    10.5.2 ユーティリティトークン:誰が必要とするのか
  10.6 イーサリアム上のトーク
    10.6.1 ERC20トークン標準
    10.6.2 独自ERC20トークンの起動
    10.6.3 ERC20トークンの問題点
    10.6.4 ERC223:トークコントラクトのインターフェイス標準提案
    10.6.5 ERC777:トークコントラクトのインターフェイス標準提案
    10.6.6 ERC721:ノンファンジブルトークン(Deed:証書)標準
  10.7 トークン標準の使用
    10.7.1 トークン標準とは何か、その目的は何か
    10.7.2 トークン標準を使用すべきか
    10.7.3 成熟度によるセキュリティ
  10.8 トークインターフェイス標準への拡張
  10.9 トークンとICO
  10.10 まとめ

 

11章 オラク

  11.1 オラクルの必要性
  11.2 オラクルのユースケースと使用例
  11.3 オラクルの設計パターン
  11.4 データ認証
  11.5 計算オラク
  11.6 非中央集権型オラク
  11.7 Solidityでのオラクルクライアントインターフェイス
  11.8 まとめ

 

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

  12.1 DAppとは何か
    12.1.1 バックエンド(スマートコントラクト)
    12.1.2 フロントエンド(Webユーザーインターフェイス
    12.1.3 データストレージ
    12.1.4 非中央集権型メッセージ通信プロトコル
  12.2 基本的なDAppの例:オークションDApp
    12.2.1 オークションDApp:バックエンドスマートコントラクト
    12.2.2 オークションDApp:フロントエンドユーザーインターフェイス
  12.3 オークションDAppのさらなる非中央集権化
  12.4 オークションDAppのSwamへの格納
    12.4.1 Swarmの準備
    12.4.2 ファイルのSwamへのアップロード
  12.5 ENS(Ethereum Name Service)
    12.5.1 ENSの歴史
    12.5.2 ENSの仕様
    12.5.3 ボトムレイヤー:名前の所有者とリゾル
    12.5.4 中間レイヤー:.ethノード
    12.5.5 トップレイヤー:証書
    12.5.6 名前の登録
    12.5.7 ENSの名前管理
    12.5.8 ENSリゾル
    12.5.9 Swarmハッシュ(コンテンツ)への名前解決
  12.6 AppからDAppへ
  12.7 まとめ

 

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

  13.1 EVMとは何か
    13.1.1 既存の技術との比較
    13.1.2 EVM命令セット(バイトコード演算)
    13.1.3 イーサリアムのステート(状態)
    13.1.4 SolidityのEVMバイトコードへのコンパイル
    13.1.5 コントラクトのデプロイを行うコード
    13.1.6 バイトコードの逆アセンブル
  13.2 チューリング完全性とガス
  13.3 ガス
    13.3.1 実行中のガス会計
    13.3.2 ガス会計に関する考察
    13.3.3 ガス費用対ガス価格
    13.3.4 ブロックガス上限
  13.4 まとめ

 

14章 コンセンサス

  14.1 PoWによるコンセンサス
  14.2 PoS(Proof of Stake)によるコンセンサス
  14.3 Ethash:イーサリアムのPoWアルゴリズム
  14.4 Casper:イーサリアムのPoSアルゴリズム
  14.5 コンセンサスの原則
  14.6 論争と競争
  14.7 まとめ

 

付録A イーサリアムフォークの歴史

  A.1 イーサリアムクラシック(ETC)
  A.2 非中央集権型自律組織(The DAO)
  A.3 リエントランシーのバグ
    A.3.1 技術詳細
    A.3.2 攻撃フロー
  A.4 The DAOハードフォーク
    A.4.1 The DAOハードフォーク年表
  A.5 イーサリアムイーサリアムクラシック
    A.5.1 EVM
    A.5.2 コアネットワーク開発
  A.6 その他の著名なイーサリアムフォーク

 

付録B イーサリアムスタンダード

  B.1 イーサリアム改善提案(EIP)
  B.2 主要なEIPおよびERCの一覧

 

付録C EVMオペコードとガス消費

 

付録D 開発ツール、フレームワーク、ライブラリ

  D.1 フレームワーク
    D.1.1 Truffle
    D.1.2 Embark
    D.1.3 OpenZeppelin
    D.1.4 ZeppelinOS
  D.2 ユーティリティ
    D.2.1 EthereumJS helpeth:コマンドラインユーティリティ
    D.2.2 dapp.tools
    D.2.3 SputnikVM
  D.3 ライブラリ
    D.3.1 web3.js
    D.3.2 web3.py
    D.3.3 EthereumJS
    D.3.4 web3j
    D.3.5 EtherJar
    D.3.6 Nethereum
    D.3.7 ethers.js
    D.3.8 Emerald Platform
  D.4 スマートコントラクトのテスト
    D.4.1 ブロックチェーンテスト
    D.4.2 Ganache:ローカルテストブロックチェーン

 

付録E web3.jsチュートリアル

  E.1 説明
  E.2 async/await(非同期)方式におけるweb3.jsとコントラクトの基本操作
    E.2.1 Node.jsスクリプトの実行
  E.3 デモスクリプトの確認
  E.4 コントラクトのインタラクション
  E.5 awaitを使った非同期操作

 

付録F 短縮URL一覧

  F.1 スマートコントラクトセキュリティ
  F.2 トーク

 

訳者あとがき

索引

 

著者紹介

Andreas M. Antonopoulos

en.wikipedia.org

 

Andreas M. Antonopoulos (born 1972 in London) is a Greek-British bitcoin advocate, tech entrepreneur, and author. He is a host on the Let's Talk Bitcoin podcast and a teaching fellow for the M.Sc. Digital Currencies at the University of Nicosia.

 

(DeepL翻訳)https://www.deepl.com/translator

アンドレアス M. アントノプロス(1972年ロンドン生まれ)は、ギリシャ・イギリスのビットコイン提唱者、技術起業家、作家です。彼はLet's Talk Bitcoinポッドキャストのホストであり、ニコシア大学のデジタル通貨学修士ティーチングフェローでもあります。

 

twitter.com

 

aantonop.com

 

www.youtube.com

 

Gavin Wood

en.wikipedia.org

 

Gavin Wood is a British computer programmer who co-founded Ethereum. He invented Solidity and wrote the Yellow Paper specifying the Ethereum Virtual Machine, and served as the Ethereum Foundation's first chief technology officer. After leaving in 2016, he co-founded Parity Technologies (formerly Ethcore), which develops core infrastructure for Ethereum, Bitcoin, Zcash and Polkadot, an interoperability protocol he also co-founded.

 

(DeepL翻訳)https://www.deepl.com/translator

ギャビン・ウッドは、Ethereumを共同設立したイギリスのコンピュータプログラマーです。Solidityを発明し、Ethereum Virtual Machineを明記したYellow Paperを執筆し、Ethereum Foundationの初代最高技術責任者を務めた。2016年に退任した後は、Ethereum、Bitcoin、Zcash、Polkadotのコアインフラを開発するParity Technologies(旧Ethcore)を共同設立し、同じく共同設立した相互運用性プロトコルの開発を行っています。

 

twitter.com

 

gavwood.com

 

出版社情報

www.oreilly.co.jp

 

正誤表

第1刷までの修正

2020年6月更新

 

■P.124

署名の検証手順の5

【誤】5. 楕円曲線上の点、Q≡u1 * _G + u2 * K (mod p)を計算する

【正】5. 楕円曲線上の点、Q≡u1 * G + u2 * K (mod p)を計算する

 

書評

イーサリアムは、仮想通貨であるだけでなく、DAppsを作る基盤ともなっています。

 

ja.wikipedia.org

 

イーサリアム(英: Ethereum)とは、分散型アプリケーション (DApps) やスマート・コントラクトを構築するためのプラットフォームの名称、及び関連するオープンソース・ソフトウェア・プロジェクトの総称である。イーサリアム・プロジェクトによって開発が進められている。

イーサリアムでは、イーサリアム・ネットワークと呼ばれるP2Pのネットワーク上でスマート・コントラクトの履行履歴をブロックチェーンに記録していく。またイーサリアムは、スマート・コントラクトを記述するチューリング完全プログラミング言語を持ち、ネットワーク参加者はこのネットワーク上のブロックチェーンに任意のDAppsやスマート・コントラクトを記述しそれを実行することが可能になる。ネットワーク参加者が「Ether」と呼ばれるイーサリアム内部通貨の報酬を目当てに、採掘と呼ばれるブロックチェーンへのスマート・コントラクトの履行結果の記録を行うことで、その正統性を保証していく。このような仕組みにより特定の中央管理組織に依拠せず、P2P全体を実行環境としてプログラムの実行とその結果を共有することが可能になった。

 

イーサリアムの仕組みを勉強して、DAppsを作ってみたいと思います。

 

オライリーから出ている詳細な解説本なので、とりあえずこの1冊を理解できれば、イーサリアムの基礎は身に付くでしょう。

 

は~、でも分厚いから全部読むのはしんどいかな?

…頑張ります!😅