この技術記事は、Nervos が毎週水曜日に開催する Dev Meetup からのもので、著者は Secret Ape Technology の Nervos AppChain テクニカル ディレクターである Duan Yangyang です。

---

CryptoKitties などのブロックチェーン DApps をプレイしたことがある人は多いと思いますが、特にかわいい猫を見つけて購入したいと思うと、通常、MetaMask をダウンロードしてインストールするように求めるプロンプトが表示されます。 MetaMask は PC ブラウザをベースにしたプラグイン ウォレットです。正常にダウンロードしてインストールするには、インターネットに関する科学的な知識が必要です。インストールが成功したら、MetaMask プラグイン ウォレットを呼び出して支払いトランザクションを完了できます。 。

ただし、携帯電話で CryptoKitties をプレイしたい場合は、MetaMask ウォレットを持っていないため、ゲームを続行できないことがわかります。携帯電話に imToken やその他のモバイル ウォレットがまだ残っている可能性がありますが、残念ながら、モバイル ブラウザから CryptoKitties ゲームを開いた場合、署名支払いのために imToken やその他のウォレットを自動的に起動することはできません。

PC ブラウザに基づくアプリケーションや携帯電話のネイティブ APP アプリケーションなど、DApps を持ち運ぶにはさまざまな方法があることがわかります。同様に、ウォレットにも、imToken モバイル クライアント ウォレット、公式イーサリアム ウォレットなどの PC ベースのクライアント ウォレット、MyEtherWallet などのオープンソース ウェブ ウォレット、さまざまなコールド ウォレットなど、多くの持ち運び方法があります。コールド ウォレットは簡単に理解できます。私の携帯電話がインターネットに接続されていないハードウェアであると仮定します。支払いに署名する必要がある場合、USB ケーブルを使用してコンピュータに接続するだけで署名できます。秘密キーは、プロセス全体を通じてインターネットに公開されません。

つまり、PC ブラウザーと携帯電話で同じ DApp エクスペリエンスを実現したい場合、ウォレット アカウントを頻繁に切り替える必要がなく、ましてや送金を行き来する必要がないのが現状です。 PC側ではMetaMaskウォレットを使用できますが、携帯電話側では完全なDAppを体験するにはモバイルウォレットで開く必要があります。 Alipay と WeChat Pay のワンストップ クロスプラットフォーム エクスペリエンスについて考えてください。そのようなアイデアはありますか。ワンストップのマルチプラットフォーム署名の問題点を解決できるウォレットはありませんか?

さらに残念なのは、メタマスクが公式ブログで、プラグインウォレットは安全ではないため、ユーザーはそのようなプラグインウォレットに多額の資金を入れることは推奨されないと述べたことです。おそらくこの瞬間、あなたは苦笑するでしょう。私は単なる初心者ユーザーです。複数のプラットフォームでトランザクションに署名でき、安全なウォレットが欲しいだけです。この小さな要件は満たされないでしょうか?心配しないで、現在の状況と考えられる解決策を分析しましょう。

すべてのプラットフォームで DApp 署名の問題を解決できるウォレットがあれば、一貫したエクスペリエンスが保証されます。また、モバイル ウォレットの利点は、秘密キーが常に携帯電話のローカルに保存されることです。第二に、ユーザーはさまざまなプラットフォームからのトランザクションを処理するためにさまざまなウォレットをインストールする必要がありません。

したがって、セキュリティと使いやすさ、およびプラットフォーム間で一貫したエクスペリエンスのバランスをどのように取るかが、マルチプラットフォーム署名スキームが解決する必要がある問題です。これが私たちがこれまで見てきた業界の魅力であるため、調査を開始し、解決策を提供しようとしました。

既存のインターネット アプリケーションが参考になるかもしれません。下の写真の左側は、携帯電話の Alipay の支払いページです。 Alipay はよく知られており、携帯電話での支払いに Alipay を使用すると、アプリケーションが自動的に Alipay を起動し、Alipay で直接支払いプロセスを完了します。パソコン側のタオバオウェブサイトで支払う場合、タオバオの支払いページにQRコードが表示されますので、携帯電話でAlipayを開いてQRコードをスキャンし、携帯電話で支払いを完了すると、支払い結果が表示されますタオバオに送信されます。完了しました。エクスペリエンスは非常に優れており、非常に安全です。

写真の右側は Netease メールボックスのサービスです。PC ブラウザで Netease メールボックスにログインする前に、アカウント番号とパスワードを入力する必要があります。後で Netease がこれはあまり安全ではないと感じました。アカ​​ウント番号とパスワードを入力します。も面倒だし、パスワードを紛失したらどうすればいいの？？誰もがスマートフォンを所有しており、携帯電話は比較的プライベートで安全性が高いことを考慮すると、ブラウザでログインする際にQRコードが付与され、携帯電話のメールアプリでQRコードをスキャンすることで、携帯端末でコードが完成します。検証と認証が完了すると、PC ブラウザ上の Web メールは自動的に正常にログインします。既存のインターネット製品の解決策は、ブラウザ側ではより優れたセキュリティを解決できないため、モバイル側でコードをスキャンするより安全な方法でこの欠点を補うことです。

この考え方に沿って考えると、PC ブラウザで CryptoKitties をプレイしていて、かわいい猫を購入するために注文したい場合、以前は科学的にインターネットをサーフィンし、MetaMask をインストールし、ウォレット アカウントを作成する必要がありました。そしてそれを購入し、imToken または他のウォレットを使用して MetaMask ウォレットに ETH を転送し、最後に署名して支払いを行います。 CryptoKitties のトランザクション データを QR コードの形式で直接提示し、モバイル ウォレットをスキャンし、携帯電話上で署名トランザクション プロセス全体を完了してから、トランザクション データをチェーンに送信し、最後にトランザクション結果はブラウザの Web ページに送り返されるため、全体的なエクスペリエンスは非常に優れています。

この計画を考えましたが、後から考えてみると問題が発生しました！どうしたの？

通常の送金トランザクションが問題ない場合、トランザクション データは比較的小さいですが、コントラクトが展開されるとどうなるでしょうか。これは通常の契約です。その機能は単にデータの保存と読み取りです。データフィールドの数は限られています。これを QR コードに置き換えると、ほとんどのアプリがまったくスキャンできないほど高密度の QR コードが見つかります。 . 明らかに、コードを直接スキャンする方法は機能しません。

その後、社内ハッカソンで別の方法を試してみたのですが、データが複雑かつ大容量で、QRコードを直接読み取って携帯電話に送信することができないため、サーバーを中継してデータを転送できないか？これはまだ元の DApp であり、最初に複雑なトランザクション データをリレー サーバーに送信し、次にリクエスト インターフェイスを DApp に返します。この HTTP リクエスト インターフェイスを通じて、クライアントは完全なトランザクション データにアクセスできます。DApp がリクエストを取得した後、インターフェースアドレス、リクエストアドレスからQRコードを生成します。

ウォレット APP は QR コードをスキャンし、リクエスト アドレスを取得し、リクエスト アドレスからトランザクション データを取得します。ウォレットはローカル秘密キーで署名を完了してチェーンに転送し、最後にブロックチェーンによって返されたトランザクション ハッシュを送信します。中継サーバーに接続すると、DApp と中継サーバーが常時接続されているため、DApp はトランザクション ハッシュを取得し、トランザクション ハッシュに基づいて後続のビジネス プロセスを処理できます。

これは素晴らしいアイデアです。少なくともいくつかの問題は解決しますが、別の問題も引き起こします。

DApp の正式名称は分散型アプリケーションです。中継サーバーが追加されると、DApp 自体とウォレットの両方が中継サーバーに大きく依存します。サービスが異常または利用不能になると、署名プロセス全体がブロックされます。代わりに、分散型アプリケーションは集中型サーバーに強く依存する必要があり、これはブロックチェーンの分散化の概念と矛盾します。

DApp とウォレットが中央サーバーに大きく依存しているという問題を解決するために、携帯電話をサーバーにできないか考えました。携帯電話とコンピュータが同じローカル エリア ネットワーク内にある場合、IP 経由で相互に直接アクセスでき、コンピュータがサーバーになることができるため、携帯電話もサーバーになることができます。携帯電話はサーバーであり、DApp はトランザクションをサーバーに直接送信します。携帯電話がトランザクション データを取得した後、データに署名してブロックチェーンに転送し、チェーンから返されたトランザクション ハッシュを DApp に送信します。 。これにより、集中化と分散化の間の矛盾は解決されますが、コンピュータと携帯電話は同じローカル エリア ネットワーク内に存在する必要があり、そうでない場合はデータを要求する方法が存在しないという問題があります。

携帯電話をサーバーとして利用する方法は珍しいですが、通常は大容量のファイルを近距離で高速に転送する場合や小規模な2地点間の通信にのみ使用され、拡張には向きません。携帯電話を LAN または 4G に変更すると、その IP が変更され、DApp は接続の IP アドレスを頻繁に変更する必要があります。良好な互換性を実現する方法がない場合、これは良いアイデアかもしれません。

業界の多くのチームもこの問題の解決に取り組んでおり、WalletConnect は最も有名なソリューションの 1 つです。また、リレー サービスも使用しており、このリレー サービスは上記以外のことも行います。簡単に言うと、まず、DApp とリレー サーバーが最初にハンドシェイクを行い、長期セッション接続チャネルを確立します。次に、DApp は将来の暗号化されたトランザクション データ用の対称キーを生成し、DApp は暗号化されたトランザクション データを送信します。トランザクション データの送信先 中継サーバーに移動し、サーバーから返されたトランザクション データ要求アドレスを取得します。

次に、DApp はリクエスト アドレス、対称キー、セッション ID をパックして QR コードを生成し、モバイル ウォレットは QR コードをスキャンしてデータ リクエスト アドレスと対称キーを抽出します。その後、ウォレットはインターフェイス アドレスからトランザクション データの暗号文を取得します。そして、対称キーを使用して復号化し、トランザクション データの平文を取得します。次に、モバイルウォレットでトランザクションの確認、署名、転送を完了し、最後にチェーンから取得したトランザクションハッシュを中継サーバーに送信します。 DAppとリレーサーバーは永続的に接続されているため、リレーサーバーはトランザクションハッシュを取得した後、それをDAppにプッシュし、DAppはトランザクションハッシュに従ってブロックチェーン上のトランザクションの実行ステータスをクエリできます。

WalletConnect は上記の方法と同じですが、さらに一歩近づいています。トランザクション データは対称キーで暗号化されており、セキュリティが向上しています。リレー サーバーはトランザクション データが転送される場所であり、QR コードはDApp. おサイフケータイによる情報通信媒体は、より軽量なデータを伝送します。

このソリューションには、プッシュ サービスと呼ばれる別のサーバーが存在する場合があります。プッシュ サービスがある場合、DApp は後で QR コードをスキャンせずにトランザクション データをリレー サーバーに送信しますが、データを直接プッシュ サービスにプッシュし、プッシュ サービスがメッセージをモバイル ウォレットにプッシュします。次に、署名してチェーンに送信し、トランザクション ハッシュをリレー サービスに通知します。もちろん、プッシュサーバーがない場合でもプロセス全体を実行できますが、モバイルウォレットはコードをスキャンしてトランザクションデータリクエストをトリガーし、その後のプロセスを完了する必要があります。

WalletConnect はパブリック Push サービスを提供するのではなく、パブリックリレー サービスのみを提供することに注意してください。DApp やウォレットの運営者にとっては、一元化された Push サーバーを維持する必要があります。エクスペリエンスとセキュリティは非常に優れていますが、ソリューションには多少の問題があります。 WalletConnect は、この一連のデータ仕様を EIP プロトコルにすることをイーサリアム財団に提案しましたが、現在このプロトコルは議論中であり、まだ最終決定されていません。

前の解決策よりも少し単純な別の方法があります。モバイル開発を行った友人は、DeepLink または単に AppLink を知っているかもしれません。

ブラウザで Web サイトのリンク アドレスを開くと、目的の Web ページにジャンプできることは誰もが知っていますが、スマートフォンの場合、各アプリは情報の孤立した島であり、アプリ間に単純な通信メカニズムはありません。簡単な例を挙げると、タオバオとWeChatは相互にブロックしており、WeChatにあるものはBaiduでは見つけることができません。アプリ間の情報は分割された状態です。したがって、Google と Apple は、オペレーティング システム プロバイダーとして、この問題をオペレーティング システム レベルから解決したいと考えており、AppLink が存在します。

特定のプロトコル仕様に従ってアプリが AppLink サービスに登録されている限り、他のアプリは AppLink サービスを通じてそのアプリに接続し、通信できます。たとえば、PCのブラウザで猫を購入したい場合、購入ページに取引用のQRコードが表示されるので、QRコードの内容がiPhoneのカメラでQRコードをスキャンします。オペレーティング システム AppLink モバイル ウォレットに登録している場合は、モバイル ウォレット ページを呼び出して、その後の署名支払いプロセスを完了できます。

ただし、このサービスはさまざまな理由で広く使用されていません。最も重要な理由は、アプリがデータの共有を嫌がることです。アプリはユーザーの粘着性を高めるために、ユーザーがアプリ内にとどまることを好みます。さらに、Android の断片化は比較的深刻で、多くの国内携帯電話メーカーがオペレーティング システムの基盤となるコードを変更しているため、一貫した良好なエクスペリエンスを提供する方法がありません。したがって、このソリューションは一部の比較的小規模なシナリオで実現可能であり、すべてのシナリオに適しているわけではありません。このデータ プロトコルは、ERC 標準の確立を目指してイーサリアム財団にも提出されていますが、現在草案段階にあり、合意には達していません。

最後のケースは非常に興味深いもので、MyEtherWallet と呼ばれる Web ウォレットがあり、P2P セキュア チャネルを確立することで署名トランザクションを完了するスキームを提案しています。以前は、MyEtherWallet でウォレットを作成する場合、秘密キー、ニーモニック、その他の情報はすべてウォレットによって生成され、ブラウザのストレージ領域に保存されていました。しかし、Web ページ上に秘密鍵を保存するのは実際には安全ではなく、Web ページ自体には一定の保存機能はありますが、そのセキュリティは携帯電話に比べてはるかに弱いため、このセキュリティ問題をどのように解決するのでしょうか。

MyEtherWallet は最近 NEWconnect と呼ばれるモバイル APP をリリースし、少し前に公開テストを開始しました。 NEWconnectというモバイルウォレットを開発したのですが、これはウォレットの機能を多く備えていますが、独立したウォレットとして機能するのではなく、ウェブウォレットと連携して利用されます。たとえば、ユーザーが Web ページ上で 1.5eth のアカウントを転送したい場合、ユーザーは Web ページ上でトランザクションを生成し、携帯電話は P2P を通じて Web ページにポイントツーポイントで直接接続し、確認が行われます。トランザクション ページが自動的にポップアップし、P2P 通信チャネルが Web ページに送り返され、トランザクション処理後に Web ページが更新されてデータが表示されます。

このプログラムの経験は非常に優れており、非常に安全です。プライベートなP2P通信チャネルであるため、トランザクションデータは簡単には盗まれず、上記の問題を完全に解決できます。ただし、このソリューションには拡張が難しいという問題があり、クローズドなシステムでしかデータを転送できません。 P2P自体はピアツーピア通信であり、これを拡張するとチャネル確立のプロセスや暗号化の仕組みなどが必要になりますが、この考え方は学ぶ価値があります。

業界全体としてはまだ最終的な解決策が見つかっておらず、私たちもさまざまな研究や試みを行っており、ハッカソンで暫定的な解決策は得られたものの、まだ完璧ではありません。多くの人が業界の要求や問題点を発見し、積極的に解決しようとしていますが、業界全体が合意に達した解決策にはまだ達していません。

現時点では、多くのブロックチェーン サービスとインターネット サービスの間には、エクスペリエンスの面でまだギャップがあり、インターネット サービスは集中化されており、エクスペリエンスとセキュリティの問題を解決する集中化された方法が数多くあります。ブロックチェーンのアプリケーションも分散化されており、ウォレットやDAppsも分散化されていますが、それをリレーサービスを使えば、分散化の問題を一元的に解決するのと同じことになります。最適解ではありません。

QRコードによる取引データは改ざんが容易であり、中継サービスによる取引リクエストも傍受されやすいため、インターネットアプリケーションであればデータの検証が可能であり、セキュリティも重要な考慮事項です。集中型の方法では可能ですが、分散型アプリケーションの場合、セキュリティと分散型の間のバランスをどのように達成するかについてはさらなる議論が必要です。

Google Play や​​ App Store には多数のウォレット ソフトウェアがあり、そのエクスペリエンスはそれぞれ大きく異なりますが、Alipay のようなマルチプラットフォームの署名支払いの問題を解決することはできませんでした。このため、将来的にはセキュリティ、経験、分散化を考慮したソリューションを実現したいと考えており、MVP の検証と研究を現在も行っています。