概要
Flare Networkは、基盤となるすべてのチェーンの状態を安全に解釈することを目的としています。他のネットワークでは、このために信頼できる第三者に頼るか、他のチェーンを自分たちの標準に適合させることを強要し、事実上、独立したチェーンのプロトコルを変更して通信を開始させています。対照的に、Flareでは、基盤となるチェーンのバリデーター以外を信頼する必要はなく、Flareは基盤となるチェーンのバリデーターにFlareの存在を意識させる必要もない。
ステートコネクターシステムにより、Flareは任意のブロックチェーンから任意のトランザクションの存在、有効性、順序を獲得することができます。他のネットワークからの資産を直接Flare上で表現するためのF-assetプロトコルを含め、Flare上のすべてのアプリケーションは、任意のチェーンからの任意のトランザクションに関するこれらの特性を証明する能力を自由に利用することができます。
目次
設計
状態コネクターシステムがどのように動作するかについての高レベルの前提は、その脅威モデルによって最もよく理解されます。基礎となるチェーンからFlare Networkアプリに不正な状態を吸収するために、攻撃者は以下を侵害する必要があります。
- 自分のFlareバリデータのチェーンに対する見解
- 他のFlare検証者の大多数のチェーンに対する見解
- Flare上のアプリが独自に必要とする基礎チェーンのブロック確認数よりも長く続く持続的な攻撃。
この脅威モデルは、コンセンサスにおいてどれだけ重要な役割を果たしているかに関わらず、Flare Networkの各バリデータに、統合されたすべての基礎チェーンの状態を独立して観察することを要求することで実現している。下層チェーンの状態に関する提案は、バリデータが提案された下層チェーンの状態を独立して検証した後にのみ、バリデータのローカルコピーであるFlare上のEthereum Virtual Machine (EVM)に適用される。
以下のセクションでは、ステート・コネクターの2段階の機構設計を定義します。第1段階では、Flareのバリデータが、現在利用可能な基礎チェーンからのデータのスパンに同意することを可能にし、第2段階では、基礎チェーンからのトランザクションの実際の証明を行う。
ステージ1：データ提供に関する合意
ある基礎チェーンの特定の取引がFlare上で証明される前に、まず、すべてのFlare検証者がグローバルに利用可能な基礎チェーンのブロックの範囲が合意される。誰もが、データ利用可能性証明トランザクションをFlareに提出することで、任意の基礎となるチェーンについて、このプロセスを長期的に維持することを競うことができます。証明の形式はシンプルで、入力として受け取るだけである。
- chainId: ChainId：現在選択されている基盤チェーンの数字による識別子。
- ledger: ledger: 現在利用可能であると提案されている基礎となるチェーンからの一連の ledger の最後の ledger インデックス。
- dataAvailabilityPeriodHash。dataAvailabilityPeriodHash: 基礎となるチェーンの元帳に指定されたハッシュの keccak256 ハッシュ。
- chainTipHash: chainTipHash：新たに作成された台帳のkeccak256ハッシュで、台帳よりも確認数が少ないもの。例えば、あるチェーンが 10 回の確認を必要とし、dataAvailabilityPeriodHash が ledger 100 に該当する場合、chainTipHash は ledger 110 に該当する。
function proveDataAvailabilityPeriodFinality(
uint32 chainId,
uint64 ledger,
bytes32 dataAvailabilityPeriodHash,
bytes32 chainTipHash
) external isInitialised chainExists(chainId) senderNotBanned returns (
uint32 _chainId,
uint64 _ledger,
uint16 _numConfirmations,
bytes32 _dataAvailabilityPeriodHash
)
データ有効性証明の検証
最初の実行可能性チェックは、標準的なEVMトランザクションコールである
st.evm.Call(from, to, data, gas, value)を使用して行われます。ただし、このコールは、EVMの状態を変更する実際の状態遷移コールとは別に、先行して実行されます。
// Check if this transaction pertains to a state connector transaction
if selectProveDataAvailabilityPeriodFinality || selectProvePaymentFinality || selectDisprovePaymentFinality {
// Increment the nonce for the next transaction
st.state.SetNonce(msg.From(), st.state.GetNonce(sender.Address())+1)
// Charge extra gas for state connector transactions beyond EVM gas use due to the additional golang computations
stateConnectorGas := st.gas / GetStateConnectorGasDivisor(st.evm.Context.Time)
// Check basic viability of the data availability proof
checkRet, _, checkVmerr := st.evm.Call(sender, st.to(), st.data, stateConnectorGas, st.value)
if checkVmerr == nil && binary.BigEndian.Uint32(checkRet[28:32]) < GetMaxAllowedChains(st.evm.Context.BlockNumber) {
// Basic viability test passed
// Verify the data availability proof by contacting your underlying chain validator
if StateConnectorCall(msg.From(), st.evm.Context.Time, st.data[0:4], checkRet) {
// Proof was verified
originalCoinbase := st.evm.Context.Coinbase
defer func() {
st.evm.Context.Coinbase = originalCoinbase
}()
// Create signal that proof has been verified
st.evm.Context.Coinbase = st.msg.From()
}
}
// The data availability proof is only permitted to transition EVM state
// in this call if st.evm.Context.Coinbase == st.msg.From()
ret, st.gas, vmerr = st.evm.Call(sender, st.to(), st.data, stateConnectorGas, st.value)
}
最初の実行可能性チェックの後、最初の proveDataAvailabilityPeriodFinality の呼び出しからゴランレベルで checkRet と checkVmerr という値が返されます。
checkRetには{_chainId, _ledger, _numConfirmations, _dataAvailabilityPeriodHash}が含まれ、checkVmerrは最初の生存率テストに合格した場合はnilとなります。これらの出力は、対応する名前の関数の入力を反映していますが、_numConfirmationsは例外で、入力されたChainIdに基づいてステート・コネクタのコントラクト・ストレージから取得されています。numConfirmationsの値は、基礎となるチェーン上のブロックが確定したと判断するためのコンセンサス確認数を表しています。これは主にプルーフ・オブ・ワークベースのチェーンに適用され、インスタント・ファイナリティ・チェーンでは最低でも1に設定されます。
次のステップでは、基礎となるチェーンのバリデータに、 Flareバリデータの立ち上げ時に指定したURLエンドポイントを介して 直接コンタクトします。checkRetの値は、dataAvailabilityPeriodHashが、現在検討されている基盤チェーンの元帳の正規フォーマットのkeccak256ハッシュと一致するかどうかを判断するために使用される。
このシステムは、基礎となるチェーンのバリデータが利用可能になるまで 情報を継続的に要求するための完全なエラー処理機能を備えており、要求が失敗した 場合のバックアップとして、複数の選択された基礎となるチェーンのバリデータを 許可している。このプロセスが完了するまでの時間に制限はないが、他の人がこの外部呼び出しのステップから戻ってきてEVMの状態に移行すると、Flare Networkはあなた抜きで継続することになる。
自分のバリデータのEVM状態が移行するのは、下層のチェインバリデータへのコールで dataAvailabilityPeriodHashの正しさに関する答えが返ってきたときだけです。つまり、下層のチェインバリデータが安全である限り、 どんな証明や量のFlareバリデータでも正しくない状態を強制することはできません。
先行するステップが戻り、成功していれば、EVM内のblock.coinbaseの値がmsg.senderの値に変更されます。
block.coinbaseの値は通常、ブロックチェーン上で、ブロックを採掘するリーダーとして成功した場合の報酬アドレスを定義するために使用されます。
しかし、Avalancheコンセンサスプロトコルはリーダー不在のプロトコルであるため、block.coinbaseの値は使用されず、通常は0x010000000000000000にハードコードされている。block.coinbaseを成功したデータ利用可能性証明送信者に変更するこのステップは、データ利用可能性証明トランザクションが検証されたことをstate connectorコントラクトに示すために使用される。
ステージ2：取引を証明する
基礎となるチェーンからのトランザクションを証明するプロセスは単純で、以下を提供する単一のトランザク ションを送信するだけである。
- {ChainId、dataAvailabilityPeriodIndex、dataAvailabilityPeriodHash} 支払いがデータ利用可能領域内に含まれていることを判断するためのもの。
- paymentHash。基礎となるチェーンペイメントの定期的にフォーマットされたハッシュ、元帳番号、ソースアカウント、デスティネーションアカウント、デスティネーションタグ、および送信金額のkeccak256ハッシュ。paymentHashの事前イメージは、EVMトランザクション内のこの段階では提供されない。
- txId: 基礎となるチェーンペイメントの定期的にフォーマットされたハッシュ。
データ利用可能性証明システムと同様の2段階のメカニズムで、基本的な実行可能性の事前チェックが行われ、最初に支払いがデータ利用可能領域内に存在することをチェックする。
基本テストに合格した場合、システムは基礎となるチェーンバリデータを呼び出し、その txId を使用して支払いの詳細を取得する。システムは、取得した支払いがデータ利用可能領域内に存在することを確認します。
取得された支払いの詳細は、paymentHashの形式に一致するkeccak256ハッシュを構築するための事前イメージとして使用されます。構築されたハッシュがpaymentHashの値と一致した場合、支払いは有効であるとみなされ、状態コネクタのコントラクトストレージに保存されます。これは、flare上の他のコントラクトが、paymentHashの事前イメージがflareにファイナライズされたことを確認したい場合に参照するためです。
また、基礎となるチェーン上の特定のブロックの高さによって、支払いが発生していないことを証明することもできます。
https://gitlab.com/flarenetwork/flare#verify-an-underlying-chain-payment-on-flare
単純な支払確認（SPV）の証明は有害であると考えられる
単純支払い検証（SPV）証明とは、あるブロックチェーンに対して、他のブロックチェーンで支払いが発生したことを証明する方法です。
この証明は通常、プルーフ・オブ・ワークなどのコンセンサス証明や、現在検討されている基礎的なチェーンを管理していると考えられる一連の検証者の署名入りk-of-nマルチシグネチャを含むヘッダーで構成されています。SPVの証明自体は、提供された支払いが、提供されたメルクルツリーに含まれるハッシュの事前イメージを形成していることを証明する、メルクルツリーに基づくハッシュのセットを含んでいるだけである。
ブロックチェーンの主な利点の1つは、トランザクションの順序を決める際のタイブレーカーとしての役割以外に、バリデータに依存しないことである。
つまり、ブロックチェーン上のバリデーターは、全員が同意して実行する状態遷移ルールに適合しない誤ったトランザクションをネットワークに挿入することはできない。例えば、ブロックチェーン上の採掘者として、自分に属さない1枚のコインの移動を強制することはできません。そのためには、ネットワークの生成状態までさかのぼって所有権の移転履歴が確認できるような有効な取引に署名するしかありません。
しかし、SPVの証明はこの三権分立の保証を破るものである。つまり、バリデータが自己言及的でネットワークの生成時には結びつかない孤立したMerkle treeの証明を提出することを許可するものである。
例えば、検証者が結託して偽のSPV証明を作成した場合、実際にはそのような金額を所有したことがないのに、10億単位の資産を送る取引があったと別のブロックチェーンに信じ込ませることができます。
SPV証明は、プルーフ・オブ・ワークではないチェーンでは、時間の経過とともに変化するバリデーターセットを追跡しなければならないため、複雑になります。
あるチェーンから退出したバリデーターセットが、Flareへの証明に署名することを拒否するというシナリオを考えてみよう。このような場合、どのようなペナルティがあるのだろうか?
このような方法でバリデータセットを管理しようとすると、 悪い行為を行ったのと同じオペレータセットが悪い行為を行うことになってしまう。
したがって、SPVの証明は、基礎となるチェーンの状態を他のネットワークに証明する目的では有害であると考えられる。
このアプローチは、資産の所有権を偽装できるようにするために、基礎となるチェーンのバリデータの権限を拡大するものであり、このアプローチにおける悪行の実行は、悪行を実行したのと同じ事業者の集合によって行われなければならない。
ステートコネクターシステムの利点
ステートコネクターシステムは、スマートコントラクトに対して基礎となるチェーンの状態を証明するための競争力のあるアプローチであり、以下のような利点があります。
- トランザクションの有効性は、基礎となるチェーンのジェネシス・ブロックにさかのぼって参照する。SPV証明のような他のアプローチは、トランザクションの有効性をチェックしません。
- 安全性は基本チェーンのバリデータにのみ依存する。経済的なインセンティブやリスクを持つ、信頼できるサードパーティのサービスは存在しない。安全性が失われるのは、チェーンのバリデータがビザンチンフォルトに陥った場合のみであるという保証を活用することで、信頼を最小限に抑えることができる。
- 基礎となるチェーンのバリデータの協力は不要である。あるチェーンのバリデータは、Flareがネットワークを解釈できるようにチェーンのコードベースを変更する必要はない。また、ステート・コネクタ・システムを動作させるために、チェーンのバリデーターがFlareの存在を意識する必要もありません。
- あらゆるブロックチェーンの状態を読み取ることができる。ステートコネクターは、基礎となるチェーンが持つ、可能な限りのSybil抵抗技術を操作することができます。例えば、プルーフ・オブ・ワーク、プルーフ・オブ・ステーク、さらにはネットワークをコントロールするバリデーターのセットについてグローバルな合意がない場合のフェデレーション・ビザンティン合意などが挙げられます。
- Flareのスマートコントラクトでは、基礎となるチェーンを管理する現在のバリデーターをエンコードしない。SPV証明のような他の状態中継アプローチのこの要件は、状態を中継する際の悪行の実施が、悪行を行った事業者の同じセットによって行われる必要があるという危険なシナリオにつながります。
- 一定サイズの証明：データ利用可能性の証明と支払いの証明は、考慮されるデータ利用可能期間中の他の支払いの数に依存せず、一定サイズである。
- すべてのFlareバリデータは、チェーンの状態を独立して検証する。自身のFlareバリデータがあるチェーンの正規の状態を観測していれば、そのチェーンに対する安全性が失われることはない。