【長文記事】Lisk公式による先日発生した問題とその後

Yume♪
2018/06/04 22:52

こんにちはYumeです♬

一昨日はLiskのブロックチェーンが作成されない問題でSNSでは話題でしたね～(/・ω・)/

私が仮想通貨を始めて、初めて購入したのがこのLiskだったので気になっていました…

当初はビットフライヤーの取り扱いがなく、コインチェックだけで取り扱っていたんですよね！それがちょうど1年前です

最近ではビットフライヤーも取り扱いを始めていたため、昨日のLiskについてコインチェックだけでなく、ビットフライヤーもコメントをしていました

さて、この問題が発生した際にALISに【速報版】Liskがコインチェックで送金停止中をいった記事を投稿しました

記事投稿後のLiskについてと、どういった問題が起きて今回のブロックチェーンが生成されないことになってしまったか、追ってみましたので報告いたします

1.TwitterにてLisk公式が問題がないことを発表

Lisk公式の発表がTwitterにありました。

上記内容の日本語訳はこうなっています。

今朝、ブロックチェーンはhttps://www.reddit.com/r/Lisk/comments/8o033l/lisk_blockchain_temporarily_halts_due_to_an/ …、自動セキュリティ対策のために一時的に停止されました。ユーザーの資金は影響を受けておらず、この問題に対する修正は既に実装されています。アップデートについては、以下のスレッドの頭に記載。

要するに、「セキュリティ対策によってブロックチェーン生成は停止しましたが、もう問題は修正したので大丈夫ですよ！みんなの資金には影響ないです！」とのことです。

最近は51%攻撃を受けたBitcoin Gold、"Block withholding attack"を受けてしまったMONA coin など問題が明るみになってきているので心配でした…

※"51%攻撃"や"Block withholding attack"についてはぴゅーぱさんの記事がとても参考になります

【解説】モナコインが攻撃された！？Selfish mining,Block withholding attackってなに？

取りあえず大きな問題がなくて良かったですね♬

次に実際に何が起きたか公式の見解を見ていきましょう。

２．Lisk公式がredditにて起きた問題について内容を発表

Lisk公式がリンクで貼っていたサイトはredditというサイトになります。

様々なICO等に参加されている方は、redditを覗いたことがあるかもしれませんね

ではまずredditとは何かについてですが、IT用語辞典によるとこのようになっています。

redditとは：
redditとは、米国の出版大手コンデナストが運営するソーシャルニュースサイトである。「Digg」と並ぶ代表的なソーシャルニュースの一つとして認知されている。
redditは、ユーザーがWeb上の面白いニュース記事へのリンクを投稿し、他のredditユーザーの投票によって評価およびランク付けをすることで、面白いニュース記事を紹介する形式となっている。2005年に公開され、2008年にオープンソースプロジェクトとなっている。2011年6月現在、英語のほかにドイツ語、フランス語、イタリア語、スペイン語、そして日本語のローカライズ版が公開されている。

引用：IT用語辞典(https://www.weblio.jp/content/Reddit)

簡潔に言えば、意見交換場のようなイメージでしょうか。

このredditに昨日の件について、公式による投稿がありました。

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

During European morning hours, an anonymous individual broadcasted a faulty transaction to the Lisk network. Due to a rare edge-case bug in transaction processing, this transaction was deemed valid and went through the processing steps on each individual node. However, it was an invalid, maliciously customized transaction type that utilised this particular code bug.

For these cases there are security measurements built into Lisk Core in order to prevent the blockchain from continuing and causing forks. For this reason every individual node has temporarily stopped processing new blocks which has resulted in the Lisk network to halt. This is automated and intended behaviour in order to protect our users from any loss of funds.

At this time, there are currently 150 transactions in limbo which occurred after the incident, but were never included into the Lisk blockchain. Our current plan is to not re-broadcast these transactions. The network will continue as if these transactions have never happened - this means no funds are at risk.

In lieu with our commitment to full transparency, we have had similar edge-cases take place 2 or 3 times in the past. In all scenarios, the Lisk blockchain always remained secure, as intended, through the deployment of new Lisk Core versions which fixed such issues and allowed for the Lisk blockchain to continue running as normal.

The fix for this matter has already been discovered and implemented. Today, we will release Lisk Core v.0.9.15 which will resolve the issues and allow for the continual and normal operation of the Lisk network. When this fix is deployed we will ask for all delegates to rebuild their nodes by upgrading to the newest version. Further updates to our community will take place as we progress with resolving this issue.

引用：
https://www.reddit.com/r/Lisk/comments/8o033l/lisk_blockchain_temporarily_halts_due_to_an/

日本語訳(Google翻訳)：

Lisk Blockchainは、自動化されたセキュリティ対策により一時停止する - すべてのファンドを安全かつ修正済み

ヨーロッパの午前中、匿名の個人がLiskネットワークに不正なトランザクションをブロードキャストしました。トランザクション処理ではまれなエッジケースのバグがあるため、このトランザクションは有効であるとみなされ、個々のノードごとの処理手順を経ました。しかし、この特定のコードのバグを利用した、無効で悪意を持ってカスタマイズされたトランザクションタイプでした。

これらの場合、ブロックチェーンが継続してフォークを引き起こすのを防ぐために、Lisk Coreにセキュリティ測定が組み込まれています。このため、個々のノードごとに一時的に新しいブロックの処理が停止され、Liskネットワークが停止しました。これは、ユーザーの資金損失からユーザーを保護するために、自動化された意図された動作です。

現時点では、事件の後に発生したlimboには現在150の取引がありますが、Liskブロックチェーンには含まれていません。当社の現在の計画は、これらの取引を再放送することではない。ネットワークは、これらの取引がまったく起こらなかったかのように継続します。これは、資金が危険にさらされていないことを意味します。

完全な透明性へのコミットメントの代わりに、過去に同様のエッジケースが2〜3回発生しています。どのようなシナリオにおいても、Liskブロックチェーンは、そのような問題を修正した新しいLiskコアバージョンを展開し、Liskブロックチェーンが正常に動作し続けることができるように、意図どおりに常に安全な状態を保っていました。

この問題の修正はすでに発見され実装されています。今日では、問題を解決し、Liskネットワークの継続的かつ通常の運用を可能にするLisk Core v.0.9.15をリリースします。この修正プログラムが展開されると、すべてのデリゲートが新しいバージョンにアップグレードすることによってノードを再構築するように求められます。この問題の解決に向けて、コミュニティへの更なるアップデートが行われます。

上記の長い文章をまとめると、以下の様になります。

・匿名の個人が不正なトランザクションを送った。

・トランザクション処理で稀に特定の動作パラメータにより発生するバグがあるため、障害のあるトランザクションを処理すること（トランザクションを通過させる）ことが出来る。そのため、このトランザクションは有効なものとみなされて処理が行われた。

・しかし、Liskは不正なトランザクション処理が行われた際にフォークを避けるために自動で一時的にブロック生成を停止する機能(フェールセーフ)があるため、それが実行。

・問題は既に修正されたので、Lisk Core v.0.9.15をリリースします。

尚、新バージョンのリリースは既に完了しています。

あとは、各取引所がバージョンアップをすれば良さそうですね

Liskが何か問題が起きた際に自動で停止する機能を持ち合わせていることは初めて知りました。

"生成を停止する機能"は今後アプリケーションが作られていく際に良いか悪いか判断が分かれる箇所かと思われますが、現状ではエラー処理が正しく動作し、不正防止、正常な処理に戻りやすくなるのであればLiskを保有しているユーザからしてもあって損はないですね。

また、実際に動作したという証明にもなったので良かったと思います。

ではでは、次にどの箇所でのエラーだったのかという点についてお話します。

３．GitHubにて有名プログラマーが原因を特定？

先ほどの例に伴い、GitHubについてです。

GitHubとは：

コンピュータープログラムの元となる「ソースコード」を、インターネット上で管理するためのサービス。米サンフランシスコに拠点を置くGitHub(ギットハブ)社が、2008年4月にサービスを開始した。
複数人が携わるソフトウエア開発において、ソースコードの共有や、バージョン管理といった作業は必要不可欠となる。GitHubは、開発者同士がコラボレーションしながら、ソースコードを管理できるサービスとして広まり、15年11月時点で、ユーザーは1000万人を超えている。
GitHubには、ソースコードを始めとするプログラム開発に必要なファイルやそれらの変更履歴等を保存する「リポジトリ」と呼ばれる場所があり、ソースコード等のバージョンを管理する機能の他、プログラム開発等に対する開発者間でのレビューやコメント機能、プログラム開発の進捗(しんちょく)を管理する機能等が備わっている。

出典：(株)朝日新聞出版発行「知恵蔵」知恵蔵について、コトバンク

簡潔に言えば、GitHub社がサービスを開始した、プログラムのソースコード共有を行うことが出来るサイトのようなイメージです。

このGitHubにて、Liskの開発メンバーではないですが、界隅では有名なプログラマーがこの問題について述べています。

具体的なプログラムの箇所は以下の箇所のようです。

（引用：https://github.com/LiskHQ/lisk/pull/2087）

ERROR: integer out of range
STATEMENT: INSERT INTO "trs"("id","blockId","type","timestamp","senderPublicKey","requesterPublicKey","senderId","recipientId","amount","fee","signature","signSignature","signatures") VALUES ('181175095785369468','5488578331239914243',0,-3704634000,'\x6dd24c92d91c0082f5be68f7350d87b7cdf105267543f1f61d3043a5c2d8a00b',null,'3402562013208542942L','3402562013208542942L',1,10000000,'\xcde9a3459b1f5590a9b6f32a5d9c2e85596be9d01ded14fa9d9c5f276a37e2562e40f459c727599323e1ee84435a63316b3a3a50fb3b5d687dc7ea1f1ad9e001',null,null)
ERROR: insert or update on table "blocks" violates foreign key constraint "blocks_previousBlock_fkey"
DETAIL: Key (previousBlock)=(5488578331239914243) is not present in table "blocks".
STATEMENT: INSERT INTO "blocks"("id","version","timestamp","height","previousBlock","numberOfTransactions","totalAmount","totalFee","reward","payloadLength","payloadHash","generatorPublicKey","blockSignature") VALUES ('13977984917448353211',0,63803270,6144655,'5488578331239914243',0,0,0,400000000,0,'\xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855','\x6cb825715058d2e821aa4af75fbd0da52181910d9fda90fabe73cd533eeb6acb','\x0b534abcbe640cef4df6a579bbffe00eb62401b9090e6d7f1ef72e4dafaa31bdb8594b85007f7d8ed79d4166835334ca2adb0830a175d6ac39263fe5fcf8950f')
ERROR: insert or update on table "blocks" violates foreign key constraint "blocks_previousBlock_fkey"

コメントの引用は以下のとおり。

原文：

Update
As you can see in the first INSERT INTO statement of the logs above, there is -3704634000 in the 4th column (timestamp). This value is a valid JavaScript number and within the safe integer range, i.e. the number can be represented without rounding errors in JavaScript. However, the value should be stored in a Postgres database column of type integer, which is signed and of size 4 bytes = 32 bit. The signed 32 range is -2147483648 to +2147483647. Since -3704634000 < -2147483648, the number cannot be stored in the database.

日本語訳：

更新
上記のログの最初のINSERT INTO文で分かるように、4列目（タイムスタンプ）に-3704634000があります。この値は有効なJavaScript番号であり、安全な整数の範囲内です。つまり、JavaScriptで丸め誤差を発生させることなく数値を表すことができます。しかし、値は整数型のPostgresデータベース列に格納されていなければなりません。これは符号付きでサイズが4バイト= 32ビットです。符号付き32の範囲は、-2147483648から+2147483647です。-3704634000 <-2147483648であるため、データベースに数値を格納することはできません。

この問題の結果ですが、簡潔に言えば、

プログラム内の太字の箇所("timestamp")で、Postgresデータベースに範囲外の整数なのにも関わらず値を入れようとしてしまった

もっと簡単にこの状況を例にすると、

1～９しか入らないところに１０を無理やりいれようとしたのでエラーになった。

というもののようです。

ビットフライヤーの加納社長もTwitterで型の問題というように述べていますね。

聞いてみれば、「そんなことだったのか～」と思う方も多いと思いますが、プログラミングに関わっている方は他人事ではあまりなく、2038年問題を彷彿とさせるような出来事ですね…。(あとちょうど２０年後です♪)

ただし、このLiskで起きた型の問題についてGitHubでも討論されていますが、簡単に型を直せば良いといった問題ではないようです。

理由としては生成されてきたブロックチェーンに既に刻まれているためとのことです。

結局Postgresデータベース、javascriptのどっちの問題か？というと、Liskの開発言語であるjavascript側で適切な処理を行う必要があったとコメントもありますね。

私個人としても、プログラム内での日付関連箇所はエラーが発生しやすい箇所だと感じているのでこれからLiskはどういった対処をして開発を行っていくのだろうと注目していきたいですね♬