参加録「bitFlyerのC#erたちが語る、あなたの知らないBitcoin,Blockchainの世界」
2017/01/31 (火) 19:30 ~ 21:30 in 渋谷ヒカリエ
bitFlyerのC#erたちが語る、あなたの知らないBitcoin,Blockchainの世界
コンテンツ
Jeremyさん：
「Approaching some everyday (C#) programming problems practically」（20分）柴田さん：「日本最大のビットコイン取引所の裏側（仮）」（20分）
竹井さん：「フルスクラッチ Blockchain」（30分）
bitFlyerとは…
C#、.Net、Azureでサービスを運用
35名うち半数エンジニア
C#エンジニア内訳
5人フルタイム（2名デザイナー、2名エンジニア、1名ブロックチェーン）
Private Blockchainを開発している会社です。
講演①： Jeremy Simmonsさん
「Approaching some everyday (C#) programming problems practically」
F#好き
10年くらいエンジニア
保守しづらいコードについて、サンプルコードをもとに解説。
Order
OrderItem
OrderCreaterとCreateOrderがある…
voidでなにやってるか
CalicurateTotals…とか
いざ、リファクタリング。DDD的にやってみる。
OrderにBehaviorをもたせよう
public class Order
{
public Order(TaxCalculator calc)
{
/*..*/
}
}
ここで、デザインパターンの Memento Pattern を使う。
Stateの保存と保存されたStateの呼び出しのため。
Immutable Orderが作れればOK。
単体テストつくる
ダイスを振る
ランダムに目が出る
…と、あって以上。
講演②：柴田航平さん
「ビットコイン取引所の裏側 」
Webアプリエンジニア
サーバサイド、クライアントサイド担当
売買のマッチング
世界一取引量
39,098 BTC取引
サービス："bitFlyer Lightning"
3層構成
Worker
取引所エンジン
注文マッチング
Webサーバ
JSON RPC
イベントPush（注文通知等）
クライアント
ブラウザ
Worker
取引所（同時稼働数は最大1台）…シリアルで処理する
ダウンタイムは最小限にする
アクティブ、スタンバイ構成にしたい
Azure：PaaSを利用
Azure Cloud Service
Cloud Service
冗長構成、クラスター化のサポートないので切替時を自作した
Azure Service Fabric
2016/03 GA
マイクロサービス構築用
クラスター化前提
Webサーバ
ASP.net SignalR（WebSocket使用、SocketIOみたいな挙動）
Push通知をさばく
SignalR
複数サーバでデータ共有のための”backplane”という仕組みがある
下記サポート
AzureServiceBus（初期はこれで1年くらい）
SQL Server
Redis（いまはこれ）
Azure上で障害
AzureServiceBus
メッセージングが不安定になる
Redis
いい感じ
課題：
通信料が高い
SignalRでデータ垂れ流すのも限界では？
モバイルバッテリー消費も問題
クライアントサイド
“RxJS"のデータフロー管理
SignalRのイベント、APIコール、ユーザー操作、タイマーのObservableとしてI/F
LINQもOK
サーバ側でReactiveExtensionを使ってない
Rx
SignalRでデータ受け取ったらAPIを呼び出す
1秒に1回とか
要件に応じて複雑化
型が欲しいのでTypeScript検討
Q＆A：
現行のワーカーはFabricで実現可能？
→可能だが、現状いい感じに抽象化されてるため緊急要件ではない。
講演③：竹井悠人さん
「ゼロからつくるBlockChain」
MS MVP C#
C#大好き人間、16年
※スライドは追って公開予定
.Net Core 1.1.0 SDK
最小限の機能をもったブロックチェーンを動かします：MinChain
コンセプト：
Etheriumのサンプルを動かすようなものではない
SourceCodeでブロックチェーンをつくる
P2Pは時間都合で実装せず
ブロクチェーンの基本
取引データをブロックに固める、それを連結したもの。
①ハッシュ関数
メッセージのダイジェストを生成する
１：短くできる（32バイトで収まる）
２：改ざん不可にする
３：辞書の鍵にする
②電子署名 ※Util/ExService.cs
公開鍵暗号方式
楕円曲線暗号（ErecticCurve/ECC）
VS2017
Extension：拡張用ライブラリ
Util：汎用（ハッシュ関数、SHA256を二回適用、
③コンセンサスアルゴリズム
NW内の複数エンティティ（PC）どうしがルールに従う限り、安定的に合意する仕組み。
BitcoinではProof of workを使用。
Block
前ブロックID
難易度
Nonce
日時
Tx Root Hash（ブロックヘッダーに入れる、ハッシュ木。データ量を定めるため）
通信時はトランザクションデータも含める
河合さん作ライブラリ：ZeroFormattableを使用。
トランザクション
日時
送金元（IN）：電子署名つき（Pay-to-pubkey-hash形式）
送金先（OUT）
UTXO（Unspent Transaction Output）
未使用のお金の管理
Transaction outputはDictionaryでデータ型
マイニング
BlockIDが難易度で定められた数以下になるように。
コインベース
Create Coinbase
フォーク
ブロック難易度高くても起こりうる
フォークすると台帳が複数できてしまう、のを避けるよう優先度をもつ
例：
0001234
↓2^4倍難しい
0000001234
MinChainについて
Program
Config
KeyGenerator
Genesis
Runner
ConnectinManager
InventoryManager
Executor
Mining
Program
コマンドもらって関数呼び出し
Runner
データもらって、接続する、接続きたらHello、モジュール呼ぶ
ConnectinManager
TCPリスナー生成
メッセージをシリアライズ
InventoryManager
メッセージ呼ばれると、ブロックリクエストを対応する
もってるか調べる、もってないなら無視、もってたらあげる
渡すときは、Executorへ渡す
Executor
InventoryManagerがトリガー
難易度判定
Runブロックでトランザクションさわる、
いざ稼働させてみる
dotnet build （DLL生成）
dotnet MinChain.dll xxx
鍵の生成
Config生成
鍵とConfigのパス指定で genesis.binが生成（※最初は自分にブロックリクエストしてもらうように指定）
dotnet MinChain.dll run genesis
マイニングが進むと difficultyが上昇していく
2009年のBitcoin的な状態を再現している…。
現状、Blackは固定でシリアライザーが必要
バリデーションないのため、放題の状態
Walletがほしい（トランザクション機能がない）
Multi-Sigができたら素敵（鍵の複数による安全化）
Blockchain Engineer 募集
miyabiチームではBlockChainつくれる場所があります。
***
以上です。
公開されたMinChainはブロックチェーンの基礎のようなので、学習教材として最適と思われました。
3分間でつくれるGo言語開発環境
Blockchain本を読んでいたらGo言語（以下golang）の検証環境に出くわす。
pythonのAPIもあったけどどうしようかな、避けて通るかな…。
と瞬間思うも、何かの縁だと思いgolang入門。
以下本題。
■環境
> brew install go
※なにかbrewがおかしなエラー吐いたら診断。
> brew doctor
不具合解消例：
> sudo chown -R $(whoami) /Users/(your_name)/Library/Logs/Homebrew
> sudo chown -R $(whoami) /usr/local/opt
□ gopathを設定
ファイルを開いて、
> vi ~/.bashrc
下記追記して…
> GOPATH=$HOME/.go; export GOPATH;
反映。
> source ~/.bashrc
□ デバッガインストール
> brew install go-delve/delve/delve
IntellijのPreference > Pluginから、goを検索してインストールする。
IntelliJ IDEA 2016.3 Help :: Managing Enterprise Plugin Repositories
□ IntelliJ CE 設定
- インデント：デフォルト8字を4字に変更
以上。
インストールでエラー出なければ能動的3分間だったのではないでしょうか。
環境出来たところで Tour of Go (-;
■ 参照
- IntelliJ CE + Delve で Go 言語のデバッグ環境構築(Mac) - Qiita
- Intellijでgolangな環境を構築する - techium
- Goコマンド参照（※オプション詳しい）
■ IDE汎用ショートカットキー
- デバッグ： "Command","Shift" ,"Option" 同時押し+ fキー
- コード整形： "Shift" ,"Control" 同時押し+ dキー
- Build："Shift" ,"Option" 同時押し+ F9キー
- Run："Shift" ,"Option" 同時押し+ F10キー
イベント参加録 アクセンチュア流セキュリティワークショップ
セキュリティ業務系のワークショップがあるとのことだったので参加してきました。
そういえば「王様達のヴァイキング」ってハッカーが主人公で好きな漫画です。
タイトル：「アクセンチュア流！セキュリティ課題解決に必要な分析力と技術力の活かし方を体験するワークショップ」
開催日時：2017/01/14 13:30-17:00
主宰：アクセンチュアセキュリティ
コンサルタント：藤井さん
セキュリティ業界で起きていること
JPN：気にしていること
サイバーアタック
自然災害
Global：気にしていること
雇用
エネルギー
ここに差異がある。
日本にはセキュリティ対策が必要という意識はあるが…。
意識はあるが、予算が割かれていないという現状。
5000億円相当が国内情報セキュリティサービス市場
セキュリティ
モノが多い？サービスのほうが大きい？
合計で9000億円市場
システムインテグレーションの（導入設計、運用ほか）
セキュリティ保険の市場
費用試算ができるようになっている
保険に任せてしまう判断もある
マネージドセキュリティサービス
機器、とその運用でマネタイズ
日本はセキュリティ後進国
決められたことをやる
それ以上はやらない、踏み込まない
ニーズあってもやらない、そういうサービスが出てこない
※ドイツも同様の傾向あり
世界に比べて日本の費用は少ない
1企業あたりはグローバルの半分くらい
国内セキュリティ人材不足
現状、ユーザー、ベンダー合わせて40万人程度が必要
推計値
2016年
132,000人（不足）
240,000人（ユーザー）
4200人（提供、エンジニア）
2020年
193,000人（不足）
315,000人（ユーザー）
56,000人（提供、エンジニア）
海外
自社開発するのが多いため、自社内でセキュリティも兼務
日本
自社で賄う、2〜3人はいる傾向
自社のこととして捉えているため、基本的に外注しない
オリンピックへのセキュリティ投資も増えている
監査、検査、コンサル業の不足が多い
ネットワーク負荷からアタック検知も。
# スライド
１：増え続けるをリューション
２：難化するトリアージ
３：追いつかない人材供給
今）困難化：攻撃者がプロ。政治犯も出る。
昔）ウィルス。愉快犯が主だった…。
ログ収集、トリアージのツール。Sandbox, SIEMとか流行り。
ツール入れた、がルールが不在などの実態ある。
優先度づけの支援とかする。
現場のしわ寄せ。
犯罪化の可能性ある
危機感ある。
セキュリティ変革
境界だけ抑えるのでは不十分。
ランサムウェアが流行った。
ユーザーが開く。
勝手に文書が暗号化される。
解除には課金が発生する。
→ネットの入り口を塞ぐだけでは対処正しくない。
ROI（投資効率）
コストがゼロなのが最高だが…何もしない訳にもいかない。
現状：都度対応、守りが受け身。
ユースケース洗い出しが大事。
シミュレーションサービスも提供
リスクの識別
対、攻撃手法の洗練。
セキュリティ
勉強する
アナリティクスで改善できるかもな期待
人手をかけないサービスの需要が求められる。
特定サービスに依存しない
どう使うとどうなるかを考える知見ある。
成熟アライアンス
BLUE COAT
アクセンチュアセキュリティ
ホワイトハッカーとの協業
C SIRT組織設計
Hot Topic: IoT/Fintech
※一気通貫でやってます
新テクノロジー推進するのは別組織
アクセンチュアデジタルが担当
ワークショップ
背景
Connected Vehicleをアクセンチュアデジタルが企画
自動車の乗っ取り
CEOがCISOにセキュリティリスクを報告指示
提案内容
CISOの責任問題
道の領域、社内のみでは不安
外部専門家への痛い
問い：
・Connected Vihcleの脅威は？
・対策は何する？
※CISOだけでなく、COO・CEOが安心してコンセプトにGo出せること。
イメージ映像（企画提案資料が動画でした ※映像に日本語スクリプト付きで提案）
Connected Vihcleの特徴
ハンドルなし
ブレーキなし
移動体通信システム
アプリケーション
車載エンタメ
オンデマンドサービス
生体認証
音声対話
交通情報網リアルタイム
駐車場駐車不要、帰宅時に送迎完備
新しいLife Styleの提案
今回チームごとに一つのユースケースについて検討
・自動運行
・移動最適化
・保険追加契約等、OnDemannd
・IoTデバイス
経営陣の意気込みを聴く
いろんな立場の声がある
CEO（デビッドさん
COO：革新的
CISO：保守的
ワークショップ内容
脅威の見つけ方
前提：開発時点、企画段階ということ
例
決済情報関わる
内部犯も脅威のひとつ
提携先など
CISO
漏れがないように。
機能ごとに。脅威を出す。
３大脅威について
１：情報漏えい
２：改ざん
３：サービス停止
ユースケースの「機能」を洗い出して、マトリクス組んで抽出
・情報取得
・比較
・通知
・意向確認
・締結（確認）
・全体
各脅威に対して、対策を組み合わせる
１ 通信暗号化
２ セキュア認証
３ 電子署名
４ システムセキュア化（ミドルウェア、バッチ）
５ 運用ポリシー（ロギング、監視設計、SLA締結）
６ サプライチェーン監査（製造工程）
７ 複数段階認証
８ HW／データデンター冗長化
９ IPS/IDS/CDNの導入
※業務では、このユースケース洗い出しの後、リスク評価の工程を行うとのこと。
他班
・PCでやる対策を車載デバイスに行う
・アウトソーシングをうまく使う
対策チーム
・自律運行
のっとり
車向けランサムウェア
身代金
連携の接続ポイント
侵入経路（カーナビ、USB、…
ホワイトリスト化する
多段認証
車側のSandboxを用意して、検証後、本番実行する環境をつくるとか
セキュリティパッチの自動Update（IoTだと大事）
一言でいうと：ひとの命を守る
データ改ざん
困るもの
位置情報（クルマ）
運行情報、交通ルールデータ（一方通行とか）
渋滞情報
支払情報
対策
通信経路の暗号化
認証（発信元）の確認、パスワードソルトの適用
改ざんされた場合
システム冗長化（運行情報を複数サーバから受け取って情報の正確さを担保する）
変更情報の通知、検知
GPS（位置情報、時差、）の改ざんは大きなテーマ
USAの軍事衛星は先行例あるらしい
交通制御システム
安全な走行が可能なもの
脅威
・クルマの暴走
・システムののっとり
・一般車との差異
対策
・通知
・多重化
・バイオメトリクス、物理キーとの二重化
・IDSによる通信抑制
他要素認証は大事
安全面
付加価値
クルマの問題点
情報の整合性
外部制御（のっとり…
複数情報
情報制御（複数箇所からデータ取得する）
暗号化、防御システム
動物センサー設置とか
文化価値を照合
アクセンチュア提案の場合…
検討アプローチ
ユースケース確認
脅威識別
企画◯◯◯に特有なユースケースは何か？
最新攻撃手法は考慮されているか？
連携先が求める特有の要件は何か？
↓
リスク評価
脅威から想定されるリスクはどう評価されるか？
技術的対策だけでなく、運営上の考慮点は何か？
↓
リスク対策の定義（AsIs/ToBe）
あるべきセキュリティの姿に必要な対策は？
その対策で責任ことなるCOO/CISOが許容可能なリスクとなるか？
利作に必要な予算はいくらで、誰が確保するか？
↓
継続的改善に必要な取り組み
適切なリスク対策を継続的に運営する仕組みは何か？
その仕組の運営には誰が参画する必要があるか？
脅威検討例
１：主要機能リストアップ
２：企画◯◯の想定脅威
３：リスク評価項目
Connected Viecle
Linuxである。PCと同等のリスクがある。
対策の情報を集めるにあたって…。
技術的な有識者が世界のどこかにいる。
コンタクトをとって、ツールや方法論をキャッチアップする。
セキュリティコンサルタント
5,000人以上のアクセンチュアプロフェッショナル
各拠点
ワシントンDC
マニラ
エンジニアリング
セキュリティ・コンサルタント
セキュリティエンジニア
これらは異なるもの
大事なこと
アプローチが大事、ユースケースの洗い出し
テクノロジー入れるだけではダメ、運営体制も大事
作って終わりでない、不要であれば破棄可能な状態になる
外部委託先の情報も観るべき
参考：
書籍「スノーデン」
世界中の通信傍受が可能
→2017年1月に映画公開
以上。
Dash前の踏み込み段階
商品到着のご報告。
Node.jsと"node-dash-button" libraryでボタン押下イベントをハンドリングするみたいなことを試したかったのです。
縦6cm、横3cm、厚み1.5cm。
このサイズなら冷蔵庫あたりに複数貼り付けていても、邪魔にならないサイズ感です。
そういえば2016年末、バズっていた記事もメモがてらに転載します。
ハード屋とソフト屋の思考の違いの着眼点。
Amazonの脅威は、プラットフォーマーがビジネスモデルから逆算してデバイスを売るという戦略とのこと。
低関与商品の位置づけを、広告からAmazonマーケットプレイスに置き換えるもの。言うなれば広告殺し。
2017年はIoTとマーケティングの実験時代。
新宿三丁目 立ち飲み日本酒BAR 酛（もと）
会社からの帰途。
ふらっと立ち寄りたくなる場所のひとつに「酛（もと）」というBARがあります。
https://tabelog.com/tokyo/A1304/A130401/13111891/
長居するでもなし。一人でふらっと入れるのが良いです（※最近店内満員のこと多いですが…）
会ったことのない銘柄探しという楽しみ方。
リストのなかの好みは、而今。次いで上喜元、飛露喜。
たまの贅沢です。
2016年の振り返り
画像とともに振り返る2016年。
2016年1月。アクセンチュアのUXのワークショップ。
体験のデザインというワークは初めて。
当初、このイベントはUIデザインのみスコープとして扱うものかと想定していたのですが、コンサルタントの視点にたって企画から提案まで問題解決を行うというものでエキサイティングでした。
そういえばこのワークショップ前後で、戦略コンサル企業が国内の広告代理店と衝突していく流れになっていること知りまして。ちょうど時代の変わり目なのですね。
春頃。dotsイベント「デザインの作り方」。
これは事例紹介が中心でした。
既存のゲームやイベントに、技術的、デザイン的な新しい要素を採り入れる。そこに価値が生まれる。
昨今のVRについても、徐々にサービスが立ち上がっていることと通じるものあります。
夏。はじめてのAirBnB。
リーズナブル、贅沢な空間。そして宿舎近辺はなにも設備がないという環境。
こういう施設も出てきているのだというのが新鮮でした。
言葉だけ知っていても、自身の体験に落とし込まないとわかったつもりになってしまうので怖いなと。
秋。水道橋のチームラボにて、Kinnectを使用したゲーム開発イベント。
最終評価の段階で、子どもが最も喜んだものが優勝というもの。
彼らは全力で取り組むのである程度耐久性が求められること、それとすぐ飽きてしまうのでリアクティブな要素を体験に組み込むのが大事なの痛感しました。
AWSのServerless（サーバレス）サービスのワークショップにも参加。
日本のそれは、USAから2年ほど遅れている現状との指摘もあるとのこと。
既存のサービスの置き換えにしても、新規事業にしても、クラウドを使うことで価値を出せるのはなんだろうという意識、大事ですよね。
冬。dotfes 2016。
CyberAgent社がエンジニアとデザイナーの価値を高める取り組みを、4年かけて積み上げてきたことに衝撃を受けました。
開発をオフショアないし完全外注体制からの脱却。社内に知見を貯める制度の構築。
勝てる組織の経営判断といいますか、変われる組織というのが脅威ですね。
最後に下記は、年末のUX関連のイベント。
IMJ流体験デザイン講座の最終回だけ参加。
誰かの不満を解消する。かつその手段は問わずといった条件下の考察は、悩ましくそして楽しいものでした。
UXに投資しない。それが価値あるものであることが伝わらないという点が、海外との明らかな差だとのこと。
振り返りは以上。
総じて、UX周辺に関心高かった気がします。
2017年も、気になることを追っていくスタンスで、手を動かしたり、各イベントで情報集めようと思います。
渋谷dotfes2016 補足編
CyberAgent佐藤さんの講演は非常に学びが多いもので、資料公開を首キリンにして待機していた…のですが、しばらくしても出てこなそうだったので当日撮った写真を補足として載せます。
先日書いたブログの方に、講演内容のテキストを載せているので適宜見てください。
※なお、部分的に公開されているものはありました。
dotFes 2016。
CAのこと、まずは社則の紹介。
この項目に「クリエイティブで挑戦する」を追加するまで4年間頑張った話し。
実践したことは経営陣とのGive＆Take。このKPIを達成したからこういった社内制度を取り入れたいという提案を徐々に推し進めていった。
講演アジェンダ
- CAとは
- CA流のモノづくり
- インハウスデザイナーに求められる役割
デザイン思考の捉え方。美大出身者であれば黒炭の白黒描写で黄色いレモンを表現できるがエンジニアにとってそれはツライ。
エンジニアもデザインを学ぶ時代。それがデザイナーとの成果物への共通理解を深める。
CAではそれを実現する職種を「テクニカルクリエイター」と位置づけている。
なのでエンジニア含めてアニメーション研修もあると。
佐藤さんはDNP在籍時代に「妥協に感動は無い」と教わったとのこと。
インハウスデザイナーとは。制度やサービス各事例をもとに説明。
制度紹介：「デザイナーロワイヤル」
社内メンバーで架空サービスに対して侃々諤々するというもの。ノウハウの蓄積の仕組み。
モックアップを作成して、デザイナー・エンジニア間で議論する場（Tech Lab）もあり。
こうしておくと、実装工程で成果物のイメージがしやすくなる。
Ameba Ownedの事例
コンセプトは、社長の実家の母でも簡単にWebサイトが作れるようになるサービス。
デザイン設計当初は、機能を盛り込みすぎていたので、簡便さ追求してブラッシュアップ。
AbemaTV事例
実際にTVアプリとして使用した場合の体験設計にも注力。
・Web版
・スマホ版
・タブレット版
以上。
モックアップに制作コストをかける。
エンジニア、デザイナー間のプロダクトへの共通理解を深める。
社員の人材価値向上のための制度をつくる。
…等々。
CA社には社内にナレッジを蓄積する仕組みやモチベーションを上げる制度ができていて、社員層の厚い会社であることが分かりました。
