Ethereumのスケーリングについて

スマートコントラクトのスケーリングに限ります

主に期待値の高い順に以下

1. Plasma

2. Sharding

3. Raidos(Raiden2.0)

---

1. Plasma

これ　→　Minimal Viable Plasma - Plasma - Ethereum Research

を読み込むのが一番の近道（しかし簡単とは言ってない）

（3/7追記： Ethereum Foundationにお願いして公式に和訳させてもらってます）

OmiseGOのUNOさんとDavid Knottくんに助けられて理解が捗った。本当にありがたい。界隈にコントリビュートしていきたみ。

以下がわかりみにあふれる疑問なので答えが欲しい。

この界隈では答えをクレクレしてると怒られが発生するので、持論を組み立てて議論するしかないのであった。

ちなみにPlasmaはPoW上では現状無理な設計なのでだいすきなZilliqaの上では走らないのであった。あとexit管理の関係でUTXOモデルで残高管理するデザインなのでSolidityの仕様が変わる。移行には大規模な書き換えが必要。またテストしないといけない、つらいですね。

（3/7追記： WPを読み込んだら、PoWでも使えることがわかりました）
（3/7追記：Plasmaチェーンは完全に別のチェーンだと思ったほうがいいです。代わりにEthermintなどを用いて任意の言語でスマートコントラクトを書けるようになると言われています。）

---

2. Sharding

これ　→　Sharding FAQ · ethereum/wiki Wiki · GitHub

これ　→　PDF  https://docs.zilliqa.com/techfaq.pdf

あたりを読むと良い感じ（ただしめっさ長い）

これはEthereumのShardingなんだけどShard間の通信を必須にしてるのと、Shard分けのロジックが簡素なのがZilliqaと違うところ。

（3/7追記：EthereumのShardingがZilliqaよりはるかに複雑なのは、コントラクトのスケーリングもやろうとしているから。Zilliqaはトランザクションのスケーリングのみ。ZilliqaはSCILLAがLoop/Recursionがないことからも分かるように、金融システムの置き換えだけなら簡単なコントラクトで良いとの考えであろうのと、トランザクションが減ればコントラクト実行も詰まらず、もともとFinalityがあるので、いいよねという考え方かなと。）

Zilliqaは2時間おきのDS(Directory Service/ノード管理) EpochでPoW(ethash)の結果に応じてDS Commitee(リーダーノード)を選んでからノードたちをShardに入れていく。Shardに入ったあとは普通にQueueに詰めて順繰り処理させるのでパフォーマンスがノード数に対して線形向上する。

Sybil Attack(Sybilというのはとある多重人格患者の名称)という、アイデンティティをめちゃくちゃ作って多数を占めてvoteに勝つみたいな不正を、参加にコストを貸すことで経済不合理にしちゃう感じ。

Zilliqaの欠点だなって思うのはk8sのGPU sharingが次の次のバージョンとかで出て来たとしたら、19枚刺しマザボとかでVM間でGPU資源を融通してしまえば、Queueに並んでるノードはGPU使わないので、そのオバケマシンに所属しているノードがリーダーノード選出に勝ち続けるみたいなASIC的な状況はあるかもなってことです。経済性やコネマターでリーダー固定化問題はRippleとかByteballとかDASHとかLISKでもちょいちょい耳にするかな。ASICみたいにGPUを刺せる枚数を増やしまくる会社が出て来たらおもしろいっすね。

（ETHのShardingの話全然してねえ）ETH Shardingの上にPlasmaが乗ったら指数関数的に処理が早くなってやべえってDavidがテンション上がってました。

(3/8追記：

“Ethereum Sharding Update— Prysmatic Labs Implementation Roadmap”

ShardingのEthereumテストネット"Sapphire"が2018年末に。そしてEthereumのメインネット"Diamond"実装が2019年とのこと！

https://t.co/sH3oh2Fhlw

— うどん＠Enigma Japan運営してます (@udon_crypto) 2018年3月7日

 らしいです。

)

3. Raidos

これはちょっと存在を示唆してるだけの状態でRaiden1.0ですら1年半かけてセキュリティがしっかりしてることを検証しながらRolloutするので、ちょっと遠い話なのと、Solidityってチューリング完全なので、stateに保存できてしまう状態が多様すぎて「マイクロコントラクトチャネル」的に状態更新を2者間でmutexとって相殺するのが難しいなと思っていて、他のユーザーが共有している状態を更新しようとしたらロックが成立しないかロックを待つかのどちらかが起こるので、つらたんですね、と。

でもPlasma WPのJoseph Poonがいうには、Plasmaはfinalityを得られるように作ってるわけじゃないのでfinality(つまり言い方によっちゃトランザクションの即応性)が欲しいなら、LN(Lightning Network＝今回はRaidos的立ち位置にあたる)がないとダメだよって言ってるんで、まあ彼もLN作者なわけでその可能性にかけているが故にそこに繋ぐためのPlasmaという発明だと思うんで、大発明を期待して待ちたいところ。

---

さて、淡々とコントリビュートして参りましょう。以上です。