BLSシグネチャは、イーサリアムのコンセンサスからEigenLayerまで、いたるところにあります。しかし、使い方を間違えるのは簡単です。 BLS署名とは何ですか?それらを使用する正しい方法と間違った方法について話しましょう。

しかし、最初に、BLS署名とは何ですか? BLS 署名は、ECDSA のようにメッセージの署名に使用される暗号化プリミティブです。 計算の仕組みは次のとおりです。これは、楕円曲線の組み合わせの上に構築されています。 しかし、何が彼らをそんなに特別なものにしているのでしょうか?なぜこれらの派手な組み合わせを使用するのですか?

BLSのキラー機能:署名集約。 多数の BLS 署名を 1 つの署名に組み合わせることができます。これにより、N個の署名を一度に送信して確認することができ、スペースと時間効率が向上します。また、オンチェーンでは、ガスの節約には最適化が非常に重要です。

BLS署名の仕組みと、集約とマルチ署名の構築プロセスの詳細については、このスレッドの最後にリンクされている完全なブログ記事をご覧ください。 それでは、BLSシグネチャがどのように間違っているか、そしてEigenLayerがそれらをどのように使用するかを見てみましょう(適切に、これらの落とし穴を回避します)!

EigenLayerは、イーサリアムのリステーキングレイヤーです。EigenLayer AVSでは、バリデーターは検証計算の結果に署名します。 アグリゲーターは、これらすべての署名を収集し、チェーンにプッシュします。集約された署名は、チェーン上で検証されます。

タスクには、タスクが作成されたときのブロック番号と、タスクの検証に必要なオペレーター検証の割合を示すしきい値が含まれています。 AVS にオプトインしたオペレーターは、それらのタスクにタスクの回答を計算させ、オペレーターはタスクの BLS 署名を含む回答をアグリゲーターに送信できます。 同一回答のしきい値に達するとすぐに、アグリゲーターはすべての BLS 署名を一意の集約署名にマージし、AVS コントラクトに送り返します。 コントラクトは、署名が正しいことを確認し、チャレンジャーが検証が間違っていたことを証明できるチャレンジ期間を開き、そうであれば、不正行為をしたオペレーターはスラッシュされます。

コントラクトでは、検証は「trySignatureAndApkVerification」関数で行われます。

ただし、マルチシグネチャは、誤って使用すると、ローグキー攻撃と呼ばれる深刻な問題が伴います。 正直なユーザーが公開鍵「pk_0」を持っているとしましょう。以前に「pk_0」を見た攻撃者は、pk_1 = sk_1⋅G_1—pk_0 として公開鍵を選択できます。 攻撃者は、公開キーに関連付けられた秘密キーを知りません。ただし、マルチ署名検証では、次のようになります。

メッセージに署名するために必要なのは 'sk_1' だけで、最初のユーザーが署名していなくても、有効なマルチ署名になります。 これは、不正なキーを選択することで、正直なユーザーの任意の数の「r」に簡単に一般化できます。

前のAVSの例では、以前に不正なキーを登録していた悪意のあるアグリゲーターが、バリデーターによって署名されていない集計署名を送信しても、コントラクトによって受け入れられる可能性があるため、これは危険な脅威です。 これは、バリデーターが不正行為をしなくてもスラッシュされることにつながります。

したがって、不正なキー攻撃を防ぐために、一般的な方法は、秘密鍵が自分の公開鍵と一致することを知っていることを証明するようにユーザーに要求することです(所有の証明と呼ばれます)。 したがって、最初の登録手順では、ユーザーは、次のような所有πと共に公開鍵を登録するように求められます。

基本的に、ユーザーは公開鍵またはその他の識別メッセージに署名するよう求められます。AVS では、メッセージはオペレーターのアドレスです。 EigenLayerコントラクトでは、所有の証明は「registerBLSPublicKey」関数によって検証されます。

関数 'pubkeyRegistrationMessageHash' は、カスタム ドメイン セパレーター 'PUBKEY_REGISTRATION_TYPEHASH' とオペレーター アドレスをハッシュするために使用されます。

登録後、公開鍵が契約に追加されます。その値を確認するには、「getRegisteredPubkey」関数を呼び出します。 以下は、EigenDA AVS に登録された BLS 公開鍵の例です。

所持の証明は基本的にBLSの署名です。ただし、所有証明のステップでマルチシグを使用することもお勧めできません (たとえば、1 人の参加者に対して複数の公開キーを登録する場合など)。 その場合、参加者はスプリッティングゼロ攻撃を達成します。この場合、参加者は、合計するとキャンセルされ、所有の証明をバイパスできるキーを登録できます。

BLSマルチシグは、大きな最適化の機会を提供することがわかりました。 EigenLayerの実装は、BLSシグネチャの力を実証し、その実際の展開に伴う複雑さも強調しています。ただし、マルチシグはローグキー攻撃などのセキュリティリスクをもたらすため、所有証明などの保護手段が必要になります。 しかし、Pectra のアップグレードが BLS12-381 をサポートすることで、Solidity にさらなる実装と改善が見られる可能性があるため、この投稿が既知の実装バグや脆弱性を回避するのに役立つことを願っています。

BLSシグネチャ、ビルディングアグリゲーション、マルチシグネチャの詳細については、以下の最近公開されたブログ記事をご覧ください。