Supreme Information Freedom

Decentralized Applications を作ろう!

Ethereum Swarmとは?

Ethereumの関連技術である「Swarm」とは何でしょうか?

 

f:id:sagasite:20201001190644p:plain

 

 

sif.hatenablog.com

 

後にイーサリアムを一連の分散技術の1つとする「Web 3」技術仕様の重要性が増すとともに強くなりました。他に関連する技術として、WhisperとSwarmがあります。

 

f:id:sagasite:20201001183202p:plain

 

参考情報

 

www.google.com

 

kojiryo.com

 

Swarmとは

ワールドコンピューターのワールドハードディスク

 

SwarmはEthereum上で提供される前提で開発されている分散ストレージです。

・写真などのファイルの保存

・Dappsのホスティング

・Ethereumエコシステムとの連携

 

  

qiita.com

 

Ethereumの仕組みを使って、不特定多数の参加者にファイルを分散配布します。

参照する際にはファイルを持っている人が誰か分からなくても、誰かが持っているのでその誰かからファイルを送って貰うことができるのです。

エンドユーザから見ると、普通のHTMLサイトにアクセスするのと同様にファイルにアクセスすることができます。

 

どんなことができるかって?

・たとえば、非中央集権のファイル共有サービス

特定のファイルサーバがなくてもファイルのアップロードができます。

 

 

https://swarm.ethereum.org/

swarm.ethereum.org

 

Swarm is a distributed storage platform and content distribution service

 

 

https://github.com/ethersphere/swarm

github.com

 

 

Swarmはイーサリアムの分散ファイルストレージで、画像ファイルとかをユーザー同士で共有できるんですね。

 

 

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

 

Ethereum Whisperとは?

Ethereumの関連技術である「Whisper」とは何でしょうか?

 

f:id:sagasite:20201001185104p:plain

 

 

sif.hatenablog.com

 

後にイーサリアムを一連の分散技術の1つとする「Web 3」技術仕様の重要性が増すとともに強くなりました。他に関連する技術として、WhisperとSwarmがあります。

 

f:id:sagasite:20201001183202p:plain

 

参考情報

 

www.google.com

 

qiita.com

 

WEB3の構成要素

  1. Ethereum(プロトコル: ETH) ブロックチェーン、コンセンサス
  2. Whisper(プロトコル: SHH) ブロックチェーン以外のメッセージング
  3. Swarm(プロトコル: BZZ) 分散ファイルシステム

 

Whisperのユースケース

  • Dappの中で、あまり大量ではないデータを公開状態にする必要がある場合
     例: 為替取引のDappを作った際の参考為替レート
  • Dappの中で、トランザクションを実際に実行する前に両者を調整する場合
     例: 為替取引のトランザクション前にレートを調整するなど
  • 両者のメッセージのやりとりをするアプリ
     例: チャットルームアプリ
  • ハッシュ以外にお互いのことを知らないような2者間でコミュニケーションを行う場合

 

 

qiita.com

 

EtherumにはWhisperという一種のチャット機能があります。
このWhisperでのメッセージのやり取りはブロックチェーン上には記録されませんが、メッセージのやり取りをしながら、送金処理や仮想通貨の売買を実施する等、工夫次第でDAppsの機能を拡張することが可能となります。
ブロックチェーン上には記録されない為、一定時間経過後にメッセージがなくなるという時限制のあるもの(※時間設定は個人で可能。)ですが、P2Pを介した非同期通信(※相手がオフライン状態でもメッセージ送信可能。)という利点を有しています。

なお、Whisperの実装は、shhというライブラリを使用することになります。

 

 

github.com

 

whisper は DApp (分散型アプリケーション) が互いに通信するための通信プロトコルです。

 

 

 Whisperはイーサリアムに付いているチャット機能で、ブロックチェーンは使わない、とのこと。

ブロックチェーンで記録を残すまでもない、ちょっとしたメッセージのやりとりで使える道具なんですね。

 

 

 

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

 

マスタリング・イーサリアム 1.3 イーサリアムの誕生

「マスタリング・イーサリアム」の読書メモ。

 

sif.hatenablog.com

 

 

1.3 イーサリアムの誕生

(p.3)

イーサリアムは、ビットコインモデルの有効性が皆に認識され、暗号通貨アプリケーションをより進化させようとしていたときに考え出されました。

 

 2013年の終わりに、若いプログラマービットコインの熱狂的な支持者であるヴィタリックは、ビットコインとマスターコインビットコインを拡張して、基本的なスマートコントラクトを提供するオーバーレイプロトコル)の機能をさらに拡張することを考え始めました。

 

 2013年12月にはヴィタリックは、チューリング完全な汎用ブロックチェーンであるイーサリアムのアイデアの概説となるホワイトペーパーを公開しました。数十人の人々がこの初期ドラフトを見て、フィードバックを送り、ヴィタリックがこの提案を発展させる手助けをしました。

 

 

https://vitalik.ca/general/2017/09/14/prehistory.html

vitalik.ca

 

Gavin can also be largely credited for the subtle change in vision from viewing Ethereum as a platform for building programmable money, with blockchain-based contracts that can hold digital assets and transfer them according to pre-set rules, to a general-purpose computing platform. This started with subtle changes in emphasis and terminology, and later this influence became stronger with the increasing emphasis on the "Web 3" ensemble, which saw Ethereum as being one piece of a suite of decentralized technologies, the other two being Whisper and Swarm.

 

イーサリアムのビジョンは、設定されたルールに従いデジタル資産を保持し転送できるブロックチェーンベースのコントラクトを用いて、プログラム可能な資産を構築するためのプラットフォームから、汎用コンピューティングプラットフォームへと変化していきましたが、ギャヴィンはこの変化にも大きく貢献しました。この取り組みでは重要な変更が加わり、用語についても変更がありました。その影響は、後にイーサリアムを一連の分散技術の1つとする「Web 3」技術仕様の重要性が増すとともに強くなりました。他に関連する技術として、WhisperとSwarmがあります。

 

f:id:sagasite:20201001183202p:plain

 

 

 2013年12月から、ヴィタリックとギャヴィンはこのアイデアを洗練して進化させ、後にイーサリアムとなるプロトコルレイヤーを構築しました。

 イーサリアムの創設者たちは、特定の目的を持たず、プログラムされることで幅広い種類のアプリケーションをサポートできるブロックチェーンについて考えていました。その考えとは、イーサリアムのような汎用ブロックチェーンを用いることで、開発者がP2Pネットワーク、ブロックチェーン、コンセンサスアルゴリズムなどの基礎的な仕組みを実装することなくアプリケーションを開発できるというものでした。イーサリアムプラットフォームは、これら細かな仕組みを取り出すことを目的とし、非中央集権型のブロックチェーンアプリケーションのための決定論的で安全なプログラミング環境を提供するために設計されました。

 

そして2015年7月30日、最初のイーサリアムのブロックがマイニングされました。ワールドコンピュータが、世界に向けて稼働を開始したのです。

 

イーサリアム誕生の歴史

 

イーサリアムが汎用ブロックチェーンのプラットフォームとなることで、開発者はDAppsを手軽に作れるようになったんですね。

 

 

 

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

 

マスタリング・イーサリアム 1.2 ブロックチェーンの構成要素

「マスタリング・イーサリアム」の読書メモ。

 

sif.hatenablog.com

 

 

1.2 ブロックチェーンの構成要素

(p.2)

 

ja.wikipedia.org

 

ブロックチェーン(Blockchain)は、暗号技術を使ってリンクされたブロックと呼ばれるレコードの増大するリストである。

各ブロックには、前のブロックの暗号化ハッシュ 、タイムスタンプ、トランザクションデータ(一般的にはマークルツリーで表される)が含まれている。

 

設計上、ブロックチェーンはデータの改変に強い

ブロックチェーンは、「2つの当事者間の取引を効率的かつ検証可能で恒久的な方法で記録することができるオープンな分散型台帳」である。

分散型台帳として使用する場合、ブロックチェーンは通常、ピアツーピアのネットワークによって管理され、ノード間通信と新しいブロックの検証のためのプロトコルに準拠している。

一度記録されたブロックのデータは、後続のすべてのブロックを変更しない限り、遡及的に変更することはできない。

ブロックチェーンの記録は変更不可能ではないが、ブロックチェーンは設計上安全であると考えられ、高いビザンチンフォールトトレランスを持つ分散型コンピューティングシステムの例とされている。

したがって、分散型コンセンサスがブロックチェーンで主張されてきた。

 

ブロックチェーンは、2008年にサトシ・ナカモトという名前を使った人物(またはグループ)が、暗号通貨ビットコインの公開取引台帳としての役割を果たすために発明したものである。

サトシ・ナカモトの正体は現在まで不明のままである。

ビットコインブロックチェーンの発明により、ビットコインは信頼できる当局や中央サーバーを必要とせず、二重取引問題を解決する最初のデジタル通貨となった。

ビットコインのデザインは他のアプリケーションにも影響を与え、一般に公開されているブロックチェーンは暗号通貨として広く利用されている。

ブロックチェーン決済手段の一種と考えられている。

プライベートなブロックチェーンは、ビジネスでの利用が提案されている。

Computerworldなどの情報源は、適切なセキュリティモデルを持たないこのようなブロックチェーンマーケティングを「スネークオイル」と呼んでいる。

 

パブリックブロックチェーンの標準的な構成要素

  1. P2Pネットワーク
  2. メッセージ
  3. コンセンサスルール
  4. 状態マシン
  5. ブロック
  6. コンセンサスアルゴリズム
  7. インセンティブスキーム
  8. クライアント

 

ブロックチェーンシステムの特徴

  1. オープン open
  2. パブリック public
  3. グローバル global
  4. 非中央集権 decentralized
  5. 中立性 neutral
  6. 検閲耐性 censorship-resistant

 

 

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

 

マスタリング・イーサリアム 1.1 ビットコインとの比較

「マスタリング・イーサリアム」の読書メモ。

 

sif.hatenablog.com

 

1.1 ビットコインとの比較

 

 

 

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

 

マスタリング・イーサリアム 1章イーサリアムとは何か?

「マスタリング・イーサリアム」の読書メモ。

 

sif.hatenablog.com

 

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

 

  • イーサリアムは「ワールドコンピューター」と呼ばれる。
  • 「スマートコントラクト」=オープンな演算基盤。
  • プログラムを実行するために、「イーサ」と呼ばれる暗号通貨を使う。
  • 開発者は自由にDAppsを作れる。

 

 

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

 

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

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

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

 

マスタリング・イーサリアム ―スマートコントラクトと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冊を理解できれば、イーサリアムの基礎は身に付くでしょう。

 

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

…頑張ります!😅