文：Sergio Demian Lerner（RSK Chief Innovation Scientist）

完全分散型およびトラストレスにブロックチェーンを構築するのはブロックの困難な研究対象の1つです。IOV Labsでは、2016年に、RSKとBitcoin のペグ比1:1 を3年間にわたって実現することとなった、初のソリッドのfederated ブリッジを創造しました。現在、私たちはRSK とEtherium の完全分散型ブリッジに取り組んでいます。この投稿記事では、この新しいブリッジ、ならびに動力源である基本的な分散型プロトコルの技術的詳細を紹介します。

はじめに

ブロックチェーン間のトークン移動方法を理解するために、最初によく使われる用語と歴史を振り返ってみましょう。双方向ペグ（two-way peg）（および1:1 ペグ）とは2つの別個のブロックチェーンに存在する2つのトークンを経済的に同等にしようとするシステムのことです。一方の要求が高まると、双方向ペグはトークンが反対側から流れ込むのを許容することから、価格等価が保たれます。2013年、まだそうしたシステムが考案される前のことですが、将来的には、Bitcoin が双方向ペグでメインのチェーンに接続されたいくつかのサテライト・サイドチェーンを有することになることが着想されていました。サイドチェーンは、ネイティブアセットがforeign であることからトランザクション手数料がこのforeign アセットで支払われるような別個のブロックチェーンと考えられます。内部のコイン発行を伴わないため、ブロックはサイドチェーンのマイナーに補助金を支払う必要がありません。しかし、実証済みの双方向ペグの設計が欠落していると、サイドチェーンの用語の定義が不明瞭となります。2014年、ステートレスのUTXO ベースのソリューションがBlockstream によって企図されました。その設計は本来のElementsサイドチェーンで実施されていましたが、このアプローチは後になって、固有のセキュリティおよび検閲の問題を理由に断念され、Elements はFederated ペグへと転換を図り、Liquidサイドチェーンになりました。したがってサイドチェーンという用語は1:1 ペグを維持するアセットの移転を実行する実際の通信システムを決定しません。マルチトークンのブロックチェーンの台頭に伴い、双方向ペグを管理する相互運用性システムがトークンブリッジ（token bridge）になったのです。トークンブリッジは、いずれも相手方のサイドチェーンではない2つの任意のブロックチェーンを結合させることができます。独立したブロックチェーンを結合するトークンブリッジとコラテラルとして利用可能で不正行為にて破棄されうる独立したコインの利用可能性に関してサイドチェーンに同局供給するトークンブリッジとの間には重要なcryptoeconomic 上の相違があるものの、この記事では詳しく取り上げません。 

最初のリリース可能なトークンブリッジは2017年に実装されたRSK サイドチェーンに埋め込まれて展開されました。RSK ブリッジはハイブリッド型で、Bitcoin からRSK への方向は完全にステートフルのSPV ベースであり、すなわち、分散化と検閲への耐性（ネットワークを潰すことが実質不可能）という望ましい特性を実現しつつ、RSK からBitcoin への方向がfederated されています。Bitcoin はRSK コンセンサスを検証することができないため、RSK からBitcoin へのbitcoin 移転にあたっての分散型の検閲への耐性のソリューションを実施することができず、全二重実行が不可能です。しかし、以下のダイアグラムに表示されている現行のRSK-Bitcoin ペグは考えられる最良のソリューションの1つを構成します。

RSK ハイブリッドFederated-SPV 双方向ペグ（RSK Hybrid Federated-SPV Two Way Peg）

RSK-Bitcoin ブリッジはハッキングされたことがなく、100% アップタイムという実績を誇ります。RSK-Bitcoin ブリッジは自律型のハードウェア・セキュリティ・モジュール（Hardware Security Modules：HSM）を用いて大規模なマルチシグのプライベートキーを保護します。HSM は時間経過とともに進化し、新世代のRSK HSMs がチェーンのPoW（プルーフ・オブ・ワーク）を検証することで最長のチェーンと同期します。結果、federation 機能性の大部分でさえペグ・トランザクションについて不正を働いたり、検閲することができません。ただし、federated ブリッジには欠点があり、つまり、依然、HSM を起動させ、ネットワークに効果的に接続するうえで必要な小規模のエンティティ群に依存し、同時に、秘密の通信路、偏った乱数生成またはバックドアを導入しないためにHSM を生産する会社の誠実性に依拠することです。新しい分散型プロトコルの世界では、federated ブリッジは、より優れた分散型システムが交換対象として構築されるまでの間に存在するに過ぎません。2つのブロックチェーンを結ぶ真にセキュアな分散型ブリッジは簡潔に相手方のコンセンサスを検証する各ブロックチェーンを依拠する必要があります。

SPV Light クライアントとのトークンブリッジの構築（Building a Token Bridge with SPV Light-clients） 

SPV クライアントは軽量なシステムであり、考えられる多くの候補から誠実で最良のチェーンを発見するために、高度なcryptoeconomic セキュリティにて、累積PoW の簡潔なプルーフを受諾します。SPV light クライアントは2つのPoW ベースのブロックチェーンをつなぐスマートコントラクトベースのブリッジの構築に理想的です。しかしながら、標準SPV クライアントには、とりわけ高いブロックレートを伴うブロックチェーンの場合、多くの制約があります。RSK は高いブロックレート（30秒ごとに約1）を誇りますが、すなわち、完全クロスチェーン・ヘッダー限定検証が空間と検証時間の双方の点で高価となっています。より高いブロックレートおよび相当に重いPoW 検証を理由に、Ethereum はこの点でもっと深刻です。以下のダイアグラムには、クロスチェーン・ヘッダー限定コンセンサス検証に基づく仮想分散型ブリッジが示されています。各ブロックチェーンはSPV モードで相手方ブロックチェーンの最良のチェーンの表出を維持します。

仮説ステートフルSPV ブリッジ

2015年当時、ブロックヘッダーのチャレンジ・レスポンス・インタラクティブゲームに基づくショートのSPV プルーフを創造する方法が一般認知されていました。こうしたゲームはFiat-Shamir トランスフォーメーション（後に非インタラクティブPoW（Non-Interactive Proofs of Proof of Work）またはNiPoPoWsと呼ばれるようになりました）を用いて非インタラクティブに変換可能です。その概念とは、証明者がブロックチェーンにコミットし、チャレンジャーがブロックヘッダーの数を証明者に尋ねる（証明者は、明かされたブロックが同じ結合されたブロックチェーンに属することを示す情報とともに教える必要があります）というものです。ただし、2017年になるまで可変難易度（variable-difficulty）のプルーフ作成方法は明らかになりませんでした。2017年、FlyClientプロトコルが登場し、ついにこの問題が解決されました。FlyClient はブロックインデックス選択機能を、難易度の変化に適合させることができます。さらに、FlyClient は様々なプルーフサイズに適合させ、クライアントのセキュリティニーズに応じて多彩な不正確率バウンド（cheating probability bound）を提供することができます。

FlyClient 非インタラクティブ・プロトコル（FlyClient Non-Interactive Protocol）（簡易）

しかし、FlyClient を既存のブロックチェーンに適用するのはコンセンサスの変化なくして不可能だと考えられますが、すなわち、FlyClient はブロックヘッダーの全ての従前ブロックハッシュに対する定期的なコミットメントを要求するからです。コミットメントはツリー形式（拡張型MMR と呼ばれます）に整理されていて、累積のPoW  およびタイムスタンプがMMR ツリーの中間ノードに保管されています。

2019年、私たちはRSK とEthereum をどのように結合させるか調査を開始しました。私たちはコンセンサスを変更することなく、Ethreum のFlyClient を有効にする方法を模索し、FlyClient を拡張してこれを成就し、依然として簡易プルーフを使用する方法を発見しました。この発見はHawkClient と呼ぶものに発展しましたが、これはCryptoeconomic インタラクティブPoW（CIPoPoW）と呼ばれる新たなカテゴリーのプロトコルに属します。HawkClient プロトコルはRSK、Ethereum、Ethereum-Classic などのあらゆるEVM ベースのスマートコントラクトに作用します。言うまでもなく、ブロックチェーンがMMR ツリーのコミットメントをネイティブに実行すると、プロトコルは大いに簡素化されます。

HawkClient の提示（Presenting HawkClient）

簡潔に言うと、HawkClient はforeign「リモート」ブロックチェーンに同期される1つの「ホスト」ブロックチェーンにスマートコントラクトを維持するインタラクティブの分散型スマートコントラクト・システムで、明示的な貨幣価値を持った情報の移転を可能にします。2つのブロックチェーン間で鏡で反射させるように実行される2つのHawkClient システムは分散型トークンブリッジの基盤となり、特定のブロックチェーンから別のブロックチェーンへのトークンの移転を可能にします。

鏡で映し出された2つのHawkClient システムに基づくトークンブリッジ

私たちは、トークンの移転が価額面で制約を課され、トークンは明示的なトークン数量を伴う移転にあたって既知の市場変動に晒されることから、任意のトークンを移転することができます。このことはcryptographic レベルのセキュリティの必要性を撤廃し、ブリッジがcryptoeconomic モデルのセキュリティに基づいて作動するのを可能にしてプルーフのサイズを低減します。このcryptoeconomic モデルでは、移転はバッチされ、セキュリティボンドで保護されています。

簡素型のHawkClient システムは4つの役割に基づいており、つまり、証明者、認証者、Approximate Merkle Mountain Range（AMMR）Updater またはAMMR-Updater（後ほど詳述します）およびユーザーです。1人の証明者がリモートのブロックチェーンの最良チェーンにコミットし、コミットメントを認証者に提出します。その跡、認証者はチャレンジを用意し、証明者が最良チェーンの選択されたヘッダーのサブセットおよび結合や連鎖のプルーフを包含するHawkClient プルーフを創造します。読み出されるブロックヘッダーのサブセットは、チャレンジに由来するシードを持つ疑似乱数生成装置に基づいて、累加的な難易度空間をサンプリングして選択されます。トークンブリッジの場合、全体のプロセスは日に1回程度、繰り返されます。

認証者はHawkClient プルーフを認証するホストのブロックチェーンにて実行されるスマートコントラクトで、プルーフを用いてリモートのブロックチェーンの拡張と維持を行います。認証者はブロックチェーンSPV ノードに類似していますが、コンセンサスで起動しています。これこそ、本質的にRSK およびbtcrelayが行うことです。認証者は他の証明者が、チャレンジ期間中にプルーフの正当性を疑う、あるいは代替のプルーフを提示するのを可能にし、その後、最も高い累加PoW のプルーフを受諾します。しかしながら、btcrelay モデルから逸脱して認証者が証明者との間でチャレンジ・レスポンスを実行することから、通常のトランザクション検閲攻撃は阻止されます。ユーザーはホストおよびリモートのブロックチェーンの双方と相関し、そういった相関が受領証に記録されるリモートのブロックチェーンにイベントを生成します。そういったイベントは証明者によって後々、ホストのブロックチェーンに周知されます。ホストのブロックチェーンのスマートコントラクトは周知されたイベントを知覚してそれらと相関します。 

RSK-Ethereum ブリッジ（RSK-Ethereum Bridge）

RSK-ETH ブリッジはRSK をEthereum に結合し、2つのブロックチェーン間のERC-20 の移転を可能にします。現在、IOV Labs によって積極的に開発されています。ブリッジはHawkClients を基盤としています。加えて、ブリッジはユニークな特性群にて設計されています。例えば、特定規模のプルーフを提供する承認と引き換えに、証明者がコミットしようとしているセキュリティボンドの貨幣上の価値を選択するのを可能にし、不正が常に負けの戦略であることを徹底します。例えば、証明者は認証者によって実行されたより多くのクエリに応答するのを申し出てセキュリティボンドを低減させつつプルーフの規模を大きくすることができます。トランザクション手数料が高い場合、証明者はセキュリティボンドを増やしてプルーフの規模とトランザクション手数料を引き下げることができます。不正が検出されるとボンドが悪影響を被ることから、不正は決して合理的な戦術ではなく、cryptoeconomic セキュリティは保証されています。さらに、HawkClient はコミットメントのオンチェーン化およびチャレンジが以降のブロックハッシュに由来するのを強制することから、攻撃者はオフラインで何百万もの多様なコミットメントの攻撃を試行することができません。攻撃者が関与するブロックチェーンのハッシュレートの50% 未満しかコントロールできないという前提では、攻撃者はせいぜい1つのコミットメントの攻撃を実行できるに過ぎません。言い換えれば、システムがインタラクティブであることから、攻撃者はオフラインで容易にコミットメントを力任せに攻撃して都合の良いチャレンジを手に入れることはできません。例えば、私たちが100万分の1という不正確率という限界を設けていれば、不正の企図に対する巨大な阻害要因を設定することができます。通常は暗号化セキュリティ低下につながるこうした不正の確率は、極めて高度なcryptoeconomic セキュリティにつながります。最後に、ブリッジは、ネイティブのコインと対照的に、既存のトークン価格に設けられている上限を発見する予言として作用する特殊な簡素型トークン市場を使用します。この市場には売買にあたって大きな遅延（最長で数週間ほど）が伴い、トークン価格の不正行為が企図されない限り、実際のトレードではこの市場は利用されないでしょう。こうした予言システムを備えることで、私たちはトークンではなくネイティブ通貨でセキュリティボンドを実行でき、トークンの預け入れを要求することなく、複数の証明者に対応することができます。

Etherem からRSK への情報伝達にあたってのHawkClient システム

RSK-Eth ブリッジのもう1つの興味深い特性とは、セキュリティボンドにコミットする意思がある限り、誰もが証明者になれることです。さらに、私たちは特殊なオペコードの必要なしに、ETHash プルーフを認証する非常に効率的な手法を開発してきました。次回のブログ投稿記事で詳しく取り上げます。

HawkClient プルーフの重要な特性（Key Features of a HawkClient Proof）

以降のセクションでは、HawkClient プルーフの主な特徴、とりわけ、分散型ブリッジの創造を可能にするためにどのように相関するのかについて説明します。

インタラクティブなプルーフ（Interactive Proofs）

HawkClient プルーフはインタラクティブです。プロトコルには1人以上の証明者が伴います。また、各証明者は他の証明者の潜在的な偽のプルーフの正当性を疑う役割を担います。証明者はプルーフおよび特殊なスマートコントラクトにコミットし、HawkClient 認証者と呼ばれる人がクエリ群が由来するチャレンジ・シードを選択します。そして、証明者はこうしたクエリに応答する必要があり、その後、クエリは認証を行う認証者のスマートコントラクトに送り返されます。  この最初のステージを経て、残りのユーザーはさらなる信憑性を提供させるべく証明者の正当性を疑ったり、あるいは自らが証明者になってさらなる累積的な難度を伴うブロックチェーンのプルーフを提出して1つ前のものを無効にすることができます。

Cryptoecomic プルーフ（Cryptoeconomic Proofs）

HawkClient プルーフはcryptoeconomic で、すなわち、攻撃者が不正を成功させる、一定の、軽視することのできない確率が存在します。攻撃を回避するために、プロトコルが「セキュリティボンド」として証明者にコインを事前に預け入れらるよう強制し、結果、不正にあたって攻撃者にとって見込まれる見返りは、正直に行動している場合の見返りよりも小さくなります。ブリッジはトークン価格を設定する自律型の予言として作動するサブシステムを提供します。

ブリッジが1日あたりに移転することのできる金額は制限されています。なぜなら、PoW ベースのブロックチェーンが二重支払攻撃のリスクに晒されているからです。攻撃者は、ブリッジを欺こうと、24時間でリモートのブロックチェーンのハッシュレートの51% を賃貸するのに相当する費用を被る可能性があります。したがって、現状で賃貸可能な十分なマイニング・ハードウェアが存在するという前提から、ブリッジが時間的期間あたりに移転可能な金額に上限が設定されています。以下の表には、2020年1月時点での、様々なブロックチェーンにて24時間という期間で持続する51% の攻撃に相当する概算の電気代が示されています。

ブロックチェーン（Blockchain）	コスト（USD）
Bitcoin	12M
Ethereum	1.1M
RSK	6M

仮想通貨の価格は頻繁に変動することから、ブリッジは十分な規模のセキュリティマージンでパラメータ化される必要があります。例えば、RSK-ETH ブリッジが1日あたりにEthereum からRSK 移転させることのできる価額は600K USD、その逆だと3M USD です。 

このことはリスクモデルの簡素化に過ぎませんが、特定される攻撃には全て、（リモートのブロックチェーンの難易度に関連する）HawkClient プルーフおよび認証者のブロックチェーンの難易度の累積難易度と直線的に成長するコストがあります。

斬新的なプルーフ（Gradual Proofs）

外的インプットを検証する必要のある2つの極値がスマートコントラクトのプロトコルに存在します。一方では、セキュリティがオンチェーンのレイヤーの利用可能性と検閲への耐性に完全依存している「怠惰な」、あるいは「楽観的な」プロトコルが存在します。楽観的なプロトコルでは、証明者はステートメントを断定し、スマートコントラクトのレイヤーは、不正証明にてチャレンジが断定に変わるのを待ちます。これらのプロトコルは「アサート・チャレンジ（assert-challenge）」のデザインパターンで作動します。ステートメントは、一定期間にわたって不変の場合、真実であると仮定されます。スマートコントラクトは自らは認証を実施しないことから、怠惰であると考えられています。このモデルはTrueBit、そして、その後、Arbitrumによって採用されました。もう1つの極値についてですが、「強力な」プロトコルが1つ1つの外的アサーションを検証し、チャレンジの必要はなく、一部ながら、zk-SNARKs 等の強大なProofs of Computation Integrity を使用します。怠惰なプロトコルには、トランザクションの検閲やマイナーの通牒を奨励するという欠点があります。怠惰なプロトコルは、私たちがトランザクション検閲攻撃の対価を見積もれば、cryptoeconomical に安全であることを実証できます。しかし、検閲は、実行にあたっての費用は安価ながらも証明が困難という理由で、これは気が遠くなるような作業で、一般として、特定のマイナーに帰属させるのは不可能です。マイナーは自身の評判や名声を危機に晒しますが、外部のオブザーバーにとって見極めるのは困難です。 

強力なプロトコルの唯一の欠点とは、実行リソース（ガス）の面で費用がかさむことであり、このコストはプロトコルのユーザー間で分担されるべきです。これらの中間が漸増的プロトコル（gradual protocols）です。  漸増的プロトコルはアサーションから始まり、続いて認証コントラクトが一定の確率的検証を実行して初期の必然性を認識します。その後、他のユーザーがプルーフの正当性への疑義、認証者へのいっそうの必然性の提供の要請、別の競合するプルーフの提供、もしくはプルーフが受諾されるまでの待機のいずれかを行うことができます。最初のプルーフが2番目に競争力のあるプルーフによって正当性が疑われると、1人目の承認者には、さらなる累積PoW を証明して最良のチェーンを巡る争いに勝利する機会が与えられます。表示する累積PoW を他に持たない追加のプルーフは、証明者の1人が諦めるまで、続くことができます。最終に、正当性を疑われないプルーフが最良チェーンとして選ばれます。

FlyClient に楽観的、強力および漸増的（Optimistic, Strong and Gradual for FlyClient）

攻撃の構成可能性など、他の不明瞭なコストも存在するプロトコルの場合：攻撃者がいくつかの無関係のシステムに不正を働くために1つのプルーフを使用するとどうなるか?セキュリティを証明することには、不正に利益を得ることのできるあらゆるシステムを認識することが必要です。

持続性の散発性MMR コミットメント

リモートのブロックチェーンがFlyClient をネイティブにサポートしない場合、HawkClient はAMMR Updater と呼ばれる一定のスマートコントラクトのストレージ内にMMR コミットメントを検索することができます。このコントラクトはBLOCKHASH オペコードを使って過去のブロックハッシュを収集し、最新のツリーを構築します。AMMR とはApproximate Merkle Mountain Range のことです。このツリーには実際の累積難易度と時間価値についての上限が組み込まれています。AMMR コミットメントはブロックごとに更新する必要はありません。私たちは、各N が、AMMR Updater コントラクトへの外部呼び出しにて、平均してブロックするたびに更新されていると仮定しています。各N が平均してブロックすると、ブロック時間は正確に判明します（ブロック時間には、BLOCKTIME オペコードを使ってアクセスできます）が、中間ブロックのブロック時間はコントラクトによって未知です。Ethereum コントラクトは正確な累積難易度を認知しないことから、そういったオペコードは存在しません。したがって、AMMR Updater コントラクトは、呼び出されると、累積難易度の限度を算定する必要があります。プロトコルは、累積難易度が常に百分率誤差範囲内であるのを約束します。誤り限界の存在ですが、ブロックの難易度がAMMR アップデート間で大きく変動することはあり得ないので、正当化されています。では、ブロック難易度がブロック間の因数+-1/2048 によって変動しうるEthereum について考えてみましょう。最大256ブロックの距離でAMMR 更新を受諾することですが、ブロック難易度が最大6.65% の上限することが考えられると示唆されます（最大/ 最小ポイント、ブロック128周辺）。しかし、AAMR Updater が難易度オペコードを使ってこれを検証することから、最終ブロックで本当のブロック難易度に到達する必要があります。したがって、AMMR Updater は既存ブロック内の累積難易度の上限を算定することができます。最悪のケースでは、前の256のブロック内に更新が発生せず、ブロック難易度が直近の更新から変化しなかった場合、この限界は実際のブロックチェーン累積難易度における最大3.2% の上下に相当します。よって、本当の難易度がスマートコントラクトに隠れていたとしても、実際の難易度を実に正確に辿り得るのです。また、検出されることなく難易度を変更するには、256のブロックは攻撃者によって採掘されるか、あるいは攻撃者が256のブロックヘッダーを受領しないよう管理することが不可欠になります。

AMMR ツリーは正確な累積難易度値を保管しないため、多くのAMMR Updates を包含するプルーフを提示する際、連続したブロックの累積難易度限界は重複します。すなわち、攻撃者は、特定の累積難易度x によってブロックの指標化へのクエリで正当性を疑われる場合、この曖昧さを用いて、x を含む難易度の限界を持つ複数の隣接するブロックから1つを選択すると考えられます。したがって、攻撃者は重複しないインターバルごとにブロックを1つだけ採掘して必要な作業量を縮減することが可能です。こうした攻撃を防ぐには、証明者はまた、2つ目のMerkle ツリーである、ブロックごとの正確な累積難易度と時間を包含するExact Merkle Mountain Tree（EMMR）にコミットする必要があります。このツリーはそれぞれの中間ノードにて累積難易度および累積時間で増大します。そして、AMMR ノードで実行された本来の機能および認証はこうした2本のツリーに分断されます。各クエリについて、証明者はAMMR ブランチおよびEMMR ブランチを示す必要があります。EMMR ブラントは特定の累積コミットメントでブロック番号を特定するのに用いられ、AMMR ツリーは、このブロック番号を探すために横切られます。その際、累積難易度および累積時間の難易度限界が照合されます。以下のダイアグラムは、累積難易度が0から始まる仮想のブロックチェーンを示しますが、各ブロックの難易度は不変で10とします。コンセンサスにより、難易度は各ブロックで10% 上下する可能性があります。8つのブロックの後、本当の累積難易度（80）が、各中間ブロックの実際の難易度を認知せずに達成された可能性のある最小および最大の累積難易度から分岐します。最終ブロックの難易度だけが既知です。緑色の各ボックスは最小および最大の累積難易度を示します。プルーフの検証中、EMMR ツリーはブロックの特定のために使用され、AMMR ツリー内のブランチがブロック番号で検索されます。各ステップにて、正確な範囲が限界範囲によって包含されているか検証されます。

Exact およびApproximat Merkle Mountain Range Trees（Exact and Approximate Merkle Mountain Range Trees）

HawkClient と相関するシステムは全てAMMR Updater コントラクトのアドレスを認知しておく必要があります。誰でも、AMMR Updater コントラクトを創造するトランザクションを精査して展開コードを検証することができます。しかし、微妙な攻撃が存在します。AMMR Updater の創造者は、ブロックヘッダー構造とPoW を共有する、先に分岐済みの別のブロックチェーンに同一のアドレスを持った相似するコントラクトを創造することができます。このブロックチェーンでは、コントラクトは異なるVM バイトコードで展開可能です。この攻撃を防ぐためには、MMR Updater コントラクトはCREATE2 で展開される必要があり、CHAINID オペコード（EIP-1344）を用い、構築中にターゲット・プラットフォーム上で実行しているかどうかを検証し、実行していない場合には構築を中止する必要があります。このオペコードはEthereum のイスタンブール・ハードフォーク以降、利用可能です。

サマリ

IOV Labs では、私たちはメインのPoW ブロックチェーンを結合する分散型ブリッジに取り組んでいます。このブリッジのコアはFlyClient の延長であるHawkClient プロトコルです。FlyClient とHawkClient にはいくつかの相違点があります。HawkClient では、

• プルーフはインタラクティブです
• プルーフのセキュリティはcryptoeconomic であって暗号化されていません
• システムはセキュリティボンドを要求します。双方向ブリッジ向けに使用される場合、ネイティブ通貨とトークンの双方でのセキュリティボンドが必要になると考えられます
• プルーフは漸増的です
• AMMR コミットメントは散発性ながら持続的で、ブロックチェーンのコンセンサスを変更する必要がありません
• また、証明者は正確な累積時間を包含する2番目のEMMR ツリーにコミットします。このツリーはコンセンサスで生成される必要がありません。 
• プルーフには1人以上の証明者および1人のスマートコントラクト認証者が伴います。証明者とスマートコントラクトの双方はチャレンジャーになることが可能です。
• 最良のチェーンは単調に増加し、不変です
• 最良のチェーンの成長が遅延します（実証されたチップから最良チェーンチップまでの待ち時間）

2つのブロックチェーン間で鏡で映し出されるように実行される2つのHawkClient システムがRSK-ETH ブリッジの基盤を形成します。ブリッジは現状、開発段階で、間もなくRSK テストネットで展開日をお知らせしますが、同時に、ソースコードをコミュニティにリリースし、ウォレットやスマートコントラクトから使用する方法についての全詳細をお届けします。私たちは初の真に分散型のcryptoeconomic ブリッジに取り組んでいることを非常に嬉しく感じており、RSK-ETH ブリッジがあらゆるブロックチェーンにとってのコミュニティの屋台骨の構築における最初のステップとなり、全てのEVM 互換ブロックチェーン・トークンがRSK 経由でDeFi on Bitcoin アプリケーションに利用可能となることに興奮を隠せずにいます。