1. アップデート
1.1. Flontier
1.2. Homestead
1.3. Metropolis
1.4. Serenity
2. アドレス生成
2.1. 秘密鍵からECDSAで公開鍵（64バイト）を生成 公開鍵をハッシュ関数Keccak-256に通し文字列（32バイト）を得る 最初の12バイトを消し20バイトのアドレスになる そのアドレスにprefixの0xを加えることで最終的なアドレスを得る
2.1.1. イーサリアムのアドレスの特徴として、イーサリアムアドレスは チェックサムを持っていないことがあげられる。チェックサムは アドレスが正しい形式であるか検証するためのコード。つまり、 アドレスを1文字でもタイプミスしてしまったら送金を失敗して しまうということ。
2.1.1.1. このようにイーサリアムでチェックサムを導入していない 理由としては、将来的にアドレスをネームの登録制のよう に扱おうとしているから。イメージ的にはURLのドメ インのような感じ。実際に、2017年5月にENS(Ether eum Name Service)がローンチされ、オリジナルのドメイ ンを取得できるようになっている。
2.1.1.1.1. また、最近はイーサリアムのアドレスはICAPフ ォーマットに移行しつつある。ICAPはビットコ インと同様にbase58でフォーマットされており チェックサムも含まれている。 ICAPの特徴はIBAN(Internation al Bank Account Number)という規定を満たして いること。これにより、銀行のシステムがイ ーサリアムアドレスを認識することができ、銀行 システムとイーサリアムアドレスの互換性を保つ ことができる。
2.1.2. 基本的な流れはビットコインと同じだが、ハッシ ュ関数の違かったりBase58（いわゆるチェックサ ム）のフォーマットを使用していないなどの違い があげられる。
3. スマートコントラクト
3.1. Solidity
3.1.1. solc
3.1.1.1. solidity標準で利用できるコンパイラ 別にRemixというコンパイラも存在する
3.1.1.2. コンパイルされたバイトコードは ethereumのEVMで実行される
3.1.1.2.1. コンパイルすると２つの結果が表示される
3.1.2. web3.js
3.1.2.1. フロントエンドとsolidityとを連携させ、 さらにgeth環境に繋げる
3.1.3. geth
3.1.3.1. go言語で実装されたethereumクライアント アカウントの作成からマイニングまで、 ethereumに関わる多くの機能を担う
3.1.4. コンパイル後にethereum上で実行可能なプログラム言語
3.2. 改ざん、修正ほぼ不可能
3.2.1. だから一度デプロイすると、 コードの書き換えは（修正）極めて困難
3.2.1.1. ハードフォークすれば 簡単に書き換え可能
3.2.1.1.1. しかし、コミュニティの制約や、 トークン既存保有のホルダーに対する対応、 価格ボラティリティ上昇などの理由から実質的に難しい。 さらに、DEXなどで別のトークンと取引可能になっている トークンとかだとなおさら困難
3.2.2. Zeppelin-os teamがupgradableな コントラクトの制作考え中(2018/6)
3.3. 0. 契約の事前定義（管理者が入力） 1. イベント発生(プログラムによる自動実行) 2. 契約執行・価値の移転(プログラムによる自動実 行) 3. 決済(プログラムによる自動実行) これらの事前定義を満たした自動執行プログラム
3.4. スマートコントラクトを活用できるかも しれないプロセス
3.4.1. そのプロセスに多くの仲介者が存在し複雑である
3.4.2. 仲介者が多くの利益を得ている
3.4.3. プロセスの透明性が重要
3.4.4. トランザクションが自動的に実行される必要がある
3.4.5. プロセス中で改善やごまかし、詐欺などが起こりやすい
4. 分散型アプリケーションブロックチェーン
4.1. ethereumはコストであり、イーサリアム 上で構築されたアプリケーションで使用 する通貨
4.2. メインネットというパブリックチェーン を展開している
4.2.1. プライベートネット用のイーサリアム ブロックチェーンも存在する
5. Proof of Work
5.1. マイナー
5.1.1. ハッシュ値を導く計算
5.2. トランザクションをブロックに入れる作業
5.3. 将来的にProof of Stakeに移行予定
5.4. 問題点
5.4.1. 1.電気代
5.4.1.1. ビットコインの年間消費電力量は 小国の年間消費電力より多い。 etherreumはこのままでいいの？
5.4.1.2. 環境への負担が懸念
5.4.2. 2.ファイナリティ
5.4.2.1. ファイナリティ≒トランザクションが覆らないこと
5.4.2.2. PoWは確実なファイナリティではなく、 確率的なファイナリティなので、 絶対に安全な訳ではない
5.4.2.2.1. 51%攻撃
5.4.2.2.2. selfish mining
5.4.3. 問題点解決のため、今後PoS移行予定
5.4.3.1. Proof of Stake
5.4.3.1.1. 資産の賭け高による証明
5.4.3.1.2. 2011年 bitcoin forumで提案
5.4.3.1.3. 単純なPoSの問題点
6. World State
6.1. World Stateは20byteのethereumアドレス をkeyにして、そのアドレスのaccount stateをvalue荷物データの集合
6.1.1. accounts stateには、nonce,balance,c ode,storageの４種類のpデータが含ま れる(EOAはvonce,balanceのみ)
6.1.1.1. これらをマークルパトリシア木で表現 し、RLPでシリアライズしたものがsta te datebase
6.1.1.1.1. state datebaseはブロックチェーンには含 まれず、ハッシュ値のみがブロックヘッダ ーに記録される
7. ブロック
7.1. https://i0.wp.com/zoom-blc.com/wp-content/uploads/2017/11/ethereum-block.png?resize=444%2C489&ssl=1
7.1.1. ヘッダー部分の内部に注目すると、以下 の図のようなデータが含められている。
7.1.1.1. https://i0.wp.com/zoom-blc.com/wp-content/uploads/2017/11/ethereum-blockheader.png?resize=800%2C553&ssl=1
7.2. イーサリアムのブロックサイズはビット コインのように1MBと決められているの ではなく、ブロック内に含められている トランザクションのgas limitの合計値がブ ロックで定めらているgas limit以下になる ように決められている。
7.2.1. https://i1.wp.com/zoom-blc.com/wp-content/uploads/2017/11/ethereum-blocklimit.png?resize=800%2C511&ssl=1
7.2.2. ただgasはイーサリアムネットワークで実 行されるトランザクションの手数料であ り、これはトランザクションのデータサ イズによってほとんど決められるため、 実質的にはブロックサイズも含められる トランザクションのデータサイズで決ま っている。
8. ERC
8.1. ethereumで発行できるトークン の仕様を決めているもの
8.1.1. ERCにそってトークンを発行すると、準 拠したサードパーティ製のウォレットや 分散型取引所で使用できる。
8.1.1.1. ERC20
8.1.1.1.1. ERC20には送金するアドレスを間違うと 二度と引き出せなくなってしまう重大な 問題がある。
8.1.1.1.2. コントラクトのアドレスに間違って送っ てもトランザクションが承認されてしま い、送金したトークンが二度と引き出せ なくなる
8.1.1.1.3. 2017年12月27日時点で325万ドル
8.1.1.1.4. ERC20
8.1.1.2. ERC223
8.1.1.2.1. ERC223は送金を行なった際にトークンを 受け取れることのできるアドレスかを確 認して、問題がなければ処理を実行する
8.1.1.2.2. 間違って送金した場合は、元のアドレス に送り返される
8.1.1.3. ERC721
8.1.1.3.1. ERC20をさらに別方向に発展させた新し い規格 ERC20の後方互換
8.1.1.3.2. NFTトークン（代替不可能トークン）
8.1.1.3.3. 代替不可能な財産（土地、家、チケット etc）の権利保護や、ゲーム内アイテム （レアアイテムなどは、アンダーグラウ ンドでの取引が活発で問題になってい る）のオープンな取引などにも実装でき る可能性を秘めている
9. ウォレット
9.1. MetaMask
9.1.1. chromeにインストールして使うタイプ Dappsの開発には必須
9.2. MEW
10. スケーラビリティ
10.1. 特にノードの増加は問題。スマートコントラクト の処理には通常の送金処理よりもコストがかかる ので、ノード数が増えるとそれだけネットワーク 全体での処理能力が低下してしまうから。
10.1.1. イーサリアムのノード数20,000以上存在 していて、ビットコインよりも圧倒的に 多い。ノード数が多いということ はより分散化されているということだが 、トランザクションの処理が遅延した り特定のノードに集中化が起きてしまう という負の側面もあります。
10.2. ブロックチェーンを基盤としたネットワ ークにおけるスケーラビリティ問題には ユーザーの増加とノードの増加という2つ の側面がある。 ユーザーの増加は単純にトランザクショ ンが増えることで、ブロックチェーンが それを処理しきれなくなり送金遅延や手 数料増加が起こる。
10.2.1. 解決策
10.2.1.1. Plasma
10.2.1.1.1. 2017年8月にイーサリアム創設者のVitalik Buterin氏とライトニングネットワークの 共同開発者であるJoseph Poon氏によって 発表された
10.2.1.1.2. 実装することで、1秒間当たりのトランザ クションの処理数やより大きなデータサ イズのトランザクションの処理を劇的に 向上させることが見込まれる
10.2.1.1.3. イーサリアムのブロックチェーンを親ブ ロックチェーンとして、プラズマブロッ クチェーンを階層的なブロックチェーン のTree（木）を作っていくアイデア。
10.2.1.1.4. 実現が見込まれていること
10.2.1.1.5. Ploof of Staleが前提の技術
10.2.1.2. Raiden
10.2.1.2.1. ライデンネットワーク(Raiden N etwork)とは、イーサリアムネッ トワーク上でEtherやERC20に準 拠したトークンをオフチェーン 処理で移動させること。
10.2.1.2.2. Balance Proofs
10.2.1.2.3. 問題点
10.2.1.2.4. プロジェクト
10.2.1.3. Sharding
10.2.1.3.1. シャーディングは、トランザクション の検証作業をノード群ごとに役割分担 し、検証作業を並列化していくことを 目指している。
10.2.1.3.2. シャーディング(Sharding)とは元々データ ベースシステムの用語で、データベース を水平方向に分割することを意味してい る。イーサリアムにおいても同様で、ブ ロックチェーンの「状態」が分割されて 複数のシャード(Shard)が存在することに なる。
10.2.1.3.3. phase1
11. マイニング
11.1. GHOST(Greedy Heaviest Observed Subtree)
11.1.1. GHOSTプロトコルによってどのチェーン をメインチェーンにするか決めている。 GHOSTにおいて、マイニングによ り最も多く計算が蓄積されているチェ ーンをメインチェーンとしている。
11.1.1.1. もっとも多くの計算量の理由は、 ビットコインと違い、ブロック 生成時間が１５秒と短いから
11.1.1.1.1. 短いブロック生成時間による 問題点