ブロックチェーン熱の廃墟やリソース配布の実際的な利点に関する応用技術

近年、ニュースフィードは、文字通りどこからともなく現れ、都市をスマート化し、著作権から世界を救うなど、さまざまな問題を解決する（あるいは解決しようとしている）新しいタイプの分散コンピューティングネットワークに関するメッセージで溢れています。侵害者、またはその逆、密かに情報やリソースを転送し、ある地域または別の地域の国家管理下から逃れます。 分野に関係なく、それらはすべて、最近の仮想通貨と関連技術のブームの中で公開されたアルゴリズムと技術が成長の原動力となっているという事実により、多くの共通の特徴を持っています。 おそらく、当時の専門リソースに関する記事の XNUMX つおきには、タイトルに「ブロックチェーン」という単語が含まれていました。新しいソフトウェア ソリューションと経済モデルについての議論が、しばらくの間支配的な傾向となり、その背景として、分散コンピューティング システムの他の応用分野が注目されました。背景に追いやられました。

同時に、先見の明のある人や専門家は、この現象の主要な本質を認識しました。それは、多数の異質かつ異種の参加者によるネットワークの構築に関連する大規模分散コンピューティングが、新たな開発レベルに達しているということです。 誇大広告の話題を頭から捨てて、その話題を反対側から見るだけで十分です。これらすべてのネットワークは、何千人もの孤立した異質な参加者で構成される巨大なプールから組み立てられており、単独で出現したわけではありません。 暗号化運動の愛好家は、データの同期とリソースとタスクの分散という複雑な問題を新しい方法で解決することができ、これにより、同様の大量の機器を組み合わせて、XNUMX つの狭い焦点を当てた問題を解決するように設計された新しいエコシステムを作成することが可能になりました。

もちろん、これは無料の分散コンピューティングの開発に携わるチームやコミュニティには受け入れられず、新しいプロジェクトが誕生するまでに時間はかかりませんでした。
しかし、ネットワークの構築や機器の操作分野の開発に関する入手可能な情報の量が大幅に増加しているにもかかわらず、有望なシステムの作成者は深刻な問題を解決する必要があります。

XNUMX つ目は、どんなに奇妙に聞こえるかもしれませんが、方向性の選択の問題です。

方向性は正しいかもしれないし、行き詰まりにつながるかもしれません。ここからは逃れられません。IT コミュニティへの千里眼の集中供給はまだ遅れています。 ただし、チームが広範な領域を取りすぎて、最初から別の非専門的な汎用分散コンピューティング プロジェクトを作成しようとするという従来の罠に陥らないように、選択を行う必要があります。 作業の範囲はそれほど恐ろしいものではないようです。ほとんどの場合、既存の開発を適用するだけで済みます。つまり、ノードをネットワークに結合し、トポロジーを決定するためのアルゴリズムを適応させ、データを交換し、それらの整合性を監視し、ノードをランク​​付けして検索する方法を導入します。もちろん、独自のクエリ言語、言語およびコンピューティング環境全体を作成するだけです。 普遍的なメカニズムというアイデアは非常に魅力的で、常にある分野や別の分野で現れますが、最終的な結果は依然として XNUMX つのうちの XNUMX つです。作成されたソリューションは、大量の保留された「ToDo」を備えた限定されたプロトタイプであることが判明するか、 」とバックログに残っているか、悪臭を放つ「チューリング沼」に触れた人を引きずり出す準備ができている使用できない怪物になるか、プロジェクトを理解できない方向に引っ張っていた白鳥、ザリガニ、パイクが安全に死ぬという事実から単に安全に死ぬか、単に無理をしすぎただけです。

愚かな間違いを繰り返さず、タスクの範囲が明確で分散コンピューティング モデルに適した方向性を選択しましょう。 すべてを一度にやろうとする人の気持ちは理解できますが、もちろん選択肢はたくさんあります。 研究開発と開発の観点から見ても、経済学の観点から見ても、多くのことが非常に興味深いように見えます。 分散ネットワークを使用すると、次のことが可能になります。

• ニューラルネットワークを訓練する
• プロセス信号ストリーム
• タンパク質の構造を計算する
• XNUMXD シーンをレンダリングする
• 流体力学のシミュレーション
• 証券取引所向けのテスト取引戦略

適切に並列化された興味深いもののリストをコンパイルすることに夢中にならないように、さらなるトピックとして分散レンダリングを選択します。

もちろん、分散レンダリング自体は新しいものではありません。 既存のレンダリング ツールキットは、長い間、さまざまなマシン間での負荷分散をサポートしてきましたが、これがなければ、XNUMX 世紀に生きることは非常に悲しいことになるでしょう。 ただし、このトピックは広範囲にわたって取り上げられており、何もすることがないと考える必要はありません。別の差し迫った問題、つまりレンダー ネットワークを作成するツールの作成について検討します。

私たちのレンダリング ネットワークは、レンダリング タスクを実行する必要があるノードと、レンダリングを処理するための空きコンピューティング リソースを持つノードの組み合わせです。 リソース オーナーはステーションをレンダー ネットワークに接続し、ネットワークでサポートされているレンダー エンジンの XNUMX つを使用してレンダー ジョブを受信して​​実行します。 この場合、タスク プロバイダーはネットワークをクラウドであるかのように操作し、独立してリソースを配布し、実行の正確さを監視し、リスクやその他の問題を管理します。

したがって、一連の一般的なレンダリング エンジンとの統合をサポートし、異種ノードのネットワークを編成し、タスク フローを管理するためのツールを提供するコンポーネントを含むフレームワークの作成を検討します。

このようなネットワークの存在に関する経済モデルは基本的に重要ではないため、最初のスキームとして、暗号通貨ネットワークの計算で使用されるスキームと同様のスキームを採用します。リソースの消費者は、レンダリング作業を実行するサプライヤーにトークンを送信します。 フレームワークがどのようなプロパティを持つ必要があるかを理解することは、はるかに興味深いものです。これについては、ネットワーク参加者間の対話の主なシナリオを検討します。

ネットワーク内の対話には、リソース プロバイダー、タスク プロバイダー、ネットワーク オペレーター (本文ではコントロール センター、ネットワークなどとも呼ばれます) の XNUMX つの側面があります。

ネットワーク オペレータは、リソース プロバイダーにクライアント アプリケーション、または展開されたソフトウェア セットを含むオペレーティング システム イメージを提供します。これらのイメージは、リソースを提供したいマシンにインストールされます。また、Web インターフェイスからアクセスできる個人アカウントにより、次のことが可能になります。リソースへのアクセス パラメータを設定し、サーバー ランドスケープをリモートで管理します。ハードウェア パラメータの制御、リモート構成の実行、再起動を行います。

新しいノードが接続されると、ネットワーク管理システムは機器と指定されたアクセス パラメータを分析し、ランク付けして特定の評価を割り当て、リソース レジスタに配置します。 将来的には、リスクを管理するために、ノードのアクティビティパラメータが分析され、ネットワークの安定性を確保するためにノードの評価が調整される予定です。 過熱によりフリーズすることが多い強力なカードでシーンをレンダリングするために送信された場合、誰も喜ばないでしょうか?

シーンをレンダリングする必要があるユーザーは、Web インターフェイス経由でシーンをネットワーク リポジトリにアップロードするか、プラグインを使用してモデリング パッケージまたはインストールされているレンダラーをネットワークに接続する XNUMX つの方法を使用できます。 この場合、ユーザーとネットワークの間でスマート コントラクトが開始され、その完了の標準条件はネットワークによるシーン計算の結果の生成です。 ユーザーは、個人アカウントの Web インターフェイスを通じて、タスクの完了プロセスを監視し、そのパラメータを管理できます。

タスクはサーバーに送信され、そこでシーンのボリュームとタスク開始者が要求したリソースの数が分析され、その後、合計ボリュームが、ネットワークによって割り当てられるリソースの数とタイプの計算に適合する部分に分解されます。 。 一般的な考え方は、視覚化は多くの小さなタスクに分割できるということです。 エンジンは、これらのタスクを複数のリソース プロバイダーに分散することでこれを利用します。 最も簡単な方法は、セグメントと呼ばれるシーンの小さな部分をレンダリングすることです。 各セグメントの準備が完了すると、ローカル タスクは完了したとみなされ、リソースは次の未処理のタスクに進みます。

したがって、計算が単一のマシン上で実行されるか、多数の個別のコンピューティング ステーションのグリッド上で実行されるかは、レンダラーにとってそれ自体には違いはありません。 分散レンダリングは、タスクに使用されるリソースのプールにコアを追加するだけです。 ネットワークを通じて、セグメントのレンダリングに必要なすべてのデータを受信し、計算して、そのセグメントを送り返し、次のタスクに進みます。 一般的なネットワーク プールに入る前に、各セグメントは、実行ノードが最適なコンピューティング タスクを選択できるようにする一連のメタ情報を受け取ります。

計算のセグメント化と分散の問題は、実行時間の最適化の観点だけでなく、ネットワークの経済効率が依存するため、リソースの最適利用とエネルギー節約の観点からも解決する必要があります。 。 解決策がうまくいかない場合は、ノイズを出さずに電気を無駄にしないように、ノードにマイナーをインストールするかオフにすることをお勧めします。

ただし、プロセスに戻りましょう。 タスクを受信すると、プールとノードの間にスマート コントラクトも形成され、タスクの結果が正しく計算されたときに実行されます。 契約の履行結果に基づいて、ノードは何らかの形で報酬を受け取ることができます。

コントロール センターは、タスクの実行プロセスを制御し、計算結果を収集し、再処理およびキューのランク付けのために間違った結果を送信し、タスクを完了するための標準期限を監視します (最後のセグメントがタスクによって占有されないようにします)。任意のノード)。

計算結果は合成段階を経て、ユーザーはレンダリング結果を受け取り、ネットワークは報酬を受け取ることができます。

したがって、分散レンダリング システムを構築するために設計されたランドスケープ フレームワークの機能構成が次のようになります。

1. Web アクセスのある個人ユーザー アカウント
2. ノードにインストールするためのソフトウェア キット
3. 制御システム別:
   • アクセス制御サブシステム
   • レンダリングタスク分解サブシステム
   • タスク分散サブシステム
   • 合成サブシステム
   • サーバーランドスケープおよびネットワークトポロジ管理サブシステム
   • ロギングおよび監査サブシステム
   • ラーニングエキスパートサブシステム
   • 外部開発者向けの REST API またはその他のインターフェイス

どう思いますか？ このトピックはどのような疑問を提起し、どのような答えに興味がありますか?

出所： habr.com