tl;dr;

要約

SKALEネットワークの主な目的は、ETHと互換性があり、ETHメインネットを安全性のある基盤として使用する、分散・非許可型クラウドを創設することにあります。SKALEプロダクションネットワークが稼働すれば、AWSで行えていたことはすべて、ETH+SKALE上において、より安価で、信頼性が増した、より分散化された方法で行うことができます。

ETHメインネットは私たちにとって非常に重要であるため、当社ではこのメインネットをスピードアップし、より満足度の高いユーザーエクスペリエンスと共により速いファイナリティを実現し、レイヤ1セキュリティ保証を維持できるオプションを提供することに関心があります。イーサリアムを効果的にスケーリングするための長期的対策が、メインネットのバリデータセットのみに依存するべきだとは考えてはいませんが、SKALEが「完全な」スケーリング技術を有するための主な要件として、適切なユースケースに対するメインネット依存性スケーリングメカニズムの統合が挙げられます。

11か月前、私たちは、BLSロールアップを発明しました。この方法により、レイヤ1セキュリティ保証を維持しつつ、SKALEネットワークを使用してイーサリアムメインネット上のトランザクションとスマートコントラクトを効率的かつ安全に高速化することができます。

本日、私たちは、BLSロールアップをSKALEプロダクションネットワークに加える決定をしたことを発表します。すべてのSKALEバリデータがBLSロールアップに参加し、BLSロールアップ手数料から利益を得ることとなります。これは、私たちの敬愛するバリデータの皆さんが利益を増やすことのできる、素晴らしいチャンスです!

BLSロールアップ:

  • 即座に安全を確保でき、安価です
  • 待機期間を必要としません
  • 重い計算が必要なzkSNARKS/STARKSは必要ありません

とにかく便利。

ロールアップは、レイテンシの問題(記事の最後で詳述)を解決するわけではないため、すべての解決策とは言えませんが、スループットを大幅に向上させ、コストを削減できます。

BLSロールアップのデザインチョイスを行う際、私たちが胸に刻んでいたのは、Yコンビネーターのポール・グラハムによる「人々が欲しいと思うものを作ろう」という教えでした。高速処理を可能にするだけでは十分ではありません。それが使いやすいことが、同じくらい重要なのです。

BLSロールアップには、2つのフェーズがあります:

  • フェーズ1では、SKALEネットワークを使用して、ETHメインネットを僅かに高速化します。これにより、ERC-20トークンの転送スピードは、毎秒50トランザクション程度となります。
  • フェーズ2では、SKALEネットワークを使用してメインネットの高速化をさらに進め、毎秒350トランザクション程度のスピードを提供します。
  • フェーズ3における長期目標は、困難なソフトウェア開発を伴い、近い将来ローンチされるETH 2.0ネットワークの全速度に匹敵、もしくは上回る、毎秒1000トランザクション以上のスピードを目指します。

このことを簡単な言葉で説明しましょう。基本的には、今後数年間で、世界中で行われるすべての「意味のあるサイズ」の消費者取引をサポートすることが可能になる一方で、より小規模で頻繁に行われる、ファイナリティが重要なマイクロトランザクションについては、サイドチェーンで実行することができます。

このSKALEによるアプローチ特有の利点は、すべての口座残高がオンチェーンで保存され、すべての計算がオンチェーンで実行される点にあります。これは、レイヤ1ネットワークを可能な限り遵守したソリューションです。

楽しみですか?この先もぜひお読みください!質問があれば、@stan_kladko 宛にツイートしてください。

1 | BLSロールアップの概観

BLSロールアップの中心的な考え方は、取引規模を小さくすることにあります。トランザクションを小さくすれば、ブロックチェーンは速くなります。以下で、その理由についてご説明しましょう。

ティブロンとサンフランシスコ間を1時間ごとに運航するフェリーを想像してみてください。フェリーに100台の車を搭載できるすると、スループットは1時間あたり100台となります。

さて、車のサイズを小さくして、フェリーに1000台の車を搭載できるようにしたとします。その場合、スループットは1時間あたり1000台になります。10倍も増えるのです。

つまりは、車が小さいほど、スループットが高くなるということです。

さて、ETHブロックをフェリー、ETHトランザクションを車だと想像してみてくだだい。ETHトランザクションを10分の1に縮小すると、スループットは10倍も高くなります。

では、どうやってトランザクションを縮小するのでしょうか?次のセクションをご覧ください!

2 | ETHトランザクションを縮小する

一般的なETH送金取引のサイズはどの程度でしょうか?答えは、100バイト超です。そのうちかなりの部分(約64バイト)を、トランザクションのECDSA署名が占めます。トランザクションを占めるもう1つの大きな部分は、受信ウォレットのアドレス、20バイトです。

トランザクションを縮小する最初のステップは、20バイトのアドレスの代わりに、各ユーザーに4バイトのUserIDを付与することです。ユーザーがBLSロールアップに登録すると、UserIDが割り当てられます。

2番目のステップでは、ECDSA署名を完全に削除します。これはどのように実現できるのでしょう?それには、集約型BLS署名と呼ばれる魔法の暗号アルゴリズムを使用します。多くの当事者が文書に署名すると、これらの署名は魔法のようにひとつの集約型BLS署名につなぎ合わされます。このBLS署名は、元の署名よりもスペースを取りません。

複数の署名をBLS署名へとひとつにつなぎ合わせる当事者のことを、アグリゲータと呼びます。

それがどのようなものか、ご説明しましょう。サンフランシスコからニューヨーク行きの小さな手紙を大きな封筒に入れて送る人を想像してみてください。それは非効率的です!つまり、アグリゲータは、封筒の山をもらって、そこから手紙を取り出し、その全ての手紙をひとつの封筒に入れる人なのです。はるかに効率的でしょう!

さて、ブロックチェーン上では、手紙はトランザクションであり、封筒は署名に当たります。この集約技術をBLSロールアップ フェーズ1と呼んでいます。

次のセクションでは、その詳細について掘り下げます。

3 | BLSロールアップ フェーズ1:集約化プロトコル

まず、アグリゲータを選択する必要があります。

単一のノードをアグリゲータに指定することはできません。なぜなら、そのノードは独裁者になり、トランザクションの検閲を始めてしまう可能性があるからです。

代わりに、10分毎に時間を分割し、各エポックごとにアグリゲータをランダムに選択します。注:各エポックに対して複数のアグリゲータを選択する、さらに高度なバージョンのプロトコルも存在しますが、ここでは、単純な説明に集中しましょう。

人々の集まり(SKALEネットワーク)を想像してみてください。そこからランダムに1人選び、例えば、ダイアンを10:00から10:10までアグリゲータとして働かせるとします。そして、次の時間枠では、別の人が選ばれます。

その場合、6段階集約化プロトコル(SSAP)は、次のようになります。

  1. ユーザーは、アグリゲータであるダイアンにトランザクションを送信します。
  2. ダイアンは、大規模なユーザーグループGからのトランザクションを、トランザクションのチャンクCにつなぎ合わせます。
  3. ダイアンは、Cを元のグループGに含まれるすべてのユーザーに送り返します。
  4. トランザクションのチャンクCを受け取ったすべてのユーザー、ジョンは、署名を行い、署名Sを送り返します。
  5. ダイアンは、すべてのユーザーから署名を受け取ると、これらの署名をBLS署名 BLS_SIGとしてつなぎ合わせます。こうして、トランザクションのチャンクCBLS_SIGは、「ひとつの封筒の中にあるたくさんの手紙」となります。これで、たくさんのスペースが節約できました!
  6. 今度は、ボブがCBLS_SIGをメインネットに送信します。

集約化プロトコルの実行速度は? ユーザーはブラウザやモバイルアプリを使用し、アグリゲータはウェブサーバーを使用します。ウェブサーバーとユーザーとの間の対話は並行して行われ、現在の一般的なインターネット速度を考えると、集約化手順全体で数百ミリ秒が必要です。

さて、ジョンが悪意を持ち、ステップ4で署名Sを提出しなかったとすると、どうなるでしょうか?その対策として、以下の2つの非常に効果的な方法があります。

  • 第一の方法は、アグリゲータはジョンのトランザクションをチャンクから取り出し、集約化手順を再開する方法です。そしてアグリゲータは、ブロックチェーン上でジョンの低評価を記録します。ジョンの評価が一定基準を下回った場合、彼はシステムから追い出されます。Uberを考えてみてください。Uberを呼んでも利用しないことを続けると、乗客としての評価は下がり、ある時点以降はUberを使用できなくなります。
  • 第二の方法は、ジョン以外の全員が署名した場合、アグリゲータはチャンクCをメインネットに送信し、ジョンを非署名者としてマークする方法です。チャンク内にあるジョンのトランザクションは、ブロックチェーンによって単に無視されることとなります。

実際にブロックチェーンに提出されるものについて要約しましょう。

  • まず、それぞれが約12バイト(ソース 4バイト、宛先 4バイト、金額 4バイト)の大きさの数多くのトランザクションがあります。
  • 次に、これらすべてのトランザクションを保護する、ひとつの署名 BLS_SIGがあります。

完成!

チャンクCBLS_SIGがメインネットに送信されさえすれば、その後の処理は非常に簡単です!次のセクションで、その後何が起こるかについてご説明します。

4 | BLSロールアップ フェーズ1:メインネット処理

トランザクションのチャンクCと署名 BLS_SIGがメインネットに到着すると、スマートコントラクトがトランザクションを処理します。このスマートコントラクトのことを、BLSロールアップマネージャーもしくはBRMと呼びます。

BRMが行うことは次のとおりです。

  1. BLS_SIGが有効であるかを確認します。
  2. チャンク内の各トランザクションについて、
  • トランザクション金額を読み取ります
  • その金額分、送信者の残高を減額します
  • その金額分、受信者の残高を増額します

完成!

さて、BRM処理はどのくらいのGASを消費するのでしょう?付録Aにある概算では、ERC-20トークンのトランザクションあたり約13,000 GAS、NFTトークンのトランザクションあたり7,000 GASが必要です。これと、現在のERC-20トークン送金価格、約52,000 GASとを比べてみてください。

ブロックあたり10,000,000 GASの制限および15秒の平均ブロック時間を設けることで、私たちは、ERC-20トークン送金では約50 tps、NFTトークン送金では約90 tpsを達成できます。

BLSロールアップ フェーズ1は、2020年上半期に製作に入る予定です。

BLSロールアップ フェーズ2は、2020年夏頃に準備が整い、より劇的な高速化を実現する予定です。詳しくは、次のセクションでご説明します。

5 | BLSロールアップ フェーズ2:より安価なストレージを使用する

さらに高速化したい場合、トランザクションあたりのGAS消費量を削減する必要があります。BLSロールアップ フェーズ1において、ERC-20トークン送金を行う際、5.2万から1.3万までGASを削減できたことを思い出してください。

ここにおける重要な知見として、1.3万のうち1万 GASは、EVMストレージにおける送信者と受信者の残高を更新するために必要である点が挙げられます。EVMに保存されている値を更新するために、1回あたり5,000 GASがかかります。

ETHメインネットには、より安価なストレージがあるのでしょうか?その答えはYESで、その名をログストレージと言います。ログストレージは、イベント毎にかかる375 GASに加え、データ1バイトごとに8 GASが必要です。

何故、EVMストレージの代わりにログストレージを使用しないのでしょう?それは、ログストレージはEVMから読み取れないからです。EVMからログストレージに書き込むことは可能ですが、EVMの外部からしか読み取ることができないのです。

そこでこんなアイデアが生まれました。EVMがストレージから読み取る必要があるたびに、SKALEネットワークがそれを読み取り、EVMにプッシュしたらどうでしょうか?完成!これでログストレージが利用できるようになりました。

詳細については、以下の2つのセクションでご説明します。

6 | BLSロールアップ フェーズ2:ストレージ形式

BLSロールアップ フェーズ2では、UTXOと呼ばれるビットコイン様コインを使用して、資金をログストレージに保管しています(注:Plasmaも UTXOを使用しています)。各ユーザーはいくつもの未使用コインを所有しており、ユーザーの合計残高は、ユーザーが所有するすべてのコインの合計を意味します。

各トランザクションは、送信者に属する複数の入力コインを費やし、2種類の出力コインを作成します。ひとつは受信者に受け渡される資金、もうひとつは送信者の資金の残額です。

例として、アリスがボブに4トークンを支払いたい場合、彼女は1トークン、1トークン、3トークンと自身のコイン3つを消費します。そして、ボブに送る3トークン、自身に送る1トークンの2つのコインを作成します。

このトランザクションに対応する、実際のログレコードの形式は次のとおりです。

ここにおいて、transactionCounterはトランザクションのシーケンス番号、input_coinsは入力コインの額と対応するログレコードのブロックチェーン上の場所、output_coinsは出力コインの額と所有者を表します。

topicはEVMにおいて特別な目的を有しています。すなわち、EVMはトピック別にログレコードを検索する簡単な方法を提供しているのです。ユーザーが簡単に自身のコインを検索できるよう、私たちは送信者と受信者という2つのtopicを追加しています。

上述の1回のトランザクションに対応する、ログレコードのGASコストは約1,300 GASです。送信者と受信者の残高を更新するのに12,000 GAS近くが必要な、フェーズ1よりも驚くほど安価です!

こうして、ストレージコストを大幅に削減できました。次に、トランザクションの時間が来たら、EVMが記録を読み取る手助けをする必要があります。SKALEネットワークがメインネットをどのように助けるかについては、次のセクションでご説明します。

7 | BLSロールアップ フェーズ2:SKALEネットワークによるイーサリアムメインネットの支援

要約すると、ログレコードを読み取る時が来たら、SKALEネットワークのノードがそれを読み取り、メインネットにプッシュすることです。レイヤ1セキュリティを確保するためには、読み取りを行うためにSKALEネットワークから少なくとも111個のランダムノードを必要とし、それらに3分の2以上の圧倒的多数が署名した集約型BLS署名が必要となります。なぜ111個のノードが必要なのでしょう?ETH 2.0の場合、111個のノードからなるコミッティサイズがレイヤ1セキュアであると認められているからです。しかし私たちは、このセットを永久的に固定するつもりはありません。その代わり、SKALEネットワーク内のすべてのノードがセットに参加できるように、メンバーをゆっくりとランダムに循環させています。

次に、セクション3で説明したSSAP集約化プロトコルを用いて、集約化プロトコルのステップ1とステップ2の間でアグリゲータが実行する、追加のステップ1.5を導入しています。

ステップ 1.5:アグリゲータが、アリスのコイン(UTXO)を消費してボブに送金するという保留中のトランザクションを受け取ると、その保留中のトランザクションを111個のバリデータノードに渡します。

バリデータの仕事は簡単です。トランザクションが正しいことを確認し、有効なコインを消費し、二重支出を避けるだけです。

詳しく述べると、各バリデータノードでは次の手順を実行します。

  • トランザクションで引用された UTXOがブロックチェーン上に存在するか、額は正しいか、通常のビットコインにおける文脈で消費されていないか(すなわち、このUTXOを入力とするトランザクションがその後存在していないか)を確認する
  • このUTXOを使用しようとする、その他の保留中のトランザクションがないかを確認する(バリデータがトランザクションを受信する際、保留中として保存する)
  • 集約型BLSバリデータ署名を使用して、トランザクションに署名を行い、アグリゲータに返信する
  • アグリゲータは、ステップ2でトランザクションをブロックチェーンに送信する際、BLSバリデータ署名を含める

トランザクションがBRMスマートコントラクトによって受信されると、バリデータ のBLS署名を検証し、セクション6で説明したようにUTXOのログレコードを作成するトランザクションの処理を行います。

トランザクションあたりの総コストを見積もると、約1,600 GASでした。そのうち、1,300 GASは上記で説明したログレコード作成コスト、190 GASはトランザクションごとにBLS公開鍵集約化が必要なため、100 GASはその他の操作に由来します。

8 | BLSロールアップ フェーズ2:パフォーマンス

BLSロールアップ フェーズ2のトランザクションごとの総コストについて当社で概算したところ、ERC-20トークン送金のトランザクションあたり約2 200 GASとなりました。現在のERC-20トークン送金価格、51,000 GASと比べてみてください。これは、1秒あたり300超のトランザクションに相当し、さらにはレイヤ1様セキュリティを通常コストの5%で維持できます。

しかし、重要なのはパフォーマンスだけではありません。BLSロールアップは、すべての情報と計算をメインネットに保管し、必要な場合にのみメインネットを支援するためSKALEネットワークを使用します。つまり、現行のインフラストラクチャで動作し、既存のウェブクライアントやモバイルクライアントへの変更は最小限に抑えられます。

9 | BLSロールアップ フェーズ3:限界まで押し上げる

毎秒300トランザクション超という速度を有するBLSロールアップ フェーズ2は非常に高速であり、長年にわたり経済圏の成長をサポートすることができます。現在、ETHメインネットは1毎秒10トークン未満の送金速度であり、BLSロールアップもメインネットと同様のレイテンシであることにご注意ください。

BLSロールアップを改善して高速化する方法はまだ存在します(ただし、今後数年以内にそれを行うことは想定していません)。

重要なのは、可能な限り最小のトランザクションサイズを使用し、ひとつのログレコードに多くのUTXOを記録することです。これにより、レコード作成に必要な固定コスト 1,125 GASを削減することができますが、標準のトピックベースEVM検索機能を使用してのUTXOレコードの検索はできなくなります。自身が保有している金額を、ユーザーが簡単に検索することができなくなるのです。私たちはこの問題を、各SKALEノードに外部検索エンジンとインデックスエンジンを追加することで解決します。

自身のコインを探すために、アリスはメインネットを検索する必要があります。それを行うには、ユーザーはSKALEノードのうちのひとつ、もしくはその他プロバイダ(Infuraなど)と対話するか、インデックスエンジンを自身で実行する必要があります。

フェーズ3についての概算では、トランザクションあたり700 GASと算出され、これは毎秒900超のトランザクションに相当します。

10 | スラッシング

上述のシステムは、悪意のあるバリデータによるいたずらやスラッシングの証拠を簡単に提供します。不正証拠はメインネットに送信され、悪意のあるバリデータを削除することができます。このブログ記事はこの時点でかなり長くなってしまったため、スラッシング条件についての考察は、読者の皆さんにお任せします。その条件はかなり明白ですから。

11 | 結論

BLSロールアップは、レイヤ1セキュリティ保証を維持し、メインネットにユーザー資金を保管しつつも、メインネット上のトランザクションレートをスケーリングする方法を提供しています。SKALEネットワークは、メインネットを支援するヘルパーレイヤ1ネットワークの役割を果たしています。

BLSロールアップは、ユーザーの監視、待機期間、紛争解決を必要としない唯一のロールアップです。その点から、より優れた、ユーザーフレンドリーなソリューションと言えるでしょう。

BLSロールアップは、送金や大規模な購入の際にとても有効に使用することができます。メインネットに基づいているため、メインネットのファイナライズが遅いという問題が残っています。ユーザーは、メインネット上のトランザクションが成功したかを確認するため、5分以上も待つ必要があります。車を買う場合ならそれでも良いかもしれませんが、コーヒーを買う場合には不都合です。コーヒーを買いたい場合は、サイドチェーンを使うことをお勧めします。

* 付録A

フェーズ1における、ERC-20送金トランザクションごとのトランザクションGASコストの見積もり(イスタンブールおよびベルリンフォーク後):

  • 送信者残高の読み取り:800 GAS
  • 受信者残高の読み取り:800 GAS
  • 送信者残高の更新:5000 GAS
  • 受信者残高の更新:5000 GAS
  • 送信者BLS公開鍵の読み取り:800 GAS
  • 集約鍵取得目的での送信者BLS公開鍵の追加:190 GAS
  • 合計:約13,000 GAS

フェーズ1における、ERC-721 NFT送金トランザクションごとのトランザクションGASコストの見積もり(イスタンブールおよびベルリンフォーク後):

  • 現所有者アドレスの読み取り:800 GAS
  • 現所有者の更新:5000 GAS
  • 現所有者の公開鍵の読み取り:800 GAS
  • 集約鍵取得目的での現所有者BLS公開鍵の追加:190 GAS
  • 合計:約7,000 GAS
  • Appendix B
  • 付録B

フェーズ1における、ERC-20もしくはERC-721 NFT送金トランザクションごとのトランザクションGASコストの見積もり(イスタンブールおよびベルリンフォーク後):

  • UTXOログレコード:1300 GAS(ログイベント 375 + 2トピック分 2 * 375 + データ)
  • BLS公開鍵集約:190 GAS、うち150 GASは楕円曲線追加 + プリコンパイルコール40 GAS
  • コールデータ:最大18バイトのコールデータに対して最大300 GAS
  • 計算:50 GAS未満

合計:約2,200 GAS

  • 一般的なトランザクションの最小サイズは、20バイトで、2種類の入力UTXOのシーケンス番号、受信側のインデックス、作成された 2つのコインの金額についての情報が含まれる。コールデータは1バイトあたり16 GASであるため、コールデータイベントでは320 GASが必要となる。
  • BLS公開鍵集約には、190 GASが必要。
  • ログレコードサイズは、およそ20バイトで、2種類の入力UTXOのシーケンス番号、受信側のインデックス、送信側のインデックス、両当事者に受け渡された金額についての情報が含まれる。これには、1バイトあたり8 GASで160 GASが必要となる。
  • 計算:50 GAS未満

よって、合計は約700 GAS