HOPRベーシック：チケットと支払いチャンネル

HOPRの基本を解説するシリーズの第7話目です。過去のエピソードへのリンクは、記事の最後にあります。

HOPRのproof of relayの仕組みは、あるノードの支払いを、リレーチェーンの中でその前後のノードの行動と結びつけることによって、プライベートミックスネットにどのようにインセンティブを与えるかというパラドックスを解決しています。この解決策は、プライバシーネットワークを構築するために、もはやノードランナーの利他主義に頼る必要がないことを意味します。HOPRは、最も利己的な行動が最も多くの報酬を得る方法であるため、すべてのノードランナーが協力することができる信頼性のないシステムです。

しかし、私たちはまだトンネルの端にいるわけではありません。概念的には、リレーの証明は完全にスケーラブルなプライベートネットワークを構築するための鍵を提供しますが、高いコストを発生させたり、プライバシーを再び壊すことなくパブリックブロックチェーンにこれを実装する方法については、まだ疑問が残されています。

このエピソードでは、HOPRのソリューションの最初の部分であるチケットと支払いチャンネルをここで紹介します。

ブロックチェーンが抱える問題点

前回は、proof of relayの理論について説明しましたが、これを実際にどのように実装するかについては触れませんでした。「インセンティブ」や「報酬」について話すのはとても良いことですが、これらはどのような形をとるべきなのでしょうか。報酬はどのように生成され、請求されるべきなのか？

興味深いのは、この時点まで、どのエピソードもブロックチェーンについて全く触れていないことです。HOPRはクリプトプロジェクトであり、ほとんどの読者はHOPRトークンを通じて初めてHOPRを知ることになるため、このことは意外に思われるかもしれません。しかし、これまでの説明でブロックチェーンが必要なものは何もなかった。

しかし、HOPRはブロックチェーンに大きく依存しています。取引とスマートコントラクトのための分散型、トラストレスなプラットフォームのみが、以前のエピソードで説明したプライバシー要件を満たすという単純な理由があります。

しかし、パブリックブロックチェーンは2つの問題を生み出します。

• 1つ目は、単純に出費がかさむことです。HOPRネットワークの各ホップがオンチェーン取引を誘発する場合、ノードランナーは各報酬を請求するためにガスを使わなければならない。つまり、パケットごとに、リレーをするので、パケットを中継することになります。合理的なインセンティブを与えるには、ノードを実行することによる報酬がコストを上回る必要があるため、ネットワーク上でデータを送信するコストは非常に高くなってしまいます。
• 2つ目は、プライバシー問題です。ネットワーク上のすべてのホップが自動的にブロックチェーン上のトランザクションを発生させる場合、ネットワーク使用に関する多くのメタデータが漏れることになります。攻撃者は、一般に公開されている取引記録を使って、誰がノードを動かし、HOPRネットワークを利用しているのか、その実態を把握することができます。

Just the Ticket

HOPR introduces several mechanisms to eliminate metadata leakage in its payment layer. The most important is that relaying data doesn’t automatically trigger a payment. Instead, relaying data results in a cryptographic ticket. These tickets can be exchanged via a HOPR smart contract on the blockchain for a reward at any time.

The simple act of introducing an unknown delay already makes it much harder for attackers to learn about the HOPR network from the blockchain data. If relaying a packet automatically created a blockchain transaction, then you could be fairly sure that each reward transaction associated with an address happened at roughly the same time as the node associated with that address related to some data (give or take a few blocks for delays). You could maybe also start to make links between other HOPR transactions, to build a picture of which nodes were sending data at the time rewards were being claimed.

But if a node can wait an arbitrary amount of time before claiming their rewards, then the connection between the time the reward was earned and the time it was redeemed is severed. You could still get an estimate of how much relaying a particular node had done, but on its own, this is much less useful.

チケットについて

HOPRでは、決済レイヤーにメタデータの漏洩を防ぐためのいくつかの仕組みを導入しています。最も重要なのは、データを中継しても、自動的に決済が行われないことだ。その代わり、データを中継すると、暗号化されたチケットが発行される。このチケットは、ブロックチェーン上のHOPRスマートコントラクトを通じて、いつでも報酬と交換することができます。

未知の遅延を導入するという単純な行為によって、攻撃者がブロックチェーンのデータからHOPRネットワークについて知ることは、すでにかなり難しくなっています。パケットを中継することで自動的にブロックチェーンのトランザクションが作成されるのであれば、あるアドレスに関連する報酬トランザクションは、そのアドレスに関連するノードが何らかのデータに関連したのとほぼ同時に発生したことをかなり確信できるだろう（遅延のために数ブロックは許容される）。また、他のHOPRトランザクション間のリンクを作成し、報酬が請求された時間にどのノードがデータを送信していたかを把握することができます。

しかし、ノードが報酬を請求する前に任意の時間を待つことができる場合、報酬を獲得した時間とそれを償還した時間の間の接続が切断されます。それでも、特定のノードがどれだけ中継を行ったかの推定値は得られますが、それだけではあまり役に立ちません。

支払いチャンネル

また、HOPRは支払いチャンネルを利用して、オンチェーンデータ量を削減しています。支払いチャンネルは、必要な取引量を減らすために暗号分野ではよく使われる手法です。2人のユーザーが支払いチャンネルに出資し、互いに取引を行い、支払いチャンネルが終了すると、相対的な残高差分だけがチェーンに記録されます。

これは通常、コスト削減のための措置ですが、オンチェーンデータを関係する正確な取引から切り離すことができるという利点もあります。

上の図は、支払いチャネルとチケットがどのように連携しているかを示しています。

BettyとChaoは、それぞれのノード間に支払いチャネルを開設し、HOPRトークンで資金を調達します。
両者のノード間でデータがリレーされると、支払いチャンネルの相対的な残高が変化し、リレーごとにBettyまたはChaoの新しいチケットが生成される。これらのチケットは、一方のノードがすべての報酬を請求できるようになるまで蓄積される。この時点でチャネルは閉じられ、両ノードはチャネルが開かれてから行ったすべてのリレーに対して報酬を請求する。
チャネルが閉じられると、2 つの終了残高がオンチェーンで記録され、その残高がベティとチャオのウォレットに戻される。チケットの償還も1つの取引として記録されるが、これらは理論的には1つの取引に集約することができ、ガスとメタデータをさらに減らすことができる（HOPRの現在の実装ではチケット集約はまだ行われていません）。

さらなる改善点

支払いチャンネルとチケットの使用は、ブロックチェーンの取引データをHOPRネットワークで実際に起こっていることから切り離すのに大いに役立ちますが、中継された各パケットは、チェーン上で引き換える必要がある独自の報酬を生成するという問題が残っています。これは非常に非効率的であり、許容できないプライバシーウィークが発生します。HOPRは、確率的支払い、つまり1チケット1リワードシステムと同じリワードを全員が受け取れるようにする方法、しかしチェーン上でのトランザクションをはるかに少なくすることでこれを解決します。次回のエピソードで、その仕組みを見ていきましょう。

Sebastian Bürgel,
HOPR Founder

Website: https://www.hoprnet.org
Testnet: https://network.hoprnet.org
Twitter: https://twitter.com/hoprnet
Twitter（日本語）:https://twitter.com/HOPR_Japan
Telegram: https://t.me/hoprnet
Telegram（日本語）：https://t.me/HOPRJapanese
Discord: https://discord.gg/dEAWC4G
LinkedIn: https://www.linkedin.com/company/hoprnet
Forum: https://forum.hoprnet.org
Github: https://github.com/hoprnet

HOPRベーシック エピソード一覧：

Episode 1: HOPRについて
Episode 2: メタデータについて
Episode 3: 匿名ルーティング
Episode 4: ミックスネット
Episode 5: インセンティブ
Episode 6: Proof of Relay
Episode 7: チケットと支払いチャンネル
Episode 8: 確率的支払い
Episode 9: カバートラフィック
Episode 10: カバートラフィックノード
Episode 11: カバートラフィックのバランス
Episode 12: HOPR DAOの紹介