builderscon 2019-08-30に参加してきたのでアウトラインメモ。

ブロックチェーン時代の認証 - builderscon tokyo 2019

スライド: ブロックチェーン時代の認証 / Authentication in the Blockchain Era - Speaker Deck

  • ブロックチェーンのゲーム開発してる
  • ブロックチェーンとウェブ認証
  • ガードナーによるとブロックチェーンは幻滅期に入った
  • ブロックチェーンゲーム
    • ブロックチェーン技術を使ったゲーム
    • ブロックチェーン上にアイテムやキャラクタの所有情報を記録する
    • デジタルアセットが運営からの貸与じゃなくて、ユーザーの所有になる
  • 通過
    • 量を扱う単位
  • デジタルアセット
    • モノに近い概念をデジタル上に再現している
  • mch.gg
    • ブロックチェーンゲーム
  • MyCryptoHeroes
    • ブロックチェーンのEthereumを利用してる
  • ブロックチェーンゲームの歴史
  • なぜゲームにブロックチェーン?
    • ゲームにエコノミーを再現できるから
  • ブロックチェーンとは
    • ブロックチェーンは分散型台帳を実現する記述
    • 「前ブロック情報」と「実行するトランザクション情報」とある条件を満たすNonceを見つける = マイニング
    • マイナー
  • ブロックチェーンの用語
    • 文脈によって「ブロックチェーン」の意味が変わる
      • 技術の話 ← 今回はここ
      • 暗号通貨
      • ブロックチェーンネットワークの話
    • ネットワークも種類がある
      • プライベート
      • パブリック
  • パブリックネットワーク
    • 誰でも参加できる
    • Bitcoin
      • ブロックの概念にインセンティブを導入して成り立つようにした
    • Ethereum
      • 分散型台帳とSmartContractというアプリケーションプラットフォームを使った
    • Ethereum
      • EVMで実行されるSmartContractをSolidity言語で記述する
        • 賢い契約
      • EIP/ERCというコミュニティ主導の標準規格
      • 開発から見ると
        • 公開暗号鍵によるアカウント機能とEthereumの仮想通貨を使った決算基盤が便利
    • ブロックチェーンは改ざん不可能
      • ノード運営者は自分の利益のためのブロックを生成する
      • だれかの一人だけの意思で改善は不可能
      • トランザクションも電子署名を使ってるのでなりすましができない
    • ブロックチェーンはリアル
      • デジタルアセットを自由に扱える = 所有
      • 管理者によっては管理は困難
      • ブロックチェーンによって不自由になるけど現実に近い
    • 公開暗号鍵と電子署名
      • 秘密鍵と公開鍵のペアをもつ
      • あるメッセージのハッシュに対して秘密鍵を使った電子署名を作成する
      • 電子署名とメッセージを使って公開鍵を得ることができる
    • ブロックチェーンにおける公開鍵暗号技術
      • ECC 楕円曲線暗号を使った ECDSAを使うことが多い
      • secp256k1が用いられることが多い
        • Bitcoinが最初に採用、Ethereumもそれに追従してる
        • NISTには採用されてない
    • アドレスとトランザクション
      • 秘密鍵に対応する秘密鍵にハッシュ関数をかけたものをアドレスと呼ぶ
        • ブロックチェーンでは アカウント = アドレス
      • ブロックチェーン上に発行する処理の単位をトランザクションと呼ぶ
    • トランザクションの履歴を見れる
      • 誰でもトランザクションの履歴が見れて、アドレスをたどっていける
    • 非中央集権的なWeb、Web3
      • 今のウェブは中央集権的なサービスを通じて個と個がやりとりできるようになった
        • 中央集権的なサービスを経由してやり取りする
        • プライバシーやデータはサービス提供者により管理されている
      • ブロックチェーン、Ethereumの登場でアプリケーションは非中央集権的な管理ができるようになった
        • 管理者が不在で管理できる
      • Web3
        • Ethereumを扱うライブラリのことをWeb3と言ったりしてる
    • Ethereum Wallet
      • Ethereumにおける鍵の単位
      • 秘密鍵だけではなにもできない(手計算)なので以下の機能セットをEthereum wallet
        • ノードへの接続情報
        • トランザクションの生成
        • トランザクションの署名
        • その他、サービスから秘密鍵を隠蔽してサービスにアクセスできる
    • Web3というぐらいなのでブラウザから利用できる
    • window.web3
    • 非中央集権的
      • 全てをブロックチェーン上で処理するのは難しい
        • スケーラビリティ問題
        • 実行負荷は利用者が負担
      • 現実的にはオフチェーン(普通のサーバアプリ)と併用しないと無理
        • どこまでオフチェーンを使うかは好み
      • オフチェーンを利用する場合は、なんらかの方法でオフチェーンのアカウント紐付ける方法が必要になる
        • オフチェーン上で認証が必要になる
    • パスワード認証
      • 推測不可能な文字列にする必要がある
      • サービスが同じものを使うべきではない
      • 多要素認証なども必要
      • ⇒ ユーザー負担が
    • 認証に利用される要素
      • 知識: パスワード、秘密の質問
      • 所有: セキュリティキー、デバイス
      • 整体: 指紋、静脈などの本人の生体情報
    • FIDO2/Web Authn
        1. 事前に公開鍵を登録
        1. ログイン要求
        1. チャレンジコードに対して秘密鍵で署名
        1. 検証して一致すればOK
    • ID管理からの分離
      • 中央集権型ID
      • ユーザー中心ID
      • 非中央集権型ID
    • 中央集権型ID
      • 殆どのサービスはこれ
      • サービスに認証情報を登録して利用可能になる
    • ユーザー中心ID
      • SNSログイン、ID Providerへの集約
      • SSO
    • ブロックチェーンとウェブ認証
      • 公開暗号鍵技術が重要な位置づけ
      • アカウントを認識する手段にも使われている
    • SSID (Self Sovereign Identity)
      • 特定の管理主体に依存せずに、ユーザー自信のIdentityを自ら作り出す
      • ブロックチェーンと相性がいい
    • ブロックチェーンのログインのデモ
      • ログイン
        • チャレンジトークに対して署名するかどうか
      • FIDO認証の流れと大体同じ
      • EIP 191というメッセージ署名の仕様がある
      • 「所有」情報だけで署名してる
        • デバイスを取られると盗まれる
    • ブロックチェーンが普及した世界では誰でも電子署名ができる
      • その世界では、アカウントの信頼とは何かという話になる
      • アカウントの信頼を得るための権利を購入
      • 行動履歴によって信頼される
    • KYC
      • 身元確認
      • デジタルアイデンティティとリアルなアイデンティティは別の可能性がある
        • KYC(身元確認)とは相性が悪いかも
        • KYCは国によって守られてる
    • ブロックチェーン会員権
      • あるトークンを持っている人だけの入れるコミュニティ
        • トークンは売り買いできたりする
      • 現実ではこれやると色々問題がある
        • ゴルフの会員権問題とか
    • アカウントに紐付いた行動履歴での信頼
      • SSIDが目指してブロックチェーンが得意な部分
        • 健全な取引をしている
      • ブロックチェーンの設計はトラストレスであるが、人の判断はトラストフルに行われる傾向がある
    • アカウントとは
      • 今までの話では、秘密鍵 = アカウント
      • 秘密鍵はいくつでも作成できる
      • 人間より多くなる
      • アカウントによってなにを確認したいかが重要になる
      • この状態では初回アカウントに対するインセンティブはリスクが高い
    • 鍵の紛失 = IDの喪失?
      • 管理者が紛失についてバックアップしてくれたけど、非中央集権だとそれがなくなる
      • 鍵の中央集権的なサービスが出てくるのでは
      • 署名 as a service
    • 生体情報
      • 生体情報から鍵を生成する技術はあるらしい
      • seed値を生体情報にする
    • まとめ
      • ブロックチェーンは不可逆性、非中央集権によりデジタルがリアルに近づく
      • ブロックチェーンにおいてパスワードレスは実現されてる
        • 紛失とか色々問題も
    • Q. RTMができる
    • A. RTMはガチャモデルと相性が悪い。ガチャを売れると賭博モデルになる。ブロックチェーンゲームだとただのアイテム販売なので、ガチャを避けてる
    • Q.GPG
    • A. 現実の人間と紐付けていない。複垢とかは許可していて、複垢によるインセンティブをなくす方向にしてる

RDBのトラブルの現場を追え！

スライド: ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳

  • RDBMSの死はサービスの死
    • DBが書き込めないとサービスが止まる
  • WSL 2が壊れた
  • https://www.amazon.co.jp/dp/B07P8PMHLL/
  • スロークエリの現場
    • サービスを落とすのにはスロクエリがアレばいい
    • REPLACE構文 = MySQLの独自構文
      • サブクエリ
      • MySQL 5.5相当以下だと駄目
    • とてもでかい文字列を引く
      • バイナリをデータベースに保存しない
      • PostgreSQLだと追記なので2倍の容量が必要
        • HOT(Heap Only Tuples)がは一定サイズ以上だと使えない
        • ⇒ PostgreSQLだとラージオブジェクトを使う
      • でかいデータはRDBMSに入れずにパスを入れる
        • Phantom
      • バルクインサート
        • もっと早い機能がある
          • MySQLならLOAD
          • PostgreSQLならCOPY
          • CSVを一括でインサートできる感じ
          • こっちのほうが早い
    • スロークエリの原因
      • 無知 ⇒ クエリチューニング、クエリを直す
      • 設計の問題 ⇒ テーブル設計を直す
    • スロークエリ
      • 実行計画を見る → テーブル設計を直す
  • 不正データの現場
    • データが壊れた場合
    • 制約で守る → 守れないものがある
    • 予約のテーブルの例
      • 予約時間 < キャンセル時間
      • チェック制約 MySQL 8
    • 過去のデータのリストアできない
      • テストでも困る ← チェック制約にかかる
    • 遅延制約をつける
      • ALERTとかCREATE時に付けないといけない
      • あとからは付けられない
    • nullはuniqueなのでindex付けない
    • 管理画面とか生SQLで書いてしまって不整合なデータができる
      • テストとかヒューマエラーが不正なデータ入ることがある
      • データはINSERTやUPDATEに成功してしまうと、それが正しいのかは別
    • 不正なデータから守るには
      • 制約でデータを守る
      • テストで振る舞いを守る
      • モニタリングでサービスで守る
  • パフォーマンスチューニングの現場
    • ISUCON 8の予約テーブルの設計
    • 設計の問題があるのでパフォーマンス問題がある
      • 共有テーブルなのでロックが入る
    • ⇒ 残席テーブル(座るテーブル)を作る
      • 予約されたら残席テーブルをいじる
    • InnoDBは event_id で暗黙的にsortされる
      • 先頭からlimit 1で取ればランダムで取れる
      • MySQLだけなので
  • ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
  • JSON型
    • EAV(エンティティ・アトリビュート・バリュー）の代替えになる場合がある
  • 集合論から外れないようにRBDMSの特性を生かした設計をする
  • 突然DBが壊れた現場
  • 何か壊れたかが大事
    • パフォーマンスの悪化
    • データの不整合が発生
    • データベースが応答を返さない
    • コネクションが溢れている
    • 間違えてDROP TABLE
      • MySQLは begin して drop tableするとauto commitされて消える
      • PostgreSQLは restoreできる
  • 壊れ方を知るためにはモニタリングが大事
    • Selectでメモリに乗らなくなるといきなり遅くなる
  • データベースが突然遅くなる
    • データが増えて、メモリに乗らなくてスワップで落ちる
    • CPUがサチってDisk IOに余力がない
    • データ傾向が変わって実行計画が変わった
      • BTreeでインデックスが聞く場合のデータ量の違い
    • そもそも意図した実行計画を使ってくれない
    • 1つの小さな遅延がロックによって顕在化する
      • DBは遅くなるときは右肩上がり
  • データはカジュアルに壊れる
    • バグやヒューマンエラーで壊れる
      • → 制約で守る
    • 予想外のデータはいつでも入ることがある
    • DROP
  • mysql-casualとpostgresql-jp
    • slackグループ
  • DBAがやってる
    • DBREはDBAがやってることをみんなができるように
  • DBは同じ話が30年前からある

非同期処理の歴史から見たコンピューティングの進化

  • 非同期処理
  • 画面がフリーズしないようにするために非同期処理をいれたのにフリーズする
  • 累計のインターネットユーザー
    • 32億
  • CPU Clock Seek
    • 1 CPUの性能が限界がでてきてマルチコアが増えてきた
  • Oracle Concurrency Guide
  • Swigのプラクティス Java 1.4
    • Initial Thread
    • Event Dispatcher
    • Worker Thread
  • Java 1.4
    • Thread Poolで処理ができるようになった
    • Executorに処理を渡すとThread Poolで処理をする
  • Thread Interface
    • 非Atomicな操作
    • Javaでは++ とかはAtomicな処理じゃないので、Thread間で同じ処理するとおかしくなる場合がある
    • Atomicにするには syncronized でできる
  • happens-before
    • syncronizedはhappens-beforeをもたらす
    • 順番を位置ずれる
    • これをJava 5.0でしようとしてまとめた
    • Java memory model - Wikipedia
  • java.util.concurrent.locks
    • volatile
    • Thread間でhappens-beforeを持たせらせる
  • CAS
    • CPUでのThread Safeの命令
    • 書き込みを行う時メモリが書き換わっていたら失敗する
    • Concurrent
  • OSとCPU
    • Systems Performanceという書籍
    • CPUのメモリアクセスは階層
      • Register
      • L1 Cache
      • L2 Cache
      • L3 Cache
    • CPUに状態がある
      • BSDだとProc.hにCPUの状態が定義されてる
      • CPUで走らせるThreadの数はコア数に依存する
        • それ以上だとコンテキストスイッチが起きるのでコストでかい
    • AjaxとGoogle Maps
      • Google Maps以前は画面遷移が必要だった
    • コールスタックとイベントループ
      • タスクをスタックに処理を積んで、イベントループで処理をスタックがとってくる
    • C10K
    • Node.js
      • イベント駆動モデル
      • タスクキューを種類別に持っていて、そのキューに積んだ処理を順番にイベントループで処理していく
    • C10K問題のまとめ
      • OS thread生成やコンテキストのコストがある
      • イベントループ
    • Promise
    • Async Function
      • 非同期処理を同期処理のように
    • Scala Future
    • Functional Programming と Immutable
      • どちらか一方がwriteである場合にconflictすると、data raceの原因
      • Immutable objectsの話はOracle Concurrency Guideでもでてくる
      • Functional Programming
    • Akkaとactor model
      • JavaのActorモデルの実装の一つがAkka
      • リッチなアプリケーションだと状態が増える
      • Immutable + 非同期のときに
        • 複数のThreadに同じIDを持つImmutableオブジェクトが存在することがある
        • IDでデータを取り出したいときに困る
      • ⇒ Demon Threadで管理できるが
        • Conflicting accessが復活する
      • Shared mutable
        • Immutableを諦めるパターン
      • アプリケーションの状態をデータベースに逃がす
        • DBのトランザクションで管理する
        • DBが複雑化する
      • Actor
        • オブジェクトはカプセル化され、メッセージのみでやり取りする
        • 直接オブジェクトのメソッドは呼べない
        • メッセージのtypeに対してコールバックを登録する感じ
        • Akka ActorのメッセージキューはConcurrentLinkedQueueを使ってる
          • CAS命令を使ってる
        • ある時点においてはActorは1つのスレッドで実行される
          • Akkaの中でvolatileを使ってる
          • happen-beforeが成り立つ
          • volatileな変数をreadするときに、そこに至るThreadでの変更を観測可能になってる
      • 関数型方向の進化(Scala)
        • Scalaで非同期処理を主要機能に含むライブラリ
      • 関数型での非同期処理のプラクティス
        • Computation
          • メインの処理
        • Event Dispatcher
          • イベント駆動用
          • 少ないThreadでいい
        • Blocking IO
          • IOに対するThread
    • 全体的なまとめ
      • 処理の細分化、書きやすか
        • Java 5.0時代は書きやすい感じではなかったけど、色々書きやすいものがでてきた
      • 抽象化
      • 堅牢化
      • 効率
  • Q&A
  • Q. 非同期処理のデバッグが大変なイメージ。Akkaでのデバッグはどうやってる?
  • A. 泥っぽい方法。print、ログを充実させていく

ソースコードを堪能せよ - builderscon tokyo 2019

スライド: ソースコードを堪能せよ - Google スライド

  • ソースコード上に誤りがあるとコンパイルエラーになる
    • コンパイルエラーがなくなるまで修正する
  • コンパイルエラーにならないバグもある
    • 仕様どおりに作られてない
    • ライブラリの使い方の問題
    • 文法上は問題になってないミス
    • 実行時エラー
  • コンパイルエラー以外のバグを見つける方法
    • テスト
    • QA
    • 監視
  • バグは早い段階で見つけたほうがいい
    • バグの発見が遅れるほど、深刻化しやすい
    • デプロイ前に見つかるといい
  • コンパイル前にバグを見つける方法
    • 静的解析を行ってコンパイルエラーにならないバグを見つける
    • 静的解析 = プログラムを実行せずに解析
      • Lint
    • 動的解析 = プログラムを実行して解析
      • Race Detector
  • ソースコードは文字列の固まり
    • 静的解析を行う理由
  • みんな大好きgrep
    • grepだと文字列の検索
    • 文字列としての検索しかできなくて、関数名として検索とかができない
  • コンパイルでは発見できないバグを見つける
    • reviewdogでコメント
    • 人間に指摘されるより機械的に指摘したほうが気持ちが楽
  • Go
    • go: ソースコード → トークン → AST → 型情報
    • x/tools/go: SSA → ポインタ解析
  • goパッケージ
    • go/* にASTとかの標準パッケージがある
    • x/tools/go/* に更に高度な操作ができるパッケージがある
  • 字句解析
    • go/scanner, go/token
    • プログラムのソースコードを意味がある単位に分解していく
  • 構文解析
    • トークンを木構造のASTに変換する
  • 静的解析で見るける問題のコード例
    • 実行時エラー
      • パニックがおきる例とコード例
    • 同じパッケージを２回読み込んでいる + 名前違い
      • コピペで起きやすい
  • GoのAST
    • FuncDec
    • GenDec
  • 型チェック
  • SSA(静的単一代入)形式
    • 変数への入力(代入)を1回だけに制限した最適化
    • その変数に対する代入は1度のみになる
    • 解析がしやすい ← 代入が一回だけになるので
  • 基本ブロック
    • 関数を構成する単位
    • FFAまで落とすとパターンがシンプルな構造になる
  • エラー処理のミス

    • nil以外を返すべき所nilを返している

      if (err != nul){ return nil; // <= NG }

    • if命令 → return命令でnilを返してるところを探せばできる

  • Spannerのセッションリーク
    • オープンしたけどクローズしてないのを探す
    • Goだとブロック単位なので、ブロックをたどってstopやdoを読んでいなければ、そのブロックのコントールフロー
  • ポインタ解析
    • ポインタがどこの変数を示しているのかを静的に解析する
    • インターフェースを介したメソッド呼び出しをトレースできる
  • 各フェーズのまとめ
    • 字句解析
    • 構文解析
    • 型チェック
    • SSAへの変換
    • ポインタ解析
  • Goでの静的解析
    • skelton
  • 静的解析
    • プロダクションアプリの一部として
    • 採点基準のツールとして
  • Q. SSAはどういう?
  • A. SSAにすると tmp1、tmp2みたいな感じで変数を割り当てて行く
  • Q. false positiveにどうする?
  • A. 見つけたほうがいいほうがマシなものに対して積極的に書ける
  • 間違ってたとして、もし合ったら困るやつにはfalse positiveを受け入れてる