画像の説明
クリックしてビデオを見る
シャオシャオ：皆さん、こんにちは。私は HashKey Capital の投資ディレクター、Xiao Xiao です。今日の AMA のホストでもあります。本題に入りましょう。
ビットコインが暗号分野で最も強いコンセンサスを持つ資産であることは誰もが知っていると思いますが、今日に至るまでその主な用途は依然として価値の保管と交換です。 DFINITY コミュニティは、昨年 9 月に ICP とビットコイン ネットワークの直接統合を提案し、スマート コントラクトを通じてビットコインにさらに多くのアプリケーション シナリオをもたらし、機能を強化し、IC エコシステムに高品質の資産をもたらすことも計画しています。当時、この提案は 96% 以上の支持を得ており、この技術に対するコミュニティの期待を十分に示しています。
この提案が可決された後、非常に重要なマイルストーンが最近現れました。それは今年の 6 月 10 日で、DFINITY 財団がビットコインと直接統合の第 1 段階の完了を発表しました。これは、以前によく話した ECDSA 署名の閾値です。 、これは比較的大きな進歩であると言え、ビットコインのIC統合を解決するための重要な前提条件でもあります。
テクノロジーを実現する方法を誰もが知っていると思いますか?それの使い方？今後どのように展開していくのかも含めて好奇心でいっぱいです。本日は、DFINITY の中核技術エンジニアである Paul Liu 氏をお招きして質問にお答えいただけることを大変光栄に思います。次回は Paul 氏に引き継がれる予定です。
Paul Liu：シャオさん、ありがとうございます。皆さんとお話しする機会ができてとてもうれしいです。私は DFINITY のエンジニアです。私の名前はポールです。約 4 年前に DFINITY に入社し、初期の従業員です。私たちのメインネットも昨年立ち上げられ、立ち上げ以来多くの新しい開発が行われてきましたが、最も重要な新しい開発はビットコインとの統合計画です。
本日は、当社のインターネットコンピュータ一体型ビットコイン技術の概要をご紹介させていただきますので、特に深い技術的な内容についてはお話しませんが、その前後の具体的な状況をより明確にご理解いただければ幸いです。
まずビットコイン チェーン上のトランザクション プロセスを確認しましょう。クラスメートが 2 人いて、1 人はアリス、もう 1 人はボブだとします。アリスはボブにサトシを送ろうとしており、400,000 を送金する必要があります。この図では、公開鍵を表すために鍵を使用しており、点線が秘密鍵です。アリスとボブは両方とも独自の公開キーと秘密キーを持っており、ビットコイン チェーンへのトランザクションを開始するには秘密キーを使用してトランザクションに署名する必要があります。
具体的なプロセスを見てみましょう。トランザクションを作成するには、彼女は一定量のビットコインを手元に持っている必要があります。彼女のビットコインは、通常 UTXO と呼ばれる前のトランザクションによって生成された出力です。各トランザクションのソースと入力は、1 つ以上の前のトランザクションの出力である必要があります。たとえば、ここでは、アリスは前の 2 つのトランザクションから 100,000 を取得し、もう 1 つは 300,000 を取得し、ボブへの 400,000 の出力を形成します。彼女は、使用されていない以前のトランザクションのみを使用できます。これはコイン固有のビットですUTXOモデル。
前の 2 つのトランザクションは、新しいトランザクションの作成に使用され、この新しいトランザクションを Bob に割り当てます。緑色になっていることがわかります。この緑色は、Bob に送信された公開キーに対応するアドレスを示しています。その後、彼女はこのトランザクションを開始して、それをビットコイン ネットワークに引き渡したいと考えています。それがマイナーであれ、ビットコイン ネットワークのノードであれ、彼らはユーザーから受け取ったトランザクションをブロックに入れます。各ブロックには約約 1500 のトランザクションがあり、そのようなブロックがビットコイン ブロックチェーンを構成します。もちろん、ここでは無視されている詳細がまだたくさんあります。
私たちが懸念しているのは、トランザクションを作成するプロセス全体です。独自のトランザクションに署名するには、独自の秘密キーが必要であることがわかります。また、新しいトランザクションを見積もって発行するには、彼女の以前の UTXO を知っている必要があります。
ビットコインのプロセスを見終えた後、インターネット コンピューターについて簡単に紹介しましょう。私たちはそれをインターネットコンピュータと呼んでいます。これは、インターネット コンピューター プロトコルと呼ばれるプロトコル上で実行され、パブリック ブロックチェーン サービス プラットフォームを提供します。最下層はデータ センターであり、データ センター内のノードはコミュニティ ノード オペレーターによって独立して運用されます。ノード オペレーターは、特定のデータ センターと契約を結んで、そこでノードを実行することがあります。ノードは ICP ネットワークに参加できます。参加後、すべてのノードは基礎となるネットワークを形成します。その上で、インターネット プロトコル (IP) が実行されます。IP の上で、ICP プロトコルが実行されます。ノードは複数のサブネットに分割され、コンセンサス プロトコルは各サブネット内で実行されますが、すべてのサブネットが一緒になって結合ネットワークを形成します。このネットワーク上では、このネットワークによって提供されるコンピューティング プラットフォーム、またはスマート コントラクトなどのプログラムを実行できる仮想マシンとして抽象化されます。
その主な特徴は、スマートコントラクトがネットワークHTTPサービスを直接提供できることであり、クエリ応答はミリ秒レベルであり、状態を変更できるトランザクションが開始される場合、2〜3秒かかる場合がありますが、2〜3秒です。現在のブロックチェーン時代において最も先進的なものでもあります。主な目的は、スマート コントラクトを Web サイト上で実行できるようにすることであるため、ユーザーに料金を請求することはできません。ユーザーは料金を支払うことなくスマート コントラクトにアクセスできます。たとえば、ブラウザーを使用して直接 Web サイトにアクセスする場合、料金を支払う必要はありません。リバースガスモデル。サブネット間の通信、およびサブネットと外部ユーザー間の通信には、RTC またはリモート呼び出しと同様のモデルが使用されます。 HTTP を呼び出しと考えることもできます。
計算コストが比較的低く安定していると言えるのは、リリースされたばかりで使用する人が少ないから計算コストが低いということではありません。実際、最先端のシャーディング技術が使われているため、新しいサブネットを追加することでネットワーク全体の負荷を分散することができ、理論上の上限はなく、ハードウェアが許す限り無限に拡張することが可能です。これが可能な理由は、各サブネットが非常に高度な暗号化知識を使用して相互の計算結果を検証するためです。サブネットワークの履歴トランザクション記録がなくても、サブネットワークの現在の計算が有効であるかどうかを検証できます。これが、公開鍵を渡すだけで済むため、スマート コントラクトの実行結果が正しいことを携帯電話やブラウザで直接検証できるため、スマート コントラクトに Web サイトのサービスを直接記述することができる理由です。
おそらく、アプリケーション層における IC の最も顕著な機能の 1 つは、スマート コントラクトを通じて投票でき、投票決定を自動的に実装できる自律的な投票ガバナンス システムを備えていることです。 DAO モデルは今日まで発展していますが、手動での投票や、追加の署名を 1 つずつ求めることは廃止され、自動化するにはスマート コントラクトを使用する必要があると思います。
前述の IC の開発環境は仮想マシンとみなすことができるため、開発者はスマート コントラクト コードを直接アップロードして IC にデプロイできます。これは、クラウド サービスにコードをデプロイするのと似ています。デプロイ後の各コードは独立したコンテナーになり、これをキャニスターと呼びます。IC 上の各コンテナーには、スマート コントラクトのコードがあるだけでなく、その状態も含まれます。変更できるすべての状態はコンテナー内に保存されます。他のコンテナの状態にアクセスしたい場合は、他のコンテナのインターフェイスを介してアクセスする必要があり、このインターフェイスへのアクセスはリモート呼び出しと同等です。ただし、相手がこのインターフェイスを開いていない場合、またはオープン インターフェイスが必要なデータを提供していない場合は、そのインターフェイスにアクセスすることはできません。したがって、これは比較的大きな違いであり、現在の他のブロックチェーンとは大きく異なる可能性があるため、特に開発者は注意する必要があります。ただし、これは従来の Internet Docker または MicroService 開発モデルに比較的近く、従来の開発者は IC での開発に比較的慣れている可能性があります。
いわゆるスマートコントラクトとビットコインの統合とは何ですか?以前にビットコインのトランザクションも見たことがあります。ビットコインは、署名されるトランザクションを開始します。ここでは、アリスとボブを使用してビットコインをコンテナに直接送信する場合、コンテナがビットコインを直接受信できるかどうかがわかります。この場合、コンテナは次のことができます。スマートコントラクトはユーザーと同じように相互にトランザクションを発行し、実際にビットコイン資産を管理できる、つまりビットコインのスマートコントラクトプラットフォームを提供できます。
したがって、その中のより重要な前提の 1 つは、IC 上の各キャニスター、IC 上のスマート コントラクト、IC 上の各キャニスターがビットコイン アドレスを取得できる場合、それはプログラム ロジックのビットコイン資産を通じて管理できることを意味するということです。これは設計の本来の目的です。各キャニスターに独自のビットコイン アドレスを持たせる必要があります。独自のアドレスを持つということは、独自のトランザクションを発行できる必要があることを意味します。
具体的な実装プロセスを見てみましょう. 統合はまず基盤となるプロトコル層で行われます. プロトコル層は、実行中のビットコインのライトノードであるビットコインネットワークにアクセスし、ネットワーク上のトランザクションのステータスを知ることができますビットコイン ネットワークとその最新のブロックですが、ビットコイン マイニングには参加せず、ユーザー トランザクションの送受信にのみ使用されます。ただし、これらのブロックの情報は IC 上のすべてのノードで取得でき、このノードはこの情報を仮想マシン (ユーザーが実行するキャニスター) に渡すことができます。したがって、キャニスターは、彼が所有するこの BTC アドレスのすべての UTXO を取得できます。
ユーザーが資産をキャニスターに転送したい場合、つまり私がビットコインをキャニスターに送信すると、キャニスターはビットコイン ネットワークを監視することでこの情報を受信できます。これは、最新のブロックを知ることができ、ブロックが存在することがわかるためです。誰かがそのアドレスにビットコインを送信すると、その情報を知ることができます。
どのように送信されるのでしょうか？彼はトランザクションに署名する必要があり、作成した署名はビットコイン ネットワークに送信する必要があります。そのため、キャニスターへの入力プロセスだけでなく、キャニスターからの出力も必要になります。キャニスターからの出力は、ビットコイン ネットワーク上で循環できます。通信網。したがって、これは基盤となるノードによって提供されるサービスです。 IC の元のノードと比較して、ビットコイン ネットワークと直接情報を交換するプロセスである、もう少し多くのサービスを提供します。
先ほど主な理由をお話ししましたが、各キャニスターコントラクトに独自のビットコインアドレスを持たせてビットコイン資産を管理できるためですが、その前提として、同じく開発中の「しきい値ECDSAしきい値署名」と呼ばれる技術を実装する必要があります。比較的良い進歩を遂げた。このテクノロジーにより、各キャニスターに独自の BTC アドレスを割り当てることができ、いわゆる独自アドレスとは、キャニスターが独自の公開鍵を持つことを意味します。署名することはできますが、この署名は彼が自分の秘密鍵を保持しているということではなく、彼の署名は IC ネットワーク上のサブネットを通じて署名されており、サブネットはキャニスターの代わりにキャニスターが署名したい契約に署名することができます。これについては後で詳しく説明します。
各キャニスターが独自のビットコイン アドレスを持ち、チェーン上の関連する UTXO トランザクションを取得できる場合、新しいトランザクションを開始する必要があるか、ユーザーからより多くの情報を取得する必要があるかどうかを、プログラムを通じて独自に決定できます。より多くの情報により、ビットコインネットワークと対話できるだけでなく、同時にブラウザを通じてユーザーと直接対話できるようになります。また、トランザクションのために新しいトランザクションをネットワークに送信することもでき、サイクル全体が実行できれば、IC 上で実行されているユーザー コードがすでにビットコイン ネットワークにスマート コントラクト サービスを提供しているのと同等になります。したがって、この 3 点ができる限り、いわゆる IC と BTC の統合において最も重要です。
この機能を使用するには、開発者はいくつかのシステム インターフェイスを経由する必要がありますが、このインターフェイスは比較的シンプルで、直接残高を取得したり、ビットコインを送信したりすることができ、署名を提供するインターフェイスもあります。最も重要なのは署名を提供することですが、この技術はどのように実装されているのでしょうか?まず、IC の主なコア技術は分散鍵生成プロトコルである DKG です。 DKG の主なプロセスは、サブネット内の各ノードが秘密キーの共有を生成できることです。秘密キーは理論的には完全な秘密キーではありませんが、署名には使用できます。各ノードは独自の秘密を保持し、この秘密鍵共有はこのノードにのみ属し、他の誰にも知らせません。 DKG プロトコルの後、参加している各ノードは独自の秘密鍵共有を生成でき、お互いの秘密鍵共有は知りませんが、自分自身の秘密鍵共有は知っています。
このプロトコルは別の結果を生成します。このサブネットには公開キーがあります。この公開キーは一意です。各ノードが独自の秘密キー共有を持った後、その秘密キー共有を使用して独立して署名できます。これらのノードが同じメッセージを共有する場合、署名とこの署名をブロードキャストします。他のノードの署名を知った後、これらの署名を最終的な署名に結合できます。この最終的な署名は、サブネットの公開キーを使用して検証できます。これは、最終署名は固定公開鍵で検証できるが、この公開鍵に対応する秘密鍵を知る者は誰もいないことを意味します。
視覚的に言えば、それはすべてのノードに配布され、全員がコピーを持ち、全員がそれに署名します。署名後に最終的な署名が合成できれば、公開鍵は検証できますが、対応する秘密鍵の秘密は誰も知りません。 key. 、すべての署名を合成するには、大多数のノードが参加する必要があります。通常、署名を完了するにはノードの 3 分の 2 以上が必要であり、トランザクションの最終署名は公開キーを使用して検証できます。 IC の主な技術はこれですが、以前に作成した署名は BLS 暗号署名の技術に基づいていました。今後は、ECDSA 署名にも対応した同様の技術を完成させる必要があります。BLS と比較して、必要な量は多くなります。より複雑であり、これまで多くの論文で暗号の最前線研究が論じられてきましたが、特に安全な方法は見つかっておらず、常に何らかの妥協が伴います。したがって、私たちはこの分野で最新の進歩を遂げ、システム全体の設計に非常に満足しています。もちろん、暗号の専門家による監査も必要であり、さまざまな検証を経て最終的に安全性が確認されます。
ただし、その具体的なアプローチは、抽象的な理解のレベルで DKG プロセス全体と一致しています。最初に、DKG プロトコルを実行することによって、サブネットのノードは独自の秘密鍵を取得し、独自の秘密鍵で署名し、Put に署名した後、それをすべて一緒にして、それで終わりです。結合された署名は、その公開鍵が通常の ECDSA 公開鍵であるため、通常の ECDSA 署名と区別できません。そのため、ビットコイン ネットワークでは ECDSA 署名が使用されますが、後に Schnorr 署名が導入されました。Schnorr 署名であれば、通常の ECDSA よりも簡単になります。 DKGになります。通常のECDSAをサポートする理由は、適用範囲がビットコインに限定されず、他の方向性もあり得るためです。
サブネットには公開キーがあると言いました。ビットコイン ECDSA 署名には BIP32 標準があり、これにより、キーのペアからより多くのキー ペアを生成できます。これらのサブキーを使用して署名すると、署名には独自のアドレスがあり、トランザクションを受け取る相手はマスターキーが何であるかを知りません。使用されるシステムは BIP32 標準に基づいており、しきい値署名にも適用されます。したがって、各キャニスターの公開キーは、作成時に割り当てられる一意の ID であるキャニスター ID を介して使用され、IC ネットワーク上の合意の後、この ID を偽造することはできません。
したがって、この ID を使用して、BIP32 標準を使用してサブネットの公開鍵と照合し、各キャニスターの公開鍵を生成することは完全に実現可能です。キャニスター内であっても、その中でトランザクションに署名して発行したい場合は、より多くの異なる公開キーを使用してさまざまなことを行うことができます。各公開キーはアドレスに対応しているため、基本的に任意の数の公開キーを提供して使用できます。キャニスターで。このようにして、各キャニスターが署名するときに、独自の署名要件をサブネットに送信し、サブネットの各ノードが BIP32 を通じて独自の秘密鍵で署名し、最終的に最終署名を合成します。
つまりIC一体型BTCはブリッジではありません。ブリッジングとは、クロスチェーンアセットを容易にするためのもので、通常、いずれかのチェーン上のスマートコントラクトによってロックされ、アセットがこのスマートコントラクトに送信され、同じ開発者が対応する他のチェーン上に別のチェーンを開発します。一連のスマート コントラクトによって新しい資産が発行され、資産を交換できるようになります。
これの主な問題は、ブリッジを提供する開発者を全員が信頼する必要があることですが、IC 上のこの署名のおかげで、単一の当事者を信頼する必要がなく、単一の開発者を信頼する必要もありません。私のスマート コントラクト ソースを公開することで直接リリース コードはここにあり、私のスマート コントラクトは IC プラットフォーム上で実行されます。IC サブネットが分散型プラットフォームであると信頼し、その操作の結果が正しいと信頼できる場合、そのようなものがある場合実際、それは分散型信頼であり、より多くのことを実行できます。
特にブリッジングでは、資産を担保に入れる必要があります。すべてのアプリケーションにブリッジが必要なわけではありません。たとえば、定期的にビットコインをアカウントに送信したい場合は、ブリッジや担保の必要はなく、署名することで直接送信できます。 。
私たちの技術的特徴を要約すると、各スマート コントラクトは独自の独立した BTC アドレスを持ち、コア テクノロジーは Threshold ECDSA しきい値署名です。ビットコイン トランザクションは依然としてビットコイン ネットワークを経由することを指摘することが重要です。すべてのビットコイン トランザクションは最終的にビットコイン ネットワークに送信され、ビットコイン ネットワークによって確認されるため、UTXO トランザクションがチェーン上のビットコインに正しく記録されていることを確認できます。 。コントラクトは、API を介して UTXO をクエリし、トランザクションを発行および送信できます。そのセキュリティは、IC サブネットのセキュリティから来ます。IC ブロックチェーンとビットコイン ブロックチェーンの組み合わせを通じて、2 つのセキュリティが一緒になってスマート コントラクトのセキュリティを保証します。
おそらく、最初に簡単な紹介でここで終了し、何か質問があるかどうかを確認します。
シャオシャオ：オーケー、ポール、共有してくれてありがとう。今日の Q&A セッションに移りましょう。私たちはまた、過去 1 週間で開発者コミュニティと一般ユーザー コミュニティから多くの質問を集めました。その中には私自身の調査から残ったものも含まれています。 。今日は、より重要かつより一般的な質問をいくつか選択しました。さらに、AMA を見ている友人、他の友人がいる場合は、ライブブロードキャスト ルームのコミュニケーションおよびディスカッション エリアに電話することもできます。時間が許せば、現場からさらにいくつかの質問を受けることもできます。後で聞いてください。
まず、誰もが一番気になるのは、ユーザーや開発者にとって最も重要な質問ですが、開発者側とユーザー側がいつ正式にこの機能を使えるようになるのかなど、具体的なローンチスケジュールはどうなるのでしょうか？
Paul Liu：スケジュールについてはあまり多くは言えませんが、現時点でわかっている技術の 1 つは ECDSA 署名ですが、まだ完了していないテスト作業がたくさんあるため、完全に完成したとは言えませんが、現時点では署名されたデモは通過できます。ユーザーはメッセージを送信し、キャニスターに署名を要求できます。キャニスターはメッセージを受信してシステム API を呼び出し、システム API が各ノードに送信され、各ノードが署名を実行できます。最終的な署名がまとめて作成されます。最終的に署名が取得され、最終署名がキャニスターにフィードバックされ、キャニスターがユーザーにフィードバックします。このようなプロセスはすでに社内で実行されており、次に開発プロセス全体が加速されます。
したがって、私たちの暫定計画は、開発者が実際の ECDSA 署名を使用できるように、第 1 四半期に ECDSA テスト バージョンをリリースすることです。ビットコインネットワークをリッスンしてトランザクションを送信するためのビットコインとビットコインの統合の暫定バージョンもあります。開発者がローカルで使用してデバッグ作業を行うための専用 API が今月末にリリースされる可能性があります。これはこれはビットコインのメインネットワークではなくテストネットワークです。今月末には開発者向けプレビュー版がリリースされると思いますが、具体的なリリース日も第1四半期の3月にはベータ版となる予定です。実際に大規模なアセットは入れないことを願っています。テストは予定されています。安全で信頼性が高く、使用上のあらゆる面で大きな問題はない、おそらくそうでしょう。
シャオシャオ：理論的に言えば、実際の直接統合後、ビットコインの送金速度はどの程度加速するのでしょうか?
Paul Liu: すべてのビットコイントランザクションは依然としてビットコインネットワーク上にあるため、私たちはビットコインのトランザクション速度を高速化しようとしているわけではありません。私たちが行っている一連のことは開発者が使用するためのものであり、私たちが基礎的に行っていることに属していることを理解してください。インフラストラクチャー。開発者はこのテクノロジーを使用して、必要なアプリケーションを作成します。簡単な例をいくつか挙げますと、1つはブリッジを作ります、私が開発者であればブリッジを作ります、ビットコインユーザーとICユーザーの両方にスマートコントラクトを利用できます、ビットコインを受け取ることができます。これは直接実行できるものです。現在市場では、この種の橋を運営するには集中管理された会社が必要であり、その会社を信頼する必要があります。これを契約に含めることができれば、本契約で発行されたWBTCをそのままICネットワーク上で取引することができますが、最終的にはBTCに変換するための決済、またはBTCネットワーク上での取引が必要となります。これはライトニング ネットワークに似ており、実際のトランザクションは別の場所で行われ、より高速です。ビットコイントランザクションは依然としてビットコインネットワーク上に置かれており、高速化はありません。
シャオシャオ：しかし、このプロセス中に送金に遅延は発生するのでしょうか。また、ビットコイン自体に必要な時間に加えて、どれくらいの時間がかかるのでしょうか?
ポール・リュー: これにはそれほど時間はかかりません。延長戦はすべて秒単位で終わります。例えば、署名の発行には数秒かかりますが、UTXOの取得は基本的に直接呼び出しなので、統合にかかる追加時間はわずかだと思います。10～20回の確認が必要なビットコインに比べれば、微々たるものだと思います。より安全な方法であり、追加時間の可能性は無視できます。
シャオシャオ：先ほど、ビットコインの統合はサブネットのノードにも影響するというお話がありましたが、当局はビットコイン専用のサブネットを開設する予定があるのかどうかお聞きしたいのですが。
Paul Liu: これは良いアイデアだと思います。いくつかの異なるソリューションがあり、どれを使用するかはまだ決めていません。個人的には、サブネットを開く必要があると思います。専用サブネットを開くと、他のタイプのスマート コントラクトを実行する必要がないため、より効率的です。計算という点では、ビットコインの署名に集中した方が効率的かもしれません。
シャオシャオ：わかりました。鍵導出 BIP32 標準についても先ほど触れましたが、ポール兄弟にこの標準の利点をさらに紹介していただけますか?従来の独立したキー方式を使用せずに、キー開発に BIP32 標準を選択するのはなぜですか?
Paul Liu：ビットコインは、この考慮事項のために ECDSA 曲線を採用しています。ビットコインは、誰もが異なる公開鍵を通じて異なるアドレスを使用できることを期待しており、これにより柔軟性が高まります。資産には必ずしも 1 つのアドレスだけが必要なわけではありません。異なるアドレスを使用できます。異なるアドレスは次の方法で生成されるため、あなたなら、それらを管理できます。このBIP32導出方法がなぜ有利であるかというと、個々のキーを保存する必要がなく、導出ルールに従ってキーを使用し、プレフィックスとサフィックスを決定してラダー構造を実現できるためです。このようにして。ただし、セキュリティやその他の側面に関しては、人によっては異なるニーズがあり、異なる公開キーと秘密キーのペアを使用する必要もあります。
たとえば、ハードウェア デバイスを使用して公開鍵と秘密鍵のペアを生成し、そのハードウェア デバイスを他の人に渡すことができます。また、公開鍵と秘密鍵が直接生成された場合、相手はより安心するかもしれません。ハードウェア。
メインの秘密キーを第三者に渡すことは不可能であるため、この導出方法を使用するのは非現実的です。私たちの統合では、サブネットには固有の独自の公開キーがあると先ほど述べました。しかし、異なるサブネットを持つこともでき、異なるサブネットは異なるビットコインで発行されたサービスを提供することもでき、異なるサブネットで同じ公開鍵と秘密鍵を実行することも、異なる公開鍵と秘密鍵を実行することもできます。異なるサブネット間で通信できるため、スマート コントラクトがどのサブネット上にあるかに関係なく、他のサブネットが提供するビットコイン サービスを使用できます。署名要求をそのサブネットに送信すると、そのサブネットはそのサブネット内のノードを通じて署名要求を行い、署名の結果はそのサブネットの公開キーに対応します。
したがって、より多くの公開鍵と秘密鍵のペアを実装することもできますが、おそらく焦点はこの側面ではなく、より多くの異なるアドレスを導出できることにあるでしょう。派生関係を直接介して、私たちの側でこの派生関係を適用することは、各キャニスターが公開鍵と秘密鍵を個別に生成するのではなく、主にすべてのキャニスターをサポートすることです。秘密キーを個別に生成する場合の主な問題は、その背後で使用されているテクノロジに比較的大きなオーバーヘッドがあるためです。署名するために秘密キーの共有を保存することは、先ほど述べたほど単純ではありません。このプロセスはより複雑です。簡単に言うと、1つのDKGではなく、たくさんのDKGが入っていて、その多くは一時的なもので、1回やって使い切ると捨ててしまいます。したがって、サブネットは 1 つの公開キー ペアのみを使用します。これはノードにとって受け入れられやすいものです。セキュリティの観点から見ると、1 つのペアが安全でない場合、多くのペアはさらに安全ではありません。したがって、少なくとも 1 足が安全であることを確認する必要があります。各キャニスターの ID は一意であるため、各キャニスターに割り当てられたアドレスと公開鍵も安全です。おそらく次のようになります。
シャオシャオ：わかりました。統合後、Canister を通じてビットコイン資金の出所や所在、または取引履歴を照会することは可能ですか?このクエリ プロセスは IC ネットワークのリソースを消費する必要がありますか、それとも APP 開発プロセス中にこのクエリを実行するためにビットコイン ブラウザを直接統合してもよいでしょうか?
Paul Liu：このクエリでは、各 IC ノードがビットコイン ライト ノードを実行し、ビットコイン ネットワーク上のすべての新しいトランザクションを検証できるため、クエリ用のシステムの API を直接提供します。 Genesis ブロックから始まる、いわゆるライト ノードは特に軽いわけではありません。
維持されているアカウントはすべて UTXO であり、各ノードを信頼する必要はありません。ノードはすべて独立して BTC のライト ノードを実行しており、各サブネットのノードによって実行される計算は同じでなければなりません。計算できるようになった結果の検証です。複数のサブネットワーク ノードがコンセンサスを実行すると、UTXO クエリが正確であることが証明され、文字列を変更せずにスマート コントラクトにのみ返すことができます。
もう 1 つは消費するリソースです。これは IC ネットワーク上で実行されます。この API 呼び出しには料金を支払う必要があります。エンド ユーザーはこれに料金を支払う必要はないと前述しましたが、開発者は独自の契約を結ぶ必要があります。呼び出しまたは署名通話ごとに別途料金が必要です。
シャオシャオ：開発者の支払いについて言えば、ビットコイン転送自体はまだビットコイン ネットワーク上にあるため、ビットコイン ネットワーク ガスを依然として消費する可能性があると先ほど述べましたが、このガスをユーザー側で鈍感にすることはできますか (リバース ガス モデル)、このタイプのガスはカバーされますか？
Paul Liu: 各スマート コントラクトには BTC アドレスがあり、契約によって支払われる必要があるため、このタイプのガスはカバーできます。そのため、これは引き続き開発者に渡されます。開発者がユーザーのトランザクションに対して私が支払う意思があると判断した場合は、もちろん、BTC ネットワーク上で支払うことができます。
Xiao Xiao: もう一つの質問は、先ほどWBTCの話が出ましたが、IC統合後のBTCにはどのような規格やフォーマットがあるのか、それともオリジナルのUTXOなのか、それともビットコインの新しい規格なのか、標準出力なのかを聞きたいです。
Paul Liu：「財団はこの標準を作るのがあまり得意ではないと思います。これは開発者に任せたほうがいいでしょう。私たちがやっているのは、各キャニスターに BTC アドレスがあるということです。内部の BTC をどのように使用するかを決めるのはあなたです。これはすべてビットコインで行われます。」インターネットにはICネットワークが存在しません。したがって、WBTC を作成することを選択できますが、同様のことを行う他の開発者もおり、この公正な競争の決定は市場に委ねられています。もちろん、WBTC を実行する必要はありません。この方法を必要としないアプリケーションはたくさんあります。
シャオシャオ：コミュニティが資産基準を確立した場合、役人はそれに従うことを選択するでしょうか、それとも特定の基準を支持することを選択するでしょうか?
Paul Liu：私たちが最も重要に考慮すべきことは、あまりにも多くの詐欺師が出現しないようにすること、またはセキュリティについてより心配しすぎないことだと思います。
シャオシャオ：私たちは他のエコロジーにも注目しています。例えば、私たちの観点から見ると、ビットコインの初期から現在に至るまで、多くのプロジェクトが RSK や Blockstack などのビットコイン上でスマート コントラクトを派生させたいと考えています。 ICの統合 現在市場で見られるスマートコントラクト層のプロトコル層プロジェクトと比較して、技術的にどのような利点があるのでしょうか？あるいは、最も重要な違いはどこにあるのでしょうか?
Paul Liu：主な違いは秘密鍵の保管方法だと思います。先ほど、しきい値署名内の秘密鍵が何であるかは誰も知りませんと言いました。各ノードは自分のシェアしか知りません。したがって、これは秘密鍵の比較的分散された保管場所です。まあ、実際にこれをやった人は誰もいないと言っても過言ではありません。以前は、ビットコインにスマート コントラクトを提供することが提案されていましたが、それらはすべて、ハードウェア、秘密鍵を保存する信頼できるハードウェア、信頼できるハードウェア署名などの何らかの方法でこれを回避していました。ただし、ハードウェア署名が信頼できるところは信頼してください。署名が盗まれないことは信頼できますが、署名が正しく使用されていると信頼できるでしょうか。したがって、ユーザーの信頼を得るために複雑なプロセスを設計したい場合、そのような方法はより困難であり、技術的な問題や妥協が生じる可能性があります。
IC の主な方法は分散型で署名を行うことだと思いますが、DeFi を想像してみましょう。CeFi ではなく DeFi を強調します。 CeFiは取引所のようなもので、ウォレットをしっかり管理するのが正しい取引所の署名であり、万が一漏洩してしまうと大変なことになります。ウォレットの使用回数や使用方法には多くの手続きやルールが必要であり、不便でもあります。
しかし現在では、署名や計算を行うための分散型の方法が存在します。従来の分散型ではスマートコントラクトの計算結果を誰もが信頼できましたが、秘密を保持することはできませんでしたが、DKG技術では分散型で署名を信頼できるようになり、これは画期的だと思います。暗号の観点だけでなく、大規模に応用できれば、新たなブレークスルーとなることは間違いありません。
シャオシャオ：この ECDSA は非常に低レベルな技術のように見えますが、この技術が実際に実現されれば、イーサリアムとの統合や既存の成熟したプロトコルの統合など、後から他のネットワークを統合することは比較的容易ということですか?
Paul Liu：はい、私たちもそのような見通しに期待しています。ビットコインが最初に選ばれる理由は、ビットコインは現在まだ資産ネットワークに集中しており、信頼できるスマートコントラクトアーキテクチャが欠けているためです。したがって、まずビットコインを組み合わせのパイロットとして選択し、次のステップはイーサリアムの計画を立てることですが、イーサリアム自体も 2.0 の変更があり、そのような段階にあり、まだその変更を待っているところです。ただし、イーサリアムの統合も提案されており、開発中です。したがって、同じテクノロジーをイーサリアムでも使用でき、あまり問題なくイーサリアムトランザクションに署名できます。
イーサリアムはスマート コントラクト プラットフォームであるため、BTC の統合は依然として、BTC アドレスを持ち、署名できる資産に重点を置いています。しかし、イーサリアムには署名するだけではなく、スマート コントラクトがあり、イーサリアムのスマート コントラクトを呼び出すことができる必要があります。イーサリアムのスマート コントラクトを呼び出すということは、署名を行うためのメッセージを送信することを意味するかもしれませんが、イーサリアムが IC 上でコントラクトを呼び出すときにやるべきことがまだいくつかあるため、BTC との統合はまだ少し異なります。双方向コールが実現できれば、ブリッジングとの違いはさらに大きくなる。なぜなら、ブリッジングは1つの資産の抵当権にしかなり得ず、そこでは同等の資産または異なる資産が交換されることになるからである。スマートコントラクトの双方向呼び出しが実現できれば、クロスチェーンにとっても大きなブレークスルーになると思います。
シャオシャオ：わかりましたが、スマートコントラクトの難しさに加えて、資産側も別の難しさになると思いますか?実際のところ、イーサリアムのアカウント モデルはビットコイン UTXO とは多少異なりますが、この一連のロジック全体を最初から書き直す必要があるのでしょうか、それとも実際には特に難しくないのでしょうか?
Paul Liu：アカウント モデルは異なり、実際にはアプリケーションがこれらのアカウント モデルをどのように使用するかに依存するため、これに問題はありません。クエリできるインターフェイスを提供しているだけで、ビットコインのすべての UTXO をクエリできます。イーサリアムのすべてのステータスもチェックできます。クエリが分散されていて、検出された結果が信頼できるものであることを保証します。これを行うことは難しくありません。各 IC サブネット ノードはビットコインのクライアントを実行できるため、他のチェーンのクライアントも実行できます。
シャオシャオ：長期的な将来、多くのメインチェーンを結合した後、各チェーン上のスマートコントラクトとアセットを同じキャニスターから同時に呼び出すことができるようになりますか? その時点では、マルチチェーンの概念は存在しない可能性があります。実際には、1 つのキャニスターすべてのチェーンまたはすべてのウォレット資産を制御できますか?
Paul Liu：これは非常に良い見通しであり、私たちはこれを達成できることを期待しています。
シャオシャオ：アプリケーションの観点から、先ほどライトニングネットワークの話がありましたが、その発展は非常に早いのですが、将来的にビットコインが統合された後、ライトニングネットワークとの相乗効果や統合はあるのかどうかをお聞きしたいのですが。
Paul Liu：Lightning Network の主な技術は、トランザクションをマージできることです。BTC を使用せずに Lightning Network 間で送金することができます。暗号化の知識を使用して、最終的にマージされたトランザクションを 1 つのトランザクションで検証します。このような技術です。同じ技術をIC上に実装することも可能であり、これに意味があるかどうかについては、特に明確ではありませんが、ここで大きな技術的困難はないはずであることを指摘しておきたいと思います。アプリケーション層では、IC の基盤となるインフラストラクチャ上で新しいことを行う必要はありません。
しかし、Lightning Network はこれしかできません。なぜこれらのトランザクションをマージできるのかというと、これを行うための一連の暗号化の知識があるからですが、もっと複雑なロジックを判断できるかどうかなど、もっとやりたいことがあるからです。これらのトランザクションが何らかの条件で成功するかどうかを確認するには、その場所に少し送って、この場所に少し送ってください。プログラミングが必要な場合は、ライトニング ネットワークを使用すると機能しません。そこにはスマートコントラクトを必要とする一連のものが含まれており、ライトニングネットワークもこのブレークスルーを見つけようとしていると思います。したがって、IC 上のスマート コントラクトは、ライトニング ネットワークに次の開発スペースを提供する可能性もあります。
シャオシャオ：支払いに加えて、アプリケーションには、ビットコインを DeFi に持ち込む、独自のエコロジーを持つ、またはビットコイン自体を追加するなど、他の方向性があると理解していますが、将来のアプリケーションの計画があるかどうかはわかりません。ビットコイン支払いですか、それともビットコインと Defi などのアプリケーションを開発しますか?
Paul Liu：これらはアプリケーション層や開発者に任せていますが、多くの開発者は、統合後に自分のアプリケーションを宣伝できるかどうかも含め、この点について非常に懸念していると思います。私たちの財団が現在行っていることから考えると、すべてを貫く 1 つのテーマは、IC ネットワークの分散化を促進したいということです。それがより信頼できるものになることを望み、それがより信頼できるものになって初めて、より大きな拡張が可能になります。容量。
つまり、1 つは IC ノードの分散化であり、もう 1 つは投票メカニズムの分散化です。つまり、基礎となるアプリケーションが私たちは得られた技術に参加し、アプリケーション層で完結できるものであれば、全力でアプリケーション層に引き継ぎますので、財団が特別な立場を持つ必要はありません。
シャオシャオ：先ほどのタイムラインによれば、開発者は今月末にいくつかの基本的なテストと基本的な試みを行うことができるということですが、これは非常に良いニュースです。
