Cosmos SDK IBC denom・voucherトークン｜ブロックチェーンから別のブロックチェーンへのIBCを使用したトークン転送について

NFTStudio

2022年1月17日 02:11

この記事は「Understand IBC Denoms with Gaia」を日本語訳したものです。

Cosmos SDKを使用する場合の最も強力なテクノロジーの1つは、ブロックチェーン間通信プロトコル（IBC）です。Cosmosエコシステムでは、すべてのブロックチェーンがソブリンおよびアプリケーション固有であることが意図されています。

IBCを使用すると、すべてのブロックチェーンがIBCプロトコルを使用して別のブロックチェーンに接続できます。この通信プロトコルは、最終的にはソブリンおよび接続されたブロックチェーンのシステムを作成します。

序章

IBCの最もよく使用される機能は、あるブロックチェーンから別のブロックチェーンにトークンを送信することです。トークンを別のブロックチェーンに送信すると、voucherトークンが他の（ターゲット）ブロックチェーンで生成されます。

2つのブロックチェーン、ブロックチェーンAとブロックチェーンBを想像してみてください。最初は、ブロックチェーンAにトークンがあります。

トークンが表す値はチェーン間で転送できますが、トークン自体は転送できません。

IBCでトークンを別のブロックチェーンに送信する場合：

ブロックチェーンAはトークンをロックし、proofをブロックチェーンBに中継します
ブロックチェーンBは、voucher交換トークンの形式で独自の代表的なトークンを作成します
ブロックチェーンBは、voucherトークンをブロックチェーンAに送り返します
voucherトークンはブロックチェーンBでburnされます
ブロックチェーンAのロックされたトークンのロックが解除されます

ブロックチェーンAのロックされたトークンのロックを解除する唯一の方法は、ブロックチェーンBからvoucherトークンを送り返すことです。

その結果、ブロックチェーンBのvoucherトークンがburnされます。書き込みプロセスは、トークンを意図的に循環から外します。

このチュートリアルでは、ブロックチェーンBのvoucherトークンの形式を学習します。

voucherトークンに含まれる情報とvoucherトークンの外観を学習し、それらを理解する方法を学習します。

トークンの情報は、IBC denomとして記述されます。

このIBC denomを解析して、voucherに関する情報を受け取り、voucherトークンがどのブロックチェーンからのものであるかを知ることができます。

次の方法を学習します：

IBC denomをトレースする
denomがどのように機能するかを理解する
トークンがどのチェーンから来たかを調べます

要件

gaiaバイナリをインストールします。

git clone https://github.com/cosmos/gaia.git 
cd gaia 
git checkout v5.0.0 
make install 
gaiad version

gaiad versionは次のように出力されます。

v5.0.0

IBCデノムとは

asset transferで導入されたvoucherトークンは、IBC Denominations（IBC denom）と呼ばれます。

voucherトークンは、あるブロックチェーンから別のブロックチェーンへのIBCを使用したトークン転送の結果です。voucherトークンの形式は次のとおりです。

ibc/DENOMHASH.

最初にsamoleansとステークトークンを持っていたブロックチェーンBで新しいibc /トークンを受け取ったと想像してください。

残高は次のようになります。

1000000ibc/CDC4587874B85BEA4FCEC3CEA5A1195139799A1FEE711A07D972537E18FDA39D,100000000000samoleans,99999977256stake

samoleansまたはstakeと同じように、ibc / CDC458787 ...はIBCから受け取ったトークンの額面（単位）です。 ibc / CDC458787 ...の後には、デノム、IBCポート、およびチャネルのハッシュがあります。

なぜCDC458787...ハッシュなのですか？

ハッシュには、他のブロックチェーンからアカウントへの複数のホップでトークンを追跡するパスが含まれています。
パスを直接プリントする場合、このパスは耐えられないほど長くなる可能性があります。
Cosmos SDKには、トークンの金額に64文字の制限があります。

ハッシュを使用することのトレードオフは、実際のパスと額面金額を見つけるためにノードにクエリを実行する必要があることです。このクエリは、denomtraceと呼ばれます。

サブコマンドに従ってgaiad、denomをクエリし、トークンの送信元のチャネルについて学習します。

gaiad query ibc-transfer denom-trace CDC4587874B85BEA4FCEC3CEA5A1195139799A1FEE711A07D972537E18FDA39D --node https://rpc.testnet.cosmos.network:443

Response:

denom_trace:
  base_denom: moon
  path: transfer/channel-14

transferコマンド出力から、IBCポートとチャネルがあることがわかりますchannel-14。ただし、ポートとチャネルの背後にあるIBCライトクライアントを知るには、別のクエリを実行する必要があります。

なぜライトクライアントと呼ばれるのですか？それは他のチェーンの軽いクライアントであるため、そのブロックハッシュを追跡します。このibc channel client-state transferコマンドは、denomパスの詳細を説明します。

gaiad query ibc channel client-state transfer channel-14 --node https://rpc.cosmos.network:443

Response:

client_id: 07-tendermint-18
client_state:
  '@type': /ibc.lightclients.tendermint.v1.ClientState
  allow_update_after_expiry: true
  allow_update_after_misbehaviour: true
  chain_id: mars
  frozen_height:
    revision_height: "0"
    revision_number: "0"
  latest_height:
    revision_height: "2207"
    revision_number: "0"
  max_clock_drift: 600s
  proof_specs:
  - inner_spec:
      child_order:
      - 0
      - 1
      child_size: 33
      empty_child: null
      hash: SHA256
      max_prefix_length: 12
      min_prefix_length: 4
    leaf_spec:
      hash: SHA256
      length: VAR_PROTO
      prefix: AA==
      prehash_key: NO_HASH
      prehash_value: SHA256
    max_depth: 0
    min_depth: 0
  - inner_spec:
      child_order:
      - 0
      - 1
      child_size: 32
      empty_child: null
      hash: SHA256
      max_prefix_length: 1
      min_prefix_length: 1
    leaf_spec:
      hash: SHA256
      length: VAR_PROTO
      prefix: AA==
      prehash_key: NO_HASH
      prehash_value: SHA256
    max_depth: 0
    min_depth: 0
  trust_level:
    denominator: "3"
    numerator: "1"
  trusting_period: 1209600s
  unbonding_period: 1814400s
  upgrade_path:
  - upgrade
  - upgradedIBCState

これは多くの情報ですが、質問に答えることはできません。このIBCクライアントが信頼できるかどうかをどうやって知るのでしょうか。

チェーンIDとクライアントID

誰でも同じチェーンIDでチェーンを開始できます。ただし、IBCクライアントIDは、Cosmos SDKIBCキーパーモジュールによって生成されます。（新しいウィンドウを開きます）（ICS-02は、IBCクライアントIDの標準を指定していません）。

チェーンネームサービスとそれほど分散化されていないGithubチェーンレジストラリポジトリは、チェーンIDとクライアントIDの組み合わせを確認できます。

チェーンネームサービスとチェーンレジストラリポジトリはどちらも開発中であり、実験的なものと見なされます。

IBCクライアントの有効期限が切れていないことを確認します

Tendermintコンセンサスが失敗した場合（バリデーターの1/3以上が競合するブロックを生成する場合）、このコンセンサス失敗の証拠がチェーン上で送信されると、IBCクライアントfrozen_heightはゼロ以外のaでフリーズします。

前の例では、gaiad query ibc channel client-stateの出力でクライアントのステータスが確認され、IBCクライアントの有効期限が切れていないことがわかります。

latest_height.revision_heightは、IBCクライアントが最後に更新されたときのブロックの高さです。ブロックの高さが最新であることを確認するには、ブロックチェーン自体にブロックの高さ2207を照会し、そのブロックのタイムスタンプ+ 1209600s / 336h / 14dのtrusting_periodが現在の時刻より後であることを確認する必要があります。

たとえば、次のクエリを使用してIBCクライアントのステータスを確認できます。

gaiad query block 5200792 --node https://rpc.cosmos.network:443

別のブロックチェーンのパスを見つける

考えられるすべてのブロックチェーンパスを一覧表示できることは、未解決の問題です。

channel作成されたブロックチェーンは、情報をあまり公開せずに、別のブロックチェーンに新しいブロックチェーンを作成できます。

現在、チャネルは、信頼できるように、個人間プロトコルを使用して相互に通信する必要があります。この個人間通信プロトコルはIBCデノムを使用するため、アプリで受け入れるトークンを識別できます。

この問題を解決するための1つのアプローチは、チェーンIDとそのノードの集中型または分散型データベースを使用することです。開発中のソリューションは2つあります。

Chain Name Service (decentralized)
1. CNS _ （新しいウィンドウを開きます）CosmosHubがいつか実行するCosmosSDKモジュールになることを目指しています。クロスチェーントランザクションが通過するハブとして、Cosmosハブが他のチェーンIDに到達する方法に関する重要な情報をホストすることは意味があります。CNSはまだ新しく、開発中です。
Cosmos Registry (semi-decentralized)
1. github.com/cosmos/registry _ （新しいウィンドウを開きます）レポは一時的な解決策です。各チェーンIDには、その起源とピアのリストを説明するフォルダーがあります。チェーンIDを要求するには、ブロックチェーンオペレーターはリポジトリをフォークregistryし、チェーンIDを使用してブランチを作成し、チェーンIDの公式cosmos/registryにチェーンIDを含めるプルリクエストを送信する必要があります。
2. すべてのチェーンIDはフォルダーで表され、そのフォルダー内のpeers.jsonファイルには、接続できるノードのリストが含まれています。
Cosmos Registrar（半分散型）
1. コスモスレジストラ （新しいウィンドウを開きます）Jack Zampolinによって開始され、ApeUnitによってさらに開発されたツールです。cosmos-registrarは、チェーンIDの要求と更新を自動化します。この場合、チェーンIDを更新するということは、新しいピアリストをGitHubリポジトリにコミットすることを意味します。このコミットはcronjobで実行する必要があります。その状態はv1.0として最もよく説明されているので、先に進んでバグをGithubの問題として報告してください。

あなたとあなたのユースケースに最も適したアプローチを選択してください。

この記事が気に入ったらサポートをしてみませんか？