勉強会の様子は録画が公開されています。Solana Labs 小野寺さんも参加されており、懇親会では参加者からの質問に回答いただけました。懇親会は録画公開の対象外ですが、有益な情報と思われましたのでSolanaの仕様に関わる質疑については参加者の皆様に許可を頂いて記載しています。
以下、本編の記述は特筆しない限り @visvirial の発表です
Solanaのホワイトペーパーを読む会とういことで、Solanaのホワイトペーパーを読むけど、Solanaの解説ではありません。どういうことかはあとで分かります。
アブストラクト
Proof of Historyを新しく導入していて、これを導入すると発生タイミングの前後関係と経過時間を貴重できるのでトランザクションの時間を追うことができる。
途中でネットワークが分断されることがあり得るが、そうしたとしても、復旧可能。
ブロックチェーンデータをちゃんと持っていることを証明するためにProof of Replicationというのを使うがそれについても書いてある。
最大で71万TPSが実現可能だということが書いてある。
アブストラクトにはそういう事が書いてあります。
はじめに
現在のブロックチェーンのアルゴリズムは基本的にブロックチェーンに参加するノードの時計があっているかの保証がないので、基本的にノードのローカルの時間はあまり関係なく、時間についてはブロックチェーン上では結構曖昧、というのが問題ですというのが書いてあります。
PoHはネットワークの基準になるブロックチェーンを提供するので、従来時間についてルーズだったのがPoHを使うと時間の基準が作れてトランザクションの前後関係が把握できるようになる。
本文の構成
ネットワークデザイン
基本的にトランザクションを赤いダイヤの形のリーダーというところが集めて、リーダーの人がトランザクションを検証して、他の検証者がたくさんいるがその人達にこれはOKですといって渡していって最終的な合意を得る。
リーダーの選出
リーダーはPoSで選ぶ。PoSはつまり、コインをたくさん持つ人が投票権があって、コインの所有枚数に応じて投票できるアルゴリズム。
リーダーはメッセージと書いているがつまりトランザクション、の順序付けを行って署名を入れてバリデータに渡す
バリデータは中身が正しいかとか署名が正しいかを検証して署名をする。
リーダーが署名をするがリーダーが署名したデータについて検証者がさらに検証をして更に署名をつけて、たくさんいる検証者＝バリデータたちがいっぱいいるがその人達がたくさん署名するとそのトランザクションはOKになるという感じ。
PoH
ものすごく凝ったアルゴリズムではなくて単純。
SHA256でハッシュ化してハッシュチェーンを作っていく。
古いデータについては１万個前のデータだと１万回ハッシュ関数を通さないといけないのでそれで時間が決まるみたいなアルゴリズム。
最初は、適当な初期値を入れて適当なハッシュ関数に入れる、以降そのハッシュ値にたいしてさらにハッシュ関数で、、、というのを繰り返す。これは普通のブロックチェーンと一緒。
4.1 概要説明
さっきちょっと言った通り、３００回とかハッシュがつながると、０番目のハッシュ値は３００回ハッシュ関数を通さないと得られないものである。0番目のものは３００回ハッシュを計算するだけの時間が経過しているということが言える。
4.2 イベントのタイムスタンプ
ハッシュの他に、ハッシュと一緒に色々なメッセージやデータを突っ込んであげると途中でそのデータが突っ込まれた状態になるので、そのハッシュチェーンの中にあるデータというのは、ハッシュチェーンのデータが取り込まれたブロック高＝何番目のハッシュが計算されたときよりも前にそのデータができたことがわかる。そのデータがハッシュチェーンに取り込まれた時間よりも前にそのデータが存在したことが確定する。
例として撮影データを入れるとこんな感じになりますというのが書いてある。
撮影データ1は３３６番目のハッシュチェーンに含まれているので、撮影データ１は３３６番目のハッシュが計算された時点より前に存在したことがわかる。
同様に、撮影データ２も６００番目より前に撮影データが作られたことがわかる。
これはいまのを図にしただけ。
インプットとしてcfd4f...というのが２番目のSha256に入るとこういう感じで計算されるという図です。
入力値が変わると、変わってしまった以降のハッシュ値が全部変わるので勝手に入力値が変えられないということを言っている。
なのでイベントと書いているがメッセージ、が挿入された場所を見ると、経過した時間が見積もれる。
4.3 検証
検証の計算についてはマルチコアで実行可能。
ハッシュチェーンが１万とかつながっているとハッシュチェーン自体の計算は１万回計算しないといけないのでシングルコアでやらないといけないが、検証についてはそれぞれのハッシュについては次のハッシュ値が正しく計算されているかそれぞれ違うコアで検証できるのでマルチコアでできるので、かなり高速にできるでしょうということが書いてあります。
GPUの例が書いて当て４千コアのGPUがあれば1/4千でできるよねということが書いてある。
図にするとこんな感じ。左から順にハッシュチェーンの１番目2番目。。。という感じになっているのですが、1番目と２番目のデータがわかればハッシュチェーンの１番目のデータの検証はできる。
データを分割することで並列化することができるということが書いてある。
4.4 平行（並行？？）スケーリング
PoS生成を全部一人で演る前提にしていたが、２人以上いる状況だと、2人のうちのどちらかに自分の入れてほしいメッセージを取り込んでもらえばいいので、２倍処理できるし、ハッシュチェーンを作る人が１０人いたら１０倍に能力が上がるということが書いてあります。
２人PoHの生成者がいる図。左の人と右の人がいるが、左の人も右の人もハッシュ関数を計算していってハッシュチェーンを作っている。
お互い同期をとることで、隣の人のPoHの生成者の出力を定期的に自分のハッシュチェーンに取り込むことで、同期できて、こうすると、どこかデータが変わると全部ハッシュチェーンが変わる（のを検出できる）ので、それで同期ができるというのを説明している。
4.5 一貫性
最後の計算結果を次の計算結果の入力値にすることで一貫性と攻撃耐性が維持されると期待される。
どういうことかというと、PoH生成者が悪意を持っていた場合、イベントの発生順序を変える攻撃ができる可能性がある。これを防ぐために各イベントトランザクションを送信するときに、クライアント（PoH生成者に対してトランザクションを作るユーザー）がいるのですが、各クライアントが今生成され続けているハッシュチェーンの最新ハッシュ値を自分のイベントに取り込むことで、そのイベントが取り込んだ最新のハッシュ値が生成されるよりも前にその値を取り込むことはできないので、それに寄って順序を変えることはある程度防ぐことができる、みたいなことが書いてあります。
実際のこのPoHのシーケンス図というか、表がこういうふうになっていて、これはイベントを１，２，３と3つ作る例。
このときにevent1のデータと一緒に最新のhash10aを取り込んで、それ全体に対して署名をするとEvent1のデータができる。
こうすると全部のイベントが最新のハッシュチェーンの値に依存することになるので、順番を入れ替えようとしてもEvent2のHash20aはEvent1のhash10aよりあとになるので、これを入れ替えると整合しないので、それによって不正が検知できる。
イベント順序の書き換え
一部分のイベント順序を書き換える攻撃が有効になるのは、クライアントがイベント送信前に検知したハッシュ値の順番からそのイベント情報がシーケンスに挿入されるまでの間だけに制限される。
要するに、ハッシュチェーンがどんどん伸びているので、ハッシュチェーンが新しくなる前にできたイベントデータは同じハッシュチェーンの値を参照しているので前後の入れ替えはできてしまうのですが、新しくハッシュが計算されるとまたイベントデータが変わってしまうのでそれによってハッシュチェーンのハッシュが更新される前はいくらでも入れ替えができるが更新されてしまうとイベントの順序を入れ替えられないと書いてあります。
実際のハッシュチェーンにどういうふうにデータを取り込むかの図。
真ん中がハッシュチェーンの計算、一番左がトランザクションのデータ。トランザクションにLast hashと書かれているのが入っている。event hashがイベント全体のデータになっていて、これを２回目のハッシュ計算に取り込んでいく。
4.6 オーバーヘッド
秒間４０００回のハッシュ計算が可能な環境では秒間１６０KBのデータが追加で生成される。検証は並列でできるのでGPUで4000コアで検証すれば1秒に出てくるハッシュ値が4000でも、0.25-0.75ミリ秒ぐらいで検証できるという意味ですかね。
4.7 攻撃
まず順序の逆転というのが書いてあります。
イベントの順序を逆転させるためには、次のイベントを受け取ったあとから不正なシーケンスを生成していかないといけない。
イベントの順序を書き換えようとすると、他の検証者のハッシュチェーンが伸びているところ自分は遅れてスタートしなければいけないので、それによって検知できるのではないかということが書かれている。
4.7.2速度
PoHの生成者が複数いることで攻撃耐性が得られるということが書かれている
生成者がたくさんいればネットワーク帯域も広がるのでたくさん取り込めるでしょうということが書いてある。
4.7.3 ロングレンジアタック
昔利用されていた古い秘密鍵を悪用してブロックチェーンを書き換える攻撃と書かれている。
それもハッシュチェーンを途中から変えていかないといけないので、過去のハッシュチェーンを作るために必要な秘密鍵を入手できたとしてもハッシュチェーンを全部再現できる計算ソフトとかがないと正規チェーンに追いつかないので難しいでしょうということが書かれている。
高速なプロセッサを使わないと普通のCPUの計算速度に追いつかないのでできないということが書いてあるんですけど、本当かな？当感じですね。
一番最後にPoRepとPoHを併用すると空間的にも時間的にも堅牢性を高めることができると書いてあります。なぜかはよくわからないですけど。
とりあえずきりが良いので質問があれば
PoHの話だったが普通のブロックチェーンと変わらないというか、なにがどう違うんやという内容な気がするのですが、なにか質問等ありますでしょうか。
なければ勧めます。
5.1 Proof of Stakeによる合意形成
ここもいわゆるPoSの説明が書かれているだけ。
PoSはいろいろな設計があるがここでは次の要件を満たすように設計する、と書かれています。
シーケンスを迅速に承認できるということと、逐次的にPoH生成者を選出できる、不正を働いている検証者たちへの懲罰ができる。
そういう設計にしましょうという感じ。
5.2 用語の説明
ボンド
不正を働いたときに備えて供託が必要。ボンドと呼ばれている。
スラッシング
PoWと違ってPoSの場合、ゼロコストで不正なチェーンと正規のチェーン両方に対して同時にステーキングできるので、正規のチェーンを伸ばすインセンティブがあまりない。PoWだと間違ったチェーンにWorkすると、そのブロックは有効にならなくて電気代は全部無駄になるので防げるが、PoSの場合不正なチェーンを伸ばすこともほぼゼロコストでできるので、それが問題ですよねというのがNothing at stake問題。これを解決するのがスラッシング。
要するに、変な、不正なチェーンに対して伸ばそうとしていったときに、ボンドとして預けた供託金を没収することができるのがスラッシングというふうに書いています。不正なチェーンを伸ばそうとすると自分のお金が取られちゃうので正規のチェンを伸ばすインセンティブがある。
大多数派
検証者は世界中にどれだけあるのだろう、１０００ノードとか、たくさんあるんですけど、それぞれの検証者が出したボンドの2/3以上を大多数派と定義しています。
2/3以上とると大多数派になって何でもかんでもできる。
2/3以上取らないと何も進められない。
逆に言うと、1/3以上の不正なコインを持っていないと不正なブランチを作れないということが書かれています。そうするとSolanaでは時価総額の1/3がないと攻撃できないので(攻撃しようと考えるた)大変だよねということが書いてある。
5.3 ボンディング
ボンドを預けること。
5.4 投票
PoHの生成者は1回決まると予め決まった期間の状態に対して署名を行うことができる。
バリデータに対してボンディングしている人たちは、PoH生成者の作るメッセージというかハッシュチェーンに対して検証して自分たちも投票できる。
基本的にYes票しかなく、否決票みたいなものはない。
そうして検証者からたくさん票を集めて2/3以上の票が集まるとブランチが正式にConfirmされる。
5.5 アンボンディング
ボンディングした通貨は自由に引き出せると問題なので、引き出し条件がある。
ボンディングしていたとしても検証者がネットワークにつながらないとかでエラーになることはある。そうしてエラーになって票をたくさん失った通貨は投票に参加する権利を失う。
一旦そうして投票の資格を失うと、手動で手続きを踏むと、ボンディングに出した通貨を取り戻すことができる。
どれくらい票をもらうことができなかったかということはプログラム、ソースコードで固定で決まっているのではなくて動的に変わる。有効票数に対してボンディングの資格を失った通貨がどれくらいの比率あるかで変わる。
Nを動的に変えていくことで大規模なネットワーク分断が起きたときに、右と左に別れたとして、右のチェーンを採用するか左のチェーンを採用するか、決めないといけないが、決定の合意がNを動的にすることで早くできるということが書いてあります。
5.6 選挙
PoH生成者の選び方＝リーダーの選び方
選挙は生成者がエラーを出したときに行われる。エラーを出すとどの人をPoHの生成者にするか投票が開始される。
検証者のボンディングに出した通貨数に応じて票が決まり、票をたくさん集めた検証者が次の生成者として任命される。
エラーが出なかったときも一定時間経つと入れ替わっていくが、途中でリーダーがエラーを起こして緊急事態が発生したときは、投票時にチームの中で１，２，３...位と記録しておいて、もし1位の人がだめになったら2位の人が繰り上がって交代していくということが書かれています。
まぁ普通のPoSですね。
5.7 選挙の開催条件
5.7.1 PoH生成者の分断
PoHの生成者が基本的にハッシュチェーンを作っていくが、分岐して復数のハッシュチェーンを作り始めてしまったときに検証者がそれを検知して、生成者を変えようぜという投票がなされることがある。
5.7.2 実行系の例外
PoHの生成者が何らかの原因で動作しなくなったときにネットワークで検知して選挙をして新しいリーダーを決める
5.7.3 ネットワークのタイムアウト
5.8 スラッシング
検証車が違うハッシュチェーンに同時に投票してしまった際には懲罰が下る。
検証者が復数のハッシュチェーンに投票してしまうとネットワークで検知してその検証者がボンディングしていた供託金が没収される。
基本的に違うチェーンに投票するとだめなのですが、ネットワーク分断とかで分断されたときにどちらかのハッシュチェーンが伸びるのでどちらかが正規になってどちらかが不正規になるのですが、ネットワーク分断が起きたときに不正規なほうに投票していたときはそれは攻撃ではなく仕方ないことなので没収しないということが書かれている。
PoHも同様で変なことをしたら没収しますということが書いてある。
5.9 副系の選挙
サブリーダーの選挙
先程あったと思いますがPoH生成者のリーダーを決めるときに1番目だけでなく2番め3番目の人も決めていくので、2番目の人がサブリーダーですという感じですね。
もしハッシュチェーンの中に不正が検知された場合ネットワークで検知してサブリーダーにフォールバックされる。リーダーが障害を起こして計算されなく鳴った場合にもサブリーダーに引き継ぎが行われる。
5.10 可用性
CAP定理によって一貫性と可用性と全部満たすのはできないのでどちらかを犠牲にしないといけないが、Solanaの場合には可用性を優先すると書いてある。
基本的に可用性を優先するが、通常時には一貫性もきちんと保たれますということが書かれています。
PoSの承認者は一定量の通貨をステーク状態にロックすることで投票する権利を得ると書いてある。それはそうですね。
ネットワークが分断された場合にどちらのチェーンが正しいかを決めないといけない。決めるための時間をなるべく短くするために、ボンディングに出された通貨のアンボンディングをうまくするみたいなことが書いてある。
色々書いてあるが、投票でたくさんの票が得られなかったものがアンボンディングされて、多数派のチェーンに対してもう一度ボンディングされて、賛成票が増えていくことで、分断された場合にも大きい票を持つほうがどんどん票が大きくなる、という仕組みを取りますというようなことが書かれている。
ざっくりいうとそういう感じです。ちょっとでも大きいほうが票を集めるようにうまく作りましょう、みたいなことしか書かれていないです。
5.11 復旧
どんな障害が起きても台帳を完全に復旧させることができると書いてあります。
先月ぐらいにブロックチェーン止まって復旧できなかったんですけど、ホワイトペーパーには復旧させることができると書かれている。
復旧については、利用不可になった検証者すべてのステーキングが解除されるまで新たなボンドによって台帳の承認を行うことは不可能となるということが書かれている。
5.12 状態確定
PoHの承認者は、基本的に500ミリ秒以内にハッシュを計算してネットワークに流すことが求められるということが書かれています。
5.13 攻撃
こっから先どういう攻撃がありそうで、それをどう解決するかという話が並ぶ。
5.13.1 コモンズの悲劇
検証者はPoHの生成者が作るデータを検証してそれに対して署名を付けて返さなければならないが、特にインセンティブがなければ、検証をサボってないも見ずに全部署名することができてしまう。
検証者なのに検証していないやつを排除するために、PoH生成者はランダムに間違ったデータをだして、それに対して間違っていると検証者が言えるかどうかを見ることでちゃんと検証しているかどうかをチェックする。
5.13.2 PoH生成者との談合
検証者がPoH生成者と結託していると不正なハッシュが流れてくるタイミングを事前に知ることができる。
ただし、PoSなのでその人がたくさん通貨を持っていないとできない、みたいなことが書いてあるんですかね？
そのへんは普通のPoSでも一緒だと思います。
5.13.3 検閲
ボンドとして提出された通貨の1/3以上がハッシュチェーンの受け入れを拒否したときには何らかの攻撃が起きていることを指すと考えられる。
ハッシュチェーンの受け入れを拒否している1/3のボンド保有者をビザンチンボンド保有者と呼ぶ。
こういうことをすると、2/3以上の投票がないと先に進めない。逆に言うと、1/3以上が悪意のある攻撃者に取られると止まってしまうので、これをどう解決するかが書かれている。
どうするかというと、ボンドが枯れて新しく使えるようになるサイクルを動的に調整することでそうした問題を解決できる。
どうするかというと、1/3以上のコインを持って悪さをしようとしても、大多数が1/3以上を持っている人をネットワークから切り離して排除することでうまくやりましょう、みたいな事が書いてある。
全部うまくやりましょう、ぐらいのことしか書いていないんだけれど、そういう事が書いてあります。
5.13.4 ロングレンジアタック
PoHは基本的にロングレンジアタックに対する耐性を持つ。
PoH生成者の計算能力を超える速度で計算しないと伸びていくハッシュチェーンに追いつけないので、できないでしょう、みたいなことが書いてある。
5.13.5 ASIC攻撃
ネットワーク分断時と状態確定時に作為的にタイム・アウトする攻撃がありうる。
分断時のASIC攻撃についてはステーキング・ボンディングの解除速度が非線形に変わっていくので大規模な分断を起こしている場合には早く計算しても意味ないみたいなことが書いてあります。
状態確定時のASIC攻撃については、PoHの生成者と結託して自分の好きな投票内容を優先的に取り込ませるみたいなことが書いてあるが、結局そのPoHの生成者と結託していないと行けなくて、検証者はたくさんボンディング通貨を持っているはずなので、できないでしょみたいなことが書いてあります。
ここまでのコメント・質疑
実際にはいまのところはGPUは使っていなかった気がしますが、それでも検証は十分速いっていうことなんでしょうか？
Solana Labs 小野寺さん: PoHの検証はCPUでも並列化できるので実用範囲では現状では十分早いですね。ノードはそれなりのメニーコアであることが求められるからです。
ホワイトペーパーではGPU使おうぜというのが書かれているけど現状では対応していない？少なくとも全部は対応していなくてCPU計算している。検証者になるには結構高いマシンスペックが要求される。10コアぐらいな気がしますけど、そのくらいのすごいハイスペックなPC、ワークステーションがないといけないので、マルチコアCPUを使っているので並列化はしている。
スラッシングを避けるためにバリデーターはどうやって不正だと思われるブランチを見抜くのか気になりました。不正なブランチというよりも不正なリーダーを見抜くというニュアンスが強いのでしょうか…。
小野寺: リーダーから提案されたブロックのデータとか署名とかを抜けなく検証して、最終的なブロックチェーン全体のDigest値が一致するかしないかで見抜けます。
怪しそうなノードという疑義とかは無くて観測可能はプロトコル違反だけに注目していればいい感じです。
ご回答ありがとうございます！ ノードではなくプロトコルレイヤーにおける違反チェックということですね！ マルチコアで順に計算された結果のハッシュ値で成否をみる感じですかね～
小野寺: PoH以外にも、トランザクションを実際に実行したり、各署名のチェックなど色々と検証ポイントは他にもありますが、プロトコルレイヤーの違反チェックということで合ってます。
質問はチャットで完結しているようなので、他になければ続けていきたいと思います。
ストリーミング形式のProof of Replication
6.1 概要
Proof of ReplicationというとFilecoinが有名で、Filecoinは分散型のクラウドストレージのようなものでユーザーから預かったデータをマイナー的な人たちがハードディスクに保存しておいてクラウドストレージのように使えるというものがある。
そういうときにデータをデータを預かったと言っているマイナーたちが、預かりましたと言いながら後ろではデータを捨てている可能性があるので、ちゃんとチェックするのがProof of Replication。
Solanaについてもブロックチェーンの過去データとかを持っていないといけないので、データを持っているアーカイブノードみたいなのがあるけど、そのノードが正しいデータをずっと持っていることをチェックするためにこういうのがある。
図7はデータを暗号化して保存すると書いてあって、CBCモードと言ってデータをブロックごとに分けて暗号化するが、2番目の暗号化データは1番目の暗号化データを混ぜることで、ハッシュチェーン的にやるというのがCBCモード。
Proof of Replicationの全体図は図8で、データを暗号化したものとPoHハッシュを混ぜてハッシュ関数を通してルートを計算するという感じでやるという図です。
6.2 アルゴリズム
具体的なアルゴリズムはここに書かれている。
このへんはちゃんと理解できていないのですが、アーカイブノードみたいな人たちはブロックチェーン上のデータに対して、それぞれの持っているハッシュ値を使って、それを鍵として暗号化をして保存することでできるみたいなことが書いてある。
この辺はPoRのアルゴリズムをちゃんと追わないとわからない感じかなと思いますが、暗号化して保存しておくことで検証できるということが書いてあります。
6.3 承認
複数コアを利用することで各複製ノードを承認するためのあんごうかを並列かつブロック一つ一つをこなすストリーム形式で計算できる。
ハッシュ計算の対象データサイズを大きく削減するために全部のデータを持ってくるのではなくて、ランダムに選んだデータにだけやることで計算を減らしましょうということが書いてある。
コア数が多ければいくらでも並列化できますみたいなことが書いてあります。
6.4 鍵のローテーション
鍵が同じだとデータを保存しておけばいいだけなので、鍵を定期的に切り替えていかないといけないということについて書いてある。
6.5 ハッシュ値の選択
PoH生成者はネットワーク全体がPoRepに使うハッシュ値を発行する。
PoH生成者＝リーダーが作ったハッシュ値をもとに、PoRepに使う鍵などのデータが決まる。暗号化の計算にかかる半分の時間に相当する周期で発行される。
各データ複製ノード（アーカイブノードみたいなの）は、暗号化計算にかかるより短い時間内に複製データを保有しているという証拠を提出しなければならない。
持ってます証明を出すのをいつまでも待つと、暗号文を再計算して作ることでデータ本体は消せるみたいなことが書いてあります。
6.6 証拠の検証
PoRepの証拠を検証する役割はPoHノードが担うものではない。検証はしないが追跡可能にすることがPoHノードの役割。実際に検証するのは検証者で、検証者からの署名を受けて証拠は正式に承認される。
データ複製ノードの承認についてはSolanaネットワーク上で1つのパケットで行われる。
6.7 攻撃
攻撃はいくつかある
6.7.1 スパム
ノードは承認を要求する際に暗号化済みデータとマークル木全体をネットワークへ提供する。
そうすると、全データをネットワークに流すので、攻撃者が多くのデータ複製ノードを作成しPoRepに対する承認リクエストでネットワークを埋め尽くそうとするかもしれない。
複製1件あたり1コアを暗号計算に必要な時間分だけ専有させるので、複製自体が検証ノードの利用できるコア数と同じぐらいしかできない、GPUだと3500コアぐらい。
6.7.2 部分消去
データ複製ノードはデータ全部の保管を避けて一部削除する可能性がある。
そういうことをすると検証するときにサボって捨てたデータに1回でも当たるとそのノードが不正なノードだということになるので、ちょっとでも捨てると検証に通らないことがいつかやってくる。なので大丈夫ということが書いてあります。
6.7.3 PoH生成者との談合
結局PoRepに使うデータはPoH生成者が作るデータで決まる。PoH生成者がデータ複製ノードに都合の良いデータを作ることができる。でもそれをやってもハッシュ値で計算するのでランダムに決まるので、自分の仲良しのデータ複製ノード全員に対して優遇することはできなくて、ランダムに決まるので、一人のデータ複製ノードにしか便宜をもたらさないので、そんなに問題にならないだろうということが書いてあります。
6.7.4 DoS
データ複製ノードを増やすためには、ストレージを用意するぐらいでできる。
データ複製ノードが増えたときに検証が必要になる。ノードが一つ増えるとコア数が一つ消費される。
データ複製ノードを大量に用意すると検証者のコア、計算能力が枯渇する可能性がある。
これを防ぐにはデータ複製ノードを指名、決め打ちで決めちゃう？ということが書いてある。
それじゃ全然分散してないことになるけど、そういう感じのことが書いてあります。
6.7.5 コモンズの悲劇
PoS承認者は検証を行わずにPoRepで作られた証拠を検証せずにひたすら承認する可能性がある。サボることを防ぐために、PoS承認者とデータ複製ノードの間で採掘報酬を分け合う仕組みにする。
一定期間でPoRep承認者がたまに間違ったデータを作ることで検証をサボっているノードからお金をとることで解決する。
7 システムアーキテクチャ
各ユーザーがトランザクションを作ってGeneratorがトランザクションを集めて承認してVerifierに渡して検証してもらう
7.1 構成要素
7.1.1 リーダー、Proof of History生成者
リーダーは投票で選ばれたPoHの生成者。
ある程度の数のトランザクションを挿入してハッシュチェーンが伸びると自動的にリーダーは署名を行う。
7.1.2 状態
データ構造みたいな話なのでこれは細かいのでいいですかね
7.1.3 承認者、状態の複製
承認者ノードが複製を行うことでブロックチェーン状態の高い可用性を実現する。
7.1.4 検証者
承認者から流れてきた情報を消化する
7.2 ネットワーク帯域の制約
1回PoHのリーダーになった人には、ユーザーがトランザクションをどんどん発行して送ってくるので、それを集めまくって順序付けをして、最後に署名をして検証してもらう。
効率化はメモリアクセスパターンに基づいてなされるとあるが具体的な話は書かれていないのでふわっとしている感じ。
バイナリデータのエンコードの話が出てくる。
この辺は今の実装と違う可能性があるのであまり真面目に読んでも、という感じですね。
最大処理性能
ここから先がパフォーマンスの話が入ってくるのだが、このパフォーマンスの話はまぁひどくて怒りを覚えるレベルだったのですが、まぁ読んでいくと、
1Gbpsのネットワークで処理可能な最大トランザクション数は1Gbps/176byters=710kTPSである。
とかいてある。割ったらそう出るのはわかる。ビットコインも250bytesなので500kTPS出せるという話になる。安直な理論が書いてあってよくわからない。
実際にBitcoin SVなどビッグブロック系の実装だとビットコインと比べてブロックサイズの制約が変わっているぐらいです。すごい改善がなされているわけではないが、SVとかで実際に何GBとかのブロックが作られてたくさんトランザクションが処理できるということができているので、それとこのホワイトペーパーに書いてあるのと同じ理論が全部適用できるんだけど、という感じで、ひどい理論だなと思いながら読んでいました。
7.3 計算能力の制約
各トランザクションについては承認情報のダイジェスト値が入っていて、このチェックは大してメモリを使わずにチェックできるし、各トランザクションごとのチェックは並列でできるから、コア数増やせばたくさんできるみたいなことが書いてある。
それはそのとおりだけど、ビットコインでも基本的には電子署名のチェックだけなので、並列化できる。まぁ一緒なんだけどなという感じなんだけど、次の文書はGPUベースのECDSA承認サーバーで実験した結果900kをマークしたとある。でもそれはECDSAの署名を測っただけで、なぜそれがSolanaの速さに直結するのか、そのへんがゆるいというか、だからなに、関係はない、あるけど、直結はしない話で、そうか、という感じです。
7.4 メモリ容量の制約
32バイトのエントリ×100億アカウントぐらいあるとメモリが640GBぐらい必要になるけど、それをランダムアクセスすると、だいたいこのくらいのメモリアクセス精度がでる、と書いてある。
メモリの物理的なランダムアクセス性能だけを見て性能が決まるならいいんだけど、ボトルネックになる場所はそれ以外にも色々あるはずで実際にやってみないとわからない。メモリのランダムアクセス性能だけ見て275万TPS出るとか書いてあるんですけど、こいつは計算の最適化とかやったことあるのかというひどい理論ですね。なかなかアクロバティックな人ですね。
7.5 高パフォーマンスなスマートコントラクト
多分これがこのホワイトペーパーで最も大事。
ちょっと今の実装でもそうなっているのか知らないが、ホワイトペーパー時点では、extended Barkeley Packet Filterという、一種の仮想言語というか、Javaの中間言語的なのがあって、それを使うと効率的にスマートコントラクトが実行できるので、それを使いましょうということが書いてある。
並列化もできるし、重い処理は外部関数に投げて中間言語じゃなくてネイティブで動かせば早くなりますということが書いてある。
これが何故重要かは後で話すのですが、こういう図が載っていて、でもこれはBPFの説明なんで、いいかな。
まとめ
ちょっと、私のあくまで個人的な、ホワイトペーパーを読んで感じた点ですが、全体的にPoSとPoRepの既存実装をただまとめただけで、すごい新しい技術というのが全然出てこなくて、何なんだろうこのWhite Paperは。何を言いたかったんだという感じです。
PoHという新しい名前をつけているが、普通のブロックチェーンやハッシュチェーンとほとんど変わっていない。変わっている部分があるとすれば、ホワイトペーパーでは強調されていなかったが、出てきたトランザクションに対してトランザクションをブロックに取り込むのではなくて、トランザクションの中にブロックチェーンの最新ハッシュを入れることで、双方向というか、トランザクションに書かれたハッシュ値よりも後にトランザクションが出てきたことがわかるし、トランザクションが含まれたブロックを見ることで、どのブロックからどのブロックの間に出てきたということがわかるので、それが既存のものとの違いかなと思う。しかし、だからなぜセキュリティが上がるかは説明されていなくて、自分の理解力では、何が嬉しいのかわからなかった、そういう感じです。
特に第7章ですが、数学的議論の検証が全く無くて、実パフォーマンスを検証せずにこれだけTPSが出ると、すごいどんぶり勘定で、PoSの部分も経済的インセンティブを与えれば悪いことするやついないよな、という謎の自信がある。PoSなのでしょうがないんですけど。
スケールしない部分は全部GPUにおまかせで並列化すればOKという感じで、GPUプログラミングどれだけ大変かお前分かっているか、という感じのホワイトペーパーでした。
ホワイトペーパーの感想としては上の二個でだいたいそんな感じです。
今の実装を見ると、暗号学的になにかすごいことをやっているのではなくて、並列化や効率化などを頑張って最適化することでトランザクションをたくさんさばける実装を作れたというのが、今の実装を見る限りの、Solanaと他のブロックチェーンとの違い。
そういう自分の見方が正しいとすれば、その並列や効率化がどれだけで来たかが最も重要なはずなので、そこを書いてくれないと、このホワイトペーパーでは何も情報がないので、よくわからないですという感じになる。
どうやって並列化がうまくできたのか、効率化できたのかを、きちんと教えてくれないと読みごたえのないホワイトペーパーだなという感じでした。
ディスりはここで終わりで、一方で、実際にEthereumなど触ったことがある方はわかると思うが、Ethereumはトランザクションさばく数がすごく少ない。その一つの理由がスマートコントラクト同士の依存関係があって、スマートコントラクト同士の順番を変えると実行結果が変わってしまったりしてしまうので、並列化がむずかしいというのがある。
White Paperでは全く書かれていないが、Solanaはスマートコントラクトのコードの一番最初にどの変数を使うかというのが全部書いてあるので、それを活用するとスマートコントラクトを実際に実行する前に依存関係がわかる。それによって並列化できるようになっている。そこは結構すごいよくできているなというふうに思いました。
ホワイトペーパーには書かれていないが、そこが結構すごいなという感じです。
なので、全体的な印象としてはホワイトペーパー見た感じではとりあえずお金と関心、人を集めて、気合で実装を作って、実装の凄さで乗り切ったみたいな感じのプロジェクトだなという感想でした。
実際にEthereumとかが詰まっている状態で、Solanaは今の実装でも何千、何万トランザクションさばける。そういう実装Solana以外に殆どないので、そういう非常に高いスループット、性能を持った実装を作れたというところでは、Solanaは非常に素晴らしいと思います。
何回も言っているが、ホワイトペーパーでは全然出てこないが、コア技術はブログ記事があって、その中でSolanaで使われているアルゴリズムの紹介が書かれていて、ここの部分がどちらかというとコア技術になっていて、ホワイトペーパーはおまけというか、頑張って調べましたねレベルなので、Solanaについて本当に知りたい人はこちらのブログポストを読んだほうがいいかもしれません。
一番最初にホワイトペーパーの話はしますがSolanaの話はしませんという事を言いましたが、Solanaのホワイトペーパーを見てもSolanaの実装がなぜすごいのかは全くわからないので、Solanaに興味がある人はこっちを見たほうがいいかもしれません。
たまにブロックチェーンが止まったりするが、可愛がって上げてください。
最後長くなりましたがこんな感じで終わりたいと思います。
質疑（Zoomコメント欄にて）
6章のあたりは、ホワイトペーパー書いたあとに arweave を発見してそちらにおまかせしたんでしょうか？
Solana Labs 小野寺: PoRepは仰有るとおりarweaveに取って代わられました。
ありがとうございます、PoHにくらべてPoRepって全く聞かないなーとおもいまして(笑
Solana Labs 小野寺: PoRepは黒歴史ですww
懇親会
Solana Labs 小野寺: ホワイトペーパーの薄っぺらい内容を見抜いていて面白かったです。コード第一主義でホワイトペーパーはないがしろにされている。Mediumの記事と、公式ドキュメントも足りないが、それで全部。
@visvirial: ホワイトペーパーの内容は古い？
小野寺: ホワイトペーパーで一番生きているのはPoHの説明で、PoRepはまるごとなくなっている。他の部分も陳腐化されている。やんちゃなスタートアップ的なところがある。ビットコインとかと比べるとまだまだ障害が起きたり未熟なところもある。
@visvirial: 自動的に復旧できると書いてあるのにしていなかった
小野寺: あれは実践と理論の乖離という話で、ソフトウェアにバグがあったりした。理論的には現状の最新版では動くのだがバグがあったりするのは間違いない
@visvirial: あれはトランザクションが来すぎてメモリが足りなくなったと聞いているが
小野寺: 障害レポートとかも出てるんですが、それは二次災害的なところで、ノードのステーク量に対して大多数が生きていないといけないけど死んでしまったので、という感じで、あっています。一番根本的なところで言えばトランザクションが大量に来たときの優先順位付けが不十分だったのでそこが良くなかった。
@visvirial: Solanaにはmempool的なのがないという噂も聞いたんですけど
小野田: mempoolは無いですね
@visvirial: 勝手にみんなが順序付けして整合性取れなくなってという感じなんですかね
小野寺: 障害起きたのは想定した以上の大量のトランザクションが送りつけられたのでそのときに動かなかった。いまはそこらへんの異常系のハンドリングを強化して同じような障害は起きないようにしようという改善は動いている。理論的には破綻していないはずで、そこらへんで今後の障害は起きにくくなるんじゃないかなと思っています。
ホワイトペーパー読んでいただいたのを聞かせていただいて、あのホワイトペーパーだけでは通じないんだなっていうのは、新しい意見として聞けたので良かったと思う。僕の理解では速さはPoHを使うことでコンセンサス形成が非同期で行えるのが一番。
PoWと比べてPoSで行くのはかなり最初にあった。PoSで行くときにどうしても合意形成メッセージングに関して、普通にやると時間がかかる。メッセージのやり取りがノード数で二次関数的に増えていく。そこを解決するのにPoHがあって性能の秘訣。
もう一つはノードが経済合理性に基づいて高スペックじゃないとノード運営できないので性能が高いのもTPSの高さの理由。そのへんはホワイトペーパーから致命的に抜けている。
@visvirial: 合意形成の方はいわゆるコンファメーションまでの時間が短いというところで、TPSの改善にもつながるんですかねそれって
小野寺: 全部の処理がパイプライン化できるので基本的には早くなると思う。ほかのPoSと比べていただいたとは思うが、カルダノ、ポルカドット、コスモスさんとくらべてタイムアウトがない、投票ラウンドがない。同期する必要がないので、PoSだとそこが遅くなる理由だが。ETH2でも同じことが言える。なのでSolanaというとPoH、PoHと宣伝しているんで、それに半分ぐらい分量割いてて、そこが強調ポイント。あとは、シャーディングするかしないかの設計思想であえてしないという選択をとったりとかあったりした上で高TPSを実現している。（スマートコントラクトは）Ethereumとちがってアクセスするデータを実行する前に指定するのでそこも早くなるポイント。
@visvirial: オモシロイと思ったんですけど、ホワイトペーパーに記述がないんですよねそれ
なので、今日の勉強会はSolanaのWhite Paperですけど、現状のSolanaについてはよく分かってもらえなかったかもしれないｗ
質問: スマートコントラクトと一言で言われていたと思う。スマートコントラクトって、EthereumのスマートコントラクトとSolanaのスマートコントラクトでいわゆるできることは同じだから一言で説明されているのか。いわゆるチューリング完全なのか。違いはあるのか。
@visvirial: 一緒だと思いますよ。言語は違いますが、計算能力は一緒だとおもうので。ブロックチェーン上で任意のプログラムを動かせること自体をスマートコントラクトと読んでいる。ビットコインもTaproot入れば結構柔軟に実行できるので、大体のブロックチェーンでスマートコントラクトありますね。
質問: 発表の最後の方で、宣言の仕方が手前の方でやるので並列化できるという話、その意味ではスマートコントラクト間のメリットデメリットが存在するのかなと思った
@visvirial: それはあると思います。スマートコントラクトと言ってもどういう機械語、中間言語に置き換えるかはプロジェクトごとに違って、EVM互換といってEthereumで動かすのはEthereum Virtual MacheneでEVMって言うんですけど、そういうチェーンもあるしSolanaみたいに独自の命令セットを導入しているのもある。それによってパフォーマンスも変わる。
小野寺: そういう説明であっていると思います。SolanaはEVM互換をいっていない独自路線を行っている。並列化とかしやすいように宣言に独自構文を用意して性能を出せるようにしている。
質問: 独自構文を考案されるうえで参考にされたプログラムの言語というか、なにか発想のもとになる言語みたいな、理解度を端折るためにこういうのを参考にしましたと言われると、そのへんなんだなともやっと理解できると思ったのだがありますか？
小野寺: 基本的にSolanaの場合はOSエンジニアなどがバックグラウンドで強いので、OSの設計とかをなるべく踏襲している。変数の宣言は、OSで言うところのPageTableと似たような考え方をしていて、どこにReadWrite、あるいはReadOnlyなのかが、PageTableAddressみたいになっていて、いい感じに並列に実行できる。アクセス競合が起きていないことがわかるので。OS詳しくないと難しいかもしれないですけど。
逆に言うと、JSじゃないようにしようというのはありました。JSだと、JSの実行環境はグローバル変数ありきですべてのステートを逐次実行されないといけなくて並列実行できない。どの関数、どのasyncでもwindowにぶら下がっているグローバル変数みれたりするのと同じで、同時並行するにはそういうのをなくさないといけない。そういうJavascriptとかみたいな実行環境ではないような実行環境を作って早く実行できるようにしようという考え方。アンチテーゼ的なところは取り入れようとしているんですよね。シャーディングしないとか。既存のブロックチェーンの僕たちの真似したくないところだなみたいなのはあって、ブロックチェーン界隈の既存プロダクトに大して参考にしたのはある。
質問: Solanaが恒常的にFeeが安いのは、Feeが高いトランザクションを優先するわけではないから？
小野寺: ざっくりいうとそう。リーダーに対する報酬は主にインフレーション経由。トランザクション実行はなぜ高くなるかというと、スループットが出ないから。スループットが出るなら前提条件が逆転して、スパムさえ防げたら安くていい。
質問: ビットコインだとスループットは10分間隔。それはネットワークの伝播速度のバーターで、それを1分にすると届かない相手がいるというバーターになる。Solanaはそのへんが非同期で解決されている？代わりに失っているものはあるのか。分散性を必要十分にしているのかなとも思ったが。スループットを実現する上で失っているものはあるか。
小野寺: 高性能なノードを動かさないとノードを動かせない。高性能なパソコンもそうだしデータセンターレベルの高性能な早いインターネット回線が必要になっている。それがTPSを出すためのバーターになっている。ビットコインに関して言えば10分で伝播するようにというのはラップトップで動かしても検証できるみたいな、かなり敷居の低いラインに揃えているのでTPSはどうしても出しにくくなってしまっている。
質問: Berkeley packet filter ってちょっと珍しいところを突いてきたなと思うんですが、BPF にしようとした理由はなんでしょうか?
小野寺: これもよく聞かれる。競合ブロックチェーンだとWASMを採択しているのでBPFにしたのは一言でいうとWASMに対してBPSは性能優位性がある。JIT、ネイティブコードに変換しやすい。リナックスカーネルで採用されていたのでそのへんでの運用実績も買われています。最後に言えばWASMよりはランタイムの大きさが小さいのでGPUにスマートコントラクト実行を任せようとしたときにもやりやすいのではないかという理由。基本的には性能重視。
質問: Berkeley packet filter ではサンドボックス作れる？
小野寺: サンドボックス作ってやっています。
質問: GPU対応は
小野寺: 部分的で、署名検証などはGPUでできる。いまは必要なほどトランザクションがないのであまり性能的に優位になれるというわけではない。もう一つ残っているのはスマートコントラクト実行をGPUでやろうというのはロードマップにあってそこら辺はまだ未実装。TPSが育たないとGPUを使ったときの恩恵が出にくいので、あまり開発の優先順位は高くない。そもそも @visvirial さんがおっしゃるとおり、GPU実行するとき色々大変というのもあると思う。そんなに詳しくないんですけれども。
@visvirial:一応CPUでできるレベルなんでまだ大丈夫ですって感じなんですかね
質問 > 逆に言うとまだまだ余裕があるんですね
小野寺 > 余力はあるがピークになったときにリカバリできるかという運用実績はこれから積んでいかないといけない。ただ度々NFTのセールなどの細かいピークはさばいているので余裕はあるのではないかと思っている。いまは通常だと2200TPSぐらいなので、もっと行っても余裕なんじゃないかなと思う。
質問: デプロイされるコントラクトのスペック上の上限は設けられているのか
小野寺 > EthereumはGasリミット。Solanaはコンピュートリミット。無限ループとかしたら途中でアボートする感じ。
質問: ガスがきれるから終わるという感じ？
小野寺: そんな感じ。良い質問ですね。無限ループが発生するのはBPFではそもそもかけないようにできるが、Salanaは許容している。Gasリミットみたいなのによって、終了しないスマートコントラクトが無いようにしている。
質問: それはそういうほうが良いだろうというアンチテーゼの一つなんでしょうか
小野寺: アンチテーゼでいえば、チューリング完全でないとスマートコントラクトかけなくなってしまうので、BTCがそうであることへのアンチテーゼではありますね。リナックスカーネルの場合そんなに込み入ったコードはBPFでは書かないので、その点ではチューリング完全である必要はないが、Solanaではやっぱりチューリング完全でありたい。
質問: そのへんをギリギリまで突き詰めたコードとかはまだ現状あまりデプロイされていない？
小野寺: いや普通にいっぱいあります。Gasリミットにヒットしてアボートするのは普通にありますよ
質問: そういうのは開発者の方はどんなコードがデプロイされているかみれるんでしょうか、ウォッチしやすい環境を作られているんでしょうか。
小野寺: ウォッチしやすくはないが見ることはできる。開発中であればデプロイしたらトランザクション失敗しているんで見たらわかる。
質問: 普通の人よりはウォッチされているんだろうなと思って。どんなコードが動いているのか興味があるんですけど、NFTもDeFiもどんなプログラムがブロックチェーンのスマートコントラクト上で動いているのか興味があるが、統計取れる立場にないので。取ろうと思えば取れるのかもしれないが。こんなのあったよというのがあったら聞きたいです。
小野寺: 基本的には機能面ではEthereumとエコシステムが揃ってきていて、一通りのEthereumであるやつは動いてるんじゃないかという理解です。たとえばUniswap系みたいな単純なAMMもあるし。実行環境が違うだけで基本的に同じことができる。ただコードを逆アセンブルして勉強できるかというとそこまでSolanaではできない。BPFの中間コードに変換されていて、Javaのバイトコードみたいなのでそれで勉強しようと思っても難しいと思う。ひとつEthereumと違って面白いのは、オープンソースになっているDEXでSerumがある。いわゆるセントラルオーダーブックをSolanaオンチェーン上で実装されていて、そこを見たら面白いかもしれない。高性能だからこそこういうのができる。
質問: これまでのDEXだとマッチングの間隔が遅いので取引所の板に比べればインターバルがあるので裁定取引などはしにくい場所だと思っていたのですが、高スループットだと早くいたが約定するんですかね
小野寺: 普通に、CEXと同じ感覚で約定できますよ。DYDXよりはちょっと遅いけど、botじゃなくて人間がやる分には十分な速度。TPSが高いのと同時に低レイテンシ、ブロックタイムが400msec、1秒の半分ぐらいなので。
質問: SerumがSalana上のDEXとして存在していると思うんですが、後続のDEXがデプロイされたら何個か存在するみたいになるんですよね？
小野寺: Solanaの面白い点は流動性はできるだけまとめようという考えエコシステム全体ではある。それがシャーディングを採用しなかった唯一至上の命題と言っても良くて、シャーディングすると流動性がまとめづらくなる。AMMでも普通の板でも。そこらへんをシャーディング無しで板を参照し会えるようにしている。たとえばRaidiumとかMangoの現物取引においてはSerumという大本の板を見たりして取引したりするので。Phantomとかのウォレットもあって、MetamaskみたいにSwapできるが、それもSerumの板を見たりしている。
質問: Serumが一番流動性のある板ということなんですね。それを見て、参照して作られているものがある
小野寺: 他のコントラクトから低レイヤーのものにアクセスすることがシャーディングがないので一気通貫でできる。
質問: コントラクトには独自の言語があるのか、一般的なもので書けるのか
小野寺: Rustというそこそこ有名な言語で書けますし、最終的にBPFのバイナリに落とせたらいいので、C++とかCでも書けるが、ほとんど今はRustで書かれている。RustはSolanaで初めて書いたけどMemory Safeなのはすごくでかくて、とっつきにくいけど良い言語だと思っている。
質問: コンパイルはLLVMというかんじですかね
小野寺: そうですね。GPUバックエンドに適用先を変えるのもそれだと楽なんじゃないかなということでLLVMを採択したんだと思うんですよね。最近だとGCC系でもBPF出せたりするみたいなことやってるんだよな。でもそこは、うろ覚えです。
質問: LLVMなら原理的にはどの言語でもできるはず
小野寺: まぁそうです
質問: Brave Browserに統合されるということだがどういうことができるようになるのか。Solanaが統合されて広がる何かは何？
小野寺: 直接関わっていないので詳しくなくて、且つ話せるところが限られている。Solanaの高TPSだからこそできる楽しいことが必ず待っていると思っていただいていいと思います。それからウォレット統合とかは積極的にされるんじゃないか。
質問: Braveでチップの機能とかある。仮想通貨が目指していたことをやってくれたと思っている。ブラウザと仮想通貨を融合するとすごい可能性があると思う
小野寺: 間違いないと思います。ただGas代が高くてマイクロペイメントができなかったが、Solanaはそのポテンシャルを秘めている。そこがBraveに認めてもらえたのではないか
質問: SolanaのウォレットはHDウォレットで受信用アドレスはいくつも作れるんですか
小野寺: チェーンと関係なくHDウォレットは使える。SolanaサポートしてHDをサポートしているウォレットなら使える。あまりHDウォレットで使い分けている人は見ないけど。
質問: 似たようなものとして早くて安いと言われるPolygonやBSCなどと比べてユーザーとしてはどう違うか
小野寺: もっと早くて安い。やってみたら体感速度でもぜんぜん違うと思います。1年前はDappsとか殆どなかったが今は充実してきている。基本的に10ドルあれば一通りのことは遊べると思います。
質問: 公式のページでモバイルウォレットを探していたが、Exodusを推奨されていたと思う。実際それをiPadとiPhoneにインストールしてリスクヘッジして使っている。そのExodusをすごい使っていてステーキングもできるし便利なんですが、それを推奨した背景を聞いてみたいと思った。
小野寺: とくにない。ステーキングまでサポートしているウォレットがあまり多くない。Solflareが対応しているが、まだモバイルウォレットを出していない。その程度の理由。余談ですがスキャムが増えてきているので気をつけてください。
質問: 私も検索で偽物がトップに出てきてインストールさせられそうになりました
小野寺: 本当に気をつけてください
（※ちょうど弊ブログの次の記事はSolanaのウォレットの話です）
質問: Rustでスマートコントラクトを書くとUnsafeになる？
小野寺: Unsafeなコードも書ける。Unsafe使うと違反メモリアクセスはランタイムエラーになる。Rustで、UnsafeなコードもUnsafeでないコードも書ける。大抵のスマートコントラクトはUnsafeを使わずに書きます。
