ブロックチェーン定義 ~プライベートブロックチェーンと既存の分散データベースの相違点~

今回はブロックチェーンの定義を確認します。特にプライベートブロックチェーンは『既存の分散データベースと同じでは?』という声が多くあるので、そのあたりを中心に整理していきます。


JBAによるブロックチェーンの定義

※JBA:Japan Blockchain Association(一般社団法人 日本ブロックチェーン協会)

1)「ビザンチン障害を含む不特定多数のノードを用い、時間の経過とともにその時点の合意が覆る確率が0へ収束するプロトコル、またはその実装をブロックチェーンと呼ぶ。」

1) A blockchain is defined as a protocol, or implementation of a protocol, used by an unspecified number of nodes containing Byzantine faults, and converges the probability of consensus reversion with the passage of time to zero.

2)「電子署名とハッシュポインタを使用し改竄検出が容易なデータ構造を持ち、且つ、当該データをネットワーク上に分散する多数のノードに保持させることで、高可用性及びデータ同一性等を実現する技術を広義のブロックチェーンと呼ぶ。」

2) In a broader sense, a blockchain is a technology with a data structure which can easily detect manipulation using digital signatures and hash pointers, and where the data has high availability and integrity due to distribution across multiple nodes on a network.

“jba-web.jp/archives/2011003blockchain_definition”

 




もう少し噛み砕いた解釈

1)
・嘘をつく参加者がいるかもしれない
・故障している参加者がいるかもしれない
・それでも合意形成が可能な仕組みがある
・形成された合意は時間経過によって覆る可能性が0に近づく

2)
・暗号技術によって改ざん検出ができる
・複数端末に分散してデータを保持
・分散して保持することで停止しない仕組みを持つ
・分散して保持したデータの同一性を保証する

 


プライベートブロックチェーンの特徴

明確な定義は見つかりませんでしたが、パブリックブロックチェーンと比較して決定的に異なる特徴がいくつか挙げられます。

①参加者の総数を把握できる
②インセンティブを与える必要が無い

これらの特徴からプライベートブロックチェーンでは合意形成にリーダーを要することが基本です。なぜならば母数が把握できる(①)ため多数決が実施可能だから、また、インセンティブが無い(②)ため分岐したチェーンに対して正とされる選択をする必要が無いからです。

ここからがわかりにくいのですが、リーダーとは合意形成をファシリテートするのであり、リーダーがどの選択肢を正とするのか独断で決めるわけではありません。リーダーは正と思える選択肢を提案するだけで、採用されるには多数決によって参加者の過半数から合意を得る必要があります。

この合意形成の部分が従来の分散データベースとの違いと言えるでしょう。

 


合意形成の仕組みがもたらす価値

分散データベースではなくプライベートブロックチェーンを用いた方が良い場面としては、参加メンバーに異なる立場と役割がある場合が挙げられるでしょう。

 


さいごに

参考書籍:

一定時間間隔で処理をループ C# System.Windows.Forms.Timer

非同期で同じ処理を繰り返したいときはSystem.Windows.Forms.Timerを使うと便利です




リンク:msdn
https://msdn.microsoft.com/ja-jp/library/system.windows.forms.timer(v=vs.110).aspx

使い方メモ

IBM Bluemix Internet-of-things(Watson-IoTーPlatform) へ MQTT送信するときの設定方法

IBM Bluemix のサービスである『Internet-of-things』(『Watson-IoTーPlatform』とどっちが正式名称なんだろう??) へ MQTT送信するときの設定方法をまとめます。

これらの設定にはユーザID、組織ID、認証トークン、デバイス名といった具合に項目がたくさんあり、下手くそな日本語訳の影響でしょうか、ドキュメントによって名前が異なったりして混乱しやすいです。


必要な情報を集める

①組織ID

Internet-of-things(Watson-IoTーPlatform)を起動した画面で右上に表示されます。

②デバイスタイプ、デバイスID、認証トークン

Internet-of-things(Watson-IoTーPlatform)にデバイス追加したときに設定した項目です。認証トークンは設定完了するとそれいこう確認不可になるのでメモしておきましょう。


MQTT設定をする

・サーバ
[組織ID].messaging.internetofthings.ibmcloud.com

・ポート
8883(※TLS未使用時は1883。ただしTLS使用必須なことが多いです。)

・クライアント
d:[組織ID]:[デバイスタイプ]:[デバイスID]

・ユーザ名
use-token-auth(※トークン認証のため)

・パスワード
[認証トークン]

・トピック
iot-2/cmd/evt/fmt/json


NodeREDからMQTT送信するときの注意点、ハマった点

・JSONノードを挿入する

・『SSL/TLS接続を使用』にチェックを入れる(奇妙な話ですが、証明書設定などはせずとも、チェックボックスにチェックを入れるだけで接続できるようになります)

Watson Visual Recognition で ラグビーとアメフトの違いを認識させる

Watson Visual Recognition で画像認識器がとても簡単に作れたのでまとめます。

実際やってみて驚きましたが、①学習用の画像を用意して②ドラッグ&ドロップ、本当にこれだけで認識器が完成しました。

なお、学習によって任意の認識器を構築する機能は標準プラン(有料)にしかない点に注意してください。無料プランではIBMが事前に用意した認識器を使用できるだけで、認識器の作成はできません。






 


認識器の構築

Visual Recognitionを開いて『Create classifier』をクリックすると以下の画面が表示されます。

直感的で分かりやすいですね。クラス名を定義して(ここでは『ラグビー』、『アメフト』の2種類のクラスを定義しました)、あとは該当するクラスの画像をそれぞれドラッグ&ドロップするだけです。

普段からスポーツ観戦が好きで写真を大量に撮りためていたため、それらで認識器構築しました。学習用画像が無い人は公開データであったり、”ImageSpider“などを活用してデータ収集してください。

※ImageSpider:Google画像検索と画像一括保存をしてくれるフリーソフト

画像を投入すると学習が始まります。

Watson Visual Recognitionの中身の詳細は公開されていませんが、まぁDNNとかで間違いないでしょう。(※流行りのディープラーニングです。)

おそらくクラウド側では先ほど投入した画像データをもとに『これがラグビー』『これがアメフト』というように学習が繰り返されています。


認識テスト

さて、Watson君はラグビーとアメフトを区別してくれるのでしょうか?

今回は京都大学体育会のラグビー部さんとアメフト部さんの公式HP画像でテストしました。

京都大学体育会ラグビー部:http://www.kiurfc.com/
京都大学体育会アメフト部:http://gangsters-web.com/

 

 

認識できましたね!簡単!!

でも簡単な反面、挙動が完全にブラックボックスなのは気味が悪いですね。だって認識がうまくいかなかった場合には完全にお手上げ侍になるので。。。

日本声優統計学会の公開データを使って声優さんの声認識

日本声優統計学会より無償利用可能な発話データが公開されたので分析してみました。

(ソースはGitHubで公開中 https://github.com/roadroller2da/sound-recognition )




日本声優統計学会より

プロの女性声優 3 名が 3 パターンの感情で音素バランス文を読み上げたファイルです.48kHz / 16bit の WAV ファイルであり,総長約 2 時間,総ファイルサイズ 720 MB です.

この音声ファイルは主に個人での研究・分析目的でのみ無償で利用可能です.
再配布や公序良俗に反する利用などの,実演家の著作隣接権を侵害する行為は禁止します.

http://voice-statistics.github.io/


MFCC抽出

音認識でポピュラーなのはやはりMFCCということで抽出します。

scikits.talkbox.featuresを使えば簡単に特徴量抽出できるらしいのですが、今回はあえてlibrosaを使ってみました。

下2つは異なる声優さんの発話データから抽出したMFCCですが、ぶっちゃけあまり違いが分かりません。一見、色が濃い位置がほぼ一致してしまって区別困難に思えますが。。。。

ソースコード(GitHub)
https://github.com/roadroller2da/sound-recognition/blob/master/GetMFCC_librosa.py


主成分分析(PCA)

「ほんとに声だけで人を区別できるの??」と思ったので、ためしに主成分分析(PCA)で3次元に圧縮して可視化。さっきのMFCCからは想像つきませんでしたが、こうしてみると音特徴によって発話者を分離できていることがわかります。

3次元に圧縮した主成分だけでここまで分離できているので、13次元だったり26次元だったりあるMFCCならもっと正確に分離できそうな期待が持てます。

ソースコード(GitHub)
https://github.com/roadroller2da/sound-recognition/blob/master/PCA_mfcc.py


SVMによる認識

SVMで認識実行。3人の声優さんの発話データが100個ずつの計300データがあるので、半分を学習データ、残りの半分をテストデータとしました。

えっ、ちょ、認識率100%いけたやん。。。(プログラムのバグではない)

ノイズも無いしはっきりと発話しているデータなので問題設定としてEasyだったんでしょうね、きっと。言い換えると、発話者の特徴について境界線が引きやすかったのかと。


極端に少ない学習データでSVM認識

それぞれの声優さんの発話データをたった3つしか使わないで認識器構築した場合にどうなるか実験しました。深層学習と違ってSVMは学習データ量が少なくてもそこそこ動くといわれているので検証です。

結果、下記のように少ない学習データ量でも精度がそこそこ出ました。対角成分が正解で、右上や右下に色がついているのは誤った部分です。1つめと2つめのクラスは10~20%くらいの誤りが、クラス3は50%に近い誤りがありました。

 

今回は認識データがクリアな音声で、3クラス分類というEasyな問題設定だったのでうまくいきました。これだけでSVMは学習データが少なくても動くと結論付けるのは軽率ですが、一応それっぽい傾向の確認が出来たということで。


深層学習で認識する

流行りの深層学習(ディープラーニング)も使ってみました。音は時系列データなのでRNNやLSTMを用いるのが適切なんでしょうけど、今回は実装が慣れているシンプルなDNNを用いて、MFCCを抽出した上述の画像をINPUTとしています。

そんないい加減な実装でも9割手前くらいは達成できました。

 

SORACOMのサービスを辿るとトレンドが見えてくる

株式会社ソラコムは、MVNOのデータ通信 SIMや、AWSを活用したクラウドサービスによって、IoT のためのモバイル通信とクラウドを一貫して提供する企業です。少ない初期コストによって人気を集めています。

既にたくさんのサービスを展開していて(各サービスは頭文字が『A』からアルファベット順になっている点が面白いですね)、これらのサービスの歴史を辿ることでIoT業界のトレンドやニーズが非常に明確にわかってきます。

(画像:https://soracom.jp/)


『A』:SORASOM Air

格安のSimカード。携帯電話用と異なり初期費用が小さく、IoTのような通信データ量が少ない場合に安く手軽に利用可能。様々なデバイスに通信機能を持たせてIoTを開始したいという需要に応えたサービスといえる。

(画像:https://soracom.jp/)


『B』:SORASOM Beam

デバイスからクラウドに収集したデータを、ユーザ端末から取得する際の経路を暗号化するサービス。デバイスからクラウドへの通信はSORACOM Airを用いるとモバイル閉域網なのでセキュリティ安全性が高い。その一方で、ユーザ端末からクラウドにアクセスするときにはインターネットを経由せざる得ないためセキュリティ対策の需要がある。それに応えたサービスといえる。


(画像:https://soracom.jp/)


『C』:SORASOM Canal

世界で最も利用されているクラウドサービスことAWS。IoTで収集したデータをクラウド上に構築したアプリケーションで利用したいという顧客は多い。この場合はSORACOMクラウドと顧客クラウドとのセキュアな接続が必要となる。そのときにインターネットを経由してしまうとセキュリティの懸念が出てくるので、インターネットを経由せずにAWS内の閉じた環境でクラウド同士を接続するサービス。というのも、そもそもSORACOMクラウドはAWSをベースにしているので、こういうことも可能であろう。

(画像:https://soracom.jp/)


『D』:SORASOM Direct

IoTで収集したデータを用いたアプリケーションをクラウドではなくオンプレ環境(例えば本社サーバ上など)に構築するユーザもいる。そういったオンプレユーザ向けのセキュアな専用線接続サービス。SORACOM Canalのオンプレ版ともいえる。

(画像:https://soracom.jp/)


『E』:SORASOM Endorse

通信回線が安全になっても、接続相手が誰かわからなかったり、なりすましがあったり、未知のデバイスが勝手に繋がってしまっては困る。そのためにデバイス認証機能を提供するサービス。認証にはSIMを用いる。

(画像:https://soracom.jp/)


『F』:SORASOM Funnel

IoTで収集したデータを用いたアプリケーションをクラウドに構築したといっても、全ユーザがAWSを使っているとは限らない。クラウドのビッグスリーであるAWS、GCP、Azureについて、SORACOMクラウドとセキュアに接続させるサービス。SORASOM Canal が AWS以外にも対応したVerといえる。(ただ、内容を見てみるとAWSとの接続に比べてGCPやAzureとの接続は若干粗末に見えてしまう。)

(画像:https://soracom.jp/)


『G』:SORASOM Gate

デバイスからクラウド、そしてクラウドからユーザ環境へとデータが送られる。その逆方向の通信を可能にするのがこちらのサービス。膨大な数のデバイスを現地に赴いてメンテナンスすることはコストがかかるが、こちらのサービスを用いればデバイスのアップデートや設定変更が遠隔から可能となる。技術的にはもちろん可能なことだがIPアドレスの割り当てやNAT機能の設計などが職人芸で難しく、それらをサービスとして提供したことは「お見事!」と言わざるを得ない

(画像:https://soracom.jp/)


『H』:SORASOM Harvest

バスワードとなって大きな期待がされているIoTだが、実際に何をすればいいのかわからないという声が近年多い。そこで、まずは簡単なプロトタイプを作成して発想を膨らませるという開発やマーケティングが多くなっている。こちらはそのような需要に応えて、簡単にデータ収集と可視化ができるサービスとなっている。(ただ、個人的には『H』くらいからだんだん他企業と似たようなことをし出したように感じており、勝手ながら少々悲しい。)

(画像:https://soracom.jp/)


『I』:SORASOM Inventory

デバイスを認証するSORASOM Endorse に対して、こちらはデバイスを管理するサービス。稼働状況などを遠隔地から監視できる。

(画像:https://soracom.jp/)


『J』:SORASOM Junction

ミラーリング、リダイレクション、インスペクションの3つの機能を提供するサービス。(デバイスの次はパケットまで確認したいという声が出てきたのだろうか?このあたりから背景や狙いがわからなくなってきました。)

(画像:https://soracom.jp/)

 

今日はここまで

 

体内Suicaをスウェーデン鉄道会社が導入

Futuristic hand implant microchip as train tickets


Image: SJ Railway

http://www.independent.co.uk/travel/news-and-advice/sj-rail-train-tickets-hand-implant-microchip-biometric-sweden-a7793641.html


スウェーデン鉄道会社が社内検札にマイクロチップを用いた乗車システムを導入。ポイントは「マイクロチップが旅客の手に埋め込まれている」こと。(biometric chip implanted into their hand と引用元に記載されている)

技術としてはお財布ケータイやモバイルSuicaでお馴染みのNFCが使われている。

「ついにマイクロデバイスの体内埋め込みが本格化してきたか!!」と驚いたのですが、既にスウェーデンでは2000人程度がインプラントしているという話の方が驚きました。(Around 2,000 Swedes have had the surgical implant to date, most of them employed in the tech industry. と引用元に記載されている)

家や車の鍵の代替としてマイクロチップを体内に、、、みたいな話も以前からよく聞きますが、個人的には今回の話も含めて「スマホでよくない??」と思ってしまいます(もしくはスマートウォッチ)。機種変更しても情報損失するようなことも減ってきてますし、破棄や売却したスマホから情報漏えいするリスクも対策が練られていますし。

ポケットやカバンにカード(または専用機器)を入れておけば、手や足裏で通信できる人体通信技術も伸びてきてますし、そっちの方が日本では普及しそうと私は考えます。というのも人体へチップ埋め込むことへの抵抗が強そうなので。

国内市場が小さく外需思考なので研究開発に力を入れ、さらに低い人口密度故に通人技術が発達した国、そんなスウェーデンからこういった技術が出てくるのは自然な流れだとは思いますが、、、、今後の行く末に注目ですね。

学習用画像を水増しする(データオーギュメンテーション)

深層学習では学習データの確保がポイントとなります。

画像認識でいうと、1枚の画像でもコントラストを変えたり、伸縮したり、拡大縮小したり、ノイズ付加したりすることで、学習データの水増しが可能です。

試しに実行してみたので、環境構築から手順をまとめてみました。


環境:Windows7、64bit

・Anaconda4.4.0 For Windows(Python3.6 ver)をコチラからダウンロード

 

・ダウンロードした”Anaconda3-4.4.0-Windows-x86_64.exe”を右クリックで管理者として実行

 

・”Add Anaconda to my PATH environment variable”にチェックを入れるのを忘れずに

 

・”pip install opencv-python”によってopencvをダウンロード(これがないとimport cv2が動きません)

 

・今回はbohemian916さんのコチラのプログラムを拝借しました

・引数に水増ししたいベースとなる画像を指定して実行

 

今日はここまで

データマイニングにおけるAnomalyDetection(異常検知)は何故難しいのか?

おはようございます、ロードローラーです。本日はAnomalyDetectionについて整理します。


AnomalyDetectionとは?

異常検知、または、外れ値検知とも表現されます。データをじ~っと眺めていて「いつもと違う、おかしい!」という事象を検出することです。


AnomalyDetectionの難しさ

これはシンプルに下記2点に付きます

① 「What is 異常?」 の定義
② 「What is 正常?」 の定義

簡単に言えば「何を正常として、何を異常とするか」という定義が一番難しいんですね。

その原因の1つ目はデータ収集の困難さ。例えば製造現場で異常検知したいといった場合に、異常の発生率が製品10万個に1つだったとすると、正条例のデータは溢れるほど手に入りますが、異常例のデータがなかなか手に入らず、定義および学習が困難です。(※特に流行りの深層学習を用いた認識器では学習データが大量に必要です。)

対策として、正条例を熟知した教師無しの認識器を用いるのがポピュラーです。ここでは異常検知と言っても「何かおかしい!」というレベルの検出で、具体的に「XXが原因で、YYという異常が発生しています。」というレベルの検出ではありません。

「いつもと違う」ことの検出には「いつも」さへ知ってればいいというわけですね。しかし、まだまだ精度が十分に出ていないとの報告があります。

原因の2つ目は統制環境か非統制環境かという点。工場のように「いつも同じことをしようとしている」統制された環境ならば正常の定義は簡単です。

一方で、生活空間における事故を検出しようとした場合、そもそもの行動がバラエティに富んだ非統制環境なので正常の定義が困難です。「夜は寝て、朝に起きて、日中はテレビを見て過ごす」といった正常の定義だと、来客があった瞬間に「なんだこのパターンは!?異常だ!!」となるわけですね。

 

今日はここまで

 

深層学習はデータさえ集まれば何でもできるのか!?

結論:そんなわけない

こんばんは、ロードローラーです。出落ちみたいになりましたが今回はそういうお話。

データを入力すれば認識に必要な特徴量を自動抽出してくれることで有名な深層学習ですが、「データさえ集まれば何でもできるんでしょ?」というわけではありません。

深層学習にはネットワーク設計、入力値の見極め、ハイパーパラメータ設定など、職人技が求められる要素がてんこ盛りです。こういった難しさを乗り越えて、使いこなして、やっと初めて「データあれば認識器を構築できる。」という境地に辿り着きます。

なんだかこういった理解・知識がある人とない人が混在していて、すごく日本語に不自由している感があったので、いまさらながら記事を書かせていただきました。

こういうすれ違いでストレス抱えている人、実は多いのではなかろうか、と思ったり思わなかったり・・・