- 1. Optimization techniques for EVM implementations
- 2. (e)WASM Code Golfing - Below Par with Nim
- 3. Yul, eWasm, Solidity: Progress and Future Plans
- 4. Wasm Precompiles for Eth 1.x
- 5. EVM Roundtable: Everything You Wanted to Ask, But Were Afraid To
- 6. Monitoring an Ethereum infrastructure
- 7. Pentesting Ethereum Contracts: Exploring a Honeypot Contract Using Ganache
1. Optimization techniques for EVM implementations
3日目の今日は朝からEVM関連セッションが連続であり、全てB7 Roomだったので朝一からB7に篭ってた。
で、最初はevmone作者のevm実相寺におけるoptimizationの話。
今日は最初はこれ!#efdevcon #devcon #devcon5 pic.twitter.com/OGVNF3KVKe
— Yukishige Nakajo(1ウェイ教) (@nakajo) October 9, 2019
はじまた。ずっとEVM作ってるのね。。。やばし。 pic.twitter.com/41YYuVhY7h
— Yukishige Nakajo(1ウェイ教) (@nakajo) 2019年10月10日
スライドはこちらからどうぞ。
How to build fast EVM interpreter — slides from my #devcon5 presentation.https://t.co/efgR8Ew2Qb
— Paweł Bylica (@chfast) October 10, 2019
セッションはタイムアウトしちゃったので途中までしか聞けなかったけど、スライド見直すと半分ぐらいしか喋れてないのねw
速度出すのに一番大変なのが、integerの割り算。CPUの回路でも割り算だけは必要な回路数が多いので、完全に別の領域に回路作られてたりするし、やっぱ大変なんだな。。。
そもそも四則演算をソフトウェア再実装しないといけないのは、wordサイズが256bitで一般的なCPUアーキテクチャとずれてるため。
で、2番目に大変なのがgas costの計測。でもこの話の途中で終わってしまった。
basic blockごとに分割してあらかじめ算出しておくことで云々って話をしてた。で、これ聞いてて思ったのが、node実装としてもopecodesを保存する際に、basic blockに解析してblockごとのgas cost totalをmetadataとして持たせるとかすれば結構早くなりそうなのかも。
ちなみに、evmoneどんだけすごいかというとこちらのベンチマークをみてもらえば一目瞭然かと。
github.com
evmoneのことすっかりさっぱり忘れてたので、これの作者かーってわかった時は個人的に鳥肌たった。
2. (e)WASM Code Golfing - Below Par with Nim
つぎ!#devcon #devcon5 pic.twitter.com/x2MNfAJRCH
— Yukishige Nakajo(1ウェイ教) (@nakajo) October 10, 2019
https://t.co/8HzPKI2Sgvhttps://t.co/ckKiASCNFa
— Yukishige Nakajo(1ウェイ教) (@nakajo) October 10, 2019
これ開いてコード?みながら?コンパイラーの動き想像しながらきいてみてとかいってるぽい。
WASMのEVM用のコードのサイズを圧縮するツールを作った話だった。
wasmのbytecodeはllvm IRに一旦コンパイルしてから生成していた。llvmかます奴が多いなぁ。
wasmようのコントラクト作成言語はnimという言語を使ってた。
結果だけ書くと、4KBぐらいのbytecodesが500B程度まで削減されてた。安全のために入れてるだろうチェックコードまで削除していくのは如何なものかな?とおもったけどw
llvmがレジスタマシン用のコードを吐くのに対して、wasmがスタックマシン用のコードなので、この差異を埋める部分に圧縮する余裕があるらしいとかなんとか。
3. Yul, eWasm, Solidity: Progress and Future Plans
今日一番聞きたかった奴。
つぎこれ!俺的メインコンテンツ!!#devcon #devcon5 pic.twitter.com/GAWpvOUErg
— Yukishige Nakajo(1ウェイ教) (@nakajo) October 10, 2019
たのしみ。#devcon pic.twitter.com/5bWKKZQiiD
— Yukishige Nakajo(1ウェイ教) (@nakajo) October 10, 2019
Yulメインの話だった。Yulの目指すところと、現状について話してた。本人のツイッターで動画取ってくれた人のツイッターをリツイートしてた。
My #devcon talk about what we did with #Yul in the past year and what we plan to do in the future. Slides: https://t.co/wyPBCr1vRr Big thanks to @LianaHusikyan for recording! https://t.co/r8Xgt15ELq
— Chris (@ethchris) October 10, 2019
Yulはよりbytecoesのoptimizationをするためと、eWASM向けのコードも吐き出すようにするために、Solidityコンパイル時のIRとして開発中。Solidity 0.6.0で完全にコンパイル時にYul IRコードを吐き出し、そこから、EVM 1か、wasmのbytecodesを吐き出すようにコンパイラが変わるとのこと。
Yul だけでもある程度かけるし、個人的に、optimizationのためなら、わかる人が使う時はより最適化するためのmetainfoを埋め込めるようになってくれてるといいなと思った。
まぁ目指すところはllvmとかにすごく似てる。 あと、現状はまだwasmコードはデプロイできてなかったら、optimizationも全然できてなかったりだけど、進んでる方向性は間違ってないという話だったと思う。
IR吐いてくれるから、さらに3rd partyのアプリで個別の最適化入れたり、frameの概念入れたりといった感じのいろんな広がりが考えられてすごく今後に期待。
4. Wasm Precompiles for Eth 1.x
つぎ!#devcon #devcon5 pic.twitter.com/of1AOXv5Rt
— Yukishige Nakajo(1ウェイ教) (@nakajo) October 10, 2019
スライドurlないやつだ!#devcon #devcon5 pic.twitter.com/x7blnx4xWc
— Yukishige Nakajo(1ウェイ教) (@nakajo) October 10, 2019
WASM precompiled と Stateless ERC20のお話だった。
— Yukishige Nakajo(1ウェイ教) (@nakajo) October 10, 2019
stateless ERC20久々に聞いたw まぁ色々まだ問題あるし、改善点もあるよね。#devcon #devcon5
正直precompilerの話はよく分からなかった。元々Wasmってcompile言語みたいなもんじゃないの?って思ってたので??のまま聞いてた。
で、まとめてる今気づいた。precompiled-contractのことか! でも尚更意味がわからん!!!
いやまぁ、precompiled contractをewasm向けに再実装するのは別に悪くはないけど、そもそもとしてewasmにしたとしても、wasmのruntime envはnodeに乗るから、precompiledが必要な部分はあったりするんじゃないの?とか思ったり。
速度はそんなに悪くないとスライドには書いてた。ちなみにリポジトリは以下。
github.com
すぎに、stateless ERC20 contractの話が出てた。State Rentの議論の中でも出てた話なので久々に聞いた!っていう感じだった。
他のオーディエンスもこっちの話の方に食いついたみたいで、質問もstateless contractについてのものが出てた。
5. EVM Roundtable: Everything You Wanted to Ask, But Were Afraid To
つぎ!#devcon #devcon5 pic.twitter.com/rSSdAjIFIn
— Yukishige Nakajo(1ウェイ教) (@nakajo) October 10, 2019
パネルディスカッション。質問はしたけど、取り上げられても多分内容がわからんぞいw#Devcon #devcon5
— Yukishige Nakajo(1ウェイ教) (@nakajo) October 10, 2019
EVMのインプリメンターたちが集まってのパネル(?)ASKベース(?)のディスカッションだった。sli.doで質問も受け付けてたので2つ投げといた。
app.sli.do
「Stack To Deep〜〜」てのと、「Re-Entrancy〜」てのが僕の質問。終わる20分前に、トイレに行きたくて部屋を出ちゃったので最後までは聞けなかったけど、僕の質問は残念ながら取り上げられなかったぽい。
ただ、他の質問でgas costが上下するもんなの?ってのが取り上げられてて、この話のなかでre-entrancyというか、あがったらどうする?下がった場合の方が安全?みたいな議論を色々してたので、多分僕の質問の範囲内の話題もされてた気がする。
けど、英語さっぱり聞き取れなかった。。。。
最初、gas price高くね?どうやったら安くなる?みたいな話してたっぽい。
— Yukishige Nakajo(1ウェイ教) (@nakajo) October 10, 2019
そして気づいたら、EIP-1380の提案は全然安全じゃないよねぇ 的な話になってる。#devcon #devcon5evmpanel
github.com
あと、この話も面白かった。自分自身に対するCALL opcodeのcostを40に引き下げたら?って話。
disk I/O発生しないから安全では?って議論だけど、実際に試してみたところ、gas limitでぶん回すと1s以上処理に時間かかるとのこと。で、安全とは単純に考えられないかもって言ってた。(githubのリンクは見落としてたので、 zigen (@kei_0811) | Twitterさんに教えてもらった)
6. Monitoring an Ethereum infrastructure
つぎこれ! 間に合うかなぁ。。、#devcon5 #devcon pic.twitter.com/akIZvJjgMx
— Yukishige Nakajo(1ウェイ教) (@nakajo) October 10, 2019
まにあった!#devcon #devcon5 pic.twitter.com/Cxcc7pxPjV
— Yukishige Nakajo(1ウェイ教) (@nakajo) October 10, 2019
gethのmoniteringの話。同じセッション聞いていた @moririn772のツイットがわかりやすかったので貼っときますw
サーバーサイドエンジニアお馴染みの彼ら pic.twitter.com/YjSFbNrzIN
— Mory@devcon5 (@moririn772) October 10, 2019
計測せよ!可視化せよ!の話やった
— Mory@devcon5 (@moririn772) October 10, 2019
gethの出すログの中で、怪しい動きしてるログを実例で少し紹介してくれる話だった。
ただ、結構色々なログが取れるんだねっていうのと、こういうログを取っておくといいよっていうのが聞けたのはよかったと思う。
(より詳しい具体的な内容は理解できなかったけどw)
7. Pentesting Ethereum Contracts: Exploring a Honeypot Contract Using Ganache
これ面白そうなので次これ。と思ったら直前にやってるのも面白そうだったのでrepo覗き見した。幸いゲーム形式だからこれで遊んどく。#devcon #devcon5 pic.twitter.com/sVXmrnqrTQ
— Yukishige Nakajo(1ウェイ教) (@nakajo) October 10, 2019
truffleのセッションか!知らないできたわw#devcon #devcon5 pic.twitter.com/FE5ADwGM2C
— Yukishige Nakajo(1ウェイ教) (@nakajo) October 10, 2019
気づいてなかったんだけど、truffleのセッションだった。ganacheの紹介と、リエントランシーの脆弱性の説明とそれを用いたHoneyPotの簡単な紹介ののちにworkshopという流れだった。
workshopはリエントランシー攻撃のためのAttack Contractを作ってテストするってのと、CaptureTheFlagの2本立てだった。
CaptureTheFlagは色々地雷が埋め込まれていて全部説明(?)したらOKみたいな感じなのかな?
一番印象に残ったのがこれ。
.transferと.send使うのがre-entrancyのアンチパターンにされちゃってた。。。まぁ今までベストプラクティスで紹介されてたのが、Constantinopleのバグで全く逆になっちゃったから、強めに訂正しないといけないのは仕方がないですね。。。