イーサリアム改善提案（EIP 152）についての調査

Ethereumの改善提案（EIP）についての調査結果をまとめる。
今回はGoEthereum（Geth）のv1.9.3に含まれるEIP152（EVMへのBLAKE2b Fプリコンパイルの追加）について調査する。（2019/09/13 現在）

参考：Ethereum Improvement Proposals 「EIP 152：Add Blake2 compression function `F` precompile」

要約

EVM（Ethereum Virtual Machine）Blake2bハッシュ関数を安価に実行できるようにし、Ethereum、Zcash、およびその他EquihashベースのPoWコインとの相互運用を容易とすることへの提案。

変更の利点

BLAKE2bは、便利な暗号化ハッシュ関数とSHA3ファイナリストであることに加えて、Zcashで使用されるEquihash PoWの効率的な検証を可能にし、イーサリアムでBTCリレースタイルのSPVクライアントを可能にします。Equihash PoW検証の1回の検証には、ハッシュ関数の512回の反復が必要であり、BLAKE2bのSolidity実装が使用される場合、Zcashブロックヘッダーの検証は非常に高価になる。
BLAKE2bアルゴリズムは、64ビットCPU向けに高度に最適化されており、最新のプロセッサではMD5よりも高速。Zcashとの相互運用性により、チェーン間の信頼できないアトミックスワップなどの契約が可能になり、非常に一般的なEthereumブロックチェーンにプライバシーに必要な側面を提供できる。

仕様

BLAkE2b F圧縮関数をラッピングするアドレス（0x09）にプリコンパイル済みコントラクトを追加することを提案する。プリコンパイルには厳密にエンコードされた6つの入力が必要となる。
[4 bytes for rounds][64 bytes for h][128 bytes for m][8 bytes for t_0][8 bytes for t_1][1 byte for f]

rounds	ラウンド数	32ビット符号なしビッグエンディアンワード
h	状態ベクトル	8つの符号なし64ビットリトルエンディアンワード
m	メッセージブロックベクトル	16個の符号なし64ビットリトルエンディアンワード
t_0, t_1	オフセットカウンター	2つの符号なし64ビットリトルエンディアンワード
f	最終ブロックインジケータフラグ	8ビットワード

変更の根拠

BLAKE2bはプリコンパイルの優れた候補である。最新の64ビットCPU向けに大幅に最適化されており、特に24ビットと63ビットのローテーションを利用して、SIMD命令とリトルエンディアン演算による並列処理を可能にする。これらの特性は、ネイティブCPUで並外れた速度を提供する。対照的に、EVMのビッグエンディアンの32バイトセマンティクスは、BLAKE2の効率的な実装を助長するものではないため、EVMでのハッシュの計算に関連するGASコストは、関数をネイティブで計算する真のコストに比例しない。
明らかな実装は、direct BLAKE2bプリコンパイルであり、EVMのほとんどのハッシュおよび相互運用性の要件を満たしている。しかし、掘り下げると、BLAKE2bの実装には、異なるプロジェクトの要件とライブラリに基づいた特定の機能と内部修正が必要になることが明らかになった。

特記事項

特になし