ポリグロット・エコシステムへの道【超訳ホスキンソン】

2022年9月26日に公開された、チャールズ・ホスキンソン氏の「Road to Polyglot EcoSystem for Cardano」を全文「超訳」しました！
今後の「ヴォルテール時代」に向けた大きな組織改変や、そのために必要な「Standard（標準規格）」と「信頼できる情報源」、そしてそれを担う「Agda Core」など、将来のカルダノに必要不可欠な最後のピースが語られます。
翻訳ー @dino_coffeepool

ポリグロット・エコシステムに必要な「標準規格」とは？

今日は2022年9月26日です。私は、非常に重要なトピックについてお話しするためのビデオを作りたいと思います。実は先週のほとんどを、何らかの形で議論したり、関連付けたりして過ごしたことなのです。ご存知のように、今、裏では「メンバーベースの組織（Member-based Organization、以下MBO）」の足場を作るための膨大な作業が進行中です。MBOは、基本的にコミュニティを集約するハブのような役割を果たし、コミュニティの意志を決定し、そこに到達するための戦略を考え、人々に実行を促します。

何が凄いかというと、誰もが自分の声を共有できるようになるのです。「声」はさまざまな方法で機能します。TwitterやReddit、Telegramに加えソフトウェアもあります。健全なエコシステムを構築するためには、ポリグロット（あらゆる基軸に対応できる）・エコシステムを構築する必要があります。つまり、全く異なる開発チーム、異なる哲学、異なる言語、そして異なるUSP（Unique Selling Proposition、独自の強み）を持つ複数のクライアント（システムを利用するPCやソフトウェアなど）が同時進行していることが必要です。

そこで、「Cardanoの正しいクライアントは何か？」という問題が出てきます。これは、「Cardanoのウォレットの標準的なクライアントは何か？」という質問と非常によく似ています。その答えは「ない」であるべきで、その代わりにあるべき答えとは、私たちが「ある標準規格（Standard）」で合意することです。そして、その「標準規格」とは、強固なテストフレームワークを備えています。そうすることで、ウォレットクライアントには、認証済みと未認証の2種類があります。

そこで、私はビデオを作成することにしました。実はリック・マクラケン（Rick McCracken）がTwitterでアンケートを実施しています。彼は、仮説的なアンケートを実施しました。

Hypothetical Poll: If @dcspark_io put in a #ProjectCatalyst proposal for $8 million USD to build another Cardano node implementation in Rust and open source, how would you vote?
(just a thought experiment)

— Rick McCracken DIGI (@RichardMcCrackn) September 25, 2022

「DCsparkがRustでオープンソースの新しいCardanoノード実装を構築するために、800万USDのプロジェクトのCatalyst提案を出したら、あなたは投票しますか？」というものです。
この質問には、多くの人が「興味ある」「賛成票を入れる」と回答しました。これは公平な質問で、実は私たちも長い間考えていたことなんです。

分散化しながらクオリティを保証する「コア組織」の必要性

私たちはPriviledgeと呼ばれるEUのレガシープロジェクトからスタートしました。私たちIOは、実際にお金をもらって、guardtime、 IBMリサーチ、タルトゥ大学（エストニア）、サレルノ大学（イタリア）、エディンバラ大学（スコットランド）と一緒に仕事をしました。それに対する私たちの貢献は、この「Updatable blockchains（更新可能なブロックチェーン）」というアイデアです。Nikos、Michele、Aggelos、Dionysisによるものです。
「セキュリティと優れた仕様と優れたテストを得られると同時に、複数のクライアントが存在可能なエコシステムをどのように作るか？」について長い話し合いを持ちました。

裏では、「Agda」という言語を使っています。 基本的にAgdaは、簡単に言うと「スーパーHaskell」です。多くのインフラを構築し、仮説のインフラから応用のインフラへという方向に進み始めています。ホワイトボードを使って今から色々説明しますが、ここで基本的にお話したいのはMBO（メンバーベースの組織）についてです。

その中にはCTFs（Cardano Technical Fellows、カルダノ・テクニカル・フェロー）という考え方があります。基本的にこの人たちはCore（コア）に携わる人たちで、コミュニティから来た人たちです。コミュニティのメンバーであり、スタッフでもあります。特定の企業に肩入れしているわけではなく、MBOに出向しているか、実際にMBOのために働いているのです。
どのような場合においてもAgda Coreがあり、それがリファレンス（標準規格）となります。注意していただきたいのは、Agda Coreはプロダクション（製品）ではないことです。
プロダクションとは、今皆さんが持っているダイダロスウォレットなどであり、これには多数の副次的なコードや、副次的要素がたくさん入っています。

基本的に、プロダクションにおいて重要なのは「クライアントが非常に高速であること」です。そのため、高速性、安全性、互換性、仕様外のもの、特定のエコシステムに組み込まれた独自のものなど、さまざまなものを搭載しています。
例えば、DCsparkが自社でクライアントを作った場合、Flintウォレットに接続するための特別なインフラを構築し、簡単に処理できるようにすると思いますが、リファレンス（標準規格）はそのようなことはしないでしょう。

そしてそれはノードについても同じことです。もし私たちがノードを商品として売り出すなら、おそらくLaceウォレットに接続するでしょう。なぜなら、良いユーザー体験を求めるからです。
これは、仕様がどうのこうのということではありません。つまり、カルダノ・テクニカル・フェローがCoreを維持することで、CIPプロセスを正式なCoreに迅速にリンクさせることができるようになるということです。 
この仕様は、テストのためのリファレンス（標準規格）となるコードを提供します。私たちはまだこれらの内容をまとめている最中で、正式なプレゼンテーションを後に行う予定ですが、基本的な考え方は「Agda Coreがある」ということです。それから、リファレンスを抽出したコードと、その他のものが少しあります。
リファレンス更新システム、ウォレット証明書、そして最終的にコア暗号が完成します。というのも、おそらく誰もが独自の暗号を展開するようにすべきではないからです。集約して展開していくべきです。これがカルダノのコアとなるリファレンスのフレームワークとなるのです。
あとは、ユーティリティやインフラ、インテグレーションするための何かしらの並行基軸が必要になりますが、これはまた別の話です。RosettaやDBsyncといったものがそれにあたります。でも今のところ、競合するクライアント（システムを利用するPCやソフトウェアなど）について話をするときは、この方法がいいと思います。 
そうすると、Haskellクライアントを取り上げて、「これはもう正規のものではありません」と言うことができます。HaskellクライアントはHaskellクライアントです。それからRustクライアント、Typescriptクライアントなども出てきます。

「コア」が標準規格を作り、コミュニティが高品質プロダクトを作る

そうなると「それは認定を受けているものかどうか？」という質問が出てきます。あるものは認定され、あるものは認定されないということもあり得ます。
基本的な考え方として、Agda Coreは、5人から10人程度の小さなチームで成り、「MBOのために働くCTF」と、「IOやDCsparkのような貢献する開発者」の組み合わせになります。
彼ら（Agda Core）は基本的にリファレンスシステムを維持し、抽出したコードのリファレンス（標準）セットを維持し、それに関する特性を証明し、さらにウォレット認証とシステムのコア暗号を維持することになります。そして、もし誰かがクライアント（システムを利用するPCやソフトウェア）を作ろうとしたら、

「自分のクライアントの安全性をどうやって確認するのか」
「自分のクライアントがプロトコルに準拠していることをどうやって確認するのか」
「Hard Fork Combinatorがそのクライアントに有効であることを確認するにはどうしたらいいか？」
「アップデートがトリガーされたときに、すべてのクライアントがアップデートされるようにするには、どうすればいいか？」

といった疑問が生じるでしょう。
このようにコミュニティーのメンバーが抱く疑問はたくさんありますが、認証プロセスは、競争による機敏さとともに、標準という安全性を与えてくれるものなのです。
Agda Coreの素晴らしい点は、プロダクション（製品）ではないので、開発者の時間はすべて標準規格に集中できることです。ここでは何週間でも、あるいは何ヶ月でも開発することができます。ものによっては何年もかけて開発します。なぜなら、虹の終わりには、さまざまなプラットフォームでテストし、互換性を確保しなければならないからです。

ユビキタス・スタンダード（普遍でありどこでも参照できる標準）を作り、みんながそれに従うようにしたい、ということです。IOは、Haskellクライアントを経済的に正しく運用できるようになれば、もっと多くのことを追加して、標準的なクライアントではなく、より商用に近いクライアントにすることができます。その上で厳しい競争も見て行きたいと考えています。

DCspark がフルノードの Rust クライアントの管理者であることもぜひ見てみたいと思います。少なくとも、TypescriptクライアントやDartクライアントなど、ウェブテクノロジーを代替する命令型クライアントを1つでも作ってほしいですね。Pythonのクライアントを持つことは、私たちのエコシステムに多くの教育的価値をもたらすと思うので、Pythonを使うのは本当にクールだと思います。CIPプロセスの最後のステップは、コアの内部で物事を指定することです。

「メンバーベースの組織」は、どこまで進んでいる？

私たちはすでに、非常に効率的なコード抽出を行っています。実際、James Chapmanやエコシステムの他の人たちは、この分野に非常に長けています。彼らはこのことについて多くの論文を書いており、この種のもののための良いフレームワークとして大きく成長してきました。
よって、どのような安全基準が存在すべきなのか、いろいろと話ができるようになります。 

ウォレット開発者であれば、「公式ウォレットとは何か？　推奨ウォレットとしてCaradano.orgや、かなり大規模な他のメディアにて掲載されるようにするにはどうしたら良いか？」という質問に対し、基本的に自主的に利用できるテストを実施し、それで認定されればCardano.org上で掲載されるということです。実にシンプルです。

さて、これを立ち上げるにはどれくらいの時間がかかるのでしょうか？

MBOを立ち上げ、できるだけ多くの会員を獲得し、コミュニティがすべての役員を務めるようにするために、私たちは本当に一生懸命働いています。それから、クールな投票なども行われるでしょう。そして、たくさんのガバナンスが進行中です。『Voltaire」は並行して大規模な開発が行われています。形式手法のグループを強化し、これらの開発を本格的に進めています。

IOでは今、このアイデアにとても興奮しています。私の望みは、できるだけ早くチームを立ち上げて、メンバーベースの組織が管理する新しいgitリポジトリのもとで、Agda Coreがどのようなものになるのかについて話し始めることです。

長い間、これをやりたいと思っていた人たちがたくさんいて、それに向かって努力してきたのです。DB sync、graphql、Rosettaの未来、blockchain explorer、smashなど、ユーティリティ、インフラ、インテグレーション（連携）に関する興味深い質問がまだありますし、TX pipeやScrollsなどのように、本当にクールなコミュニティのものもたくさんあります。公平に評価されてしかるべきだと思うのです。

分散化組織に必要な「信頼できる情報源（Source of Truth）」の存在

そこで、2種類のテクニカルフェローという概念があればいいと思います。「ユーティリティ、インフラやインテグレーション（連携）」を担当する者と、「コア」を担当する者がいて、さらに「プロジェクトやプログラムグループ」という考え方もあって、コミュニティの多くのことにリソースを割くことができます。
また、Catalystでそのプールに資金を提供することもできます。また、Cardanoエコシステムの企業がCTFを提供することで、現物出資することも可能です。もちろん、私たちもそうします。
しかし、標準的なインフラや標準的なユーティリティのインフラは、基本的にオープン・コア・モデルの下で運用されているので、人々はホタルのようにそれを利用し、独自の方法で商業化することができます。

これが皆さんのお役に立てばと思います。

最後にまとめると、あまり複雑でなければいいのですが、基本的な考え方として、「設計図が欲しい」ということです。

そして、その設計図からいくつかの受け入れ基準が示されます。そして、複数の意見を持つことになります。そして、それらの意見がクライアントとなります。では、誰が青写真を作るべきなのでしょうか？　それはコミュニティによって構築され、標準化されるべきものです。

基本的にはAgda Coreをセットアップして、ADAホルダーによる投票を行い、これが標準的なカルダノであるとするわけです。そしてそれが「信頼できる情報源」のとなります。たとえばHaskellクライアントが仕様外であったとしても、私たちはその標準仕様に合うようにコードを変更しなければなりません。

さて、リファレンスとプロダクトの間でプルーフバイシミュレーションのような完全な形式手法でやろうとすると、注意点があります。これは非常に重いプロセスで、何年もかかります。TLA+ CommunityのLeslie Lamportによる素敵なビデオもあります。彼はコード抽出不要のTLA+という形式言語を仕様作成用に考案し、Sylvia McCauleyと同様に分散システムの開発でチューリング賞を受賞しています。Microsoftの多くのエンジニアがプロダクションに利用しており、Xboxチームではメモリの問題を発見したり、そのほかにもAzureやインフラ全体で使ったりし、コードのクリーンアップに大いに役立っているそうです。また何千何万のエンジニアの間で「信頼できる情報源（Source of Truth）」を作るのにとても役立っています。「Practical TLA」という本もあるくらいです。
ほとんどの大企業は、このような種類のことをすべて行うために、何らかの形で「仕様言語」を持っています。もうひとつ、この仕様言語は、スマートコントラクトの標準にも拡張できる可能性があります。
今の説明が、みなさんが理解する助けになればと思います。カルダノにとってこれほどエキサイティングな時期はありませんし、私は物事が動いていることにとても満足しています。私たちは完全に異なる方法に近づきつつあり、それは長年の研究の基礎のようなものです。欧州連合からの助成金で始まり、科学者たちが何年もこの材料で遊んでいたのです。
多くの正式な方法が機能し、人々は高速でシームレスなアップグレードに慣れ、カルダノが持つ多くのマジックに慣れてしまったのです。

みなさんが慣れ親しんでいるように、しかしポリグロットな（あらゆる基軸に対応できる）エコシステムを継続するためには、何らかの形の「信頼できるの情報源」が必要です。
なぜなら、そのサービスを利用するためにお金を払う人たちがいるからです。そこでは主観性は許されず、客観性が求められます。そのためには、認証基準が必要なのです。

私が考える唯一の方法は、メンバーベースの組織、テクニカル・フェロー・プログラムでコアの仕様を保持するグループを作ることです。

そのグループがCIPを「仕様」に落とし込み、それが認証を受けるための基礎となるのです。

それから、protobufs（Protocol Buffers）を使うか、あれを使うか、これを使うか、というような特定の実装の詳細です。それはあまり重要ではありません。

本当に重要なのは、安全性、セキュリティ、パフォーマンス、そして標準的なテストスイートに関する特定のガイドラインを遵守することです。テストスイートは、ちょうどEthereum財団がEVMのために維持しているようなもので、ある人が作り出すさまざまなクライアントのための「信頼できる情報源」のようなものです。

しかし、私たちはその上を行かなければならないのです。「分散型更新システムの標準」が必要です。だから Hard Fork Combinator は抽象化され複数のコードベースに差し込むことができるように移植される必要があり、そのためには何らかの基準が必要なのです。
そうすれば、ずっとシームレスなアップグレードが可能になります。ですから、もしDC sparkに800万ドル以上の資金を提供するのであれば、インフラのユーティリティとインテグレーションに取り組んでもらうのが一番だと思います。
私たちはより良い開発ツールを必要としていますし、彼らが Flint や DBsync のバージョンで行ったようなことをスケールアップさせる必要がありますし、そのための資金を提供すべきです。
正規のクライアントについては、まずAgdaのクライアントを完成させることが先決だと思いますし、そのための大きな提案をするつもりです。11月にまずその話をし、来年のMBOを行う際に、そのチームを必要なところに持っていく方法について提案します。

私たちは、他の参加者と同様、公平にリソースを提供し、これまでに行われた多くの素晴らしい仕事の基礎となる仕様を、非常に迅速に作成できると考えています。そうなれば、コンソーシアムを結成し、そのコンソーシアムが今後5年間について話し合うことも大いに意味のあることです。
また、そのような革新的な技術には、多くの開発チームが参加しています。ですから、もしあなたが仕様や標準を作りたい人の一人なら、それを実現する絶好の機会があることを心に留めておいてください。 
もしあなたが、競合するクライアントを作りたいと考えている人の一人で、自分の会社が素晴らしいと思うなら、私たちにも声をかけてください。
なぜなら、このようなもののためにコンソーシアムをまとめるのはいいことだと思うからです。

とにかく、これが皆さんの考える一助になればと思います。この種のことについては常に慎重に推論したいものですが、投票を実施してくれたRickに感謝します。この投票は、私たちがどのように分散化を続けるかについて、とても必要な会話を始めるものだと思います。

そのためには、ガバナンス、オンチェーンガバナンス、投票の強化、ステートフルオペレーターの分散化レベルを向上させることなどが必要です。
そのためには、投票ツールをもっと簡単にすることも必要ですが、開発チーム間の分散化を進めることも重要です。問題は、分散化が進むと、それを正しく処理しないと、調整の問題が難しくなるため、簡単にアップグレードできなくなることです。

ですから、誰もが従うべき「信頼できる情報源（Source of Truth）」と「基準規格（Standard）」が必要で、さらに何らかの社会的構造として、人々に従わざるを得ないような認証プログラムが必要です。
このようなインフラがあれば、イノベーションのスピードを維持しながら、同時に、３つか４つ以上の競合するクライアントが突然、お互いを打ち負かすことができるだろうと、私はかなり楽観的に考えています。
ご清聴ありがとうございました。それでは、またお会いしましょう。