TON: テレグラムオープンネットワーク。 パート 2: ブロックチェーン、シャーディング

このテキストは、今年リリースに向けて準備が進められている (おそらく) 分散ネットワーク Telegram Open Network (TON) の構造を調査する一連の記事の続きです。 で 前の部分 私はその最も基本的なレベル、つまりノードが相互に対話する方法について説明しました。

念のため、私はこのネットワークの開発とは何の関係もなく、すべての資料はオープンな (未検証ではあるが) ソースから集められたものであることを思い出させてください。 ドキュメント (付属品もあります パンフレット、要点を簡単に概説）、昨年末に登場しました。 私の意見では、この文書の情報量はその信頼性を示していますが、これについては公式の確認はありません。

今日は、TON の主要コンポーネントであるブロックチェーンについて見ていきます。

基本的な概念

アカウント (アカウント）。 256 ビットの数値で識別されるデータのセット アカウントID (ほとんどの場合、これはアカウント所有者の公開キーです)。 基本的なケースでは (以下を参照) ゼロワークチェーン)、このデータはユーザーの残高を指します。 特定の「占有」 アカウントID 誰でも変更できますが、その値は特定のルールに従ってのみ変更できます。

スマート契約 (スマート契約）。 本質的に、これはアカウントの特殊なケースであり、スマート コントラクト コードとその変数のストレージが追加されています。 「ウォレット」の場合、比較的単純であらかじめ決められたルールに従ってお金を入金したり引き出したりできる場合、スマートコントラクトの場合、これらのルールはコードの形式で記述されます（特定のチューリング完全プログラミング言語）。

ブロックチェーンの状態 (ブロックチェーンの現状）。 すべてのアカウント/スマート コントラクトの状態のセット (抽象的な意味では、キーがアカウント識別子、値がアカウントに保存されているデータであるハッシュ テーブル)。

メッセージ (メッセージ）。 上では「貸方と借方のお金」という表現を使いましたが、これはメッセージの特定の例です (「送金」 Nグラム アカウントから アカウント_1 アカウントごと アカウント_2")。 明らかに、そのようなメッセージを送信できるのは、アカウントの秘密キーを所有するノードだけです。 アカウント_1 - 署名によってこれを確認できます。 このようなメッセージを通常のアカウントに配信すると、その残高が増加し、スマート コントラクトの結果としてコードが実行されます (メッセージの受信を処理します)。 もちろん、他のメッセージも可能です(金額ではなく、スマートコントラクト間での任意のデータの転送)。

トランザクション (トランザクション）。 メッセージが配信されることをトランザクションと呼びます。 トランザクションはブロックチェーンの状態を変化させます。 ブロックチェーン内のブロックを構成するのはトランザクション (メッセージ配信レコード) です。 この点に関して、ブロックチェーンの状態を増分データベースと考えることができます。すべてのブロックは、データベースの現在の状態を取得するために順次適用する必要がある「差分」です。 これらの「差分」のパッケージ化 (およびそこから完全な状態の復元) の詳細については、次の記事で説明します。

TON のブロックチェーン: それは何ですか?またその理由は何ですか?

前回の記事でも触れたように、 ブロックチェーンはデータ構造であり、その要素 (ブロック) が「チェーン」に順序付けされており、チェーンの後続の各ブロックには前のブロックのハッシュが含まれています。。 コメントでは、「DHT (分散ハッシュ テーブル) がすでにあるのに、なぜそのようなデータ構造が必要なのでしょうか?」という質問がありました。 もちろん、一部のデータは DHT に保存できますが、これはあまり「機密」ではない情報にのみ適しています。 暗号通貨の残高は DHT に保存できません - 主な理由は、暗号通貨の残高にチェックがないためです。 誠実さ。 実際には、ブロックチェーンに保存されているデータへの干渉を防ぐために、ブロックチェーン構造全体の複雑さが増しています。

ただし、TON のブロックチェーンは他のほとんどの分散システムよりもさらに複雑に見えます。これには XNUMX つの理由があります。 XNUMX つ目は、必要性を最小限に抑えたいという欲求です。 フォーク。 従来の暗号通貨では、すべてのパラメーターが初期段階で設定されており、それらを変更しようとする試みは実際に「代替暗号通貨の世界」の出現につながります。 XNUMX番目の理由は、粉砕のサポートです（シャーディング, シャーディング）ブロックチェーン。 ブロックチェーンは、時間の経過とともに小さくなることができない構造です。 そして通常、ネットワークの運用を担当する各ノードは、それを完全に保存することを強制されます。 従来の (集中型) システムでは、このような問題を解決するためにシャーディングが使用されます。データベース内のレコードの一部は XNUMX つのサーバーに配置され、一部は別のサーバーに配置されます。 暗号通貨の場合、特に当初計画されていなかったシステムにシャーディングを追加するのが難しいという事実により、そのような機能はまだ非常にまれです。

TON は上記の両方の問題をどのように解決する予定ですか?

ブロックチェーンのコンテンツ。 ワークチェーン。

まず最初に、ブロックチェーンに何が保存される予定なのかについて話しましょう。 アカウント (基本ケースでは「ウォレット」) とスマート コントラクトの状態がそこに保存されます (簡単にするために、これはアカウントと同じであると仮定します)。 本質的に、これは通常のハッシュ テーブルになります。その中のキーは識別子になります。 アカウントID、および値は、次のようなものを含むデータ構造です。

• 残高;
• スマート コントラクト コード (スマート コントラクトのみ);
• スマート コントラクト データ ストレージ (スマート コントラクトのみ);
• 統計;
• (オプショナル) アカウントからの送金用の公開キー (デフォルトでは account_id)。
• 送信メッセージのキュー (受信者に転送するためにここに入力されます)。
• このアカウントに配信された最新メッセージのリスト。

前述したように、ブロック自体はトランザクション、つまりさまざまな account_id アカウントに配信されるメッセージで構成されます。 ただし、account_id に加えて、メッセージには 32 ビット フィールドも含まれます。 ワークチェーンID — いわゆる識別子 ワークチェーン (ワークチェーン, 動作するブロックチェーン）。 これにより、異なる構成で複数のブロックチェーンを互いに独立させることができます。 この場合、workchain_id = 0 は特殊なケースとみなされます。 ゼロワークチェーン — TON (グラム) 暗号通貨に対応するのは、その中の残高です。 おそらく、最初は他のワークチェーンはまったく存在しません。

シャードチェーン。 無限シャーディングパラダイム。

しかし、ブロックチェーンの数の増加はそこで止まりません。 シャーディングを扱いましょう。 各アカウント (account_id) に独自のブロックチェーンが割り当てられ、そこに届くすべてのメッセージが含まれており、そのようなすべてのブロックチェーンの状態が別のノードに保存されていると想像してみましょう。

もちろん、これは非常に無駄です。おそらく、これらのそれぞれにおいて、 シャードチェーン (シャードチェーン, シャードブロックチェーン) トランザクションが到着することは非常にまれであり、多くの強力なノードが必要になります (将来を見据えて、私たちは携帯電話上のクライアントについてのみ話しているのではなく、本格的なサーバーについて話していることに注意してください)。

したがって、シャードチェーンは、識別子のバイナリ プレフィックスによってアカウントを結合します。シャードチェーンのプレフィックスが 0110 の場合、これらの番号で始まるすべての account_id のトランザクションが含まれます。 これ シャード_プレフィックス 長さは 0 ～ 60 ビットにすることができます。重要なのは、動的に変更できることです。

シャードチェーンの 0 つが多すぎるトランザクションを受信し始めるとすぐに、そのシャードチェーンで動作しているノードは、あらかじめ決められたルールに従って、それを 1 つの子に「分割」します。それらのプレフィックスは XNUMX ビット長くなります (そのうちの XNUMX つの場合、このビットはXNUMX に等しく、もう XNUMX つは - XNUMX)。 例えば、 シャード_プレフィックス = 0110bは分割されます 01100bと 01101b. 次に、XNUMX つの「隣接する」シャードチェーンが (しばらくの間) 十分に安心し始めると、それらは再びマージされます。

したがって、シャーディングは「ボトムアップ」で行われます。各アカウントには独自のシャードがあると想定しますが、当面はプレフィックスによって「接着」されます。 これが意味するところです 無限シャーディングパラダイム (無限シャーディングパラダイム).

それとは別に、ワークチェーンは仮想的にのみ存在することを強調したいと思います。 ワークチェーンID これは、特定のシャードチェーンの識別子の一部です。 正式な用語では、各シャードチェーンは XNUMX 組の数字 (ワークチェーンID, シャード_プレフィックス).

エラー修正。 垂直型ブロックチェーン。

伝統的に、ブロックチェーン上のあらゆるトランザクションは「決まっている」と考えられています。 ただし、TON の場合、誰かが (いわゆる。 フィッシャーマンノット) は、ブロックの XNUMX つが正しく署名されていないことを証明します。 この場合、特別な修正ブロックが対応するシャードチェーンに追加され、修正されるブロック自体のハッシュが含まれます (シャードチェーンの最後のブロックではありません)。 シャードチェーンを水平方向に配置されたブロックのチェーンとして考えると、修正ブロックは誤ったブロックの右側ではなく上から接続されていると言えます。したがって、小さな「垂直ブロックチェーン」の一部になると考えられます。 。 したがって、シャードチェーンは 二次元ブロックチェーン.

エラーのあるブロックの後、それによって行われた変更が後続のブロックによって参照された場合 (つまり、新しいトランザクションが無効なトランザクションに基づいて行われた場合)、修正もこれらのブロックに「上に」追加されます。 ブロックが「影響を受けた」情報に影響を与えなかった場合、これらの「修正波」はそれらには適用されません。 たとえば、上の図では、口座 C の残高を増やす最初のブロックのトランザクションが正しくないと認識されました。したがって、XNUMX 番目のブロックでこの口座の残高を減らすトランザクションもキャンセルされ、修正ブロックが必要になります。ブロック自体の上でコミットする必要があります。

修正ブロックは元のブロックの「上」にあるように描かれていますが、実際には対応するブロックチェーンの最後（時系列的にそこにあるはずです）に追加されることに注意してください。 XNUMX 次元の位置は、（ブロック内にある元のブロックのハッシュを介して）ブロックチェーン内のどのポイントに「リンク」されるかを示すだけです。

「過去を変える」という決断がどれほど良いものかについて、個別に哲学することができます。 シャードチェーンに誤ったブロックが現れる可能性を認めると、誤った修正ブロックが現れる可能性を避けることはできないように思えます。 私の知る限り、違いは新しいブロックに関して合意に達する必要があるノードの数にあります。各シャードチェーンで作業する人の数は比較的少数になります。」ワーキンググループ» ノード (その構成は頻繁に変更されます)、および修正ブロックの導入には全員の同意が必要です バリデータノード。 バリデーター、ワークグループ、その他のノードの役割については、次の記事で詳しく説明します。

XNUMX つのブロックチェーンですべてを管理

さまざまな種類のブロックチェーンに関する上記の情報は数多くありますが、それ自体もどこかに保存する必要があります。 特に、次の情報について話します。

• ワークチェーンの数と構成について。
• シャードチェーンの数とそのプレフィックスについて。
• どのノードが現在どのシャードチェーンを担当しているかについて。
• すべてのシャードチェーンに追加された最後のブロックのハッシュ。

ご想像のとおり、これらすべては別のブロックチェーン ストレージに記録されます。 マスターチェーン (マスターチェーン, マスターブロックチェーン）。 ブロック内のすべてのシャードチェーンのブロックからのハッシュが存在するため、システムは高度に接続されます。 これは、とりわけ、マスターチェーンでの新しいブロックの生成が、シャードチェーンでのブロックの生成の直後に発生することを意味します。シャードチェーンのブロックは、約 5 秒ごとにほぼ同時に出現し、次のブロックがシャードチェーンで生成されることが予想されます。マスターチェーン - その XNUMX 秒後。

しかし、メッセージの送信、スマートコントラクトの実行、シャードチェーンとマスターチェーンでのブロックの形成、さらにはブロックのエラーチェックなど、この壮大な作業すべての実装の責任は誰が負うのでしょうか? これらすべては、Telegram クライアントがインストールされた何百万ものユーザーの携帯電話によって秘密裏に行われるのでしょうか? それとも、おそらく Durov チームは分散化の考えを放棄し、サーバーは昔ながらの方法でそれを実行するでしょうか?

実際には、どちらの答えも正解ではありません。 しかし、この記事の余白はすぐになくなってしまうので、次のパートでは、ノードのさまざまな役割 (すでにいくつかのノードについて言及していることに気づいたかもしれません) とその動作の仕組みについて説明します。

出所： habr.com