【最強への道】Liskが不正トランザクション問題を解決するまで

Liskが不正トランザクション問題を解決

皆さんこんにちは!おーみんです。

6月2日13時07分頃からLiskのブロック生成が止まるという事件が発生しました。事の発端はコインチェックさんのこのツイートでした。

実際に6月2日19時頃にLiskネットワークの様子を見てみると、本当にブロック生成が止まっていました。

f:id:bookreadkun:20180604154019p:plain

LAST BLOCKが6時間前に生成されてからは、新しいブロックは確かに生成されていないことが確認できます。

なぜブロック生成が止まったのか、今回はその原因とLiskコミュニティ 日本チームの激闘を振り返っていきたいと思います。

 

原因は匿名の人による不正トランザクション

今回の件についてLisk CEOのMax氏は以下のように原因を述べました。

「匿名の個人がLiskネットワーク上に不正なトランザクションをブロードキャストしました。トランザクション処理では稀にエッジケースのバグがあるために、このトランザクションは有効であると見なされてしまいました。」 

引用元↓

Lisk Blockchain Temporarily Halts Due to an Automated Security Measure - All Funds Safe and Fix Implemented : Lisk

はい。意味分かりませんwww

不正なトランザクション?

ブロードキャスト?

エッジケース?

ということで、匿名の犯人君が攻撃した内容をなるべく噛み砕いて説明していこうと思います。

不正なトランザクションの中身

まず今回のエラー内容が示されているGithubを見てみましょう。

github.com

出力されたエラーメッセージの1行目に"ERROR:  integer out of range "とあります。

訳してみると「範囲外の整数」となります。

ふんふんなるほど・・・なーんか範囲外の数字がぶち込まれたのかなぁ~?と思いますね。

では2行目を見てみます。

" STATEMENT:  INSERT INTO "trs"( "id", "blockId", "type", "timestamp", ・・・) VALUES ('181175095785369468', '5488578331239914243', 0, -3704634000, ・・・) 

とあります。

これはなんだか暗号のように見えるかもしれませんが、辞書みたいなものをイメージしてくださいな。

カッコが2つありますが、この2つはお互い繋がっています。お互いのカッコの1番目同士、2番目同士~が対応しているんですね!

id = 181175095785369468

blockid = 5488578331239914243

type = 0

timestamp = -3704634000

という感じです。

もっと分かりやすく、(月、水、金)VALUES(会社行きたくない、鬼辛い、テンション爆上げ)ですと、

月 = 会社行きたくない

水 = 鬼辛い

金 = テンション爆上げ

ということですね!

ちなみにカッコ内に書かれている値は対応した順番でしか機能しません。「月=鬼辛い」という選択肢はできません。

辞書で「月」を引けば「会社行きたくない」が出る、「金」を引けば「テンション爆上げ」が出てくるというイメージです。

そういう意味で辞書みたいなものをイメージしていただければいいかと思います。

そしてもう一個だけ!

面倒かもしれませんが、あと一つだけルールがあります。

僕らが使っている辞書は日本語で書かれていますよね?

それもそのはず、日本人が見る辞書なので当然でしょう。

プログラムにもルールがあって、今回はint型(integer)という内容だけ頭に入れてもらいたいと思います。

int型というのは「整数値」を入力しなさい!ということです。

2行目を見てみると、おーー!ちゃんと整数で入力されていますね!(nullは今回は見なかったことにしてw)

ということで2行目の暗号は、ルールの定められた辞書のようになっていることが理解できました。

 

3行目以降も色々ありますが、今回のバグに関してはこの2行目までを理解していれば大丈夫です。

バグの内容とは??

2行目の"timestamp"の値を見てみると、値が-3704634000となっています。

先ほども説明した通り、ちゃんと整数だしいいじゃん!と思います。

しかしながら、こういうのにも「範囲」というものがあるんですね~(笑)

Liskが採用しているPostgreSQLのinteger型は「-2147483648~+2147483647」の範囲しか許していません。-3704634000は範囲外なのです。

timestamp! アウト~ デデーン↴

となっちゃったわけです。

のらさんのツイートも分かりやすかったので引用させていただきます。

ということで、この不正なトランザクションがLiskネットワーク内に放り込まれた(ブロードキャスト)ために、今回はエラーが発生しました。

エッジケースのバグというのは、まあ極端な(予期しない)数値がぶち込まれたものと思っていただければ良いかと思います。

こういう特殊な問題はテストする側も思いつかないことがあり、バグが起こらないと気づかないんですなぁ・・・

ということで、今回のバグの内容は理解していただけましたでしょうか?

初めて知ったLiskのセキュリティ機能

僕も初めて知ったのですが、LiskのCoreにはセキュリティ機能が備わっているようですね!不正を見つけたら自動で新たなブロックの生成を停止するという仕組みらしいです。

不正があったら自動でシステムを停止させるなんて、世界最大の仮想通貨取引所であるバイナンスを思い出しますね~!

これはLiskも未来の世界いch・・・単純かwwww

現在は正常に稼働中

今回のバグはv0.9.15のリリースをもって解決しました。ノードは再構築(組み立て)しないといけないので少し面倒そうですが、まあ大丈夫でしょう!

忘れてはいけないLiskコミュニティ in Japan の活躍

今回の件でLiskのセキュリティ機能の充実さと、財団の圧倒的解決スピードを世界中にアピールできたかと思います。

しかしながら、Liskコミュニティ in Japanの活躍もかなりのものでした。

 エビさんの翻訳や、

 kpさんの情報収集や技術解説。

 そしてのらさんの事件まとめ。

 まあおまけでおいらのツイートもw

 

もちろんこれだけではなく、Liskerエースのムックさんを筆頭に圧倒的な情報拡散力も目立ちました。

僕がLiskを保有し始めて約10ヶ月が経ちますが、今回の騒動はコミュニティの強さを最も感じた瞬間でした(とはいってもコミュニティ内に参加しはじめたのは2ヶ月前くらいからだけど・・・)

まとめ

モナコインやビットコインゴールドがブロックチェーンへの攻撃を許してしまうなどのネガティブなニュースが多い中でのLiskの事件だったため、一瞬かなりヒヤリとしましたが特に問題もなく解決してくれて本当に安心しました。

 

Liskのセキュリティ機能の高さと問題解決力を広めるには良い事件だったかもしれません。

 

追記:今回のLiskへの攻撃者は悪意があったのか、それとも単純にLiskのデータベースが処理できないことを知らなかったのか?という件についてですが、kpさんが解説してくださいました。

悪意があったとみたほうが良さそうです。

 

はい!ということで、Liskがこれからも順調に成長していくのを見守っていきたいと思います。

それでは!最後まで読んでいただきありがとうございました。

よろしければ「読者になる」ボタンも押していただけると嬉しいです。