VALUとZaifトークンは無価値である
8月27日 (日)、Zaifトークンが突如2.5円まで急騰したかと思いきや、そのまま0.4円台まで急落し、一部のトークン保有者が「補償しろ」、「ロールバックしろ」というコメントをZaifに向けて浴びせる阿鼻叫喚な光景が広がっています。
(現在は1円付近まで回復した模様)
もともとは、「Zaifを運営するテックビューロがICOを発表したCOMSA」と「Zaifトークン」が連携することへの期待という、投資するには非常に弱い根拠を元に、Zaifトークンは買い上げられていました (+イケハヤ、Zaifチャットなどの煽り)。そのような状況で、Zaif側から「COMSAとの連携予定はない」との発表があり、根拠としていた前提が崩れて価格が急落したという状況です。
この一連の流れについて、市場操作だと言ってZaifを責める声もありますが、トークンで損した人はただの噂をベースに買い上げて損しただけであり、自己責任であると言えるでしょう。
さて、そもそもこのZaifトークンですが、このトークン自体に今現在裏付けとなる価値は何一つありません。最近話題のVALUについても当てはまりますが、このトークンを買ったからといって何か特別な権利を得られるわけではなく、ただのトークンというデジタルアセットを手に入れたにすぎません。株式やBitcoinと比較することで、この点はさらに明確になるかと思います。
目次
株式との比較
株式の場合は企業が生み出した利益剰余金から、「配当」を受け取る権利が会社法で保証されています。もちろん、株主総会決議で利益剰余金を配当に回さないという決定を下すことはできますが、あくまでも最終的に配当を決めるのは株主です (取締役会設置会社の場合は取締役会の決議事項ですが、取締役の選任は最終的には株主が決定しているため、株主の意向に逆らって配当を拒否することは完全にはできません)。
一方、VALUやZaifトークンには、VALU発行者やテックビューロの生み出した利益から配当を受け取る権利は当然ありません。
また、株価は理論的には将来の配当を現在価値に割り戻したものとされています。このように株式には価格が生まれる根拠がありますが、VALUやZaifトークンの場合は将来的に何かしらのお金をもらえることが一切保証されていないため、価格が0円以上になる根拠がありません (VALUの場合、トークン発行者が何かしらの「優待」を提示する場合もあるので、その分は価格として織り込まれる余地はあります)。
さらに、株式のもう一つの機能として、会社の方針に口を出す権利が会社法で認められています。これは、株主総会での議決権であったり、株主総会での議題の提出権であったり様々ですが、いずれも会社法で法律として認められています。当然ですが、ValuやZaifトークンにはこのように会社の経営に口を出す権利は一切認められていません。
ここで、会計上トークンをどのように位置付けられるか考えてみましょう。ValuやZaifトークンの配布時の仕訳は、以下のようになるかと思います。
トークン配布時
現金 (資産) 100 / トークン発行益 (収益) 100
一方、株式の新規発行を考えると、以下の仕訳になります。
新規株式発行時
現金 (資産) 100 / 資本金 (資本) 100
一見同じように見えますがそこには大きな違いがあり、トークン発行益は損益計算書上の売上である一方、株式の場合は貸借対照表上の資本の増加になります。会社から見ると、株式の場合はこれから実施する事業のための資金調達の手段として株式を発行したということになりますが、トークンの場合は稼ぐための一手段でしかないということになります。
上の図でわかるように、この稼ぎは最終的に純利益となって、貸借対照表上の利益剰余金に計上され株主への配当原資となります。つまるところ、トークン発行はトークン保有者を利するものではなく、株主を利するためのものに過ぎません。もちろん、このトークンがその価格に見合ったサービスを提供してくれるのであれば意味のあるものですが、一切の見返りがない以上、トークンとしての価値はゼロであると言えるでしょう。
Bitcoinとの比較
Bitcoinの根元価値が何かという点は議論が絶えませんが、一つの特徴として中央管理者が不在で、分散型で運営されているということがあげられるかと思います。分散型という仕組みにより、特定の人・団体が恣意的にBitcoinの仕組みをゆがめたり、不正を働くことができづらい仕組みになっています。
この点は現在の法定通貨 (Fiat)とは大きく異なる点であり、既存の政府の貨幣政策を信用できない人からすると、資金の退避先として都合がよい仕組みになっています。
一方、Valuやトークンの場合は、特定の発行主体が存在します。Zaifトークンの場合はZaifですし、VALUの場合はイケハヤや最近炎上したYouTuberのヒカルであったりするわけです。法定通貨の場合は貨幣供給量を自由にコントロールできるため、インフレにより貨幣価値が希薄化されることが多々あります。特定の発行体が存在するということは、法定通貨と同様の価格操作が簡単にできてしまうということを意味します。
まとめ
以上のように、VALU、Zaifトークンともに株式のように配当や経営権を約束されたものではなく、またBitcoinのような分散型の仕組みでもないことが分かるかと思います。
今回の騒動は、何かしらの商品を買うときは、その裏にある本当の価値とは何かを意識しないと、自らの資産を溶かすことになるいい教訓かと思います。また、このようなトークンがここまで買い上げられたのは、これまでの限られた人だけが参戦していた暗号通貨界隈から、一部のマス層に開かれはじめた証拠と言えるかもしれません。
ICOトークンの問題点はこちらの動画にもまとまっています
コイナーぼやき部屋Ep4(10/3/2017) 反省会の反省、TB社とCF社の亀裂とICOの問題点、市場規模に騙されるな
リプレイアタック - Bitcoin Cash導入にあたっての対策 -
Bitcoin Unlimited派のViaBTCが、既存のBitcoinからハードフォークする形で、Bitcoin Cashを導入することを発表しました。Bitcoin Cashは当初8月1日にJihan Wu率いるBitmainが予定していたUAHFベースであり、UAHFのウォレットクライアントであるBitcoin ABCを利用することで使用可能なようです。
最近では、ViaBTCがBitcoinとBitcoin Cashに対して中立な立場を表明するなど、状況が混乱しています。
ビットコインますます分裂 | ビットコインの最新情報 BTCN|ビットコインニュース
ViaBTC Claims Neutrality Ahead of Bitcoin Cash's Likely Launch - CoinDesk
ただ、Bitcoin自体への影響としては、フォークの際にReplay Attack対策を導入していることにより、既存のBitcoinネットワークでのトランザクション送信は特に問題なく行えるため、そこまで大きな混乱は広がっていないようです。
今回は、そもそもReplay Attackとは何なのか、またBitcoin CashのReplay Attack対策の概要を整理したいと思います。
Bitcoin Cashの公式サイト
Bitcoin Cash - Peer-to-Peer Electronic Cash
前提
ブロックチェーンがある時点で、ハードフォークにより完全に分裂したと仮定します。それぞれのブロックチェーンの名前を以下のように定義しておきます。
元のブロックチェーン (Bitcoin):A
分裂したブロックチェーン:A1 (元チェーン、Bitcoin)、A2 (分岐チェーン、Bitcoin Cash)
Replay Attack
攻撃方法
リプレイアタックは、以下の流れで発生します。
- 送金者がA1チェーン上で送金
- 攻撃者がその送金トランザクションをコピー
- 攻撃者がA2チェーン上でも送金
これにより、A1チェーン上でのみ送金しようとしていたにもかかわらず、攻撃者によって意図せずA2チェーンでも送金されてしまうことになります。今回の騒動を例にとると、Bitcoinを送金しようとしただけなのに、攻撃者がそのトランザクションをコピーしてBitcoin Cashも送金させられてしまうという攻撃です。
Bitcoin Cashの価値がほとんどなければリプレイアタック対策がなくても問題ありませんが、BitcoinとBitcoin Cashが並存する状況だと、リプレイアタックを恐れてBitcoin利用者が減少してしまうおそれがあります。
Bitcoin Cashにおける対策
この攻撃への対策はシンプルで、A1チェーンとは異なるトランザクションのルールを、ハードフォークしたA2チェーンに導入すれば、A1チェーン上のトランザクションがA2チェーンに取り込まれることはなくなります。逆も然りで、A2チェーンで導入したルールがA1チェーンでは無効なルールであれば、A2チェーン上のトランザクションがA1チェーンに取り込まれることもありません。
今回Bitcoin Cashでは、Sighash Typeと呼ばれるパラメータにSIGHASH_FORKIDという新たなフラグを足すことで、Bitcoin Cashのトランザクションであることを認識しています。Sighash TypeはTransaction Inputに含まれる署名を検証する際 (技術的な話をすると、スタックに積まれた署名を、OP_CHECKSIGによりPublic Keyで検証する際)に、検証の挙動を変更するために利用されています。
この新フラグ(SIGHASH_FORKID)がSighash Typeとしてセットされていると、既存のBitcoinのルールでは正当なトランザクションとは認められなくなるので、Bitcoinのブロックチェーンにこのトランザクションが取り込まれることはありません。
Bitcoin Core抜粋
このコードはBitcoin Coreのクライアントソフト内から抜粋したものですが、「SIGHASH_ALLより小さい」または「SIGHASH_SINGLE」より大きい場合はエラー値が返される仕様になっています。Bitcoin Cashが導入する新たなSighash Typeには、0x40 (=64)をセットする予定ですので、Bitcoin上ではトランザクションが無効として扱われることになります。
Sighash Type
OP_CHECKSIG - Bitcoin Wiki
なお、当たり前ではありますが、このSighash TypeはTransaction Inputに含まれる署名の最終バイトを利用しているため、送金に利用するトランザクションがフォーク前のトランザクションであったとしても、リプレイアタック対策として正しく機能します。
その他のフォーク時の注意事項
UASFが導入されることが取りざたされていた際は、Wipeoutのリスクが騒がれました。Wipeoutを直訳すると「全滅」ですが、その名の通り一度ブロックチェーンに取り込まれたトランザクションが無効化されてしまう事象をさします。これはソフトフォークの場合にのみ発生する事象で、旧チェーンから見て新ルールで作成されたブロックも有効に見えることから発生します。
ざっくりと説明すると、途中までは旧チェーンが新チェーンよりも長く、正当に旧チェーンに取り込まれていたトランザクションがあった際に、新チェーンが旧チェーンより長くなると発生します。旧チェーンのルールでは、新チェーンのブロックも有効に見えるため、ブロックチェーンの長さが長い新チェーンが突如有効になってしまいます(= Reorg)。そうすると、旧チェーンに取り込まれていたトランザクションは無効化されてしまいます。
これに関しては、以下の記事が詳しいので詳細を知りたい方はそちらをご確認ください。
btcnews.jp
なぜか爬虫類の名前ばかりの暗号通貨プロジェクト!Komodoの紹介
インドネシア在住者としては、やはり牛を常食としている地上最強の生物「コモドドラゴン」の名を冠した暗号通貨を避けて通るわけにはいきません。クズコインになる前に内容を共有することで、Komodoユーザーを増やしていきたいと思います。ちなみに、私は残念ながらコインを持っていません。
Komodoとは?
Komodo公式サイトでは、Komodoについて以下のように紹介しています。
Komodo is a Zcash fork that adds the dPoW consensus on top of it and integrates into the SuperNET ecosystem.
KomodoはdPoWコンセンサスアルゴリズムを搭載したZcashのフォークであり、SuperNET ecosystemに統合されている。
Komodo dPoW Whitepaper – Komodo Platform
これだけでは全くわからないので、まずはSuperNET、Zcashを最初に説明し、最後にdPoWとは何かを説明していきたいと思います。
SuperNET Ecosystem
SuperNET Ecosystemとは、Bitcoinに代表される複数の暗号通貨をシームレスに接続するための基盤です。このSuperNET Ecosystemを実現するために、SuperNETチームはKomodoとともにIganaと呼ばれるウォレットを開発しています。
IganaはBitcoinベースの暗号通貨を保管できるウォレットです。IganaウォレットはAtomic Swapを提供しており、Bitcoinベースの通貨間では仲介者なしで、安全な取引ができることを目指しています。このIganaウォレットとKomodoが提供する「dPoW」を利用することで、暗号通貨全体のプラットフォームを構築しようというのがSuperNETが目指す目標です。
これに加えてSuperNETでは、円やドルなどFiatにペグしたアセットを作成することで、暗号通貨だけではなく、Fiatも含めたエコシステムの構築を目指しています。
Q & A: SuperNET, Iguana, and the Role of Komodo — Steemit
Zcash
ZcashはDASHやMoneroなどと並ぶ、匿名系の暗号通貨です。Zcashはzk-SNARKsという仕組みを導入しており、zk-SNARKsを利用することでTransactionを暗号化することができます。KomodoはZcashをフォークして作成したコインであるため、Zcash同様zk-SNARKsを利用して取引を暗号化することができます。
zk-SNARKsの解説記事
Zcash開発チームの記事
Zcash - How zk-SNARKs work in Zcash
Ethereum開発者のVitalikの記事
Quadratic Arithmetic Programs: from Zero to Hero – Vitalik Buterin – Medium
もともとSuperNETのプロジェクトチームは、暗号通貨の「プライバシー」、「スケーラビリティ」、「スピード」を問題視していました。zk-SNARKsを利用することで「プライバシー」の問題の解決を図っています。
残る「スケーラビリティ」の問題は前章で紹介したIganaウォレットによるAtomic Swapと、Komodoが提供するdPoWにより解決を図り、「スピード」の問題は同じくKomodoが提供するdPoWにより解決を目指しています。
dPoW
Bitcoinでは、PoWを採用してハッシュパワーに基づいてブロック承認できる頻度が決まる仕組みをとることで、Sybill Attack(シビルとハイドの二重人格者の話から命名。ハッシュパワーではなく、アドレス単位でブロック承認の機会が平等に訪れる場合、二重人格者のように複数のアドレスを駆使することで、ブロック承認頻度を増やすことができる攻撃)や過去トランザクションが覆されることを防いでいます。
これに対して他の暗号通貨では、Bitcoinと同様にPoWを利用している通貨(Litecoinなど)もありますが、Bitcoinに比べるとハッシュパワーは劣っており、セキュリティの観点でBitcoinに歩があります。また、PoS、PoIなど独自のコンセンサスシステムを利用している通貨(NEMなど)もありますが、ハッシュパワーを担保にしていないため、セキュリティ面でPoWベースのシステムに劣るおそれがあります(たとえば、 時価総額が小さいタイミングで、攻撃者が大量に買占め攻撃を行うと、51%攻撃により一部のトランザクションが無効化されてしまう恐れなどがあります)。
コンセンサスシステムの優越についてはいくつか議論があり、ある程度時価総額が大きくなると、既存のネットワークの過半を占める通貨を獲得することが難しくなることから、PoSに移行した方がセキュリティが高まるという指摘もあります。ただ、少なくとも規模が小さい暗号通貨については、PoWであろうが、PoSであろうがセキュリティリスクはBitcoinよりも劣ってしまいます。
ザキヤマさんのPoWとPoS
そこでKomodoでは、dPoWという仕組みを導入してこの欠点を補うことを目指しています。
図からわかるとおり、Komodoは他の暗号通貨をBitcoinネットワークとつなぐ中間レイヤーとして機能します。Komodoを経由してBitcoinのブロックチェーンにトランザクションをまとめて書き込むことで、作られたばかりでセキュリティ強度が低い暗号通貨であっても、Bitcoinと同等のセキュリティ強度を手に入れることが可能になります。
また、例えばPoSを利用した高速なブロック承認スピードを持つ暗号通貨がKomodoのdPoWを利用することにより、高速な承認スピードとBitcoinが持つセキュリティを合わせ持つことが可能になります。
ちなみに、KomodoブロックチェーンからBitcoinブロックチェーンへのトランザクション書き込みは、Notary Nodeと呼ばれるKomodoコミュニティによって選出された一部のノードが代表して行います。
Komodoの今後
今後はSuperNETとしての暗号通貨基盤を強化するべく、Smart Contractの実行基盤を構築することを目標にして開発が進んでいます。通貨としてのKomodoはEthereumでいうGasのように、プログラム実行の燃料(手数料)として利用される予定です。
ひとつ懸念があるとすると、ICOで調達した資金の一部をBitcoinチェーンへの書き込みに利用しているようですが、ICO資金枯渇後のビジョンが不透明な点でしょうか。おそらく、Komodoチェーンへのトランザクション手数料をBTCトランザクション手数料に流用すると思われますが、Notery Nodeを維持するSunerNET開発チームのインセンティブがなくならないか不安です。
一応、1Komodo = 0.25USDを上回っている限りは維持できるとのことですが、その価格を下回ったときにはKomodoを利用したSuperNETエコシステムは終焉を迎えることになりそうです。ちなみに、現在価格は1Komodo=0.83USDです。
NEM デリゲートハーベスティングの仕組み
日本人はなぜかNEMが好きです。Twitter上ではRippleと並んで、NEMの批判が許されない雰囲気が漂っています。実際にNEMのノード数を見てみると、日本が他を引き離して堂々の1位です。
ちなみに、私が住むインドネシアの状況はというと、
...1ノードもない。今ならインドネシアで最初のNEMノードになれそうですね。どうせなるなら、スーパーノードになりたいので、スーパーノードになるための300万XEMの寄付受付中笑
さて、NEMの魅力ですが、Ethereumほどの自由度はない一方、ドキュメント監査機能(アポスティーユ)やアセットの作成(モザイク)が、デフォルトで簡単にできる点は非常に魅力的ですね。しかしそれ以上に、「ハーベスティング」の存在がNEMの魅力を底上げしている気がします。
そもそもハーベスティングとは
ハーベスティングとは、NEMのトランザクションが詰まったブロックを承認する代わりに、そのブロックに詰め込まれたトランザクション手数料を受け取れる仕組みです。
Bitcoinでもマイニングによってトランザクション手数料を受け取ること(+新規コインの発行)ができますが、ASICと呼ばれるマイング特化のチップを利用して、ガンガン電気を使わないと収益が上がらない状況です。一方、ハーベスティングは「デリゲートハーベスティング」と呼ばれる方法を使えば、別のノード (NIS)に代わりにブロック承認作業をしてもらうことができ、高性能チップや電気代は必要ありません。
なお、どこかの雑誌がハーベスティングによってXEMが発行されるとアホなことを書いたようですが、ハーベスティングはあくまでも承認したブロックに含まれる取引手数料を受け取るだけなので、XEMが新たに発行されることはありません。
デリゲートハーベスティングの仕組み
デリゲートハーベスティング、一見魅力的ですがどのように動作しているのでしょうか?話を進める前に、少し用語の確認をしましょう。
Importance
NEMのハーベスティングはImportanceと呼ばれる、各アカウントに割り振られたスコアによってハーベストできる確率が変動します。インポータンスは主に保有しているNEMの量で決まりますが、それに加えて取引頻度や取引量なども考慮されて決定されます。
ローカルハーベスティング
デフォルトのハーベスティング設定では、デリゲートハーベスティングではなく、ローカルハーベスティングが行われます。その名の通り、リモートのノード(NIS、NEM Infrastructure Server)ではなく、自身のPC上で動作しているノード (NIS)を利用してブロックの承認作業が行われます。
ローカルハーベスティングを行う際は、自身のアドレスにひもづく秘密鍵が自PC上のNISに渡されて、NISはその秘密鍵を利用してブロックに署名を行い、ブロックの承認を行います。なお、これはデリゲートハーベスティングでも同様ですが、ハーベスティングするには10,000XEM以上のXEM(正確には、VestedされたXEM)を保有している必要があります。
デリゲートハーベスティングとは?
さて、ハーベスティングを行う際には、ローカルハーベスティングで見た通り、自分自身の秘密鍵をノード(NIS)に渡す必要があります。しかし、秘密鍵を渡すということは、秘密鍵を受け取ったノードが自分のアドレスをコントロールできることを意味します。
自分が管理していないリモートノード(NIS)に代理でハーベスティングをしてもらう場合は、そのままだと自分が持っているXEMをリモートノードに奪われてしまうリスクがあるので、ちょっとした工夫が必要になります。デリゲートハーベスティングではブロック承認専用の「代理アカウント」を作成することで、この問題を解決しています。
まず、デリゲートハーベスティングでは、実際にハーベスティングを始める前に、NEMブロックチェーン上にトランザクションを送信します。このトランザクションは、自分自身のアカウント(以降、「本体アカウント」)が保有するImportanceを「代理アカウント」にマッピングします。これにより、代理アカウントは本体アカウントが保有するImportanceを利用して、ハーベスティングに参加することができるようになります。
このトランザクションはNEMのダッシュボードでは、「インポータンストランスファートランザクション (Importance Transfer Transaction)」と表示されます。その名の通り、本体アカウントのImportanceを代理アカウントにTransferしているということですね。
代理アカウントはあくまでも本体の「代理」であり、代理アカウントは1XEMも保有していないので、安心して代理アカウントの秘密鍵をリモートノード(NIS)に渡すことができます。本体アカウントが持つImportanceの情報をもとにして、代理アカウントにブロック承認の機会をあたえられた場合には、リモートノード(NIS)が受け取った代理アカウントの秘密鍵を利用して、承認作業を実行します。
承認後、トランザクション手数料を受け取ることができますが、代理アカウントのアドレスにXEMを振り込むと、秘密鍵を保有しているリモートノード(NIS)に、そのXEMを奪い取られてしまうおそれがあります。そこで、ハーベスティングしたトランザクション手数料は、本体アカウントのアドレスに対して振り込むようにすることで、リモートノード(NIS)がトランザクション手数料を奪い取ることができない仕組みにしています。
How Local and Delegated Harvesting Works
デリゲートハーベスティングを維持する理由と仕組み
デリゲートハーベスティングが存在することで、NEMではImportanceに応じて平等にブロックの承認機会が与えられることになります。Bitcoinではブロック承認機会が特定のマイナーに集中してしまっていますが、NEMではネットワーク利用者にネットワークへの貢献度に応じて平等にブロック承認機会(=トランザクション手数料の受け取り)が巡ってくることになります。
また、ハーベスティングを代理で実行してくれるリモートノードにインセンティブがないように思われますが、リモートノードのほとんどはスーパーノードと呼ばれるノードです。スーパーノードは取引手数料とは別に、NEM Supernode Rewards Programと呼ばれる財源からスーパーノード維持の対価としてXEMをもらうことができるため、ノードを維持するインセンティブが生まれています。
スーパーノードについて詳しくはこちら
cryptocoin.hatenablog.com
Layer2解説 第2回 アトミックスワップ
前回、マイクロペイメントチャネルについて解説記事を書きました。通常の順序で行くと、次の記事はライトニングネットワークになりますが、ここではいったん寄り道をしてアトミックスワップ(atomic swap)を先にご紹介したいと思います。
というのも、マイクロペイメントチャネルとアトミックスワップの仕組みは似ており、マイクロペイメントチャネルを理解していると、アトミックスワップの話がスムーズに頭に入ってくるからです。また、アトミックスワップで使われる手法はライトニングネットワークでも利用されていることから、先にアトミックスワップを理解することでライトニングネットワークの理解が容易になります。
目次
そもそもアトミックスワップとは?
アトミックスワップとは、異なるチェーン(コイン)間でコイン交換を実現する方法です。通常、コインの交換(例えばBitcoinとLitecoinの交換)には取引所が使われますが、その場合には取引所を信頼する必要があります。例えばBitcoinからLItecoinに交換したいときに、Bitcoinを取引所に預けた後でその取引所がBitcoinを持ち逃げすると、一時的であっても預けていたBitcoinが取引所に奪われてしまいます。
また、「Bitcoinを持つAlice」と「Litecoinを持つBob」との間で相対でコイン交換をしようとしても、AliceがBitcoinをBobに渡した後で、BobがAliceにLitecoinを渡さずに逃げてしまう可能性があります。当然逆もしかりで、先にBobがAliceにLitecoinを渡したとしても、Aliceが受け取ったLitecoinを持ち逃げしてしまうおそれがあります。
この問題に対応するべく、P2P取引所のひとつであるBitsqureでは「仲介人」という仕組みを利用しています。例えば、当事者間で認識齟齬、紛争が発生した場合には、仲介人の判断で送金の実施、キャンセルができるようになっています(2 of 3マルチシグを利用)。しかし、この手法は仲介人の判断に依存しており、真にトラストレスということはできません。
注目が高まる分散型オープンソース・エクスチェンジ「Bitsquare」とは | ビットコインの最新情報 BTCN|ビットコインニュース
Bisq - The decentralized Bitcoin exchange
アトミックスワップは第三者を介さず、なおかつトラストレスにコインの交換を行うことができるため、これらの問題を解決することができます。
アトミックスワップ理解のための前提 スクリプト
「Bitcoinを送金する」とよく言いますが、実際には、Transaction Outputを送金先の人にロックすると言ったほうが今後の話を理解しやすくなります。
例えば、「AliceがBobにBitcoinを送金したい」場合、AliceはトランザクションのOutputにBobだけが解読できる情報を記載します。これで、このTransaction Outputは、誰もが使えるわけではなく、Bobに"ロック"されている状態になります。BobはBobが持っている秘密の情報を利用してトランザクションのInputに署名することで、そのTransaction Outputを利用することができるようになります。このOutputには、上記例のように「Bobだけが解読できる情報」を埋め込むこともできますし、「AliceとBobの2人が揃わないと解読できない情報(マルチシグ、2 of 2)」のような複雑な条件も埋め込むことができます。
また、このスクリプトはチューリング完全ではないものの、一種のプログラム言語として動作するので、単純な条件分岐処理を埋め込むこともできます(詳しくは、OP_IFで検索してみてください)。
スクリプトについてはこちらにまとめています
cryptocoin.hatenablog.com
アトミックスワップの仕組み
前回同様、マルチシグとタイムロックが登場します。また、先にマイクロペイメントの仕組みを理解した方が理解が早いと思うので、まだ前回の記事をお読みでない方は先にそちらを読むことをオススメします。
基本的な流れ
基本的な流れは以下の通りです。
- AliceがBobにBitcoinを渡すトランザクションを作成する。但し、このトランザクションを使用するにはBobの署名と、Aliceが持つ秘密情報 (X)が必要 (BTC Pay Transaction)
- BobがAliceにLItecoinを渡すトランザクションを作成する。但し、このトランザクションを使用するにはAliceの署名と、Aliceが持つ秘密情報 (X) が必要 (LTC Pay Transaction)
- LTC Pay TransactionをAliceが使用して、AliceはLItecoinを手にいれる。このとき、Aliceの持つ秘密情報 (X) もブロードキャストされる
- BTC Pay TransactionをBobが使用して、BobはBitcoinを手にいれる
勘の良い方はお気づきかもしれませんが、秘密情報(X)がアトミックスワップの実現のために重要な鍵となります。それでは順をおって、処理の流れを見ていきましょう。
1. AliceがBobにBitcoinを渡すトランザクションを作成する (BTC Pay Transaction)
Aliceは、BobにBitcoinを渡すトランザクションを作成します。正確に言うと、Aliceは、以下の情報のいずれかがないと解読できないTransaction Outputを作成します。
BTC Pay Transactionの利用条件
1) BobとAliceの両方の署名(マルチシグ、2 of 2)
2) Bobの署名とAliceだけが知るXという情報
利用条件2)で登場したXは、Aliceが任意に選ぶことができる乱数です。AliceはこのXを公開せずに、手元にとっておきます。最終的にこのXという情報をBobが署名とともにブロードキャストすると、BobはこのTransaction Outputを利用することができます。
以下の引用は、具体的なTransaction Outputの例になります。以下のスクリプトの6行目 (OP_HASH160から始まる行)のように、Xにハッシュをかけた値 (H(x))を、Transaction Outputに埋め込んでおきます。このトランザクションを利用したいBobは自分の署名とともにXをTransaction Inputに埋め込みます。もし、Xにハッシュをかけた値がH(x)となれば、Bobはこのトランザクションを利用できるということになります。
OP_IF
// Refund for A
2 <pubkeyAlice> <pubkeyBob> 2 OP_CHECKMULTISIGVERIFY
OP_ELSE
// Ordinary claim for B
OP_HASH160 <H(x)> OP_EQUAL <pubkeyBob> OP_CHECKSIGVERIFY
OP_ENDIF
Alt chains and atomic transfers
さて、このトランザクションをマイクロペイメントでいう「Deposit」としてブロードキャストするわけですが、Bobが失踪してもAliceがDepositした金額を回収できるように、ブロードキャストの前にRefund Transactionを作成する必要があります。もちろん、AliceがDepositしたBitcoinをすぐには引き出せないように、Refund TransactionにはTimeLockをかけておきます。
Refund TransactionにAliceとBobが署名することで、BTC Pay Transactionの利用条件1)を満たしますので、もしBTC Pay Transactionが利用されずにTimeLock期限が到来したら、AliceはいつでもこのDepositした金額を回収することができます。
2. BobがAliceにLitecoinを渡すトランザクションを作成する (LTC Pay Transaction)
続いて先ほどとは逆に、BobがAliceにLitecoinを渡すトランザクションを作成します。手順1. とほぼ同じことを実施するのですが、一点だけ注意が必要です。それは、Bobがトランザクションを作成する際にも、BTC Pay Transactionで利用したのと同じH(x)を条件式に利用することです。
OP_IF
// Refund for A
2 <pubkeyAlice> <pubkeyBob> 2 OP_CHECKMULTISIGVERIFY
OP_ELSE
// Ordinary claim for B
OP_HASH160 <H(x)> OP_EQUAL <pubkeyAliceb> OP_CHECKSIGVERIFY
OP_ENDIF
ハッシュ関数は一方向関数であり、元の数字からハッシュ値を導くことは容易にできますが、ハッシュ値から元の数字を導くことは(ほぼ)不可能です。つまり、H(x)からXを導くことはできませんから、Aliceは安心してH(x)をBobに伝えることができます。
3. LTC Pay TransactionをAliceが使用する
1.で見た通り、AliceはXという値を知っています。そのためAliceは、LTC Pay Transactionを即座に利用可能です。
4. BTC Pay TransactionをBobが使用する
3.でAliceがLTC Pay Transactionを使用するまで、BobはBTC Pay Transactionを使用することはできませんでした。しかし、3.でAliceがLTC Pay Transactionを使用したことで、BobはXの値を知ることができたので、BobもBTC Pay Transactionを使用することができます。
以上の通り、AliceとBobはお互いを信頼することなく(トラストレスに)、お互いが持っていたBTCとLTCを交換することができました。
まとめ
マルチシグとXという秘密情報を導入することで、二者間でトラストレスに通貨の交換ができました。今回登場したXという秘密情報を利用するアイデアは、最近話題のライトニングネットワークでも鍵となる考え方です。
ライトニングネットワークの場合は第三者を中継してBitcoinを送金するため、途中でBitcoinを中継者に持ち逃げされてしまうおそれがあります。Xという秘密情報を導入することで、最終的な受取人にBitcoinが渡った後でないと、中継者はBitcoinを受け取れないという仕組みにしています。詳細は次回!
Layer2解説 第1回 マイクロペイメントチャネル
BitcoinでLightning Networkを実現する方法はいくつか提唱されていますが、いずれの実装方法もマイクロペイメントチャネルを拡張することで実現しようとしています。今回は、マイクロペイメントチャネルの仕組みを見ていきたいと思います。
目次
マイクロペイメントチャネルの概要と理解のための前提
マイクロペイメントチャネルとは、二者間でブロックチェーンを利用せずに複数回の少額送金を実施するための技術です。複数回の少額送金をブロックチェーン上で実施しようと思うと以下のような問題に突き当たります。
送金者側の負担:取引ごとの手数料
現在Bitcoinでは1トランザクションあたり、数十円から数百円の手数料がかかっており、例えば継続して少額の決済をするような場合(例えば、ガス代金の支払いなど)には、毎回毎回手数料がかかることで手数料負担が重くなってしまいます。
受取人側の負担:非効率なトランザクションによる手数料上昇
少額決済を繰り返すと、ウォレットの中には細かな単位のBitcoinが積み重なることになります。Bitcoinの取引手数料は、送金額ではなく、送金トランザクションのサイズで決まるため、それらのBitcoinを送金に利用しようとすると、トランザクションサイズが大きくなり、取引手数料が高くついてしまいます。
マイクロペイメントチャネルを利用すると、一定期間の間に実行された送金/受金を相殺して一つのトランザクションにまとめた上でブロックチェーンに書き込むため、送金者の取引手数料を節約することができます。また、トランザクションがひとつにまとまるので、受け取ったトランザクションを利用するときにトランザクションサイズが大きくなることも防げます。
さて、これからマイクロペイメントチャネルの仕組みを解説していきますが、マイクロペイメントチャネルを理解するにはいくつかの前提となる知識をおさえる必要があります。
- マルチシグ (2 of 2)
- Locktime
(トランザクションの構造(Input / Output)はわかっている前提です。)
マルチシグ
通常のBitcoinの送金は、「送金先のアドレス」を指定します。アドレスはPublic Keyに対してハッシュ値をかけたものなので、この送金方法をP2PKH (Pay-to-Public-Key-Hash)と呼びます。この場合、受け取ったBitcoinを受取人が使うためには、受取人であることを証明するために受取人の秘密鍵で送金トランザクションに対して署名する必要があります。
これに対して、複数人が署名することで、はじめてBitcoinを利用できるということにしたい場合があります。例えば、企業の調達部門が資材の対価をBitcoinを使用して支払う場合に、調達担当者に加えて経理担当者の承認を必要とするといった場合です。これを実現するのがマルチシグです。
マルチシグを使いたい受取人は、まず受取人のPublic Key全て(上の例の場合は、調達担当者と経理担当者のPublic Key)を送金者に教えます。送金者は受け取ったPublic Keyの両方を受取人とする形で、トランザクションを作成しネットワークに送信します。受取人は、受取人全員(上の例では、調達担当者と経理担当者)が署名したトランザクションをネットワークに送信することで、受け取ったBitcoinを送金に利用できます。
なお、マルチシグは一般的に「2 of 2」のように、「数字1 of 数字2」の形で表現されます。数字2は受取人の数を表し、数字1は受け取ったBitcoinを利用するために必要な署名の数を表しています。例えば「1 of 2」の場合は、受取人は2人いますが、受け取ったBitcoinを利用するには2人のうち1人の署名があれば十分ということになります。
Locktime
「一定時間経過しないとBitcoinを利用できない」ということを実現するための仕組みがLocktimeです。
送金者はLocktimeにブロックの高さ、または時刻を指定します。指定されたブロックの高さ、または時刻以降にならないと、そのトランザクションは各ノードに伝播されたり、ブロックに取り込まれたりすることはありません。
マイクロペイメントチャネルの仕組み
話を簡単にするため、例を用いて説明していきます。登場人物は以下の通りです。
Alice:Bitcoin送金者。ガス会社であるBob Corporationと契約してプロパンガスを利用している。
Bob:Bitcoin受取人。Bob Corporationを経営している。
基本的な仕組み
マイクロペイメントチャネルでは、AliceとBobのマルチシグアドレスに対して、Aliceが一定額のBitcoinをDepositすることで取引開始となります。ここでは仮に、Aliceがマルチシグアドレスに対して、10 BTCをDepositしたと仮定して話を進めます(このDepositトランザクションをOpening Transactionと呼称することとします)。
Opening Transactionをブロードキャストする前に、Aliceの10BTCがマルチシグアドレスにロックされたままにならないように下準備が必要になります。例えば、以下のような事態が考えられます。
- Bob Corporationが倒産
- Aliceがガス会社を乗り換えようと思った時に、Depositしている10BTCをBob Corporationに人質として取られる
この事態を防ぐため、Opening TransactionのDeposit額全額(10 BTC)をAliceに返金するトランザクションにAliceとBobが署名して、Aliceがそのトランザクションを保持しておきます (以後、Refund Transactionと呼称します)。また、すぐにDepositがAliceによって引き出されることを許容すると、今度はBob CorporationがAliceに騙されてしまうおそれがあるため、このトランザクションにはLockTimeを設定しておきます。例えば、ガス契約期間を1ヶ月間と仮定して、このトランザクションが利用できる日を1ヶ月後のX月31日としておきましょう。BobはX月31日を過ぎた後もマイクロペイメントチャネルを閉じないでいると、このトランザクションによって全額をAliceに戻されてしまうので、X月31日までにマイクロペイメントチャネルを閉じる必要があります。
さて、Bob CorporationはAliceとガス契約を結んでいます。話の単純化のために、Aliceが1回ガスを使用すると、使用量に関わらずAliceはBobに対して1BTCを支払わなければならないとします。
X月1日、Aliceはガスを一回利用しました。AliceはBobに対して1BTCを支払わなくてはなりません。そのために、AliceはOpening TransactionをInputに利用したトランザクションを作成してAliceの署名を施し、Bobに対してこのトランザクションを送信します (以後、Pay-to-Bob Transaction1と呼称します)。この時点ではまだBobの署名がなく、ブロードキャストされていないため、このトランザクションがブロックチェーンに書き込まれることはありません。
Pay-to-Bob Transaction1
■Input
Opening Transaction
■Output
to Bob Address 1BTC
to Alice Address 9BTC
BobはもうこれでAliceとの契約を終わりにしたければ、Aliceへのガス供給をストップして、Pay-to-Bob Transaction1にBobの署名を加えた上で、他のノードにブロードキャストします。しばらくした後、このPay-to-Bob Transaction1はブロックチェーンに書き込まれて、取引が確定します。すなわち、マイクロペイメントチャネルがクローズされることとなります。
ここでは、BobはAliceと引き続き契約を継続したいため、このトランザクションをブロードキャストせず、Bobの手元にとっておいたとします。
X月2日、Bobの思惑通り、Aliceは再びBob Corporationの高額なガスを利用したため、AliceはBobに1BTCを追加で支払わなければなりません。ここでAliceは新たなトランザクションを作成して、Aliceの署名を加えた上でBobにこのトランザクションを渡します(Pay-to-Bob Transaction2とします)。
Pay-to-Bob Transaction2
■Input
Opening Transaction
■Output
to Bob Address 2BTC
to Alice Address 8BTC
このトランザクションはPay-to-Bob Transaction1と同様に、Opening TransactionのOutputをInputとして消費します。同じOutputが二回使われることはないため、Pay-to-Bob Transaction1とPay-to-Bob Transaction2は両方とも利用されることはなく、どちらか片方だけが利用されることになります。受け取ったBobが取引を確定させたい場合は、当然受け取る額が大きいPay-to-Bob Transaction2をブロードキャストすることになります(仮にBobがPay-to-Bob Transaction1をブロードキャストした場合は、Bobは1回分のガス利用料を取り逃がすことになります。Bobが損するだけなので、Bobがそれを選ぶのは自由ですが、BobがPay-to-Bob Transaction1をブロードキャストするインセンティブはありません)。
双方向での送金
さて、Aliceはここに来てやっと、ガス料金が高すぎることに気づきます。Bobに文句を言い、ガス料金を1回あたり1BTCから、1回あたり0.1BTCに減額してもらうことができました。しかも、過去分にも遡求して適用してくれるそうです。
BobはAliceに対して1.8BTC (2 - 0.2)を返金する必要があります。通常の取引であれば、BobからAliceに1.8BTCを送るだけですが、せっかくなので既に作られているマイクロペイメントチャネルを利用して返金することにします。返金するためには、以前の取引をなかったことにして、新たに0.2BTCをAliceからBobに送ることにすればよさそうです。そこでAliceは、以下のトランザクションを作成・署名して、Bobに送りました。
Pay-to-Bob Transaction3
■Input
Opening Transaction
■Output
to Bob Address 0.2BTC
to Alice Address 9.8BTC
これに安心したAliceは、Bob Corporationは返金に応じてくれて、Bitcoinも使えるいい会社だと友達にも紹介し始めます。紹介された友達はAliceの勧誘に応じて続々とBob Corporationと契約を結びました。
しかし、Bob Corporationの経営は悪化していました。できる限りのBitcoinを受けとった上で計画倒産するべく、最後に送られてきたPay-to-Bob Transaction3ではなく、2BTCを受け取ることができるPay-to-Bob Transaction2をブロードキャストして、ペイメントチャネルをクローズしてしまいます。これにより、Aliceは0.2BTC支払うだけでよかったはずが、2BTCを支払うことになってしまいました。さらには勧誘した友達からもそっぽを向かれてしまいます。Aliceは裁判所で戦うことを決意しました。
このままAliceとBobの法廷闘争を続けてもいいのですが、法廷闘争になる前にこの事態を防ぐことはできなかったのでしょうか?よくよく考えてみると、Bobの詐欺行為を防げなかった原因は過去分のトランザクションを取消しできていなかった点にありそうです。
過去トランザクションの取り消し
それではどのようにすれば、過去トランザクションを取消すことができるでしょうか?ここでは再びマルチシグとLocktimeを利用することで、この問題を解決します。どういう発想をするかというと、「もし過去のトランザクションをBobが使ってしまった場合、Depositしていた全額をAliceに戻してしまうという約束にしておけば、Bobが過去のトランザクションを使うインセンティブをなくすことができる」と考えます。
さて、AliceとBobのマルチシグにAliceが10BTCをDipositしたところまで時間を遡ります。
今回Aliceは、Bobに騙されない方法を考案しました。最初の1BTCのガス代支払いのために、Aliceは以下のPay-to-Bob Transaction1をBobに送ることにしました。
Pay-to-Bob Transaction1
■Input
Opening Transaction
■Output
to マルチシグ (Bob Temporary Address1 & Alice Address) 1BTC
to Alice 9BTC
騙されてしまった最初のPay-to-Bob Transaction1からの変更点は、「Bobに1BTCを送金するOutoput」が、「マルチシグへ1BTCを送金するOutput」になっている点です。注意が必要なのは、マルチシグで使われているBobのAddressはTemporary、つまり捨てアドレスである点です。ここではその意味には深く入らず、先に進むことにします(後で過去トランザクションを無効化するタイミングで、なぜ捨てアドレスを利用したかがわかります)。
さて、Bobが1BTCを最終的に獲得するには、このトランザクションに加えて、マルチシグからBob Addressへの支払いトランザクションを作成する必要があります。そこで、Aliceは以下のトランザクションに署名して、Bobに送っておきます。なお、このトランザクションにはLockTimeを設定しておきます。ここではOpening TransactionのLocktimeより1日だけ前のX月30日にLockTimeを設定しておきましょう。
Pay-to-Bob Transaction1-a
■Input
Pay-to-Bob Transaction1
■Output
to Bob 1BTC
LockTime付き
Bobは1BTCの受け取りで取引を確定させたければ、Pay-to-Bob Transaction1とPay-to-Bob Transaction1-aトランザクションに署名をしてブロードキャストすれば取引を確定できます(Locktime分、受け取りを待つ必要はありますが)。
さて、Aliceはガスを再び利用してしまったので、もう1BTCを支払う必要があります。今回はPay-to-Bob Transaction2を送るのに加えて、過去分のトランザクション(Pay-to-Bob Transaction1)を取り消してみたいと思います。まずは、さきほどと同様にAliceはトランザクションを作成します。
Pay-to-Bob Transaction2
■Input
Opening Transaction
■Output
to マルチシグ (Bob Temporary Address2 & Alice Address) 2BTC
to Alice 8BTC
このトランザクションをBobに送り、Bobがこの新規トランザクションの状態を承認した場合は、BobはBob Temporary Address1を作成するのに利用した秘密鍵をAliceに送ります。これで準備完了、Bobは過去のトランザクションを使えなくなりました。捨てアドレス (Temporary Address)を使用していたのは、秘密鍵をAliceに暴露するためだったのです。
ここで例えばBobがTransaction1を誤ってブロードキャストしたとします。Bobとしては「Pay-to-Bob Transaction1-a」を利用して、BitcoinをBobのアドレスに送ろうと考えます。しかし、このトランザクションはLocktimeが設定されていてX月30日までは送金を確定することはできません。そこでAliceは、約束を破ったBobに対して制裁を加えるべく、さきほど受け取った「BobのTemporary秘密鍵」と「Aliceの秘密鍵」を利用して、以下のトランザクション (以下、Remedy Transactionと呼称します)を作成してブロードキャストします。これにより、AliceはDipositしていた10BTC全額を回収することができます。
Remedy Transaction
■Input
Pay-to-Bob Transaction1
■Output
to Alice 1BTC
このように、Bobが過去のトランザクションを使用した場合には、Aliceは(LockTimeが到来するまでは)いつでもDepositしていた全額を回収可能ですので、Bobが過去のトランザクションを利用するインセンティブはなくなります(今の例ではそもそもBobが過去トランザクションを利用するインセンティブはありませんでしたが、Transaction3を作成した時のようにBobの取り分が少なくなるパターンでは、Bobが過去トランザクションを利用するインセンティブが生まれるので、このような仕組みで過去のトランザクションを無効化する必要があります。)
以上の通り、過去トランザクションを取消すことができました。あとは、Bobが最新のトランザクションを確定させたくなったら、最新トランザクションをブロードキャストすることで、トランザクションをブロックチェーンに書き込み、いつでもペイメントチャネルを閉じることができます。
さらに、Aliceの側からもペイメントチャネルを閉じることができるように、Bobもトランザクションを作成・署名してAliceに渡しておくというステップを追加すれば完成です。ここは大した話ではないと思うのですが、文章で書くとダラダラ長くなってしまうので、詳細を知りたい方は以下のリンクの解説記事その1をご覧ください。
Layer2解説、第2回はアトミックスワップ
cryptocoin.hatenablog.com
参考資料
概要記事
http://doublehash.me/micropayment-bitcoin/#more-1083
ビットコインの Lightning Network メモ
Working with micropayment channels (英語)
解説記事 (英語)
解説記事その1。体系的にまとまっていて、なおかつわかりやすい。
Lightning Networks Part I: Revocable Transactions – Rusty Russell's Coding Blog
解説記事その2。Lightning Networkの解説資料だが、前半はほぼマイクロペイメントチャネルの説明。詳細解説版。
https://lightning.network/lightning-network-paper.pdf
マルチシグやLocktime
安定のMastering Bitcoin。
Mastering Bitcoin: Unlocking Digital Cryptocurrencies
- 作者: Andreas M. Antonopoulos
- 出版社/メーカー: O'Reilly Media
- 発売日: 2014/12/03
- メディア: Kindle版
- この商品を含むブログを見る
Ethereumプロジェクト紹介 第2回 EncryptoTel
前回の「Ethereum プロジェクト紹介」では、Melonportを取り上げました。今回は、ICO情報サイトのcoinscheduleの情報を元に、直近のEtheruem ICOに関わるプロジェクトを見ていきたいと思います。まずは、EncryptoTelを取り上げます。
Coinschedule - The best cryptocurrency ICO list. Only selected ICO crowdfunding projects
掲載予定
EncryptoTel (今回)
MobileGO
Veritaseum
Back To Earth
Populous
FundRequest
(*) ここに掲載しているプロジェクトは、これから調査予定で、現時点では詳細を調べていません。ここに掲載する情報は投資をオススメするものではなく、ただの調査リストとお考えください。
前回の記事
cryptocoin.hatenablog.com
EncryptoTel
公式サイト
Encrypto Telecom
Whitepaper
http://ico.encryptotel.com/assets/pdf/EncryptoTel_WP_v1.pdf
このプロジェクトでは、SkypeやLine通話のようなWeb通話を暗号化することで、個人間、企業間の通話を盗聴から防ごうというプロジェクトです。公式サイトでは個人間の通話に関しても情報が掲載されていますが、メインとなるターゲットは企業で使用されているPBX(後ほど記載)を、EncryptoTelでリプレースすることのようです。
具体的な使用方法ですが、ZoiperなどのIP電話の統合管理ソフトと接続して利用する形になるようです。設定方法はこちらのPDFにまとまっています。
https://encryptotel.com/files/OtherMobile.pdf
PBX
PBXとはPrivate Branch Exchange (構内交換機) の略で、企業内で電話交換をするための装置になります。いわゆる、「内線」を実現するための機械、仕組みです。最近では複数拠点間でIP通信を実現し、電話代を抑えることが可能なクラウド型PBXも登場しています。EncryptoTelはこのクラウドPBXの一種としてカテゴライズできるかと思います。
基礎から始めるIP-PBX[第1回 IP-PBXのイメージを掴もう] | Call Center Trends
クラウド全般にいえることですが、企業がクラウドを導入しようというときに最も懸念する点が「セキュリティ」です。複数社で機能を共有することで規模の経済が働くため、一般的にクラウドのほうがコスト面で優れていますが、外部ネットワークに接続する必要があることから、盗聴の危険性は少なからず上昇します。これに対して、例えばクラウドベンダーのAWSなどではVPNだけではなく、専用線の引き込みを認めるなどしてセキュリティに対する懸念払拭に取り組んでいます。
仕組み
さて、肝心のEncryptoTelのWhitepaperを読んでみます。しかし、残念ながら、Whitepaperを読んでも思想やら、提供予定の機能紹介ばかりで、技術的な仕組みが全く書かれていません(笑)。推測100%ですが、以下のような感じかと考えています。
ユーザ登録機能:ブロックチェーンを利用
PBX機能:ブロックチェーンを利用+PBX用のスーパーノードを構築 (?)
通話履歴管理+課金機能:ブロックチェーンを利用
通話機能:通常のP2P通信を利用
例えばSkypeでは、ユーザ登録情報を中央のサーバで一元管理しています。その部分は確かに中央集権的な仕組みを利用せずとも、ブロックチェーンを利用することができるのでサーバ構築・運用費用分のコスト削減は可能かと思います。
また、ブロックチェーンとは一切関係がありませんが、Bitcoin / Litecoinでの利用料支払いを認めることで (他にはUSD, EURで支払いが可能)、通話通信だけでなく、支払いに関しても匿名性を担保しようとしています。
開発方針
現在β版としてEncryptoTelがサーバを保有する形でのクラウド型システムを提供しているようです。ICOにより開発資金を集め、現在のクライアントサーバ型のシステムから、ブロックチェーンを利用したシステムに変更を図っているようです。
トークンの用途
トークンはPBXやIP通話の利用料の支払いに利用されるようです。BitcoinやLitecoinでの支払いも同様に認めるようですが、ETT (EncryptoTel Token)を利用した場合は、ディスカウントすることでETT保有意欲を高める政策です。それに加えて、ETTを保有することで、EncryptoTelの意思決定への参加や、経営状況を確認するサイトへのアクセスができるようになる予定です。
The EncryptoTel Token (ETT): fuel for our telecommunications ecosystem
また、トークンの管理方法は少し特殊な方法を採用しており、EtheruemとWavesの2環境でシームレスにトークンを保持する仕組みになっています。この仕組みの実現には、Blockswapが利用されています。ちなみにBlockswapは次号でお届けする予定の、「MobileGo」でも使用されており、ICOの際のスタンダードになりつつあるのかもしれません。
What is BlockSwap and why will MobileGo use it? — Steemit
WavesとEthereum上に同時にトークンを存在させることができる仕組み。スマートコントラクトで実装してるが、Waves側はサーバーで残高管理する。ネットワーク効果を拡張する技術。通貨の淘汰よりもこれも一つ解かも。https://t.co/ZBd6PUbdU5
— ふーさん ( ぬこイナー ) (@chubchubkun) 2017年4月22日
問題点
PBXの仕組みをどのようにブロックチェーン上で実現するつもりなのかの詳細がありません。PBXを実現するためには、当然ですがPBX内のネットワークと外部の電話網を接続する必要があります。当然ブロックチェーン上でPBXを実現しようとする場合も同様で、ブロックチェーンを保持する各ノードから既存電話網に接続されている必要があります。
通話だけを行うノードもブロックチェーン上に存在すると仮定すると、一種のスーパーノードとしてPBXノードを定義する必要があります。仮にこのPBXノードをEncryptoTelが維持する構成だとすると、結局既存のクラウド型PBXとやっていることは同じになりますので、ブロックチェーンを利用する必要がまったくありません。
唯一新規性があるとすれば、ペイメントまで含めた匿名化ですが、これに至ってはPBX用のブロックチェーンとは一切関係ないため、例えば既存のPBX業者がBitcoin支払いを認めたらそれだけで新規性は失われてしまいます。
肝心の通信暗号化にしても、Skypeなどでも既に採用されているTLSを利用しているだけで新規性は全くなく、ブロックチェーンを利用する必要性も特にありません(おそらく通信はSkypeなどと全く同様のP2P通信でしょう)。
Bitcoin紀行 in シンガポール
ある朝、目を覚ました時、これはもうぐずぐずしてはいられない、と思ってしまったのだ。私はシンガポールのランデヴーホテルにいて、土曜の朝をどう過ごそうかと、ベッドの中で考えていた。
Bitcoinを使ってカフェをめぐる。ジャカルタでは到底できないことであるが、シンガポールでならもしかしてという思いがあった。シンガポールは元々はマレー人の土地を、イギリスのラッフルズが開発した土地であるが、インド洋と太平洋を結ぶ重要な場所に位置したことから、貿易港として発展してきた街である。貿易港という性格から、多様な人種が共存しており、いかにもBitcoinを使うのに適していそうな土地柄であった。
そのような思いを抱きながら、シンガポール行きの飛行機に乗り込んだまでは良かった。しかし、シンガポールにいざ着いてしまうと、当初の目的を忘れさせるシンガポールの魅力に抗えなかった。
マーライオン、マリーナベイサンズ。書いてみると陳腐だが、どれもシンガポールを代表する観光スポットであり、一度は行って見なければと思ってしまう。さらに、実際に行ってみるとどこも想像を超えて楽しませてくるので、ますます深みにはまってしまう。
結局、着いた初日は観光に明け暮れてしまい、Bitcoinを使ってカフェをめぐるという当初の目的はすっかりと頭から消え去ってしまっていた。
そんな中到着2日目、土曜の朝を迎えたわけであるが、Twitterを見ているとあるワードが目に飛び込んできた。
「Bitcoinはコーヒーを買うためのものではない」
7. 結論:ビットコインでしか出来ない新市場を考えよう。コーヒーの支払いはブロックチェーンの役割。
— 大石哲之 Tetsu Bigstone (@tyk97) 2017年4月14日
この私がやろうとしていたことを真っ向から否定する言葉を見た時、私はもうぐずぐずとしてはいられないと思ってしまったのだった。シンガポール人 - 中国人というべきかもしれないが - は合理的な人種だ。オランダ、イギリス統治時代には植民地官僚として、都市設計や警察機構を担っていた。そこには、現地人の反感を直接支配層に向けないという白人支配層の狡猾な理由もあったわけだが、中国人の持つ合理的な思考もその一因であろう。
そんなシンガポール人がBitcoinの決済をしていないというのは、Bitcoinがコーヒーを買うような少額決済に向かないという、ある種の証拠を与えてしまうことになる。そのような間接的な証拠を提示するわけにはいかなかったのである。
Aristry Cafe
外は快晴であった。雨の中出て行くのは憂鬱だが、この天気であれば、気分よく出発できそうだ。地図を見ながら、この日のターゲットを決める。とりあえず1件目として選んだのは、Aristry Cafeであった。ここを1件目に選んだ大した理由はなく、以前あるブログでそこのコーヒーを酷評していたのが気になったからであった。
だいたい、Bitcoinを受け入れるようなコーヒー屋がうまいコーヒーを出すわけがないか。そう思いながら、マリーナベイサンズを抜ける約5キロの心地よいランニングの後に、アラブストリートの近くに位置する、そのコーヒー屋にたどり着いたのであった。
店内は朝の光が絶妙に差し込んでおり、気持ちの良い空間が広がっていた。注文したコーヒーとハッシュドポテトのブランチメニューもなかなかの味であった。ビットコイナーらしくない味だ、と思いながらも、これがビットコイナーのグローバルスタンダードなのかと妙な感慨に耽りながら、ランニングでクタクタの胃に朝食を流し込んだ。
胃に満足感を覚えた後、会計をしようとレジに向かうが、この瞬間はいつも一種の背徳感を覚える。フィアット通貨が世の中のスタンダードなのに対して、大して便利でもないBitcoinをあえて使うのはたいそうな言い方をすれば革命家的な、悪くいうと少しイタい人というレッテルを貼られてる気になってしまう。もっとも、受け取る側も同じ穴の狢であるので、気にする必要はないわけだが。
「この店ではBitcoinが使えるって聞いたんだけど?」
「Bitcoinね?ちょっと待ってね。」
幸先順調である。少し褐色の肌をしたマレー系美人がBitcoinと囁くことに微かな興奮を覚えながら、その瞬間を今か今かと待った。
しかし、どうも様子がおかしい。この美人な店員はあまり決済の仕方が分かっていないようであった。たまらず奥から、こちらもマレー系と思われる男の店員がでてくる。
「Bitcoinは今は取り扱っていない。」
あー、そうか。ビットコイナーにしては、おしゃれなカフェだと思っていたが、使えないということを聞いて、納得がいった。
男の店員曰く、最近はトランザクションの承認に時間がかかるから、決済をやめているとのことであった。所詮、その程度のビットコイナーだったのだなと思いつつ、シンガポール人のビジネス感覚にしばらく感心してしまった。彼らにとってBitcoinは手段であって、目的ではないのだと。
一軒目。Artistry Cafe。
— 25歳海外駐在員 (@cryptoexpat) 2017年4月15日
最近トランザクションが全然承認されないから、Bitcoin支払いをやめたとのこと。最初から幸先悪い笑
ちなみにコーヒーは昔Kojiさんが酷評してましたが、意外に美味かったです。 pic.twitter.com/QsWqqNCPQX
New Green Pasture Cafe
気をとりなおして、2件目のNew Green Pasture Cafeに向かう。ここはGoogleマップ上の評価で、星5を付けており期待していたカフェであった。
しかし、ビルの前まで行ってそれが大きな期待外れであることがわかった。カフェは中華街のフォーチュンビルという建物の4階に入っていたのであるが、外見からはどう見てもBitcoinが使えるようには見えないのである。
おそらく周辺の再開発をした際に、立ち退きを迫られた中小小売業者が優先的に入居したビルなのであろう。Bitcoinの先進的なイメージとはかけ離れた、東南アジアのゴタっとした空間が広がっていた。だいたい、フォーチュンビル、占いビルという名前からしてセンスがない。
4階に上ると、これまた期待ができない雰囲気の店があった。New Green Pastureと言うから、緑の多い公園内にでもあるのかと思ったが、実態は緑色の照明を灯して、店内で薬草を栽培する怪しげな店であった。幸か不幸か、まだ営業時間外であったため、この日はホテルに帰ることにする。1日で2回も痛い目を見るのは精神衛生上よくなかった。
その日はインド人街でカレーを食べた後、ガーデンズバイザベイに行き、久々に都会の、だが新鮮な空気を味わった。同じ東南アジアでもここまで差が出るのはどこに原因があるのかと、答えの出ない考えに耽りながら、その夜は更けていった。
翌朝、前日と同じようにランニングをしながら、次のカフェに向かうことにする。Sarniesというこちらもなかなか評判の良いカフェであった。店の前まで行っても、前日AristryやNew Green Pastureに感じた違和感はない。オシャレ過ぎず、かといって雑多でもない、シンプルないかにもBitcoinを取り扱っていそうなカフェであった。
意を決して乗り込もうと思ったのだが、またもやアクシデントに見舞われる。そのカフェはモールの中にあるのだが、モールの自動ドアが開かないのだ。扉の前を行ったり来たりするが、一向に開かない。おかしい、と思い、Googleマップを見ると、開店時間は確かに8時と書いてある。
もう少し粘ろうか、そうも思ったが、時計の針は既に10時を回っている。空腹感には勝てず、結局別のカフェに行くことにしてしまった。
喜園珈琲店は、地元の人たちが朝ごはんを取ろうと賑わっていた。ビーフンや揚げものなど色々な誘惑があったが、店の定番であるカヤトーストとコーヒーを頼むこととする。カヤトーストは一般的には薄手のパン生地にカヤジャムと言われる甘みの強いジャムを塗った料理だが、ここのカヤトーストは厚手の食パンを使用しており、独特のフワフワ感とジャムの甘さがマッチした絶品であった。
さて、ホテルに帰り、この後どうするかと考えた時に、結局1店舗しかBitcoin取扱"候補店"に行っていないことに気がついた。Bitcoinを使ってカフェを巡るという酔狂なことをしようとしながら、結局何もやらずに貴重な休日を潰そうとしている。だめでもともと、トライしてみよう。そのような気持ちが、頭の中を駆け回った。
その日の午後、私は再びNew Green Pasture Cafeにいた。時刻は2時頃、意外に人も入っている。少なくとも、大麻の販売所ではない、と安心して入って行ったが、なんのことはない、ベジタリアン向けのお店であった。
先払い式である旨を丁稚風の男に告げられ、おもむろに尋ねてみる。
「ここではBitcoin使える?」
「ワット?」
「Bitcoin!」
「ジャパニーズ円は使えねえよ」
これはダメだ。BitcoinのBすら知らない。諦めて、ベトナム風春巻とコーヒーを頼むが、お昼に銀座いつきの天丼を食べて満腹な上に、春巻自体大して美味しくもなく、なぜここにトライしてみようと思ったのか、少し冷めたコーヒーをすすりながら考えこんでしまった。
春巻を食べていると、途中店主と思われるおばあさんが食事の感想を尋ねてきた。老獪そうな雰囲気から、もしかすると、最初の店員ではなく、このおばあさんと最初から話していれば、実は…と裏でBitcoin取引ができたのかもしれないが、それを聞く気力もなく、新緑の牧場を後にした。
Sarnies
カフェがダメなら…と、BitcoinのATMに向かうことにする。クラークキーセントラルの地下には、BitcoinのATMがあるという噂であった。そこに行けば、少なくともBitcoinのチャージをすることはできるし、うまく行けば情報も手に入る。私はそこに賭けてみることにした。
シンガポールリバーを望むクラークキーは夜になると、川沿いのバーやクラブで賑わうデートスポットである。その川沿いにあるクラークキーセントラルの地下一階に、中華系の店主が経営するシルバーショップがあり、そこにはBitcoinのATMが設置されていた。そこで持っていたフィアットを全てBitcoinに変えると、店主から情報を聞き出すことにした。
「Bitcoinが使えるって言われてるレストランにいくつか行ってみたけど、どこも使えないね。どこか使えるところ知ってる?」
「ほとんどないな。ただ、このデビットカードにチャージすればどこでも使える。こっちのが、ベターだ、カンファタブルだ、ラピッドだ、セーフティーだ!」
そういうことを聞きたかったわけではない。シンガポール人の野暮さを嘆きながらも、こちらも無理してBitcoinを使おうとしている論理的な理由があるわけではなかったため、弱みがなかったわけではない。そこにBitcoinがあるから、とでもいえば格好がつきそうなものだが、そのBitcoinが使える店を探し回っているのであるから、話にならない。結局、店主もBitcoinを使えるカフェを知ってはいないようであった。
しかし、少なくともフィアットとBitcoinを繋ぐ接点を見つけられたことで、気持ちは少なからず高ぶった。こうなったら、最後にあのSarniesだけでも試してみようじゃないか。
いざ、切符を買い、電車に乗り、ふと店の位置を再確認しようと思いGoogleマップを開いた。Sarniesと打ち込むと、朝に訪れたSarniesとは異なるところに赤いマークが表示されている。
なんと朝行ったSarniesは全く関係のない店であった。危うく全く関係のないSarniesに行き、Bitcoinが使えないことを嘆いてジャカルタに帰るところであった。逆に、このタイミングで気づいたのは、一人のビットコイナーへのsatoshiからの啓示のようにも思われた。しかも、方向的にも乗り換えがスムーズにできそうだ。
本物のSarniesは中華街の入り口にある。店はきゅっと細長くこじんまりとしていたが、外にはオープンテラスもあり、過ごしやすい雰囲気であった。よく欧米人は何にでもcozyと表現するが、このカフェはまさにcozyと言う言葉で形容するのがぴったりなカフェであった。
カフェラテを注文し、おもむろに、この旅行3回目の言葉を口にした。
「Bitcoin使える?」
「使えるわ」
今回は大丈夫だろう。中華系の美人にそう言われ、やっぱり中華系美女に敵うものはないと思いながら、その時を待った。今思い返せば、Aristry CafeとNew Green Pasture Cafeの失敗もこのフィナーレのためにあったのだと、不思議な感慨にふけっていた。
「ここにタッチして」
そう言われ、戸惑いを覚えた。タッチ?QRコードじゃないのか。よくみるとその端末にはVISAと誇らしげなマークが鎮座している。
「Bitcoinで払いたいんだけど」
「これでしょ?」
もしかして、この店ではBitcoinのデビットカードで支払うことを、Bitcoinで支払うと言っているのか。確かに店側からしたら合理的だ。二重払いに悩むこともなく、一瞬でトランザクションは成立する。しかしだ。多くのビットコイナーがしたいことはそういうことではないはずだ。Bitcoinを使って、何かを買う。そこに意味はない。しかし、Bitcoinそのものを使うことに楽しみを見出しているのだ。
そんな想いも虚しく、QRコードの提示はなかった。しかも、先ほどフィアットを全てBitcoinに変えたため、支払うすべが残っていない。財布を見るとVISAのクレジットカードがある。助かった、と思った反面、それが意味することが頭の中を巡り、敗北感に打ちひしがれた。
シンガポール、そこは合理的な国だ。でも、何かが足りない。合理性を超えて面白いと思ったことを面白くやるという点が欠けているのかもしれない。カフェラテがやけに美味しかったことが、その想いに拍車をかけた。
帰りの空港で、シンガポール滞在の感想を書くアンケートがあった。シンガポールらしく、紙スタイルの原始的なものではなく、電子化された掲示板のようなスペースである。最後に何を書くかは決まっていた。
The bitcoin had failed in Singapore.
(*) この物語は実在の都市、出来事を元にしたフィクションである。
紹介したお店一覧
inspired by 深夜特急
- 作者: 沢木耕太郎
- 出版社/メーカー: 新潮社
- 発売日: 1994/03/30
- メディア: 文庫
- 購入: 13人 クリック: 199回
- この商品を含むブログ (311件) を見る
シンガポールのBitcoinが使えるお店一覧
Ad Categories Bitcoin Accepting Restaurants, Cafes and Bars in Singapore
UASFによるSegwit導入の考察 - ブロックチェーン分岐の永続化を許容するか -
現在Bitcoin界には2種類の派閥があり、分裂危機が取りざたされています。
単純化すると、ひとつはマイナーの利益を代表するBitcoin Unlimited、もうひとつは多くのユーザ(ノード)の指示を集めるBitcoin Coreです。分派のきっかけは、Bitcoinの脆弱性(Malleability)に対応するSegwitの導入に関する意見の相違です。Segwitの導入はトランザクション手数料を低下させることにつながり、マイナー利益を損なうことになるため、Segwitを推進するBitcoin Coreに反対する形でBitcoin Unlimitedが生まれました。
Segwitの導入には、マイナー(正確に言うと、過去2016ブロック)の95%以上がSegwit導入賛成シグナルを送っているという条件があり、現在のシグナリング(30%程度)を勘案すると、いつまでたってもSegwitの導入は実現されない状況です。そのような状況で、ある匿名ユーザが「Segwitが導入されない場合にはユーザ主導でのSegwit導入 (UASF、User Activated Soft Fork)を実施する」という提案を行い、BIP148として審議中の状態になっています。
Bitcoinのバージョンアップ方法
Bitcoinのバージョンアップ方法は、大きく分けて2種類あります。ひとつは旧バージョンと新バージョンの互換性が完全になくなるハードフォーク、もうひとつは旧バージョンから見ても、新バージョンで採掘されたブロックが有効に見えるソフトフォークです。今回は、ソフトフォークに的を絞って話を進めます。
従来、Bitcoinのソフトフォークの際には、BIP9で定義されている方法を利用してきました。
BIP9とは、マイナーがブロックを採掘する際に、ブロック中のversion bitと呼ばれる領域に指定されたbit値をたてることで、そのソフトフォークの賛成を表明する方法です。逆にbit値をたてないことで、そのソフトフォークに対して反対を表明できるわけです。以下の図で言うと、Versionと書かれている部分の一番下の桁がSegwit導入への賛成/反対を示しています。
導入賛成/反対状況
2 (16進数) =Segwit導入賛成
0 (16進数) =Segwit導入反対(or 未準備)。
BIP9で定められている通り、過去2016ブロック(約2週間)のうち95%のブロックがSegwit賛成を表明している状態になった時、Segwit導入がロックインされます。そして、さらに2016ブロック経過したタイミングで、Segwitが正式に導入されることになります。つまり、投票期間と実際の導入期間には、ずれがあるということになります。
UASF
これに対して、UASFとはマイナーの投票によらずにSegwitをソフトフォークで実現する方法です。具体的には、ノードが利用するクライアントソフトウェアに、「Segwitが導入されていないブロックを無効なブロックと判定するコード」を組み込むことで、もしマイナーがSegwit未導入のブロックを採掘したとしてもノード側がそのブロックの受け入れを拒否するというアプローチです。
現在提案されているBIP148の実装では、2017年10月1日以降Segwit導入がロックインされていない場合には、Segwit未導入のブロックを拒否するという実装になっています。
bips/bip-0148.mediawiki at master · bitcoin/bips · GitHub
ちなみに、「ブロックチェーン分岐の永続化」を許容するかしないかで、UASFのハードルは大きく変わってきます。
ブロックチェーン分岐の永続化を許容しない場合
まず、ブロックチェーンの分岐の永続化を許容しない場合は、UASFを実施するにあたって、「マイナー」の少なくとも50%がSegwit導入マイナーである必要があります(ただし、必ずしもSegwit導入時点で50%を満たしている必要はなく、UASFによってSegwit側に鞍替えするマイナーがいる可能性も考慮する必要はあるかと思います)。
理由を簡単に見てみましょう。
Segwit導入ノードの比率に関わらず、Segwit未導入マイナーがSegwit未導入のトランザクションを含むブロックを採掘した場合には、当該ブロックがSegwit導入ノードで承認されることはありません。
一方、Segwit導入マイナーはSegwit導入済みトランザクションのみを採掘するので、必然的にブロックチェーンは分岐することになります。注意が必要なのは、ブロックチェーンの分岐はブロックチェーンの設計思想から許容されていることであり、重要なのはブロックチェーンの分岐が永続化するかどうかです。
さて状況を改めて考えてみると、旧バージョンを利用しているノードは新バージョンのトランザクションも正当なものとみなしますので、単純にBitcoinのルールに従い、「長さの長いブロックチェーンを正」とみなします。一方、新バージョンを利用しているノードは旧バージョンブロックチェーンを無効とみなすので、「新バージョン側のブロックチェーンを正」とみなすことになります。ブロックチェーンの分岐が永続化しない条件は、「長さの長いブロックチェーン」が「新バージョン側のブロックチェーン」と同一であることです。結局のところ、50%以上のマイナーがSegwit賛成側に最低限存在しないと、ブロックチェーンの分岐は永続化することになります。
ということで、ブロックチェーン分岐の永続化を防ぐためには、少なくとも半数のマイナーの協力を得ないと実現できないということになります。もちろん、この割合はBIP9型のソフトフォークに必要な95%という要件からはかなり緩和されていますが、Segwit賛成マイナー率は30%台をうろうろしていることを考えるといまだに厳しい比率だと言えます。
Segwit賛成票投票状況
Percentage of blocks signalling SegWit support - Blockchain
ブロックチェーン分岐の永続化を許容する場合
ブロックチェーン分岐の永続化を許容する場合には、無条件でUASFを発動できます。しかし、ブロックチェーンが完全に分岐するため、Ethereumのハードフォークのように2種類のコインが出来上がることになります。Ethereumの例で分かる通り、ブロックチェーンの完全分岐はコイン価格を下落させ、Bitcoinへの支持を弱めることにつながりかねません。
結局、ブロックチェーン分岐の永続化を許容するUASFの効果は、Bitcoin Unlimited側がブロックサイズの上限を1Mバイト以上に設定するハードフォークを行うのと同じになります(=完全にチェーンが分岐)。
6月10日追記
以下の動画で紹介されている通り、Re-Organaize (BIP148未導入チェーンが最初は長かったのが、BIP148チェーンの長さが途中で上回ると、BIP148未導入チェーンが無効になる)される可能性もあるので、ハードフォークの効果と同じとは言い切れないですね。ただ、Re-Organaizeされるまでは、2つのコインが発生している状態になるので、一時的でもコイン価格の下落は避けられません。
UASF/BIP148特別収録 with 大石哲之さん
最近の動き
3月27日にBitfuryがUASFによるSegwit導入支持を表明したブロックを採掘したことで話題になりました。
Bitfury Mines a Block Signaling UASF Mandatory Segwit Deployment - Bitcoin News
実際にブロックを見てみると、Bitfuryが採掘したブロックのCoinbase (マイナーが採掘報酬を埋め込むトランザクション) に「Segwit」、「BIP148」という文字が刻まれていることが分かるかと思います。
Transaction 82fcb9de58956b125256b9fe6a9af731f8aa2386a20180fbdc9a908522416c67 - chainFlyer
ただ、ここまで見てきた通り、UASFは特定日以降Segwit未導入ブロックを無効とみなすことでソフトフォークする手法ですので、今回のBitfuryによる採掘ブロックはUASFに対する支持表明をしたに留まります。
Ethereumプロジェクト紹介 第1回 Melonport
最近のBitcoin分裂騒動や、Ethereumを利用したアプリケーション開発コンソーシアムにMicroSoftなどの大企業が参入したことにより、急速にBitcoinとEthreuemの時価総額の差が縮まってきています。EthereumはBitcoinと異なり、チューリング完全なプログラムを実行できることから、分散アプリケーション (DAPP)の実行基盤として注目を集めています。
今回から、Ethereum上で新たに登場してきた分散アプリケーションを調査、紹介していこうと思います。
Melonport 概要
記念すべき第1回として、分散型のアセットマネジメント基盤であるMelonportを取り上げたいと思います。なぜMelonportかというと、CEOのMona El Isaさん(ゴールドマンサックス出身、26歳でゴールドマンサックスVice Presidentとかいうとんでもない経歴笑)が美人すぎて、紹介動画を見ていても飽きないから笑
紹介動画
Melonport - Asset management on Blockchain - Ethereum London
さて肝心の中身ですが、Melonportはデジタル資産への投資を行うファンドマネージャーの行動をSmart Contractで統制するとともに、Ethereum上のブロックチェーンに取引内容を刻み込み監査可能にすることで、これまで不透明な世界であったファンドを、透明性が高い状態にすることを目的としています。
また、ヘッジファンドをスタートするためには、おおよそ1億5000万ドルの投資額が必要とされています。そのため、これまでは限られたプレーヤーでヘッジファンドは構成されており、手数料もETFなどと比べると非常に高価でした。Melonport Protocol上でファンドマネージャー業務に必要なすべての機能を提供することで、ファンドの選択肢を増やし、ファンドコストを切り下げることを目的としています。
ちなみにMelonportという名前は、ギリシャ語で「未来」を意味する言葉から取っているらしいです。
Melonport | Blockchain software for asset management
Melonportの仕組み
投資対象
Melonportでは投資対象となる、デジタルアセットを以下のように3分類しています。
- 実物資産にペッグした資産(金とレートが常に一致しているような資産)
- 暗号通貨などのデジタル資産
- デジタル資産のデリバティブ
上記例で分かる通り、投資先は暗号通貨に限定されているわけではなく、Smart Contractで制御できるすべてのデジタルアセットを含んでいることになります。究極的に言えば、いかなる実物資産もそれをペッグした形でデジタル資産化できるので、どのような資産であってもトレード対象とすることができるということになります。
ポートフォリオ
Melonportではファンドマネージャーは誰でも自らファンドを作ることができます。このファンドのことを、Melonportではポートフォリオと呼んでいます。ポートフォリオは技術的にはCoreとModuleに分けられます。CoreとModuleはいずれも、 Ethereum上のSmart Contractとして作成されます。
Core
Coreはどのポートフォリオでも必須となる構成要素となります。Coreは、ポートフォリオのルールや性質を決めることになる、Module群を束ねる役目を持っています。
Module
Moduleはポートフォリオが資産を取引するのに必要となる取引所の情報や、取引を実施するにあたって必要となるルールを提供します。ファンドの目論見書のようなものであり、Smart Contractでこの目論見書の内容を強制でき、かつ監査可能であることがMelonportの一番の特徴と言えます。
このModuleは誰でも作成することができ、Moduleの開発者はそのModuleの対価としてのCommissionをMelonportのトークンであるMLNで請求することができます。イメージとしては、Apple Storeを想像するとわかりやすく、Melonport上にいくつものアプリケーション(Module)が登録され、ファンドマネージャーはそれを選択して対価としてMLNを支払うことで利用することができるようになります。
例えば、Register Moduleとよばれるモジュールでは、投資対象のデジタルアセットや取引を行う取引所をSmart Contractを利用することにより制限することができます。最近「みんなのクレジット」で投資資金の使い込みやポンジスキームが発覚しましたが、そういったこともMelonportを使用することで防止することができます。
また、金融専門家がCEOなだけあって各国の規制対策も検討しているようで、モジュールにはKYC対応のためのモジュールなども用意されています。
投資方法
各ポートフォリオへの投資方法は2種類が検討されています。ひとつはポートフォリオのShareをどこかしらの市場から購入すること、もうひとつはEtherを払い込むことで対象のポートフォリオの持分(Share)を購入することです。あえてEtherと書いたとおり、ポートフォリオへの投資の際にはMLNを使用する必要はなく、ETHを使用する仕組みになっているようです。
投資先のファンドを選択できるポータル画面
なお、2番目のEtherを払い込むことによりポートフォリオに投資を行う場合には、価格がどのように決まるかが重要になります。投資家としてはポートフォリオを通して原資産に投資したいのであって、ポートフォリオの人気に対して賭け事をしたいわけではないからです。そのことを考慮して、Melonportでは需要により決定される価格ではなく、ポートフォリオに組み込まれた資産価格を元にShareの価格が決定される仕組みになっています。
また、投資信託の購入の際にはよくファンドの購入手数料が重要視されます。購入手数料の仕組みは今現在存在しているファンドの仕組みとほぼ同じであり、2種類の手数料から構成されています。ひとつは固定で必要となるManagement Fee、もうひとつはActive Fund (市場平均ではなく、売買によって市場平均を超えた超過利益を狙うファンド)を購入する場合のみ必要となるPerformance Feeです。
開発タイムライン
2016年12月時点のCOIN INTERVIEWでのコメントを参考にすると以下のようなタイムラインで開発を目指しているようです。現在はPoC (実現性の検証)が終わり、初回のICOを完了した状態です。今後2017年8月に向けて開発を進めていく予定です。
2017年2月 ICO
2017年8月 Draft Versionとして実装完了
2019年2月 ガバナンスの強化やフロントエンドの強化を完了
Melonport Announcement: Token (MLN) Pre-sale February 15th, 2017 — Contribution and Specification…