見出し画像

BLS署名、KIP-113、およびKIP-114の理解

usamimi

セキュリティ、透明性、検証可能な真のランダム性は、ブロックチェーンネットワークが常に改善に取り組んでいるコア属性です。そして、これらの問題のいくつかに対処することを目的とする1つのテクノロジーとして、 Boneh-Lynn-Shacham（BLS）署名スキームのが注目を浴びています。

最も有名なのは、イーサリアムのフェーズ2.0ビーコンチェーンがこのBLS署名スキームを使用してバリデータのコンセンサスを処理し、検証可能なランダム関数（VRF）を通じてランダム性を実装することです。ビーコンチェーンでは、送信された署名が時間の経過とともに蓄積され、透過的に検証可能で改ざん防止のある時点で最終的にランダムな値が生成されます。

イーサリアムによるBLS署名スキームの使用に触発されて、KIP-113とKIP-114は、KlaytnでのBLS署名の使用を提案するために構築されました。KIP-113は、BLS署名に基づく公開鍵登録を通じてノードのIDを検証するメカニズムを提案しています。また、KIP-114は、ブロックヘッダーに2つの新しいフィールドを導入して、チェーンで検証できるランダムな値を生成することを提案しています。この記事では、BLS署名スキームに簡単に触れ、次にKIP-113とKIP-114について説明します。

BLS署名の理解

BLS署名には、ECDSAよりも2つの主な利点があります。それは、より小さな署名データと署名の集約です。

[図1] ECDSAとBLS署名のアルゴリズム比較

2つのアルゴリズムを比較する前に、まず 楕円曲線暗号（ECC）の重要な概念であるジェネレータを理解する必要があります。

ジェネレータは特定の楕円曲線上の点です。この点は、楕円曲線上の他のすべての点を生成するために使用されます。これは、乗法操作（2倍）によって行われます。ジェネレータが特定の回数「追加された」場合（「加算」は楕円曲線での特別な加算操作を指します）楕円曲線上の対応する他の点が生成されます。

公開鍵を生成するには、秘密鍵である乱数にジェネレータを掛けて、結果の点を公開鍵にします。

[図1]の各プロセスの比較を次に示します。

  1. ECグループ：ECDSAでは、ジェネレータはp256、secp256k1タイプの楕円曲線によって作成されますが、BLS署名では、通常、G1とG2の2つのジェネレータで構成されています。BLS12 – 381の楕円曲線を使用します。次に、G1とG2を使用して、署名と公開鍵を生成します。

  2. 鍵の生成：ECDSAとBLS署名の両方が、選択した楕円曲線上の秘密鍵とジェネレータの点の積として公開鍵を生成します。秘密鍵は、選択された楕円曲線上の整数の有限グループから選択されたランダム整数です。

  3. 記号（msgの場合）：ECDSAでは、署名生成プロセスは少し複雑です。署名者は、秘密鍵と乱数、およびメッセージのハッシュを使用して署名を生成します。一方、BLSでは、署名の生成は比較的簡単です。署名者は、メッセージのハッシュと秘密鍵のみを使用して署名を生成します。その結果、BLS署名データのサイズは著しく小さくなり、ECDSA署名データの64バイトに対して48バイトになります。

  4. 検証：ECDSAとBLSの両方で、受信者は元のメッセージ、署名、および署名者の公開鍵を使用して署名を検証する必要があります。ただし、プロセスは少し異なります。ECDSAは操作と除算を実行し、結果が署名者によって提供された値と一致するかどうかを確認します。BLSはペアリングチェックを使用して、署名が有効であることを確認します。

続行する前に、署名のサイズに戻す必要があります。ポイント3では、BLS署名データのサイズは48バイトであり、ECDSAよりも小さいと述べました。イーサリアムのコンセンサスレイヤーのBLS署名データ、およびKIP-113とKIP-113で表されるものは、実際には96バイトです。これは、片方は公開鍵のサイズが小さく、もう1つは署名データサイズが小さいというBLS署名スキームの2つのバリアント が発生するためです。

G1で公開鍵を生成すると 最小パブキーサイズになり、G1で署名を生成すると 最小署名サイズになります。署名のサイズと公開鍵のどちらを最小化する必要があるかに応じて、最小化する要素をG1として、もう1つをG2として配置できます。

Klaytnの場合、バリデータの公開鍵はスマート契約とKlaytnチェーンに保存され、ブロックの提案とトランザクションの検証と検証中に頻繁に暗号化操作が行われるため、計算を高速化するための公開鍵のサイズを小さくすることは、署名データのサイズを小さくするよりも効率的な選択です。

[図2]署名集約の例(N人が同じメッセージに署名した場合)

BLS署名のもう1つの重要な利点は、署名を集約できることです。署名の集約とは、複数の署名を単一の署名に組み合わせることができることを意味し、この結合された署名は、個々の署名をすべて検証するのと同じレベルのセキュリティを提供します。一方、ECDSAにはこの集約機能がありません。

この機能は、イーサリアムのコンセンサスレイヤーでのブロック検証に使用され、ECDSAを使用してNと比較してストレージスペースが1 / Nに削減されます。[図2]は、N人が同じメッセージに署名したときに署名の集約がどのように機能するかを示しています。

詳細については、ECCの一般的な概念とともに、次の記事を参照してください：Ethereumのアップグレード、パート2.9.1：BLS署名

KIP-113

KIP-113は、BLS署名に基づく公開鍵登録を通じてノードのIDを検証するメカニズムを提案します。BLS12– 381レジストリは、BLS署名固有の利点を活用するように設計されています。

これは、Klaytnブロックチェーンの各ノードのアドレスとノードIDを記録するKlaytnのAddressBookスマートコントラクトに似ているように見えるかもしれませんが、KIP-113はAddressBookを置き換えるものではありません。AddressBookの目的は、ノードがKlaytnネットワーク上でお互いを見つけて通信できるようにすることです。KIP-113は、ローグキー攻撃やKIP-114の防止など、さまざまなコンポーネントでのBLSの使用を容易にすることで補完することを目的としていますが、この記事でさらに詳しく説明します。

目的の機能を実行するために、KIP-113レジストリ契約はIKIP-113インターフェイスを実装して、BLS公開鍵、所有権証明情報などを登録および管理します。IKIP-113で定義されているBLS12 – 381公開鍵のBlsPublicKeyInfo構造には、2つの主要な要素が含まれています：

  • 公開鍵：:圧縮されたBLS12 – 381公開鍵。サイズは48バイト

  • PoP：Proof-of-Possessionの略で、サイズは96バイトです。これは、で指定されたPopProveアルゴリズムに起因する必要があります。（詳細：draft-irtf-cfrg-bls-signature-05のセクション3.3.3）

Proof-of-Possession（PoP）は、公開鍵を提出する参加者がその鍵に対応する秘密鍵を実際に所有していることを証明するためのメカニズムです。これは、攻撃者が悪意を持って操作された公開鍵をネットワークに注入することにより、グループの署名全体を危険に晒そうとするローグキー攻撃を防ぐ上で重要な役割を果たします。PoPはそのような攻撃を防ぐために公開鍵を検証する一方で、現在EIP-2537には存在しないため、この検証はオフチェーンで実行する必要があります。

KIP-114

一言で言えば、KIP-114は、検証可能な乱数の生成を可能にするために、ブロックヘッダーに2つの新しいフィールドを導入することを提案しています。

検証可能な乱数とは、人間の介入なしに信頼性を検証できる乱数です。イーサリアムビーコンチェーンでは、これはRANDAO方式でVRFを実装することによって計算されますが、KIP-114の場合、mixHashを実装して検証可能なランダムを生成することによって行われます。

これを達成するために、KIP-114はブロックヘッダーに2つの新しいフィールドを追加することを提案していま：randomRevealとmixHash。 randomRevealは提案者の署名です。KIP-113によって標準化されたBLS署名スキームを使用して生成されます。バリデータは、KIP-113 BLSレジストリのgetInfo（cnNodeId）関数を使用して、提案者の公開鍵と所有証明（pop）を取得できます。PoPを使用して提案者の公開鍵を検証し、randomRevealが提案者の正しい秘密鍵によって署名されていることを確認します。

mixHashは、前のブロックのmixHashで提案されているブロックのランダムなReveal値のkeccak256ハッシュをXORすることによって生成されます。前のブロックがFORK_BLOCKの場合、32バイトのゼロで構成されるmixHash値が後に続く必要があります。結果のmixHashは、検証可能で信頼できるランダム性のソースを提供します。このようにして、KIP-114はランダムで検証可能な偏見のないブロックチェーンのランダムな値となります。

これの特定の使用例の1つは、前のブロックが完了するまで非公開にしたいブロック提案者の場合です。または、次のように提出された次のブロック提案者—の選択に提案者が介入できないようにしたい場合
、KIP-146では、mixHashを使用して実装されたブロック支持者をランダムに選択するためのポリシーを提案します。

簡単な要約として、ここに再びプロセスがあります：

  1. ブロック提案者は、BLS署名スキームを使用してrandomRevealを生成します。この値は、提案者の固有の署名としてブロックヘッダーに含まれています。

  2. バリデータは、提案者の公開鍵を取得し、BLSレジストリからPoPします。

  3. バリデータは、PoPを使用して提案者の公開鍵を検証し、randomRevealが提案者の秘密鍵によって署名されていることを確認します。

  4. バリデータは、複数のrandomReveal値と前のブロックのmixHashを混合することにより、mixHashを計算します。

KIP-114は、上記のプロセス中に考慮しなければならないセキュリティの考慮事項も指定します。

  1. 攻撃再生不可：ブロック提案者が以前のブロックからrandomReveal値を再利用する攻撃を防ぐには、各ブロックで使用されるrandomReveal値が一意である必要があります。これにより、ブロック提案者が以前のランダムReveal値を再利用してmixHashを操作できなくなります。

  2. ブロック提案者の正直さ: 提案者は、独自のrandomRevealを正直に生成して送信する必要があります。提案者がrandomReveal値を操作する場合、結果のmixHash値も操作できます。したがって、提案者は、mixHashを操作せずにrandomRevealからmixHashを計算するために必要なすべての情報を正直に提供する必要があります。

  3. ブロック提案の前：提案者は、ブロック提案まで、ランダムReveal値を秘密にしておく必要があります。これにより、他の参加者が提案者のrandomReveal値を予測し、それを使用してmixHashを操作できなくなります。

  4. 検証：randomReveal値は、提案者の公開鍵によって署名され、バリデータによって検証される必要があります。これにより、提案者がrandomReveal値を操作または改ざんするのを防ぎます。

これでBoneh-Lynn-Shacham（BLS）署名スキームと、その独自の利点がイーサリアムコンセンサスレイヤーにとって最良の選択となった理由について、より深く理解していただければ幸いです。その結果、KIP-113およびKIP-114。この記事がKlaytnコア開発の現在の方向性を理解し、ブロックチェーンテクノロジーの全体的な開発と将来を理解するのに役立つことを願っています。

https://medium.com/klaytn/understanding-bls-signatures-kip-113-and-kip-114-141f5de7624d

参考：https://techblog.gaudiy.com/entry/2022/06/17/122714


いいなと思ったら応援しよう！