3
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Web上からEthereumトランザクション発行する際の問題点について

Last updated at Posted at 2018-05-11

Webシステムのような中央集権型(クライアント-サーバシステム)にて、例えば、

・会員登録画面にて、ユーザウォレットアドレス等の情報を入力して、ボタンをクリック
→自動的に指定したウォレットのアドレスにトークンが送付される

のようなシステムを構築する場合、下記①~⑧の処理が考えられます。

①【ユーザ】名前、メールアドレス、walletアドレスを入力し登録ボタンをクリック
②【メールサーバ】ユーザから送付された情報を確認し、登録完了確認メールを送付
③【ユーザ】登録完了確認メールに記載されているURLから登録完了手続きを行う
④【DBサーバ】①で入力された情報をDBに保存
⑤【Webサーバ】登録完了画面を生成
⑥【ユーザ】登録完了画面を表示
⑦【ローカルサーバ】オーナーの(プライベート)キーを使用しオーナーwalletのアドレスからユーザwalletアドレスへトークンを転送するようコントラクトを実行しトランザクションを発生させユーザwalletにトークンを送付
⑧【ユーザ】ユーザwalletにトークンが転送されているか確認

このシステムのセキュリティ上の問題点及び疑問点として、
・サーバ上からgeth経由でスマートコントラクトを動作させようとする場合、キーは何処に保存するか?
・トランザクションを発生させる際、上記のようにgethを用いる方法で問題はないか?
(代替方針としては、infuraを用いる、独自にjson-rpcサーバ構築する)
・このシステムにおけるマルチシグウォレットの適用の可能か?

等が考えられます。

svr_20180509.jpg

#####提案
・サーバ上からgeth経由でスマートコントラクトを動作させようとする場合、キーは何処に保存するか?
 →内部ネットワークからのみアクセス可能なサーバ(ローカルサーバ)に保存する。

・トランザクションを発生させる際、上記のようにgethを用いる方法で問題はないか?
 →infura経由では(アカウントを格納しない為)トランザクションの発行がややこしい。
 また、外部サーバの為、ダウンタイムや外部からの攻撃の可能性がある。
 よって、gethを用いるのが無難。

・このシステムにおけるマルチシグウォレットの適用の可能性及び必要性は?
 →マルチシグウォレットはSolidityのモジュール(gnosis MultiSigWallet)を適用する。
 →更にセキュリティ性を高める為に、スクリプトレススクリプトでマルチシグウォレットを実現する方法(論文)が公開されている
(下記論文はBitcoinに関する技術であるが、Ethereumにも応用可能)
https://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180426/fe978423/attachment-0001.pdf
https://eprint.iacr.org/2017/552.pdf

上記論文の概要(google翻訳適用):
Andrew Poelstraは、Bitcoinスクリプティング言語を必要としないスマートコントラクトを実現する方法として、スクリプトレススクリプトという概念を導入しました。 Bitcoinのコントラクトは、スマートコントラクトを構築するための標準的なツールとして浮上してきましたが、Bitcoinスクリプトにはいくつかの欠点があります:まず、Bitcoinネットワーク内のすべてのノードが、トランザクションに含まれる署名とは別にBitcoinスクリプトを解析して検証する必要があります。
第二に、Bitcoinスクリプトには、それらを集約するために必要な内部構造がありません。最後に、Bitcoinスクリプトはブロックチェーン内に不定期に追加され、プライバシーと代替性を妨げる可能性があります。
スクリプトレススクリプトでは、トランザクションには不可欠なデジタル署名スキームの機能しか必要としませんが、ブロックチェーンに表示される要素は公開キーと署名だけです。この状態では、Mimblewimble、Adapter SignaturesまたはScriptlessバージョンのLightning Networkプロトコルなど、スクリプトレススクリプトのいくつかのアプリケーションが提案されています。これまで提案されたアプリケーションはすべて、Schnorr署名方式に依存しています。
一言で言えば、それらはSchnorr署名の線形構造を利用しています。これはECDSAにはありません。そのため、ECDSAベースのスクリプトレススクリプトの構築が利用できないため、SchnorrシグネチャをBitcoinに含めることを多くの人々が主張しています。この論文では、ECDSAに基づいたスクリプトレススクリプトを構築することが可能であることを示します。最も重要な利点は、BitcoinトランザクションがECDSA署名で署名されているため、現在のBitcoinプロトコルと完全に互換性があることです。したがって、ECDSAベースの構造により、Bitcoinで現在Scriptless Scriptアプリケーションを適用できます。

他に問題点及び提案例があれば追記・修正する予定です。

この問題点に関する質問に回答をしていただいた[Hi-Ether]
(https://qiita.com/amachino/items/605ff76209d7193dc92c)コミュニティメンバーに感謝致します。

3
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?