Signal
📡 Signal｜NEARのSPICE設計でブロック生成の待ち時間削減へ
NEARのSPICE設計は順序決定、データ可用性、実行を分離する。ブロック生成の待ち工程を減らす狙いと、導入後に確かめたい性能の条件を整理する。
NEARの開発チームNear Oneが9月30日付の技術資料で、取引の順序決定、データの利用可能性、取引の実行を分ける「SPICE」の設計を説明した。NEAR公式も10月1日朝の投稿で資料を紹介し、実行処理をブロック生成の必須の待ち工程から外す構想を示した。
狙いは、計算に時間のかかる取引が、次のブロックを作る速度まで縛る状況を減らすことだ。公式投稿は導入後の効果を説明しており、今回の資料公開だけで、実運用の処理性能がすでに変わったと読むことはできない。Near Oneの設計資料が説明するのは、その仕組みである。
何がブロック生成を待たせるのか
ブロックチェーンは、複数のノードが同じ取引と状態を共有する仕組みだ。取引をどの順番で扱うか決める工程と、その取引を計算し、結果が正しいか確かめる工程がある。
Near Oneの説明では、現在のNEARは、取引データの利用可能性や前のブロックの実行・検証と、新たなブロックの生成が強く結び付いている。取引の計算が重いときや、順序を決める工程に時間がかかるとき、別の工程も待たされることがある。
SPICEは、この依存関係を緩めようとする。ブロックを生成する部分に載せる情報を軽くし、データを保持する部分、取引を計算する部分、それらの結果を確認する部分が、より独立して動ける設計だ。
たとえるなら、仕事の受付、資料の保管、実作業、検品を、一つの作業台で順番に処理する状況を変える発想に近い。それぞれを分けても、受付記録と完成品が対応していることを確認する仕組みは必要になる。
工程を分けると、確認する役割が増える
設計資料は、チェーン、データストア、実行を主要な構成要素として示す。チェーン上の情報を使って、必要なデータが取得可能であることや、実行結果が検証されたことを確かめながら状態を進める。
したがって、工程を分けることが、安全性の確認を省くことを意味するわけではない。どのデータが保持され、どの計算結果が承認され、利用者にいつ確定した結果を返せるかを、分かれた工程の間で整合させる必要がある。
ここから読み取れるのは、性能改善の評価軸も増えるということだ。ブロックが短い間隔で生成されるだけでなく、取引が実行されるまでの時間、結果を安心して使えるまでの時間、混雑時の変動を分けて測りたい。これは設計を評価するための見方であり、今回の公開資料から実測値を示せるわけではない。
他チェーンとの比較も、利用者が待つ時間から
BitcoinやEthereumを含む他のチェーンと比較する際にも、ブロック時間の数字だけを横に並べると、利用者が実際に待つ時間を取りこぼす。順序が決まったこと、計算が終わったこと、結果を次の操作に使えることは、それぞれ確認する対象だからだ。
NEAR公式は、SPICEの導入によって、より速いブロック、低い待ち時間、長く複雑な取引への対応を目指すとしている。複数の分割領域をまたぐ処理の発展にも言及しているが、導入時期や、負荷をかけた状態での性能を確定する材料は、今回確認した資料にはない。
今後の注目点は、設計説明から実装、検証、稼働へと進む過程で、どの待ち時間が、どの条件で改善したかが示されることだ。決済や複数サービスの組み合わせに使うなら、その条件が自分の処理と合うかまで確認して初めて、速さを使い勝手として評価できる。
比較用の測定を読む際は、同時に扱う取引の数や、計算の重さをそろえているかも確認したい。短い取引だけを流した場合と、複雑な処理が混じる場合とでは、利用者が知りたい待ち時間も変わる。平均値だけでなく、待ち時間のばらつきまで示されれば、設計の狙いがどこまで実現したかを判断する材料になる。
■ ことば
- SPICE：Separation of Consensus and Executionの略。取引の順序を決める処理と実行などを分け、ブロック生成との依存を緩めるNEARの設計構想。
- データ可用性：取引を処理・検証するために必要なデータを取得できること。取引の順序が決まっていても、元のデータを得られなければ処理を進められない。
- シャード：状態や処理を分けて担当する領域。分割によって並列処理を増やせる一方、領域をまたぐ取引の結果を整合させる仕組みが必要になる。
