「blockchain.tokyo #8」に行ってきた
に行ってきました。
今までblockchainを実装したりEthereumのwikiを翻訳したりしていましたが、
進化が本当に早く追いつけていない事が多いので断片的にでも今の状況がわかってよかったです！
コードも論文も読んでいくぞ！
分散システムを支える技術とProof of Stake 高橋三徳(@mistat)
分散システム
↔集中システム
- それぞれのノードが非同期的に自立して動いている
- 全体としては一貫性があり、一つのシステムとしてみえる
- 一部のノードが故障しても全体に影響しない
分散システムは課題を解決する一つの手段だが、ブロックチェーンは非中央集権化が目的になっている。
ethereum / casperを読み解く 次元 (@zigen)
new fork choice rule
- 一つのepochで複数のcheckpointから一つを選ぶ
- voteして2/3とったらjustified
- 次のcheckpointがjustifiedされたら親がfinalized
以後コードの解説 https://github.com/ethereum/casper
- どこにvoteするかをchoiceしている！
- コードを読めばわかる!
Tendermint ~ scalable blockchain consensus engine ~ 中村 奎太 (@keita0q)
solustions
- layer2
- side chains
- plasma, cosmos
- state channels
- raiden, lightning
- side chains
- layer1
- sharding
- ziliqa
- consensus
- casper, tendermint
- sharding
tendermint
- PoS Transaction処理速度が早い
- ファイナリティがすぐ得られる
- フォーク市内
- 1/3までバリデーションノードは停止していても問題ない
- ABCI 独自のアプリケーションレイヤーを実装できる
- コンセンサスエンジンとアプリケーションロジックをつなぐインターフェイス
- message protocol
- blockchain protocol
- mempool connection
- consensus connection
- query connection
- BFT-based PoS
- voteが2段階あることでpre-commitではcommitは必ず一つになる->forkしない
- DDosに弱い->IPを隠す
LT1 @tomomoto_LV3
- 前処理大全の中の人
- サスメド株式会社
- 不眠症治療アプリ開発
- 臨床試験/治験のデータプラットフォーム
- データの改竄を防ぎたい
- パブリック型では改ざんが起こってしまう->コンソーシアム型に
- データの量は少ない
Hadoop Blockchain比較
- ロギングとして扱うか、DBとして扱うか
- DBの場合はCAP定理に従う
LT2 @parakeety_
常時起動していないモバイル端末でlightning networkを利用するためにwatchtowerが必要
