対応方法 - エンドユーザ問題

この問題については、AltExecCNSAPIで全て解決する問題です。

以降はその詳細な内容を説明します。

Node化の問題とエンドユーザのEther保有の問題

この問題は一気に両方とも解消します。

通常Ethereumのトランザクションを生成してサインしてEthereumネットワークに流そうとすると、ローカル環境自体がEthereumのネットワークと繋がったEthereumNodeとなって、そこからネットワークにTransactionを流す必要が出てきます。

ClientNode

Ethereumのノードは過去のトランザクションとブロックを全て保持する必要があり、スマホやIoTの機器などをエンドユーザとして考えると、あまり現実的ではありません。

これを回避するため、本サービスではユーザに代替してサインを行うAPIを提供します。

ユーザに代替してサインを行うAPI

エンドユーザ端末のNode化・Etherの保有の問題に対しては、単純にエンドユーザからのリクエストをAPIサーバが受けて、APIサーバで代わりにサインをしてEthereumにTransactionを発行します。

代替トランザクションイメージ

これでひとまずは、エンドユーザ端末がEthereumNodeにならずに済み、かつトランザクションを発行しないので仮想通貨も不要になります。

ただし、この処理では新たないくつかの問題が発生します。

ここから、それぞれの問題に対応していきます。

処理の信頼性の問題

  • 問題点

    本来Ethereumの技術は、本人のサインに基づいて処理を行ったことが保障されるからこそ、あらゆる記録が事実として認められています。

    ただし、この処理では間に入っているAPIサーバが処理を好きなように変更できてしまいます。

  • 解決策

    次のような処理フローに変更します。

    1. リクエスト内容の全てを、クライアント側でTransaction発行と同じレベルでサインする。
    2. 本サービスAPIはリクエスト内容全てと、サインデータを受領し、そのままTransactionに入れる。
    3. Contract上でエンドユーザ自身のサインからアドレスを取得し、処理権限のあるユーザだけをコントラクトで処理する。

    これにより、ユーザ自身のサインでないとEthereum上に記録ができず、Ethereum本来の事実保障レベルを維持したまま、代替サインが実現できます。

    client-sign

APIノードのEther負担の問題

  • 問題点

    前段の解決策で、エンドユーザはサインだけしてトランザクションを発行しなくなり、エンドユーザはEtherを持つ必要がなくなりました。

    その代わりとしてAPIサーバがトランザクションを生成してEthereumネットワークに記録することになるので、APIサーバが費用負担する必要が出てしまいます。

  • 解決策

    エンドユーザがAPIサーバ経由でトランザクションを発行する際に、必ずいずれかのサービスプロバイダーのCNSアドレスを基点とした呼び出し方をしてもらう。

    https://docs.blockchain.conoha.jp/ja/docs/client/alt-exec-cns-contract/send-transaction/

    var contract = new AltExecCnsContract(account);
    contract.call(password, '0x___CNSADDRESS___', 'Building', 'getRoomIds', ['building1'], abi, function(err, res) {
        if (err) console.error(err);
        else console.log(res.join(','));
    }
    

    これは、プロバイダーからしてもバージョンアップ対応が可能な良い方法となります。

    1. APIサーバはエンドユーザからのリクエストを受け付ける。
    2. APIサーバはCNSアドレスがどのプロバイダのものか調べる。(なければエラー返却)
    3. APIサーバは対象のプロバイダの代払い用KeyPairでTransactionを発行。

    CNSへのコントラクトの登録は、プロバイダー自身しかできないため、自身が提供するスマートコントラクトアプリケーションのコントラクトにだけユーザが誘導でき、自身が提供するスマートコントラクトアプリケーションの利用料だけがサービスプロバイダに課金されるようになります。

アタックに対するサービスプロバイダの負担問題

  • 問題点

    これにもさらに問題が発生します。

    サービスプロバイダが用意したCNSに、不正なアクセスが発生した場合、大量のトランザクション処理でGASが大量消費されてしまいます。

  • 解決策

    代払いの処理フローを下記の手順にする。

    1. APIサーバはエンドユーザからのリクエストを受け付ける。
    2. APIサーバはCNSアドレスがどのプロバイダのものか調べる。(なければエラー返却)
    3. APIサーバはTransaction実行前にestimate GASで消費されるGASを計算する。
    4. サービスプロバイダ指定のGASLIMITに到達した場合はTransactionを投げずに終了する。
    5. APIサーバは対象のプロバイダの代払い用KeyPairでTransactionを発行。

    上記3・4を挟むことで、アタックなどが発生してもthrowsでエラー処理をしている限りGASの消費は発生しなくなります。

results matching ""

    No results matching ""