私たちは新しいチームと新しい意欲を持ってコロンビアから戻りました。RPCh は、HOPR に基づく最初の製品になります。これは、曖昧なプライバシー アップグレードを提供するだけでなく、Web3 における緊急かつタイムリーな問題を解決するプロトコルの明確な使用例です。ユーザーもウォレットも興奮し、私たちも興奮しました。

しかし、これからは実際の作業を迅速に開始する必要があります。私たちは先月にわたって 6 社のウォレットと協力関係を築いてきましたが、いずれも UI への直接統合を通じて RPCh 経由でユーザーのプライバシーを提供することに熱心でした。これは HOPR にとって大きな後押しとなりましたが、これらの取引はソリューションが数年ではなく数か月で準備できることが条件でした。

建築ダイジェスト

ハッカソンは優れた概念実証を生み出しましたが、それは製品どころか、製品の青写真にも程遠いものでした。そのバージョンの RPCh では、RPC サーバー、HOPRd ノードなど、すべてをユーザーが自分で用意する必要がありました。

それはうまくいきましたが、それでも大きな成果ではありましたが、それは製品やサービスではありませんでした。この設定では、ユーザーに料金を支払う必要があり、その逆ではありません。

そしてそれは実際、これ以上先送りすることができない多くの質問のうちの最初のものでした。RPCh にお金を払うのは誰でしょうか? これは、おそらくガソリンに加えて追加料金として、ユーザーが支払うものでしょうか? それともウォレットが支払いを行い、コストを吸収するか、何らかの形でユーザーに転嫁するのでしょうか?

当社の内部調査によると、ユーザーは喜んでお金を払うと言っていますが、これは常にプライバシーの問題です。誰もがそれが欲しいと主張しますが、いざという時にそれについて何かをしようとする人はほとんどいません。

既存の RPC ソリューションのアップグレードとして、RPCh がウォレットを対象とすることがすぐに決定されました。

しかし、これはすでに大きな影響を及ぼしています。たとえば、月あたり 1,000 万回の RPC 呼び出しなどのサービス パッケージを提供している場合、このクォータを割り当て、追跡し、サービスがなくなったときにサービスを制限する方法が必要です。このようなシステムのアーキテクチャは、RPCh がトランザクションごとに支払われるシステムとはまったく異なります。RPCh の伝達方法や販売方法に対する波及効果は言うまでもありません。

これは考慮すべき多くの角度のうちの 1 つにすぎず、それぞれの角度には設計に対する独自の影響と制約があります。

途方もない挑戦のように思えるかもしれませんが、ソフトウェア設計で最もやりがいのある部分の 1 つは、巨大な問題をますます明確で管理しやすいタスクに分割することです。図と夢から始めて、GitHub に詰め込まれたスプリントのロードマップと順序付きリストで終わることほど素晴らしいことはありません。

少なくとも私にとっては:)

ロードマップへの道

そして、RPCh のすべてのことと同様、これはチームの努力でした。まず、高レベルの検討事項がありました。サービスとしての RPCh はどのようなものになるでしょうか? 誰が支払うでしょうか？RPCh ノードを実行して報酬を受け取るのは誰でしょうか? これらは、その操作とインセンティブにおいて標準の HOPR ノードと異なりますか? どうやって？

これにより、さまざまなコンポーネントとその機能および相互関係を備えたアーキテクチャ設計が作成されました。ここで私の功績を称えることはできません。ほとんどの作業は創設者とコアチームによって完了したため、コロンビアでの休暇を終えてチューリッヒのオフィスに戻ると、高レベルのアーキテクチャ設計が私を待っていました。

プロダクトリーダーとしての私の仕事は、この計画を具体的な開発計画に落とし込むことでした。さまざまなコンポーネントはどのように構築され、どのような順序で構築されるのでしょうか? 彼らはどのようにテストされるのでしょうか？SDK などを介して、いつ、どのようにウォレットにアクセスが与えられるのでしょうか?

そして、非常に重要なことですが、各パーツの構築には誰が割り当てられるのでしょうか?

なぜなら、このすべての設計作業に並行して、取り組むのに非常にやりがいのある課題があったからです。私たちは、ハッカソンで素晴らしい成績を収めた 3 人のコロンビア人、カミロ、ディエゴ、ルイスを新しい RPCh チームのメンバーとして採用しました。私たちは彼らの仕事と熱意に非常に感銘を受けていましたが、特に仮想通貨に関してはまだ比較的若手でした。RPCh の開発スケジュールでは、オンボーディングのほとんどが現場で行われる必要があることを意味していました。また、彼らは私とはまったく異なるタイムゾーンにいたため、1 日の大部分を監督なしでタスクに取り組む必要がありました。

他の HOPR チームメンバーと同様に、新入社員は、さまざまなプロセスやチーム作業ツールの学習から、創設者 Sebastian による素晴らしいイーサリアム実践セッションまで、標準的な HOPR オンボーディング プロセスを経験しました (HOPR の全員が役割に関係なくこれを受講します)。または技術的専門知識）。

これは学ぶのに最適な方法ですが、ロードマップにも重大な影響を及ぼします。他のプロジェクトと同様、RPCh の構築にはいくつかの依存関係があります。つまり、相互に依存するため、特定の順序で構築する必要があります。次に、外部依存関係があります。HOPR プロトコルはまだ開発中であるため、ロードマップ内で作業する必要があります。また、最終的な統合のために RPCh をウォレットの協力者にいつどのように引き渡すかを計画する必要もあります。

チーム内にも依存関係があります。誰もが異なるスキルセットを持っており、特定のタスクに取り組むのは理にかなっています。私たちにとって幸運なことに、コロンビア人の新入社員はフルスタック パッケージのようなものとして到着しました。Diego は Devops とアーキテクチャの作業で最も経験があり、Camilo はフロントエンドの専門知識を持っており、Luis は RPCh が依存するさまざまな Docker イメージの構築に最も慣れていました。

しかし、優先順位付けのほとんどには、より柔軟な要件がありました。特定のものを最初に構築することは、実行可能な最小限の機能セットに早く到達できるため、理にかなっています。これはテストとリリースに適していますが、理解にも役立ちます。

私は、増分サンドボックス バージョン (RPCh) を構築することにしました。そこでは、各コンポーネントの初歩的なバージョンが導入され、チームがすべてがどのように相互作用し、作業している個々のコンポーネントがどのように結合するかを実際に確認できるようになります。その後、アルファ版、ベータ版などに進み、コンポーネントを改善したり追加したりしていきます。

ハードモードでプレイする

最も重要な考慮事項の 1 つは、チームにとって滑らかな難易度曲線を作成することでした。

彼らは新しい会社で新しいテクノロジーに取り組む仕事を始めましたが、それは気が遠くなるかもしれません。ソフトウェア開発では挫折は避けられませんが、常に進歩していると感じられる環境を作ることは私にとって非常に重要でした。これは、可能な限り簡単に達成できることから始め、最初のコミットや PR などのマイルストーンを祝い、スプリントを進めるにつれて難易度を上げていくことを意味しました。

また、私は HOPR コア チームでの経験から学び、初日から明確なプロセスを作成することを心がけました。また、頻繁に振り返りセッションを行って、何が機能していたかを祝い、問題が問題になる前に修正するようにしました。

何もジンクスにしたくありませんが、今のところうまくいっているようです。RPCh はすべての開発マイルストーンを達成しており、チームはエスカレートする課題に対処するために十分以上の努力を払っています。後退がなかったと言ったら嘘になりますが (その一部については次回説明します)、慎重な計画と内蔵のバッファーと冗長性により影響は最小限に抑えられ、合意されたスケジュールに沿って順調に進んでいます。 10月にウォレットパートナーと協力しました。

これは、RPCh のような比較的小規模なソフトウェア開発プロジェクトであっても、計画を立てる際に必要となる課題や考慮事項の表面をなぞっただけですが、めったに議論されない暗号の側面を見ることができて興味深かったのではないかと思います。

最終回では、RPCh チームがどのようにしてさらに拡大したか、そして過去数か月間で学んだ最も重要な教訓のいくつかについて見ていきます。

Steven Noni
RPCh プロダクト リード

Webサイト：https://www.hoprnet.orgツイッター：https://twitter.com/hoprnet電報：https://t.me/hoprnet不和：https://discord.gg/dEAWC4G

フォーラム：https://forum.hoprnet.orgステーキング:https://stake.hoprnet.org報奨金:https://bounties.hoprnet.org遊び場：https://playground.hoprnet.org