👦🏻 💼 😏 安全なレジストリを維持するためのブロックチェーンの代替 🤸🏻 🤦🏽 🎬

ブロックチェーン技術は美しく、有望です。いくつかの迷惑なニュアンスがあれば、その中のすべてが絶対に素晴らしいでしょう。

とても長い時間。 たとえば、トランザクションをビットコインチェーンに追加するのにかかる時間は、1分から30分と推定されます。イーサリアムはより高速に追加されますが、いずれの場合も、時間をほんの一瞬にすることは不可能です。 OLTPトランザクションのブロックチェーン部分にデータを追加することについて考えることは何もありません。
マイニングは非常にリソースを消費します。実際には、計算の複雑さをアーキテクチャに追加するために必要です。
とても高い。 リソース集約的な結果。
テクノロジーはうんざりするほどスケールアップとスケールダウンの両方を行います。毎日何十億ものレコードを記録するシステムを構築する必要がある場合、ブロックチェーンは役に立ちません。また、いくつかの小さなナンセンスの信頼できるロギングに適応しようとすると、ブロックチェーンはスズメの大砲から射撃します。

私は、レジストリを破壊できない信頼性の高い方法で同時に実行できるようにし、何らかの形でよりシンプルで安価な技術を手に入れたいと思っています。

モデル状況（実際のイベントに基づくフィクション）

ある大規模な生産および流通会社には大規模な販売部門があり、通常、マネージャーへのボーナスは販売量に依存していました。

最も甘い販売量は、最も人気があり、その結果、希少な商品で作られています。営業マネージャーはcな男です。彼らはすぐに、優れたボーナスを得るための最も確実な方法は、供給を絶えず監視することであり、倉庫に不足が生じたらすぐに自分ですぐにそれを確保することだと気づきました。架空の「顧客注文」を作成し、それを赤字で埋めて、これは今のところ、もっと（一般的には、通常の状況）をとる必要があると考えているクライアントであることを全員に伝えます。次に、実際の赤字リクエストが表示されたら、必要な金額を架空のアカウントからすばやく削除し、同じ秒で実際のアカウントに追加します。

その結果、事業は損失を被ります。何週間もの間、商品は倉庫に横たわっており、それは最初の日に残されていたはずです。営業部門は、新しい顧客を探して顧客との関係を構築する代わりに、終日配送を監視します。争い、面倒、相互の非難、resみ。これを使って何かをしなければなりませんでしたが、メインのビジネスプロセスを損なわないようにするためです。バックアップ操作のロギングを開始することにしました。赤字が「バイヤーの注文」によって予約されているが、この予約が同じドキュメントでの販売にならない状況を追跡するため。それを最も乱用する人は、薬にかかっています。

最初は助けましたが、その後奇妙な効果が観察され始めました：倉庫の赤字の指標は以前のものに戻りましたが、すべてはログによるチョコレートでした。営業部隊の魅力は実装では考慮されていなかったことが判明しました。高いボーナスを得るために、彼らはログから汚れを取り除くためにシステム管理者と話す習慣になりました。賄of、脅迫、いちゃつく、女性の涙-資金の武器庫全体が使用されました。管理サービスの担当者には、このような攻撃に対抗する手段がありませんでした。

ログを遡及的に歪めることを技術的手段で不可能にするという疑問が生じました。彼らはブロックチェーンの方向に目を向けましたが、人気のあるブロックチェーンプラットフォームで商品の予約をスキップするのは費用がかかりすぎることを発見しました。何をすべきかは明確ではありません。

原則として、これは公開を終了し、ハッシュ関数の無意味な選択でプロセッサの容量を無意識に燃やすことなく、すべての人がすべての人に完全に不信の条件でトランザクショントランザクションの超信頼性の高い記録を作成する方法についてのコメントで空想するように尊敬される人々を招待することができます。しかし、質問に対する唯一の答えが平凡な「これは不可能」またはサイドチェーンに関するものではないために、私は自分のバージョンを提供しようとします。

「ビットコインをどのように再編成するか」ということではないので、すぐに予約します。ビットコインをそのままにして、機能的にブロックチェーンに似たものを作成する方法についてお話しますが、特に企業システムでの幅広いニーズに使用するのに適しています。安くて怒っています。

まず、タスク自体をよく見てください。まず、改ざんから保護されたレジストリが既にあります。第二に、システムの配布は私たちにとってあまり重要ではありません。レジストリ保護システムが集中化されている場合に最も便利です。理想的には、レジストリ自体と同じサーバー上にあります。レジストリとその保護システムの配布も多くの場合に役立ちますが、簡単なものから始める必要があります。保護の原則。

企業システムインフラストラクチャのレジストリ保護システム：

先験的に、サーバーで発生するすべてのことは管理者の完全な制御下にあり、これらの管理者は人間の情熱を持って弱いリンクであると信じています。したがって、レジストリの整合性を監視する機能は、ユーザーのワークステーションに部分的に委任されます。「信頼しない、検証する」という原則。管理者はサーバー上のデータを使用して何でもできますが、レジストリの整合性を修正するためにクロールされたコンピューター（およびスマートフォン、タブレット、フラッシュドライブなど）のチェックサムをどこで、どのトラックで追跡することはできません。クライアントアプリケーション（または場合によっては別の特別な監視アプリケーション）に機能が組み込まれ、レジストリの整合性の違反が検出されると赤信号が点灯し、暗号的に信頼できる告発を生成できます。

保護されたレジストリとそのチェックサム：

各レジストリエントリに対して、独自のハッシュが計算され（H0 _i ）、2番目、3番目などの順序のハッシュのバイナリツリー（H1、H2、...）が自動的に展開されます。次のレコードがレジストリに入力されると、登録されたレコード自体がクライアントアプリケーションに返され、以前のすべてのレジストリエントリを完全にカバーするように、より高いレベルのハッシュのセットが返されます。たとえば、6番目のレコードを追加すると、D ₅ 、H0 ₅ 、H1 ₂およびH2 ₀が返されます（下の図を見ると便利です）。 15番目のレコードをそれぞれ追加すると、D ₁₄ 、H0 ₁₄ 、H1 ₆ 、H2 ₂およびH3 ₀が返されます。サーバーからの応答を受信した後、クライアントアプリケーションは次のことを行います。

D _iが登録しようとしていたものと一致するかどうかをチェックします。
H0 _iを個別に計算し、結果がサーバーが送信したものと等しいかどうかを確認します。
サーバーから受信した応答をローカルデータベースに記憶します。

偽のサーバー応答やその他のトラブルを排除するために、この応答はサーバーの電子署名によって保護できます。

クライアントの自身の記録の不変性のエクスプレスチェック

クライアントは、レジストリに別のレコードを追加したときに、以前に呼び出したときに受信したスライスを使用して、新しい受信ハッシュスライスを検証できます。ハッシュを検証するために、以前の呼び出しから追加のレベルが増加する可能性があるため、サーバーからの追加データがある程度必要になる場合があります。たとえば、クライアントが最初にD ₅を追加し、次にD _14を追加した場合、H2 ₀とH3 ₀を調整するために、サーバーに値H1 ₃を要求し、H1 ₂とH1 ₃に基づいてH2 ₁を計算し、次にH2 ₀とH2 ₁はH3 _0を計算し、結果と比較します。値が一致しない場合、赤いライトとアラームが点灯します。

灰色は、クライアント上にないデータを示しています。 最初のレコード（D ₅ ）を追加するとき、ローカルデータベースのクライアントは緑で強調表示されたデータを保存し、次のレコード（D ₁₄ ）を追加するとき、青で強調表示されたデータを受け取りました。 黄色で強調表示されているものは、保護サーバーから追加で要求されます。

レジストリの一部の継続的なチェック

クライアントは、サーバーにレジストリの一部を要求し、受信したデータからローカルストレージに格納されているハッシュに到達できるかどうかを確認します。

その結果、次のことができます。

レジストリにデータを追加する速度。コインを採掘する必要はありません。保護されたレジストリ内のデータをOLTPトランザクション内に書き込むことができるという事実までの生産性の向上。
信頼性 レジストリからエントリを慎重に削除することはできません。データ破損の複雑さは、完全なハッシュ衝突を選択する複雑さと同じです。
実装の容易さ。 優れたスケーラビリティ「ダウン」。
優れたスケーラビリティ「アップ」。レジストリに1,000億のエントリがある場合でも、バイナリツリーレベルの数は36です。SHA-256ハッシュが使用される場合、サーバーから送信されるハッシュデータは2キロバイト未満です。
レジストリのメンテナンスは一元化されますが（ビットコインスタイルの暗号通貨の場合にはあまり良くありません）、複製に基づいた分散アーキテクチャと、侵害されたノードから不正であると判明しなかったノードへの運用切り替えは非常に可能です。

PS githubのソースについては、尋ねないでください。彼らはそこにいません。アイデアは、車輪を使った出版に行きます。

安全なレジストリを維持するためのブロックチェーンの代替

More articles: