寄付窓口はこちら

Tezos とオンチェーン・ガバナンス - "Kyoto amendment" に向けて | BlockChainJam2019 05 #BCJ2019

古瀬 淳 氏

Tezos Japan - Scientific director / DaiLambda, Inc. - CEO

Tezos財団技術諮問委員、Tezos Japan科学理事、株式会社ダイラムダCEO。ヘッジファンド、投資銀行などでクオンツとして理論的計算機科学にもとづいたクリティカルシステムの安全化に関わる。2018年からTezosブロックチェーン技術のコア開発とアジアでの同技術の普及活動を行っている。京都在住。京都大学数理解析研究所修士、INRIA(フランス国立情報学自動制御研究所)、パリ第七大学Ph.D(計算機科学)。

Tezosブロックチェーン。その特徴の一つとして、新技術をプロトコルに素早く取り込み陳腐化を防ぐオンチェーン・ガバナンスがある。先日、第2回目のプロトコル更新 Babylon がコミュニティ投票により可決導入され、分散合意アルゴリズムやスマートコントラクト用VM命令セットが強化された。このオンチェーン・ガバナンスによってこれから Tezos はどのように進化していくのか、またオンチェーン・ガバナンスの実施によって見えてきたものは何か、一コア開発者の視点から紹介します。

Tezos とオンチェーン・ガバナンス - "Kyoto amendment" に向けて

スライドダウンロードできます

f:id:niwatako:20191117140837j:plain

Tezosとは

f:id:niwatako:20191117140843j:plain

f:id:niwatako:20191117140910j:plain

Tezosプロトコル開発を専業にしている会社

マークルツリーを使ったストレージのサブシステムを作ったり、関数型言語からTezos用スマートコントラクトを生成するコンパイラを開発したりしています。

アジアでTezosコア開発しているところはもう一軒ぐらい。ハブになっていきたい

対面で開発する必要がないので東京でやる必要がない。

f:id:niwatako:20191117141038j:plain

京都大学はプログラミング言語研究がさかん。そこと共同研究できる。

東京のメインストリームに追随しない文化がある。登壇者の中にも京都大学関係者や同志社の方もいて、実はブロックチェーンも京都では割と強い。

インディードとか求人を見ると大阪と京都合わせても東京の1/20ぐらい。人はいないが、人を集めるには東京はやりやすいのかも。

LINEとかのオフィスが京都にできていますが、ああやってオフィスもできると海外からの訪問者も増える。

Tezosのポイント

f:id:niwatako:20191117141233j:plain

PoSでLPoS

形式検証を使っている

オンチェーンガバナンスで自分のプロトコルをアップデートする自己修正投票

TezosはPoS。そのなかでもLPoS、と言っている。

f:id:niwatako:20191117141308j:plain

DPoS(選ばれたごく少数が参加)と違って、ステークを持っていれば誰でも参加できる。

ブロック生成者とブロック生成を確かめる裏書人をランダムに選出する。

ステークを持っている人なら誰でも選出される。

でもブロック生成の施設を持ちたくなければデリゲートすることもできる

PoSなので特殊なハードは必要ない。ラズパイ4ぐらいでブロック生成に参加できる。

我々の世界ではブロック生成のことをマイニングとは言わず、Baking(パンを焼く=安い、誰でも自分のオーブンで焼ける)という。

Tezosというプロトコルを限られたマイナー業者だけじゃなくて、持っている皆さんにプロトコルの所有権を渡すという思想。

2番めの特徴は形式検証

f:id:niwatako:20191117141530j:plain

ソフトウェアをいろいろな条件下で動作させて確認するが、我々はソフトウェアは重要だが、動作確認は安全を保証しない、数理的に、絶対間違えないことを証明していくことを重要視している。

プログラミング検証技術の最新技術を使ってテゾスのシステムを作っている。スマートコントラクトを安全にするという話が多いが、それだけではなくて、ノード実装そのものや、コントラクトの実行機や、コンパイラについても形式検証を行っていくというスタイルを取っている。

なのでTezosの開発シームは、世界で50人弱居るが、そのうち半分ぐらいがプログラミング言語研究、形式検証のPhD持っている人。私もそう。

f:id:niwatako:20191117141737j:plain

オンチェーンガバナンスがTezosの一番面白い特徴。

プロ後コルのアップグレードはチェーン上で投票を行って、本当に採用するか決める。

採択されると自動的に移行する、そういう仕組がプロトコルの中に入っている。

修正がプロトコルに入っているので自己修正といっている。

プロトコルを、ごく限られた開発者集団から、ステークホルダーにお渡しするという思想。

オンチェーンガバナンスについて詳しく話す前にユースケースを紹介

f:id:niwatako:20191117141924j:plain

一つはSTO。

安全性に関して非常に力を入れていると理解していただいているので、STOプラットフォームとして利用されている。

10億、6億といった規模の不動産などで利用されている。

他には、割と堅いプロジェクトが多い

f:id:niwatako:20191117142019j:plain

簡易保険、穀物先物、出資プラットフォーム

面白いところでは車に関するプロジェクト、CHORUS mobility

f:id:niwatako:20191117142057j:plain

自動運転や無人タクシーの支払いシステム

自動運転車が複数走っているときに小銭を払って先を活かせてもらったりとか

パブリックチェーンのTezosでやられている。

堅いものだけではなく、Coaseのデジタルカードゲーム

f:id:niwatako:20191117142139j:plain

マジック・ザ・ギャザリングのプロプレーヤーやゲーム開発のプロを呼んでモクモク作っている様子。

話を戻してオンチェーンガバナンスについて

f:id:niwatako:20191117142228j:plain

f:id:niwatako:20191117142238j:plain

よくある誤解

「オンチェーンガバナンスがあるからハードフォークしない」

Tezosは積極的にハードフォークする。

ハードフォークには2つ意味がある

非互換のプロトコルアップグレードをする、もう一つはコミュニティのハードフォーク。

どんどん新しい技術を取り込むためにハードフォークはするが、コミュニティのハードフォークはしたくない

そのために投票をオンチェーンでやる。

投票結果に従うか従わないか。あえてしがたわない人についていく人はいないだろうという位置付けでデザインされている。

ハードフォークは必ずオンチェーンガバナンスで通すが、もし本当に問題のあるバグがあったら、投票システムを通さずに緊急のバグフィックスが配布されることもある。

技術的ハードフォークは怖がらずにやる、バグがあるのでそこを形式検証や安全性を確かめる技術でやって壊れないハードフォークをする。

じっさいにオンチェーンガバナンスはこのようにおこまいます

f:id:niwatako:20191117142551j:plain

  • プロトコルの変更をコードとして提案しP2Pで配布
  • 提案の一つを選択
  • テストするか投票
  • 各ノードで自動テスト
  • 採択するか投票
  • 80%以上の賛成票が得られれば採択し自動的に行こう

約90日間で1周するサイクル。

非常に機械的アップグレード方法が書かれているが、投票に至る議論はチェーン外で当然盛んに行われている。

f:id:niwatako:20191117142737j:plain

オンチェーンガバナンスの初の社会実験

  • 2019/02/26 提案
  • 2019/05/29 移行
  • 賛成票 99.89%

GasLimit緩和、ステーキング条件緩和

このまえの Tezos 005 Babylon

f:id:niwatako:20191117142844j:plain

初の本格的なプロトコルアップグレード

  • 2019/07/26
  • 2019/10/18
  • 賛成票84.53%

合意アルゴリズムの改良(EmmyからEmmy+へ) スマートコントラクト強化 デリゲーション手続きの単純化

今入っている新しい提案 Carthage

  • 2019/11/13提案

f:id:niwatako:20191117142955j:plain

Gasリミット緩和、スマコンVM命令強化、細かいバグ修正、プロトコルコードのクリーンアップ

Delphi

f:id:niwatako:20191117143052j:plain

2020年3月提案

  • zk-SNARKsのスマートコントラクトへの導入
  • プログラマブルステーキング
  • 投票システムの改良
  • 新ストレージサブシステム

将来的には

f:id:niwatako:20191117143208j:plain

中本コンセンサスではなくてPBFTベースの合意アルゴリズム(Tendermint, Avalance)へ移行したり、Layer2ソリューションに対応したり、Prediction marketによるプロトコル改定案の評価と報酬決定(プロトコル提案を出したときに、これならこのぐらい報酬を払ってもいいのではないか)

今後の課題

f:id:niwatako:20191117143355j:plain

提案後にバグが出たり、更新後に問題が起きたときとか

プロトコル事前テイスト体制の充実が必要。アプリ開発者自身はプロトコルを触っていないが、プロトコルの変更を知って、アプリを更新しないといけない。

ユーザーはプロトコルの変更に興味がない場合も多い。

全体としてコミュニティの問題。技術アップグレードに対して全員で育てていくことが必要。

開発者としては、3ヶ月に1回プロトコルバージョンアップがあるのは大変。

アップグレード終わった瞬間に次のを出さないといけない。これは割としんどい。

プロトコル修正名は世界の古い歳をアルファベット順にやっている。

アテネ、バビロン、カルタゴ、デルファイ

f:id:niwatako:20191117143611j:plain

2021年前半にKに到達する。

Kで世界で古い都市はKyotoだ!!

そこに合わせてなにか面白い提案をできればと思っています。

ありがとうございました。