2022年3月度版Cardano360(開発進捗報告) 、皆さんが気になる主要な部分だけを切り取って翻訳したものです。
Hydra進捗状況
Hydraが初めてパブリックテストネットに公開されました。これまではローカル開発ネットワークを使用して、Hydraノードの実装テストを行ってきましたが、パブリックテストネットで実装できることが嬉しいです。これは、ネットワークでの動作テストをするために非常に重要です。同じパラメーター、遅延、などを備えているためメインネットと非常によく似ています。
最近、バージョン４をリリースしました。これはテストネットと通信できる最初のバージョンです。あくまでもテストネットで使用するためのもので試してみることが沢山あります。また、ヘッドを閉じることができない場合もあるため、最終バージョンではありません。そのため、次期バージョン５の計画と作業をすでに行っています。これにより現在実行されていないロールバック処理が大幅に改善されます。これは私たちが現在取り組んでいることの主要な１つです。全体として次期バージョンを使用すると堅牢に使用できるようになり、システム全体の成熟度と堅牢性が向上します。
リリース４では新しいドキュメントが公開されています。それと連動したウェブサイトもあります。是非 https://hydra.family/ にアクセスしてください。デモのやり方、セットアップの仕方、Hydraノードの使い方を説明しています。Hydraの背後にあるコアコンセプトについて詳しく説明します。デプロイメントモデルと使用例、Hydraヘッドの使用方法に関する情報が含まれています。もちろん、APIリファレンスなどの技術的な詳細もここにあります。
当然のことながら、今後さらに多くのリリースがあります。皆さんはメインネットリリースが10月より早くリリースされるのではと期待されていますし、そうなる可能性もありますが、Hydraのリリースはまだ決まっていません。メインネットでトランザクションを処理するのに十分な性能になるにつれて、いくつかのバージョンを用意する予定です。
ですから、Hydraを展開することは、スイッチを入れれば何でも速く、安くなるというようなものではありません。むしろ、Cardanoの人々が実際に使えるような基盤、技術の一部を構築することです。そして、高速で安価なアプリケーションを作るために利用することです。 カルダノの開発者がHydraを使えるようにすると、少しは早く、そして安く使えるようになるのがわかるでしょう。このように、私たちは基本的に今後数ヶ月の間にHydraを展開する予定です。[txtul text=’そして、Hydraをリリースするためにハードフォークする必要がないことを、できるだけ早くお伝えしたいと思います。つまり、Hydraは次のハードフォークに含まれないということでもあります。’ color1=’#ff7e8b’ color2=’#fdcad8′ bold=’0′ italic=’0′ serif=’0′ thickness=’normal’ hoverfx=’1′]
改良の恩恵はとても大きいです。6月のハードフォークで得られるものや 10月のハードフォークで得られる 潜在的な改善点などの恩恵を受けることでより高性能になりますが、厳密にはそれに縛られているわけではありません。ですから、これらのハードフォークの前、間、後にHydraノードのリリースを見ることができるでしょう。
コア開発について(ハードフォーク)
ご存知かもしれませんが、私たちは1年に3つの重要なリリースに集中することを選択しました。それは、2月、6月、10月です。 これにより、製品チームはコアの改善に集中できるようになり、重要な変更やハードフォークに備えるために必要な十分なリードタイムをコミュニティに与えることができます。私たちのコミュニティが成長すればするほど、これはますます重要になります。なぜなら、私たちがミッドリード側で構築している改良を利用し、開発サイクルの代わりにそれを統合できるようにしたいと思う企業が現れるからです。私たちは、年間を通じて、より小さな改良をリリースしていきます。開発者は、この3つのマイルストーンを、私たちが今年Cardanoを拡張する方法について説明したことのベンチマークとして見ておく必要があります。
2月はハードフォークを必要としませんでした。通常、ハードフォークが必要になるのは、大量の変更があったときです。しかし、これらのアップデートは、6月に来るVasilのハードフォークに向けて、私たちを前進させるものでした。そして、要約すると、私たちが2月に行ったことは次のとおりです。私たちは、CLIから直接CDDL互換のトランザクションを提供しました。そしてインクリメンタル・マルチシグネチャに必要なインフラの変更を行い、 リーダーシップ・スケジュール、Mempoolトランザクション・モニタリング、Plutusスクリプト・コスト見積りを導入しました。
今日お話しするのは、重要な価値を構成する要素についてです。Plutusバージョン2、スクリプト、Collateralの取り扱いと暗号プリミティブの強化です。
6月のVasilハードフォークについて
6月のVasilでは、プルータスに導入される多くの改良点のうちのほんの一部に過ぎません。4つの主要な分野に焦点を当てようと思っています。
まず、リファレンススクリプトです。これはオンチェーンにあらかじめ記録されたスクリプトで、他のトランザクションから参照することができます。つまり、スクリプトを使用するトランザクションのサイズを小さくすることができるのです。また、既存のコードの再利用も可能になります。DAPPの開発者にとっては、大きな改善となります。
2つ目は、リファレンス入力を使った参照入力の展開です。何ができるかというと、スクリプトの中からInputを消費することなく参照できるようになります。その効果は、多くのスクリプトが同時に同じ入力を参照できるようになることです。同じ入力を使って同時にいろいろなことができるようになり、スループットが大幅に向上します。
3つ目はインラインデータムがもたらす開発者が単純な入力を参照しやすくすることで、入力にハッシュを使わなくて済むようにすることです。
たとえば、それらを直接参照するだけで、ユーザーと開発者がInputを簡単に確認できるようになります。 3つの大きな改善があり、これらはコミュニティに提案したさまざまなタイプによってカバーされており、CIP33参照スクリプトに関するさまざまな専門家によってコメントが寄せられています。 1つのリファレンスは、インラインデイトンに設定されたCIPを入力します。 そして最後に、トランザクション情報のすべてのリディーマーを展開します。これから始まるのは、共有リディーマーを使用してスクリプトを連携させることです。
次に、暗号プリミティブですが私たちはCardanoで本当にクールな暗号をたくさん使っています。実際、最新鋭の楕円曲線プリミティブについてお話ししましょう。私たちはed25519というプリミティブを使っていますが、これは電子署名の観点からは最先端です。
VRFは検証可能なランダム関数という意味ですね。通常何かに署名するときは メッセージを渡し 秘密鍵を署名します そしてアルゴリズムを経て、署名が得られる。この署名は人によって検証することができ、ほとんどの人がよく理解していると思います。
VRFは基本的にシードと秘密鍵を受け取って証明と出力を生成するもので、その仕組みを理解することができます。私たちはこれをリーダーシップ・スケジュールに使用しています。このVRFは、次に誰がブロックをミントするかを決定する上で、非常に重要な役割を担っているんです。この種の暗号プリミティブでは 計算がかなり重くなる傾向があります。コンピュータにとって基本的な計算をするために高価なものなのです。私たちはこれを2回使っていたのですが、今はそれを減らしています。ブロック伝搬の過程で、VRFの計算を行う必要がなくなり、1回で済むようになりました。
つまり、こうすることで冗長性を排除しているのです。また、ブロックの検証や伝播の際に行う作業も少なくなっています。これはすべて良いニュースです。ただ、このような技術的なものを取り除くときはいつでもそれをどのように切り取るか、本当に必要ないものかどうか、非常に注意しなければなりません。しかし、私たちは、より速く・より良く同時に以前と同じように安全で、同じように決定論的な方法で、これを実現しました。
ネットワークに関する進捗(パイプライン)
この夏にはパイプラインを展開する際に、大きな変更を加える予定です。当社の優れた研究者の一人であるMathias Fitzyによるブログが公開されましたが、そのブログはかなり技術的で、それを読んだ人は、当社が何を提供しているのかがよくわからないかもしれませんので、少し紹介したいと思います。
この件に関する誤解を解いておきたいと思います。私たちがこのようなものを展開するときはいつも、研究から始まります。彼らは一日中このようなことを考え、さまざまなモデルを考え出します。その時点では、コードがあるわけではなく、思考とプロセスがあるだけです。そして形になってくると、パイプラインであれ、その他の機能強化であれ、より具体的に、よりリアルになってきます。そして、私たちが変更できるものでありシステムに大きな影響を与えるものだと考えるのです。このプロセスは、私のような構築セクションの人間に引き継がれ、私は研究のインプットを受け取ります。
それを具体的な仕様に落とし込むのが私の仕事です。そして、それを実際に作業をするエンジニアのところに持っていき、エンジニアが私の作ったものを使ってコードを書くというのが、私たちのやり方です。Matthiasのブログを読んでいる人たちは、彼が非常に学術的な立場から話していることを理解していると思います。
パイプライン化と呼んでいるのは、次のブロック生成ノードへブロック転送を高速化することなんです。ブロックの転送速度が上がれば上がるほど、ネットワーク・パラメータを増やしたり、より速く、より大きく、より良いものを作るための余裕が生まれるからです。しかし、これについて考えるとき、彼はダウンストリームの影響について考えていません。
彼は、パイプラインのさまざまなバリエーションに非常に注目しています。フュージョン・パイプライン、同期バリデーション、遅延バリデーションといった言葉を聞いたことがあるかもしれませんね。これらはすべて同じアイデアの異なるフレーバーで、ブロックを検証するプロセスをまとめる一方で、できるだけ速くデータを通信・送信するというものです。
私たちの研究者が思いついた素晴らしいアイデアのどれを選択するかは、実用的な正面から選択する必要があります。 非同期検証の方が少しは速いかもしれませんが、より危険で、より時間がかかるからです。そこで、私たちは拡散パイプラインと呼んでいるものを選びました。パイプラインはスイートスポットであり、今年中に起こるであろう驚くべき変化に対して十分な余地を提供するものだと考えています。しかし、私たちはすでにパフォーマンス・ロードマップの目標を達成しており、ブロック使用率はまだ100％ではありません。
6月には大きな変更があり、ネットワークパラメータやブロックサイズ、スピードが大幅に向上します。さらに、6月に導入するものがスイートスポットであり、十分であると信じているからです。
次にインプットエンドーザーですが、これはコンセンサスとブロック伝播を行うための根本的に異なる方法です。 そして、それについてはまた別の機会に詳しく話すことができます。 事実上、ランキングブロックと入力ブロックがあり、すべて非常に洗練されていますが、パイプラインと6月に提供する方法により、インプットエンドーザーが来るまで余裕ができます。これは、今後5年間のスケールアウトを見据えた、事実上のエンドゲーム・ソリューションです。
10月のChangハードフォークについて
私たちのチームは10月にChangハードフォークを計画し始めており、完全な範囲はまだ開発中ですが、我々は今後数週間、数ヶ月にわたって変更されます。私たちは10月にパイプラインに入る予定の特定の事柄を確実に知っており、私たちのコミュニティはこれらと近い将来これらについてもっと見ることを楽しみにしています。そしてガバナンスの領域でも変化が起きています。スマートコントラクトも進化し、パフォーマンスの変更や改善もあります。また、ウォレットやサイドチェーンなど、ワクワクするようなものをたくさん用意しています。
