Yumeville

Holochain デベロッパーパルス　No.70

インフラストラクチャの課題、HoloFuelの高速化、H-Wikiアプリの公開

概要

先週、我々はHoloPort自動更新サービスをオフラインにしてしまうインフラストラクチャの課題に直面しました。私たちはサービスをより堅牢な方法で復活させることに成功し、重要なサービスが堅牢であり続けることを確認するために我々が行う知識共有のベストプラクティスを再調査さしました。

また、HoloホストWeb SDKが一般的に使用できる日が近づいてきました。フロントエンドの開発者が一つのAPIでネイティブのHolochainユーザーとHoloでホストされているユーザーをターゲットにできるようにすることで、hApp開発を容易にすることを可能にします。

更に、以前のデベロッパーパルスで、EYSS社のH-Wikiというプロジェクトのエキサイティングなプレビューを共有しました。遂に、このアプリを試せる準備ができました。下記でインストール手順を説明します。

そして最後に、次のHoloPortの更新が明白に近づいています。開発チームは、パフォーマンスの向上につながるいくつかの小さな修正を行っています。

トピック

  1. Hydraに直面し克服—弾力性を維持するための教訓
  2. 管理者ダッシュボードとテストHoloFuelを含むHoloPort更新がリリースに近づいています
  3. H-Wiki hAppをダウンロードして試してみよう
  4. 新しいHolochainアプリ開発者のブログ！

Hydraに直面し克服—弾力性を維持するための教訓

以前に報告したように、私たちの屋根の下のさまざまなプロジェクトはNixとNixOSを多用しています。これはパッケージマネージャーでもLinuxディストリビューションでもあります。つまり、同じツールを使用して次のことができます。

我々は、Nixプロジェクトのツールの一つであるHydraを使用して、HoloPort更新をデプロイしています。 Hydraは、Nixパッケージマネージャー上に構築された継続的インテグレーションサーバーです。つまり、Hydraは、一貫した信頼できる環境の提供というNixの約束を継承しています。我々はHydraを使用してHoloPortのすべての変更をテストし、HoloPortのアップデートをリリースするためにも使用しています。 HoloPortは頻繁に自動更新サービスを起動し、Hydraサーバーにpingを送信して、何か新しいものがないかどうかを確認します。ある場合は、それをダウンロードし、再起動せずにシステムにパッチを適用します。すべてが正常に機能している場合、それはまるで魔法のようなものです。

ここ最近、このHydraサーバーにハードウェア障害が発生しました。これは、内部更新や公へのアップデートをリリースできなくしてしまい、HoloPortが自動更新できなくなっていました。新しいサーバーをプロビジョニングした後、古いサーバーの設定を再現し、新しいサーバーをオンラインにする際に問題が発生していました。

これは問題ではありますが、Holochainプロジェクトをサポートし、Holoホストネットワークを提供するために、Holo社が作業していることの回復力のギャップを発見する絶好の機会でした。私たちはすでに、このミッションクリティカルなマシンの「バス因子」のリスクを認識していました。Holo組織のリセット後、NixOS開発者の何人かが他のプロジェクトに移動しました。 Nixのエキスパートである私たちの最新のチームメンバーは、Hydraサーバーのセットアップがどのように機能するかを完全に把握していないことを承知していました。なのでこのハードウェア障害により、彼らとHolo Hostチームの残りのメンバーは、サーバーの再構築のために必要な知識をすばやく構築し、記録し、共有する必要がありました。

Nixの優れた点は、コンフィグレーションファイルの集まりからオペレーティングシステム全体を再作成できることです。したがって、セットアッププロセスを理解してデバッグしたら、Hydraサーバーを新しいマシンに簡単にリリースできました。

管理者ダッシュボードとテストHoloFuelを含むHoloPort更新がリリースに近づいています

私たちの開発チームは、HoloFuelのテストバージョンをHoloPortsにリリースするために、バグを削除することに励んでいます。子のバグの解消により、いくつかのパフォーマンスの向上が確認できています。実際、400ノードでテストが成功したことを共有する予定でしたが、執筆中に、最大500ノードになったというニュースを受け取りました。これらは、Holochainの2つの修正によるものです。

  • zome呼び出しの非同期化 – 長時間を用するzome関数呼び出し（バリデーション関数を含む）が他の呼び出しをブロックしていたため、コンダクターが応答しなくなることがありました。この修正により、コンダクターは一度に複数のコールを処理できるようになりました。
  • 自分が権限を所有しているかどうかを最初に確認 – これにより、ノードがリンクベースの著者であることがわかっている場合は、ノードが独自のDHTシャードでリンクを確認します。もしそうであれば、彼らはネットワークにクエリーを送信しないようにしました。これはHoloFuelのパフォーマンス向上へのとって大きな後押しでした。ノードは定期的に自分のエージェントIDを取得して、着信中のトランザクションへのリンクを探すようにしました。

 

H-Wiki hAppをダウンロードして試してみよう

前回のデベロッパーパルスで紹介された、我々のよき友であるソフトウェア開発社EYSSからのH-Wikiアプリがデモできるようになりました。彼らのチームは多くの努力を費やし、この初期の段階でさえ、すでに非常に魅力的で使いやすいものとなっています。このアプリのデモを確認することが重要である理由とまたそのスケジュールはこちらで読むことができます。これはまだ初期のリリースなので、コマンドラインに慣れ、Holochain開発環境がインストール(Mac/Linux及びWindows)されていないといけません。

始め方
  • eyss/h-wiki-backというGitHubリポジトリに移動してコードをダウンロードし、readmeの指示に従ってsim2hサーバー、コンダクター、およびDNAインスタンスを実行します。
  • eyss/h-wiki-frontというGitHubリポジトリに移動して、同じようにします。
コードベースのちょっとしたツアー

H-Wikiはかなり高度なホロチェーンアプリなので、内部で何が行われているのかを見てみましょう。独自のhAppを開発している場合、真似できるいくつかのベストプラクティスがあります。

「Mixin」パッケージについて – Wikiアプリのゾームは、これまで「Mixin」と呼んできたパターンを使用しています。これは、独自のゾームで使用できる有用なパターンを実装するサードパーティのライブラリです。ご覧のように、Rust HDKでは、これらのMixinがRust独自のCargoパッケージマネージャーを使用してzomeに組み込まれています。

[dependencies] holochain_anchors = { git = “https://github.com/holochain/holochain_anchors” }
holochain_roles = { git = “https://github.com/eyss/holochain_roles” }

コードを見ると、wikiがこれら2つのライブラリのエントリタイプを独自のタイプ定義にどのように組み合わせているかがわかります。これはとても簡単です。「Mixin」は、wikiゾームが呼び出すエントリ定義関数を公開しているのでそれを使うだけです。

#[entry_def] fn role_entry_def() -> ValidatingEntryType {
holochain_roles::role_assignment_entry_def()
}

#[entry_def] fn anchor_def() -> ValidatingEntryType {
holochain_anchors::anchor_definition()
}

後で、エントリがアンカーMixinからアンカーに繋ぐ必要がある場合、ミックスインのエントリタイプをベースとするリンクタイプ定義をMixinは提供します。

pub fn page_def() -> ValidatingEntryType {
entry!(
name: “wikiPage”,
description: “this is an entry representing some profile info for an agent”,
// …
links: [
from!(
holochain_anchors::ANCHOR_TYPE,
link_type: “anchor->page”,
// …
)
] )
}

アンカーパターン – ミックスインの一つであるholochain_anchorsを見てみましょう。これはアンカーパターンの標準的な実装であり、DHTに格納されているデータを簡単に見つけ出すことができます。特定のタイプのすべてのエントリをアンカーにリンクすると、テーブルやビューなど、従来のデータベースで使用していた機能の一部が再現されます。一つ例を見てみましょう。各Wikiページには、コンテンツの更新されたバージョン全てで一貫した一意のIDとして機能する独自のアンカーがあります（エントリの更新ごとに新しいIDが付与されるため、より安定した「アンカー」を作成することは良いパターンです）。

let anchor_address = holochain_anchors::anchor(“wiki_pages”.to_string(),title.clone())?;

裏で、アンカーMixinは自動的に新しいページアンカーをベースの「wiki_pages」アンカーにリンクするため、すべてのページアンカーのリストを取得できます。次に、ページの現在のバージョンがアンカーにリンクされます。

hdk::link_entries(&anchor_address, &address, “anchor->page”, “”)?;

Progenitorパターンと権限管理を含むCRUD検証 – 誰がwikiページを作成できるかを見極めるために、このDNAはProgenitorパターンを使用しています。このパターンにより、DHTに「管理ユーザー」的な存在が作成され、そのユーザーは自分の権限を他のユーザーに委任できます。ページの作成、更新、または削除が検証されると、DNAは、作成者がaction_𝚊𝚐𝚎𝚗𝚝_𝚌𝚊𝚗_𝚎𝚍𝚒𝚝ヘルパー関数を呼び出してそのCRUDオペレーションを実行できることを確認します。

validation: | _validation_data: hdk::EntryValidationData<Page>| {
match _validation_data {
hdk::EntryValidationData::Create { validation_data, .. } =>
validate_agent_can_edit(validation_data),
hdk::EntryValidationData::Modify { validation_data, new_entry,
old_entry, .. } => {
validate_agent_can_edit(validation_data)?;
if old_entry.title==new_entry.title {
Ok(())
} else {
Err(“no se puede actualizar un titulo”.to_string())
}
},
hdk::EntryValidationData::Delete { validation_data, ..} =>
validate_agent_can_edit(validation_data)
}
},

この関数は、EYSSのholochain_rolesミックスインを使用して、エントリの著者が編集者であるか管理者であるかを判断します。

pub fn validate_agent_can_edit(validation_data: hdk::ValidationData) ->
Result<(), String> {
let editor = holochain_roles::validation::validate_required_role(
&validation_data,
&String::from(crate::EDITOR_ROLE_NAME),
);
let admin = holochain_roles::validation::validate_required_role(
&validation_data,
&String::from(holochain_roles::ADMIN_ROLE_NAME),
);

match (editor, admin) {
(Err(_), Err(_)) => Err(String::from(“Only admins and editors edit content”)),
_ => Ok(()),
}
}

holochain_rolesのMixinはどのように機能するのでしょうか？誰もがDHTで平等の権利を持っているのではないですか？このような質問が浮かぶかと思います。ホロチェーン低レベル部分ではもちろんDHT上のユーザーの権利は均等ですが、アプリケーションレベルでは、一部のユーザーに特別な権限を与える検証ルールを記述できます。例え箱のようなやり方があります。

DNA JSONファイルには、「プロパティ」を含めることができます。これは、任意のキー/値のペアをzomeコードで使用して、必要なことを行うことができます。 Progenitorパターンを使用して、特定の特権を持ったエージェントの公開鍵で「progenitor」プロパティを追加します。その後、エージェントがDHTへのエントリの発行を許可されているかどうかを知る必要があるときは、zomeコードがこのプロパティをチェックします。holochain_rolesのMixinではこのようにprogenitorの鍵を見つけています。

let progenitor_json = hdk::property(“progenitor”)?;
let progenitor: Result<Address, _> = serde_json::from_str(&progenitor_json.to_string());

最初に、Progenitorには一つの組み込まれた管理者権限があります。管理者の役割を取り去ることはできません。これにより、他のユーザーの権限割り当てエントリーを作成することができます。エントリの検証機能は、作成者が管理者の役割を持っているかどうかを確認します。そうでない場合、検証は失敗し、DHTは役割の割り当てを拒否します。このようにして、最初の管理者であるprogenitorと管理者権限を与えられたエージェントのみが、他のエージェントに役割を作成して割り当てることができます。

この仕組みの秘密は𝚟𝚊𝚕𝚒𝚍𝚊𝚝𝚎_𝚛𝚎𝚚𝚞i𝚛𝚎𝚍_𝚛𝚘𝚕𝚎関数にあります。この関数は、エントリがコミットされたときに、エントリの作成者が必要な権限を持っていたかどうかをチェックします。 （注：現在の検証のタイミングではなく、コミット時にチェックしてます。検証関数は、エントリがコミットされてから数年後でもいつでも実行できるものです。誰がいつ検証するかにかかわらず、エントリは常に有効か無効である必要があります。）

新しいHolochainアプリ開発者のブログ！

3人のhApp開発者が協力して、Holochain Open-Devブログを作成しました。 Guillem Córdoba氏、Hedayat Abedijoo氏、およびTatsuya Sato氏は、ホロチェーンアプリを開発し、他のホロチェーンアプリ開発者を教育した経験を振り返りながら、彼らの知恵を共有しています。彼らの記事は、Holochainを理解し、その知識を適切に設計されたアプリケーションに適用する方法を示すことに焦点を当てています。彼ら3人は確かな開発者と教育者であり、規律を持ち、知識が豊富で、知り合えば必ず助けてくれる方々であるため、私はこのブログに非常に興奮しています。

執筆者も皆さんの参加を呼びかけています。このブログは、コミュニティのベストプラクティスに関する情報を記録して共有する共同作業を目的としています。あなたが学んだことをここに貢献することは、このブログをより包括的にするのに役立ちます！

開発ステータス

最新版

Holochain Coreリリース： 0.0.47-alpha1 ｜ 変更ログ　

Holonixリリース：v0.0.73

Try-o-rama(エンドツーエンドテストツール)リリース：v0.3.4
Holoscapeリリース：v0.0.9-alpha (Holochain Core 0.0.47-alpha1を使用中)｜ダウンロード

https://holochain.loveにて使用可能なバージョン

  • Holonix: 0.0.73
  • Holochain Core: 0.0.47-alpha1

出典：Infrastructure Challenges, More HoloFuel Speedups, H-Wiki Goes Public