はじめに
こんにちは新規事業開発室の生田@ikutyyです。
先週、メルカリさんでblockchain.tokyoの第8回が行われたので復習もかねて当日の内容をこちらにまとめたいと思います。当日の様子はTwitterでハッシュタグ #blockchaintokyo でツイートされているので、興味のある方はぜひそちらもご覧ください。
- はじめに
- 分散システムを支える技術とProof of Stake @mistat
- ethereum / casperを読み解く @kei_0811
- Tendermint ~ scalable blockchain consensus engine ~ @keita0q
- Lightning Network Watchtower @parakeety_
- ERC721 - Non-fungible token standard @yuzushioh
- 最後に
分散システムを支える技術とProof of Stake @mistat
最初の発表はメルペイの高橋さんより発表でした。
この後に続くCasperやTendermintと言ったコンセンサスアルゴリズムに関連する発表の前におさらいということで、ブロックチェーンやコンセンサスアルゴリズムの概要の紹介をして頂きました。
分散システムは通常、パフォーマンスやスケーラビリティを向上させるための手段の1つですが、ブロックチェーン（パブリックブロックチェーン）の場合、分散システムはそれ自体が目的になっていて、前者と比べて目的と手段が逆転しているというお話が印象に残りました。
まず最初の発表で導入となる登壇をして、その後に込み入った話をするというイベントの構成自体も参考になりました。次回以降、Gunosyでblockchain.tokyoを主催する際に、この登壇構成でやってみたいなと感じました。
ethereum / casperを読み解く @kei_0811
続いて次元さんよりEthereumで導入されようと議論がされているProof of StakeのCasperについての紹介です。
Casperは2つの案が提唱されていて、今回はその中でもCasper FFG(Friendly Finality Gadget)と呼ばれるEthereumを構想したVitalikが進めている案に関する内容です。
以下のスライドで紹介されているコードはこちらからご覧ください。
CasperのコントラクトはてっきりSolidityで書かれているものだと思ったらVyperとSerpentで書かれているとのこと。2つの言語が共存している時点でカオスな感じが漂いますが、本番に適用されるとなった時には綺麗になっているんでしょう。VyperやSerpentというPythonベースの言語で記述されている理由は、VitalikがPythonエンジニアだったことに恐らく由来してます。
ERC20トークンのコードをViperとSolidityで比較してみた - Gunosy Blockchain Blog
特にファイナライズをするブロックに対して投票(vote)しているではなく、ファイナライズするブロックを持つノードに対して投票しているというのは学びでした。そのあたりの正確な理解はコードを読んではじめて出来るものだと思うので、やはりコードリーディングは必須ですね。僕もCasperのコード読んでブログ書きます（宣言）。
Tendermint ~ scalable blockchain consensus engine ~ @keita0q
最後の登壇は同じくメルペイの中村さんによるTendermintの紹介でした。
TendermintはP2Pネットワークとコンセンサスアルゴリズム(PoS)をコンポーネント化してくれて、独自のブロックチェーンが開発できるソフトウェアです。ブロックチェーンが当たり前になる社会がもし来るとするならば、このようなプラットフォームやサービスは必要不可欠ですね。
びっくりしたのはTendermintはPoSなのにフォークをしないという点です。PoS以前にbitcoinをはじめとするパブリックなブロックチェーンはフォークをすることが前提で、インセンティブ設計が考えられています。ブロックチェーンがフォーク（分岐）した際に最長のチェーンをメインチェーンとするというのもその1つです。先日、この原則を悪用したBlock withholding attackという攻撃をモナコインが受けました。
モナコインへの攻撃から、ブロックチェーンへの攻撃やマイニングを深掘りする - Gunosy Blockchain Blog
フォークしないということは、このようなフォークすることによるリスクが無くなるということなので、セキュアなチェーンが構築できそうです。
Lightning Network Watchtower @parakeety_
Lightning NetworkのWatchTowerという機能に関する発表を岡田さんにしていただきました。
Lightning Networkはbitcoinのレイヤー2と呼ばれるスケーラビリティ問題を解決する施策の1つです。すでにメインネットにも実装されていて、利用できます。
Bitcoinの Lightning Network で支払いしてみた！ - Gunosy Blockchain Blog
Lightning Networkではトランザクションをメインチェーンの外側で処理する際に、Opening Transactionでチャネルを開き、Closing Transactionでチャネルを閉じます。その間に複数のCommitment Transactionを生成することができます。
そこで問題になるのは、自分に都合の良いCommitment Transactionだけを含んでClosing Transactionをブロードキャストしようとする悪質なノードが登場することです。その問題を解決するためにWatchtowerと呼ばれるトランザクションを監視する機能が提案されました。
Lightning Networkなどのメインチェーン外でトランザクションを処理することはスケーラビリティ問題を解決していくために必須ですが、また異なるセキュリティリスクが発生するのでそれらを解決する仕組みがセットになるというのはとても大切だなと感じました。
ERC721 - Non-fungible token standard @yuzushioh
最後のLTはゆずしおさんによるERC721トークンに関するお話です。
ERC721トークンは一時期話題になったCrypto Kittiesなどで用いられているトークン規格の1種です。スライドでも紹介されていますが詳しくはopenzepperin-solidityのコードをぜひご覧ください。
トークンの規格にはERC20やERC223など様々なものがあります。
もっともシンプルな実装は、ERC20なのですが、ERC721はERC20が有している基本的な実装に加えて、1つずつのトークンにユニーク性を保持するためのメソッドが追加されています。
現在はERC998でComposable Non-Fungible Tokenと呼ばれるものも提案されており、今後も新たなトークン規格が出てくることは間違いないので要注目です。
最後に
弊社ではブロックチェーンエンジニアを正社員・インターン問わず募集しております。
ご興味のある方はぜひ以下のリンクからご応募ください。