The Coffee Times

シゴト・英語・テクノロジー・人生の楽しみ方を発信してます

「チャネルファクトリー」はペイメントチャネルをより効率的にしうる

 

Bitcoinはスケーラビリティ問題に直面していて、マイクロペイメントチャネルがさばけるトランザクションレートとスピードを上げるので、解決策になりえる、と言われています。しかし、すべてが解決というわけではなく課題もあります。

例えば、マイクロペイメントチャネルは固定の額の資金を、それぞれのチャネルのマルチシグウォレットに入れておく必要があり、チャネルを作るとき・閉じるときにそれぞれトランザクションが必要になる、などです。

それらの課題に取り組む研究がいくつかされていますが、最近発行されたスイスの大学・Blockstream著の論文である提案がされました。ブロックチェーンとペイメントチャネルの間に新しいレイヤーを実装するというものです。

 

 

 

 

マイクロペイメントチャネルとは何か?

この論文では、マイクロペイメントチャネル・ネットワークでの課題を2つあげています。1つ目はブロックチェーンのキャパシティ、2つ目がチャネル開閉のためのウォレットにロックされた資金です。

これらに対する解決策を見る前に、マイクロペイメントチャネルについて説明します。(図は後日追加するかもです)

現在はビットコインブロックチェーンは、非常に少額のビットコインの支払い(マイクロペイメント)を何度も送ることができません。現在は最大ブロックウェイト(ブロックの容量)が4MBなため、平均・秒間10トランザクション以下になってしまいます。

 

ペイメントチャネルでは、まず送信者と受信者が鍵を持つマルチシグのウォレットに固定の額の資金をロックします。そして、ブロックチェーントランザクションを送ることでチャネルが開きます。次にこのチャネル内で、送信者が支払いを何度でも実施することができます。これらの支払いはブロックチェーンに刻まれれるわけではなく(つまりオフチェーンで行われ)、両者のみが関与する支払いです。

 

そしてこのチャネルが閉じたら、「最終的にどうなったか」という残高になるように、結果だけがビットコインブロックチェーンに送られます。

これが、マイクロペイメントチャネルの大まかな概要です。より改良された実装が、ライトニングネットワークで、双方向のペイメントチャネル実装が可能になります。

 

数千というトランザクションがチャネル開閉のための2回のトランザクションのみになるため、大幅な改善といえます。しかしまだこれでも、ブロックチェーンではない既存ペイメントシステムに匹敵するほどにはなりません。

チャネルは2者間でのみ存在するので、もし20人グループのうちそれぞれが、5つのチャネルを開きたいとき、100回ものトランザクションが必要になってしまいます。

さらに、あらかじめロックした資金を超えた場合の解決策がまだありません。

 

 

解決策:チャネルファクトリーについて

この論文で提案されているのは、解決策として新しいレイヤーを組み込むというものです。論文には、「ブロックチェーンとペイメントチャネルネットワークの間にレイヤーを作る。そのレイヤーはチャネルファクトリー(channel factories)と呼び、それにより、関わっている2者が素早く資金のやり取りをできる」とあります。

 

ここで1つ目のレイヤー(ブロックチェーン)と3つ目のレイヤー(ペイメントチャネル)はすでにあるもので、1つ目は資金をロックし、3つ目は実際の送金を行います。提案されている2つ目のレイヤーは、チャネル工場という名の通り、複数が関わるマイクロペイメントチャネルの挙動を管理し、ペイメントチャネルの資金が枯渇しそうになったときに、それを補填するようなことができます。論文では、20個のノードと100のチャネルがあった場合に、90%の節減ができると計算しているようです。

 

チャネルを開閉のその度にトランザクションを作るのではなく、論文の手法では、1回のトランザクションで複数のチャネルを作ることができると書いています。資金は従来のような特定のウォレットではなく、共有ウォレットにロックされるため、このようなことが可能です。さらに資金は、受信者のアドレスのついたメッセージを送るだけで、オフチェーンの送金が可能なようです。

論文で言及されているリスクとしては、グループ内のユーザがチャネルファクトリー(第2のレイヤー)を閉じることができるという点です。人数の大きなグループでは利便性が制限される可能性があります。

また、受信者が署名しないという可能性があります。論文では、タイムロックを設けるか、反則者に罰則を与えるなどの対策が書かれています。タイムロックのほうが効果的なため現在はそちらに注力する可能性が高いようです。つまりタイムロックの時間がすぎたら、現在のチャネルの状態がブロックチェーンにブロードキャストされ(情報が送信され)、チャネルを閉じる、そして罰則はなし、というルールです。 

資金の安全性についてはリスクはないようです。マルチシグのウォレットが、関わっている人すべての署名がされない限り資金は使われないためです。

 

概念的な部分も多いので、研究が進み、また自分の理解がさらに進んだら更新していきます。 

 

https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf

This New Scaling Layer Could Make Payment Channels Ten Times More Effective — Bitcoin Magazine

 

Ethereumの歴史を1000文字で見てみよう

Ethereumは、2014の7~8月にICOがされました。その後、Ethereum Switzerland GmbHという会社がICOの資金で正式にソフトウェアプロジェクトを開始しました。2015年の7月になりEthereumが公開され当時11.9百万トークンがネットワークに存在していました。

 

それ以来ここ2,3年で大きなアップデートがされてきました。

バージョンでいうと今、Metropolisの1つ目のフェーズです。

この前はというと、2015年7月にFrontierのリリースを迎え、2016年3月にHomesteadというバージョンになりました。

Metropolisの2フェーズ目へのハードフォークは、まだ正式な日程はアナウンスされていませんが、2018年のQ2かQ3になるだろうと言われています。

このアップデートのあと、少なくとも1バージョン控えています。(Serenityという名前の予定)

 

 

しかし、すべてのマイルストーン(アップグレード計画)が遅延なくこなせてきたわけではありません。

最も議論になったのが、2016年にThe DAOICOで150 million USドル(約150億円)を調達したときです。

Ethereumそのものでなく、そこに書かれたスマートコントラクトに脆弱性があり、攻撃され、Ethereumは緊急ハードフォークを実施したのです。

(Ethereum Classicを生み出したハードフォークです。)

これ以来、Ethereumのほうが注目を集めていますが、両チェーンともに争いなく共存を続けています。

 

他にもEthereumネットワークへの攻撃はおきてきました。2016年Q4には連続でハードフォークをし、2つの問題を回避したのに加え、DDoS耐性力が高くなり、ブロックチェーンの膨張も抑えることができるようになりました。

さらには、スパム攻撃者の効率性を限りなくゼロに下げることにも成功したと言われています。

しかし、Ethereumが100%安全でセキュアになったというわけではありません。最近では、ウォレットであるParityのバグがあり、Ethereumが簡単に凍結してしまうという状況が起きてしまいました。

coffeetimes.hatenadiary.jp

この問題は今開発者が頑張っているところですが、まだ解決してはいません。

 

これらの多くの課題が残っているにもかかわらず、Ethereumの価格は今年上がり続けてきました。

これを書いている時点では、時価総額300億ドル(3兆円)にもなっています。3年前にはなかったプロジェクトとしては、驚異的な額になっています。

価格は加熱している感もありますが、ユースケースとしてもインフラとしてもBitcoinとは違い競合するわけではないため、一歩一歩、未来の分散型エコシステムを作りあげていくことに期待をしています。

 

参考 :

https://blockgeeks.com/guides/ethereum/

https://themerkle.com/the-history-of-ethereum-in-500-words/

 

 

aeternity(æternity)のæpp開発

æternity(以下aeternity)は分散型aeternityアプリ(通称æppらしい)のエコシステムを作るというゴールに向かって開発を続けており、現在アプリチームは、æppのエコシステムの基礎を作っています。その進捗具合になります。

 

æpp

æternityの投票アプリは、現在Ethereumのメインネットにつながっていて、AEトークンで署名・投票することができます。(もしくは新しい投票の質問を作ることもできます。)他のæppに関してはテスト中であり、EthereumのKovan テストネットに接続されています。

 

そろそろ、AEトークンのfaucet(少量のトークンがお試しとしてもらえるツール)の実装が終わり、コミュニティの人たちがæppを試せし、その結果がテストネットのæppにフィードバックすることができるようです。

f:id:CoffeeTimes:20171123192943p:plain

 

 

モバイルの Identity Manager æppæternityの基本となるæppで、これにより、ユーザは自分たちの個人情報(ID)を管理でき、他のæppも立ち上げることができたり、トークンを使うことができます。

 

f:id:CoffeeTimes:20171123192952p:plain

 

 

またAEトークンを使って誰でもEthereumのメインネット上で、Voting æpp(投票アプリ)を試すこともできます。

 

f:id:CoffeeTimes:20171123193010p:plain

 

Notary æpp(存在証明をする公証アプリ)もあります。

 

 

f:id:CoffeeTimes:20171123193057p:plain

 

開発者向けツール

f:id:CoffeeTimes:20171123193117p:plain

 

UI関連のデータは1つのスクラッチファイルにしてGitHubにおいてあり、随時更新がされます。

 

f:id:CoffeeTimes:20171123193139p:plain

 

さらに 開発者がæpp を直接使えるVue.js æpp compononetsもまとめ始められています。

またここ2週間で行ったこととして以下のように報告がされています。

f:id:CoffeeTimes:20171123193247p:plain

休みなく開発を続けている状況です。

 

参考:

Towards an æpps Ecosystem – æternity blog

ブロックチェーンで使われるハッシュやデジタル署名とは何か?

暗号学について説明として、基礎となる概念2つ、ハッシュとデジタル署名について説明します。

ハッシュとは、任意のデータをインプットしたときに、いくつかのアルゴリズムを通し、outputととして出てきた固定の値をハッシュと呼びます。

 

f:id:CoffeeTimes:20171123124809p:plain

 

このinputは、どのような大きな値も可能です。理論的には無限のbit数のデータを入れ込めます。そしてハッシュアルゴリズムは、数ある中からニーズに合ったものを選ぶことができます。

ここで重要なことは、ハッシュアルゴリズムは無限の大きさの2進数のinputにとっても、計算をし、有限の(固定の)値のoutputを出します。(例えば256bitなどのアウトプットなど)

 

 

一般的にハッシュは何に使われるか

一般的な使い方は、ファイルの証明(フィンガープリント)に使われます。チェックゾーンとかとも言われますね。つまり、ファイルが操作や変更がされていなくオリジナルなものだ!と確認するために使われるのです。

もし私が、何か記事を書きファイルにして、MD5 というハッシュ関数を使って固定の値をつくったとしましょう。

そして、このファイルをダウンロードした人が、そのファイルをMD5ハッシュ関数

で固定の値を出してみたとします。もしこのハッシュ値同士がマッチしなければ、ダウンロードされたファイルは何かしらの変更が加えられた、ということが分かります。

f:id:CoffeeTimes:20171123125322p:plain

 

 

ブロックチェーンは何にハッシュを使うのか

ハッシュは、ブロックチェーンの現在の状態を示すために使われます。inputはブロックチェーンの状態すべてであり(どのアカウントがいくら持っていて、過去にどんな取引をしてなどの情報)、そしてそのハッシュ関数を通じて出されたハッシュ値は、現在の状態を表します。そしてすべてのノードが、「今のブロックチェーンはこれだよね」と同意できることになります。

具体的に、どのような計算が行われているでしょうか。

まず一番はじめのブロック(ジェネシスブロックとも言われます)のために、そのブロック内のトランザクションを使って一番はじめのハッシュ値が計算されます。

このあとにできていくブロックに関しては、前回のブロックのハッシュ値が、「次のブロックのハッシュ値を求めるためのinput」ととして使われます。

このように、それぞれの新しくできるブロックは、その前のブロックをinputにとったハッシュ値で、できていき、ブロックの連なり(ブロックチェーン)が形成されていきます。

このハッシュによる仕組みで、どのトランザクションも改ざんされていない、ということが保証されます。なぜなら上で述べたように、もしトランザクションが変わると、それらをinputにとって導いたときのハッシュ値も変化し、ブロックのハッシュ値も変わるためです。

すべてのブロックチェーンの情報ではなく、ハッシュ値を比べればいいため、不正を検出するのが容易です。Ethereumのブロックチェーンは、数十ギガバイト以上ありますが、たった256bitの16進数ハッシュ値で、現在の状態だというのが表現されているわけです。

 

デジタル署名について

手書きの署名のように、自分であることを証明する署名ですが、暗号技術(数学)を用いて署名がされるため、セキュアな署名といえます。インターネットでは広く使われていて、例えば、自分とサーバーで信頼性を確認するためにデジタル署名を使ったSSLなどを意識せずに使い、ウェブサイトを見ていることも多いと思います。

例えばFacebookをみるときなどは、Google cromeやfirefoxなどのブラウザが、本当にFacebookのサーバーから来ている情報か?ハックされていないか?と確認するために、webページと共に送られるデジタル署名をチェックしています。

 

 

 

公開鍵暗号では、ユーザが、あるアルゴリズムを用い、公開鍵と秘密鍵のペアの鍵を作ります。この2つは数学的に関連付けがされていると思ってもらえば大丈夫です。

公開鍵(パブリックキー)はその名の通り公開され、メッセージを受け付けるためのアドレスのように機能します。

秘密鍵(プライベートキー)は公開されずシークレットの状態のままであり、他のユーザから送られてきたメッセージにデジタル署名をするために使われます。

この署名はメッセージに含まれ、公開鍵を使って確認ができるようになっています。

つまりこのやり方であれば「送信者だけがこのメッセージを送れる」ということを受信者が確かめることができるのです。

このペアの鍵を生成するのは、ブロックチェーン上でアカウントを作るのと同じ挙動になります。さらに、ブロックチェーン上で実行されたすべてのトランザクションは、送信者が秘密鍵によってデジタル署名されるため、アカウントのオーナーだけがアカウントのお金を動かせるということを保証してくれているというわけです。

 

最後に

ブロックチェーンは、ハッシュやデジタル署名なしでは存在しえません。ハッシュは、ブロックチェーンの現在の状態をみんなが本物だと信じるための方法であり、デジタル署名は、すべてのトランザクションが然るべき人(アドレスの所有者)によって作られたものだということを保証するための方法です。これらの特徴を活用し、改ざんされないブロックチェーンが動いています。

 

ERC-20トークンコントラクトはどのように動いているのか

Ethereumの現在の主流のトークコントラクトであるERC20について、特徴と機能、仕組みを見ていきます。

Ethereum Wikiと以下のポストをまとめました。

ERC20 Token Standard - The Ethereum Wiki

Understanding ERC-20 token contracts – Jim McDonald – Medium

What is ERC-20 and What Does it Mean for Ethereum? | Investopedia

 

トークコントラクトとは何か、開発者はどう扱うのか、などに役立てばと思います。

コントラクトの基礎については、こちらのアカウントのところを読んでいただければと思います。

coffeetimes.hatenadiary.jp

 

ERC20は、Ethereumのトークコントラクト用に、共通機能を持つインターフェースとして作られました。今ほとんどの流通しているトークンはERC20です。

このERC-20は、ウォレットで異なるトークンでも残高を一覧で確認できたり、取引所がトークコントラクトのアドレスだけでトークンを上場させることができるなど、多くの構造的な利点があります。

 

目次

 

 

トークコントラクトとは何か

まずそもそもトークコントラクトとは、スマートコントラクトの一種で、「アカウントのアドレスとそれらの残高の対応表」を持ったスマートコントラクトです。

この残高は、コントラクトの作成者が定義した値で、リアルな所有物を表す場合もあれば、金銭的な価値や、ホルダーの評判を示す値の場合もあります。これらの残高の単位をトークンと呼びます。つまり残高が1であれば1トークン所有している、と同義になります。

f:id:CoffeeTimes:20171122234742p:plain

 

あるアカウントから違うアカウントへトークンが送られるとき、トークコントラクトは、それら2つのアカウントの残高を更新します。例えば、画像でいうと0x2299…のアドレスから0x1f59…のアドレスへ10トークン送ったとします。するとトークコントラクトによって、残高は以下のように更新されます。

f:id:CoffeeTimes:20171122234754p:plain

 

トークンの合計の流通量は多くする、もしくは少なくするという操作ができます。(トークコントラクトでそれらの操作を許可するか定義できます。)

まず合計の流通量を多くするには、新しいトークンを発行し(鋳造し)多くすることができます。例えば、「100トークンをアカウント0x4ba5…に鋳造した」とすると、以下のように残高が更新されます。

 

f:id:CoffeeTimes:20171122234810p:plain

 

また合計の流通量は「バーン」(燃やす)ことによって少なくすることができます。例えば、「アカウント0x4919…の50トークンをバーンした」とすると、以下のように残高が更新されます。

 

f:id:CoffeeTimes:20171122234825p:plain

 

バーン以外の方法は、秘密鍵がわからないアドレス(いわゆるThe 0 address)にトークンを送ることです。このやり方は、トークンが使えなくなるという点ではバーンと同じ意味になりますが、存在するトークンの合計量は変化しません。例えば0x93f1…というアドレスで50トークンを 0アドレスに送り、トークンを潰すと、残高は以下のように更新されます。(合計のトークン量は変わっていないことがわかります。しかし実際の流通量は少なくなります。)

 

f:id:CoffeeTimes:20171122234843p:plain

 

単純なトークコントラクトは、上のようなアドレスと残高の対応表の情報を持ちます。「分割」などの複雑な機能を持つトークコントラクトは、より便利になります。

 

 

ERC-20 トークコントラクトのパラメータ

ERC-20 トークコントラクトは、「コントラクトのアドレス」「トークンの合計流通量」によって定義されますが、他にもオプショナルな機能が多くあり、ユーザは細かな設定ができます。トークンの名前、トークンのシンボル、小数以下の桁数などです。これらは後ほど説明します。

 

 

ちなみに、トークコントラクトには中央集権型の登録所はないので、名前やシンボルがかぶったりする可能性があることに注意です。

 

トークコントラクトの name の部分は、トークコントラクトの名前(正式名称的な部分)で、例えば “My token”などです。

長さに制限はありませんが、ウォレットアプリなどで切り捨てられる可能性もあるので、短くするのが良いでしょう。

 

次に symbol の部分は、シンボルを示し、上のトークンであれば頭文字をとって、”MYT” などがよいでしょう。株で言うティッカーシンボルのようなもので、こちらも長さに制限はありませんが、3,4文字のトークンが普通です。

 

 

decimals の部分は、わりと混乱しやすい部分ですが、そこまで難しくはありません。どの程度トークンを分割できるようにするか?という設定をする部分です。(小数点以下が、0~18個になるような設定ができます。18以上も設定ができます。)

 

このdecimalsがある理由は、Ethereumは小数を扱わず、すべて整数で処理されるためです。

では分割が使われないケース、使われるケースを見てみます。

 

まず分割が必要ないケースです。例えば、ライセンストークンがあったとしましょう。

トークコントラクトはソフトウェア・ライセンスの割当を示します。

ライセンストークンを持っているユーザは、そのソフトにアクセスができます。ここでは、ライセンスが0.7個などと小数のライセンスを持っていても意味がありませんね。1.6個なども同様です。

なので、コントラクトの作成者は、「小数以下の桁数を表す」decimals を 0 に設定します。

数名がライセンストークンを持っている状況を想定すると、以下のような残高になるでしょう。

 

f:id:CoffeeTimes:20171122234900p:plain

 

上では100個のライセンスがあるのがわかります。誰かがライセンスを買ったら、そのアカウントにライセンストークンが送られ(残高が変更され)るイメージです。そしてこの残高表を見れば、ライセンスを持っているアカウントかどうか見て確認することができます。

 

 

次に分割が必要なケースを考えてみます。例えばゴールドトークンというのがあったとして、物理的な金の所有権を意味するトークンだとします。

トークンの作成者は、金1kg=1トークンとしたいとします。しかし1kg未満のグラム単位でトークンをやり取りしてもらいたいと考えた場合、Ethereumは整数しかサポートしないため、このままではできません。そこで decimalsを3に設定します。(こうするとトークン数*10の3乗となります)

そして何人かがトークンを持っていると想定したとき、対応表は以下のようになります。

 

f:id:CoffeeTimes:20171122234913p:plain

 

しかし、実際には、decimals が 3 に設定されているため、以下のように単位kgとして見ることができます。

 

f:id:CoffeeTimes:20171122234924p:plain

 

decimals は、人に合わせるための部分と言われて、人にどんなふうに残高を見せるかを設定する部分といえます。なのでゴールドトークンはコントラクト内部の計算では decimals を使うことはなく、Kgの単位で計算がされます。

 

この分割によって、細かいトークンまで扱うことができて、多くのトークンは decimals を 18 に設定しています。

 

まとめ

・1トークンが現実世界の何か1つを表すとき、 decimals を 0 に

・小数以下の桁が決まってるとき、decimals をその桁数に

・どちらでもないとき、細かくトークンを使えるように decimalsを18に

 

 

 

totalsupply はERC20トークコントラクトを定義する最後の部分で、必須のパラメータです。ERC20の仕様には明確にかかれていませんが、totalsupplyはシンプルで、totalsupplyは残高の合計とイコールとなります。

 

 

ERC-20トークコントラクトの関数

ERC20トークコントラクトには、残高をみたり、設定した条件になったら送金をしたりと色々な関数があります。例えば以下のような感じです。

 

balance0f( )関数は、与えられたアドレスの持つトークンを返します。

 

トークンを送る方法は2つあり、1つは transfer( )関数です。メッセージ送信者から他のアドレスに直接トークンを送ります。

transfer( )関数は、外部アカウントに送る分にはよいですが、スマートコントラクト内の関数にトークンを送るときには機能しません。

これはスマコンが走っているとき、資金を送金する元のアクセスの詳細にアクセスはせず、コントラクトをコールしているユーザがコントラクトを走らせるための資金を払っているためです。

 

Doer というコントラクトがあるとしましょう。 Doerは、doSomething( )という10 Do トークンで動くような関数を持つとします。AくんがdoSomething( )をコールしたくて 50 Doトークンを持っているとします。

では実際にどのようにdoSomething( ) を動かすためにDoerにトークンを送れば良いのでしょうか。

 

 

ここで、approve( )とtransferForm( )の2つの関数が必要になってきます。

 

まずはじめのステップは、トークンホルダーが自分用にもう1つのアドレスをつくり(通常はスマートコントラクトで行います)、一定数のトークンを格納します。ここで新しいアドレスに送られたトークンは、allowance(割当)と呼ばれます。トークンホルダーは approve( )を使うことでこの情報を得ることができます。

 

f:id:CoffeeTimes:20171122234938p:plain

 

上の写真で2行目の「0x1f59…」がAくんのアドレスだとすると、 0xd8f0…のアドレスにあるコントラクト Doer に、Aくんアカウントから25トークン送ってもいいよと許可している状態になります。

一度allowanceが作られると、スマートコントラクトが割当数のトークンを、ユーザの割当(図でいうAllowance)から使います。(これはコントラクトの動作の一部として使われます。)

 

この結果、Aくんは doSomething()関数をコールすることができ、この関数は、transferFrom()という関数を使い、10 DoトークンをAくんのアカウントから使うことで、動作を実行します。もしAくんが10 Doトークンを持っていない場合(つまりAllowanceが10未満のとき)は、doSomething()関数は動きません。

 

allowance()関数は、送信できる割当トークンの数を返します。ここで重要なのは、割当は、残高以上になることがある、ということです。図のように0x2299…のアカウントは500トークンを送れることになっていますが、さらに上のほうの図にあるように、90トークンしか持っていません。

allowance()関数を使うコントラクトは、トークン数を計算する際にホルダーの残高も考慮する必要があります。

 

 

ERC20トークコントラクトのプログラム実行(Event)

ERC-20ではコントラクトが定められた入力がされたときに実行するプログラム(イベント)が2つ定義されています。1つ目のイベントは Transfer( )で、これはどのアカウントからどのアカウントへ送られたというトークンの動きの情報を出力します。2つ目のイベントはApproval( )で、トークンの承認の情報を出力します。これらは残高をトラッキングする、もしくは割当の変化をトラッキングするのに使われます。

新しく作られたトークンは The 0 addressとともにTransfer( )イベントを出力します。

 

トークンがバーンされる際は、出力されるイベントはないので、バーンをしたい場合、トークンをthe 0 addressに送り、実質バーンすることが多いです。(発生イベントがなく処理が楽なため、こちらを選ぶことが一般的ということです。)

 

最後に

ERC-20は、トークコントラクトの土台となっていますが、欠点がないわけではありません。そこでERC-223の提案は、安全対策や追加機能をいれていますが、ERC20との互換性はありません。今あるトークコントラクトはERC20を引き続きサポートしながら、ERC223提案も同時におっていく必要があります。

 

 

 

BitcoinとLitecoin、ライトニングチャネルのAtomic Swapに成功

f:id:CoffeeTimes:20171117144856p:plain

 

Lightning Labsの開発チームは、テストネットのビットコインライトコインをライトニングチャネルで交換することに成功しました。(このような異なるチェーンでの通貨のやり取りはアトミックスワップと呼ばれます。)

トランザクションブロックチェーン上に刻まれず、コインの所有者を変えることに成功したことになります。

ライトコイン創始者のチャーリー・リーはBitcoin Magazineに対し以下のように答えています。

「以前実施したアトミックスワップは、オンチェーンであり、ブロックチェーンによる遅延や高い手数料などの制約がありました。」

「オフチェーンのアトミックスワップは、オンチェーンのアトミックスワップよりも簡単で、手数料も低く、プライバシー的にも優れています。」

 

 

ライトニングネットワークは、ビットコイン上の「セカンドレイヤーの支払い」ネットワークとして期待されていて、またライトコインなどの「ビットコインからフォークした他の暗号通貨」へのデプロイは比較的カンタンです。

 

もしライトニングネットワークが異なるチェーン上で実装されると、これらのチェーンは相互にリンクし合うので、ネットワーク上に「あるコインから別のコインに転送してくれる」ようなノードが1つでもあれば、「ビットコインを送り、それと同価値のライトコインを相手側が受け取る」というようなことが可能です。

リーはこのブログポストで、この可能性を感じ、自分の地位を投げ打ってでもSegwitのソフトフォークを支援するようになった、と説明しています。

segwit.org

 

 

  

テストについて

テストはローカルマシンで実施され、そのマシン内に2つのノード(名前はAliceとBob)が建てられました。BitcoinとLitecoin両方のチェーンを監視できるように設定され、固定レートで「テストネットのLitecoinをAliceからBobに送り、テストネットのBitcoinをBobからAliceに送る」ようなライトニングチャネルを作りました。テストの環境下ですが成功し、Lightning Labsは今日ブログビデオを公開し詳細を説明しています。

ノードが今日の取引所のようになり、通貨交換の役割を果たすようになる可能性もあり良いレートを競争しあうようになります。またそのような交換ノードが、支払いのプロセッサとして機能する可能性もあります。

つまりビットコインしか受け付けない店やサイトで、ライトコインが簡単に使えるなどです。またAからBにビットコインを送るのに、途中ライトコインを経由し、安く早くビットコイン送信が可能になります。

 

これからも開発が楽しみです。 

 

参考:

https://bitcoinmagazine.com/articles/atomic-swaps-how-the-lightning-network-extends-to-altcoins-1484157052/

https://bitcoinmagazine.com/articles/lightning-network-now-supports-transactions-across-blockchains/

https://blog.lightning.engineering/announcement/2017/11/16/ln-swap.html

Parityライブラリ自己破壊、何が起きたか、どう防げたか

f:id:CoffeeTimes:20171116005613p:plain

Parityのバグについて昨日、凍結された資金を持つPolkadotの見解を書きました。

そして今日、Parity側の見解がでました。

以下になります。

 

ーーー

116 02:33:47 UTC)にParityマルチシグウォレットの「ライブラリ」スマートコントラクトコードに脆弱性が匿名ユーザによって発見されました。

 

このユーザは脆弱性を利用し、自らをライブラリコントラクトのオーナーとなったのちち、このコンポーネントを破棄しました。Parityのマルチシグウォレットはこのコンポーネントに依存しているため、合計513,774.16 Ether(およそ190億円)および他のトークンを保持する587個のウォレットがブロックされました。ライブラリコンポーネントを破棄した後、ユーザ名「devops199」と名乗るアカウントはgithubにこの内容をあげました。https://github.com/paritytech/parity/issues/6995

 

パリティウォレット(UI)の他のすべての機能には、同様の脆弱性はありません。(

スタンダードのアカウント、非マルチシグアカウントにもありません)

 

影響を受けたユーザには連絡しており、まだ届いていない場合はcommunity@parity.ioまでご連絡ください。この問題が、プロジェクト・資金の将来に対して不安を抱かせてることを認識していて、実行可能な策を模索する努力をしています。

悪用が行われて以来、チーム全体で多くの議論や分析を行ってきました。この記事では、問題に関連する要因を明らかにし、質問や苦情への対応を書いていきます。

 

 

ウォレットのライブラリは監査されていなかったのか?

オリジナルの "Foundation" マルチシグウォレットコードは、Ethereum Foundationの開発チーム(パリティ・テクノロジーズ)とコミュニティのメンバーによって創られ、監査されました。そして多くレビューを受けました。

 

このコードには今回対象となったセキュリティ問題はありません。そして、パリティチームによって、ウォレットが作成されるたびにネットワークに展開される軽量のstubスマートコントラクトに再編されました。ちなみにこれには、一度だけ展開されたライブラリスマートコントラクトなどウォレットのロジックの大部分を含みます。

 

正式な監査はありませんでしたが、7月19日のバグと資金の回収もあり、このコントラクトは社内外に多くのレビューを受けていました。

 

 

事件の前に何が起きたか?

監査された元のスマートコントラクトの状態に近づけるため、できるだけ変更を加えないようにしていました。しかしこれは、ライブラリコントラクトが通常のウォレットと同じ機能を持ち初期化が必要であることを意味し、よってウォレットを消去するために設計された元のself-destruct機能(自己破壊機能)もまだ含まれたままでした。

 

2017年7月19日の攻撃の後、2017年7月20日にライブラリコントラクトを修正し、再度デプロイしました。

 

8月に、Github上のcontributorである、アカウント名 "3esmit”は、デプロイのときにinitWalletが呼び出されるべきようにコード変更をすべきと勧めました。

したがって、私たちはこの提案された拡張をライブラリコントラクトに実施し、

構築時にinitWalletを呼び出すことによって自動的に初期化するようにしました。

この推奨を拡張だと解釈し、変更されたコードは定期的なアップデートのときに展開されることになりました。

 

11月6日03:25:21 PM + UTCに、 'devops199'は7月に導入されたコントラクト内にあった未初期化オーナーを見つけ、それを初期化し、自分をオーナーとして設定しました。その後、devops199はライブラリコントラクトを消し去りました。

 

どのようにすれば防げたのか?

この悪用を避けることができた2つの方法があります。

たとえ誰かが所有権を持っていたとしても、もしコントラクトコードに自らを消す機能(suicideやkill)が含まれていなければ、何もすることができなかったでしょう。 kill機能は、元の監査済みコントラクトの残りの部分でした。もう1つの方法は、3esmitによって提案されたことを、コード変更と再デプロイによって自動的に、または7月に導入されたコントラクトに手動で、すぐに実施されていたら、防げていたでしょう。

 

パリティ・テクノロジーズは、当社が作成するスマートコントラクトについて正式な監査を、外部に定期的に依頼しています。たとえば、当社のKYCサービス「PICOPS」および当社が支援するICOの販売契約には、厳しい監査要件があります。

 

しかし、より多くの監査を行うだけでなく、セキュリティを実現するためには、デプロイ、監視、およびテストのための、より後半で正式な手順とツールが必要であると考えています。エコシステム全体としては、特にコントラクトの数や複雑さが増した場合に、同様の問題が再発するのを防ぐために、上のような手続きやツールがすぐにでも必要であると考えます。

 

パリティ・テクノロジーズは、凍結された資金を開放するために何をしているか?

深刻に状況を後悔しており、既存のEIP、また新しいEIPの提案に懸命に取り組んでいます。これらの改善提案は今後、ブロックされた資金の救済措置として一般的なケースに対応できるでしょう。

 

そのような改善案がいつ実行されるかについてのタイムラインはありません。私たちはコミュニティの意向に従い、他のプロトコル改善のような定期的なEIPプロセスを進めます。パリティ・テクノロジーズは、提案に関する開発を多く実施し、Ethereum Foundationチームおよび更なるプロトコル層開発のためのコミュニティと建設的に協力します。

 

 

他に実施する予定の事項は?

・最初のステップとして、適切なセキュリティと操作手順が確立されていると感じるまで、マルチシグマウォレットを展開する機能を削除して、これが再び起こらないようにします。

パリティウォレットUIは、安全であるとみなされるグノーシス、WHG、またはその他の複数のシグネチャウォレットを引き続きサポートします。

Parity Walletを使用して、事前に展開されたマルチシグウォレットを見たり、使用したりすることができます。

他のコントラクトと同様に、マルチシグコントラクトを手動で導入することも可能ですが、マルチシグ固有の統合された方法はありません。

 

・ウォレットではなく、ウォレットがおいてあるクロームの中間インフラストラクチャーに、注力していきます。この意味で、ウォレットはパリティを拡張できる「ユーザーレベル」のソフトウェアになります。

・我々は、秘密管理、鍵生成とパスワード管理、署名と自動更新を含む、既存のすべての機密コードの、フルスタック外部セキュリティ監査を委託しています。

・私たちは内部的にプロセスと手順を見直すことに多大な努力とリソースを投入し、具体的には業務セキュリティに専念するチームを作っていきます。

このチームは必要に応じて拡張され、リソースを自由に使います。チームは、パリティ・テクノロジーズの提供する重要な部分のレビューとメンテナンスを担当します。

 

必要なコントラクトのデプロイが、このリポジトリ内のコード変更とレビュープロセスに適切にリンクされていることを確認し、そのためのツールを作成するための取り組みをサポートします。

例えば:

・航空宇宙や医療などのように、各コントラクトごとに、デプロイのチェックリストをつくる

・デプロイされたコントラクトについては、リポジトリ内の最新のレビュー済みバージョンと比較して正しいか常に監視する

などです。

 

・私たちは、社内で努力するだけでなく、次のような外部のヘルプやリソースを探していきます。

・正式な検証や証明支援など、他のスマートコントラクト言語やツールの研究開発サポート

・ツール、言語研究、およびテストに焦点を当てたリサーチチームとの開発関係。

次世代の資産管理のセットを創るチームの作成。

セキュアなストレージとリカバリのためのツールを提供するマルチシグネチャ、タイムロック、デッドマンスイッチ用のボールトセーフなコントラクト。

・バグバウンティプログラムを拡張。(すべてのソフトウェアをオープンソースのソフトウェアとして提供しています)

 

パリティ・テクノロジーズは、エテリアムの技術開発の先駆者であり続けるよう努力し、コミュニティにとって安全で便利な技術を開発するために尽力します。

 

ーーー

 

まだあまりタイムラインなども不明確なようですね。

ただこれらの改善が、今後のEthereumおよびクリプト界隈の新たな技術を生み出してくれると良いです。

 

原文:

A Postmortem on the Parity Multi-Sig Library Self-Destruct – Parity Technologies