この内容は2017年１月27日に行われたイーサリアム全デベロッパー会議の内容です。
目次
アジェンダ
スポンサーリンク1.デベロッパー会議を決め継続して行うべきか？
おおよそ提案としては隔週で毎月第一週と第３週金曜日で14:00 UTCで行う？十分な告知があればこのミーティングの予定を前後させることもできる。例えば多くのデベロッパーが大きなイベント(2017年2月17日から18日に行われるパリで行われるEthereum European Development Conference など）
2.EIP5/8の最終合意に達する：[ファシリテーター: Christian Reitwiessner]
3.EIP196: 楕円曲線加算と楕円曲線スカラー乗法のためのプリコンパイルされたコントラクトとクリスチャンによるペアリング[ファシリテーター：Christian Reitwiessner]
4.メトロポリス、来るアイスエイジ(ディフィカルティボムによるマイニングができなくなる)と可能性のあるメトロポリスのEIP[ファシリテーター：Vitalik Burterin]
・EIP 86 by Vitalik Burterin
アブストラクション
・EIP 96 by Vitalik Burterin
ブロックハッシュと状態ルートを状態の中に置く
・EIP 98 by Vitalik Burterin
レシートからMedstate(トランザクションを処理した後の状態トライ木のルート)を取り除く
・EIP 100 by Vitalik Burterin
アンクルマイニングのインセンティブ修正
・EIP 101 by Vitalik Burterin
Bigint(数値データ型)算術
・EIP 140 by Nikolai Mushegian
安価なThrow
・EIP166 by Vitalik Burterin
ブロックハッシュと状態ルートを状態の中に置く
5.EIP 176： 新しい状態テスト（イーサリアムネットワークの変更に伴う状態テストの一般化）[ファシリテーター：Martin S.Hauge]
6.EIP 116： STATIC_CALL[ファシリテーター：Christian Reitwiessner]
7.EIP 141： EVMオペコード：指定された無効な命令
8.EIP 1アップデート：EIPプロセスに新しい変更 by Hudson Jameson[ファシリテーター：Hudson Jameson]
詳細
1.EIP5/8の最終合意に達する
サマリー：このEIPは過去のミーティングで議論され、全体的なコンセンサスに達した。Parityの公式声明の承認待ちのための一時的なコンセンサスです
2.EIP196：楕円曲線加算と楕円曲線スカラー乗法のためのプリコンパイルとペアリング
Christian：イーサリアム上でzk-SNARKSを有向にするためプリコンパイルすることを提案し、リサーチチームは順応性のあるプリコンパイルと他の楕円曲線を有向にする能力を維持しようとするが、通常は維持する凡庸的な方法はありません。そのためZcashの楕円曲線のプリコンパイル特に、楕円曲線加算、楕円曲線スカラー乗算とペアリング関数のプリコンパイルの実装を提案します。
（＊楕円曲線上の離散対数問題の困難性を利用し、安全性の根拠とする）
ペアリング関数は２つの異なる楕円曲線上の２点を有限体に写像するほど複雑であるため、写像問題に直面する可能性があり、この２点の要素を写像する独自の方法は存在しません。
またペアリング関数を実装するかわりにターゲットグループの結果が一致するかしないかによってTrueまたはFalseを返すペアリングチェッカーを導入することができ、 これによって複雑さを大いに軽減できるでしょう。
ToDo：２つの楕円曲線の点のためのエンコーディングとガスコストの割当を決める.
Vitalik：「もう少しプリコンパイルの合計を一般的にしたい場合、Bパラメータを持つ曲線を加算と乗算サポートすることによって行えます。よってBパラメータは０になりますが、Bはどのような値でもかまいません。またすでにイーサリアムに実装しているECC(楕円曲線暗号システム）もカバーすることができ、0の複雑性ともなるでしょう。」
Christian：「Vitalikが楕円曲線演算をより一般的にできるとしていると言っているが、ペアリングではない？」
Vitalik：「再度チェックする必要がある。また一つ追加する価値のあるものはRust(プログラミング言語)で実装を見ることができる。」
Christian：「RustとC++の実装があるが、GOチームはどう思いますか？」
Jeffrey：「ECCリカバリのためのGo 実装があり、イーサリアムの唯一C++依存性はリカバリ機能ですがそれ以外の場合プリコンパイルを自分たちで実装する必要があるでしょう。また他言語からのリファレンスと他の助けを借りることができ、交雑親和性を破るためC++の依存性はあまり好ましくない」
Christian：「なるほど」
Vitalik：「もし追加したいなら実装を持たないユーザーのためにPythonをリファレンス実装として使用することができる」
Jan：「Rubyのためにラッパーを加えることができるので大丈夫」
Parityチーム：「Parityも大丈夫です」
Javaチーム：「最近新バージョンをリリースしたので追加するだけです。多分動くでしょう」
EIP 196の結論
EIP 196はコンセンサスを得たが、詳細はCristianが一つのEIPとして更に内容を盛り込みます。次のミーティングで話し合われるでしょう。
3.メトロポリス、来るイーサリアムのアイスエイジ（マイニング氷河期）、可能性のあるメトロポリスのEIP
スポンサーリンク
EIP 86：アブストラクト
2つのコンポーネント
1. もし0ETHのトランザクションに署名した場合、0番地から送金されたと仮定する
2.コントラクトがどのようにしてアドレスを生成するかのルールを変更、どうやら一人のユーザーは新しいルールにクリエイトオペコードを生成することと古いものの弱点を見つけ安全に批判する方法を見つけることに幸せをかんじている様だ（ETHアンチ？）
Vitalik：今までのミーティングでこの件について何度か話し合ったが、基本的に0ETHの送信者とコントラクトのアドレスを決定していたスキームを修正する２つの機能を持つ新しいトランザションタイプを許可している。送信者とノンスからセンダーとコードへ離す。またユーザーが一般的に受け入れられるアイデアを思い出しています
・以前持ち出された可能性のある問題
仮に何度もそのようなコードで作成しようとするような方法で呼び出す既存のCREATEコントラクトを必要がない限り壊したくはない
・可能性のある解決策
1.それを検出し、違うアドレスにジャンプする複雑なスキーム
2.(簡単な）新たなCREATE OPCODEを作成する
Vitaik：よりクリアになるため意見としては2になるとしていた覚えがあります
チャットでの質問：
Q.オペコードの代わりに生成のためにプリコンパイルができるか？
A.それは考慮する価値があり、オフラインで話合えると嬉しいです。もしCREATEプリコンパイルをCREATE OPCODEなしで使用する場合、理論上はEVM(Ethereum Virtual Machine)コードを持たないプリコンパイルとなり、複雑さを増します。当分の間はオペコードを使用する
EIP96：ブロックハッシュと状態ルートを状態の中に置く
メトロポリスの部分的なアブストラクションであり、通常合意されている
EIP 98 ：レシートからMedstateを取り除く
中間の状態ルートを取り除く。Jeffによるとライトクライントに干渉を与えるとしてるためこの長所もあり短所もある点についてはJeffとオフラインで話し合うので参加自由です。
EIP 100：アンクルマイニングのインセンティブ修正
Sergio Lermerが指摘した大きなマイニングプールがアンクルをマイニングすることを促進するインセンティブの欠陥に対するバグレポート
解決策：ブロックが増加している間の時間を対象にする代わりにアンクルと簡単な変化式(1行のコード変更）を含むブロックの間の修正時間を対象にします。
EIP 101：Bigint(数値データ型)算術
Vitalik：イーサリアムはRSAの様な多彩なBigint暗号をサポートできるのが理由で、もしサポートするならモジュラーの指数性は十分であり、乗算と加算に悩まされる必要はありません。根拠はその３で、指数性は最適化が必要なもの一つで乗算と加算はすでに安価に行うことが可能です。
EIP 140：安価なThrow
Jeff：どうやら危険なようです。反転状態(トランザクションの取り消しなど）がコストなしで行われるます。
Vitalik：消費したガスは失ってしまうが、残りのETHは返金されるだろう。
Christian：ガス欠後にThrowを行うことができるため、コストなしで実装しないといけないという規定がありませんか？
全員：その通りですね
Christian：このバグによりガス欠になった時は現在、ずさんなガスカウントをしてしまうということです。これはオフラインで確認しましょう
サマリー
一般的なサポートを行う。またもしホームステッドで時間をとられてしまうならセレニティで行うこともできる
メトロポリス実装時期とロードマップの話し合い
Hudson：イーサのメトロポリスかセレニティまたは両方のフェイズについての今までの話合いには大きな進展がなかった覚えがあります。
Vitalik：メトロポリスの実装をパート１とパート２に別けることを提案した時はDoS攻撃の修正とこのメトロポリスのハードフォークにいくつかのEIPを潜在的に加えたいときでした。現段階ではメトロポリスへのワンステップは十分です
Vitalikによるイーサリアムの氷河期が始まるおおよその時期
・おおよそ2017年3月25日（後約２ヶ月後）ー ブロックタイム：15.2秒
・おおよそ2017年7月25日（後約６ヶ月後）ー ブロックタイム：29.7秒
Hudson：メトロポリスに関する正式な資料はethereum/pm repoに記録しておくことができ、このメトロポリスの議題を作成したためアップデートを見逃すことはありません。このミーティングと次回のコアデベロッパーのミーティングまでにEIPの実装とテストにおおよそのタイムリミットを決定したいと思っています。このデータを使用してメトロポリスのEIP MVPをリスト化したものを作成し、そしてもし時間があればその他のものも追加します。
Vitalik：一旦的にEIPの非公式なコンセンサスを得たら、先にすすみ可能な限り早く実装をはじめます。
EIP 176： 新しい通常状態テスト
このテストをサポートし、進めていく。Jeffがいくつかの提案があり、EIPにてコメントします。次回の全イーサリアムコアデベロッパー会議１０でEIP176を再度取り上げ、受け入れるかどうかを決断する
EIP 116：STATIC_CALL
CALLと類似している新しいオペコードではあるが制限付きのもの
・状態の改良は行わない（STATIC CALL)
・どちらの状態の読み込みも行わない（PURE CALL） ＊VitalikはCALLBLACKBOXが望ましいとする
・他の種類の制限？可能な組み合わせを模索する必要せいあり
追加のオペコードの代替手段、CALLをINTERRUPTに統合する、動作を変更するための引数としてFlagをとるが、この動作変更Flagは静的解析をより難しくしてしまう
更なる話し合いはGitHubのEIP116にて行う。またEIP 116は次の全コアデベロッパー会議のアジェンダとして上げる
EIP 141：EVMのオペコード：指定された無効な命令
Solidityは異なる”Throw”動作を行いたい。１つは”Throw”その他はオーバーフローetc…
この変更に対するコンセンサスをグループに聞いており、0xfeか0xefかを指定する
0xfeにコンセンサスを得て無効を継続する
EIP 1 アップデート：新しいEIPプロセス
・テンプレート：現在のものと同様
・プロセス
1.まず最初に議題（1行またはフルPR-Styleにすることができる）を開き、自由に話し合う
2.そしてPRを公式の残ったEIPの公式サブミッションとして作成する
数週間以内に実装されるべきで全ての詳細はEIP 183
参加者
Alex Beregszaszi (EWASM)
Arkadiy Paronyan (Parity)
Alex Van de Sande (Mist/Ethereum Wallet)
Anton Nashatyrev (ethereumJ)
Casey Detrio (Volunteer)
Christian Reitwiessner (cpp-ethereum/Solidity)
Dimitry Khokhlov (cpp-ethereum)
Greg Colvin (EVM)
Hudson Jameson (Ethereum Foundation)
Jan Xie (ruby-ethereum & pyethereum)
Jeffrey Wilcke (geth), Kumavis (MetaMask)
Roman Mandeleil (ethereumJ)
Martin Becze (EWASM/EthereumJS)
Martin Holst Swende (security)
Nick Johnson (geth/SWARM)
Vitalik Buterin (Research & pyethereum)
Yoichi Hirai (EVM)
スポンサーリンク
ビットコインやイーサリアムその他仮想通貨の情報はツイッター上で速報を出しています。
Follow @bokujyuumai Tweet
仮想通貨ランキング Tweets by bokujyuumai