コスモスとビットコインおよびイーサリアムの比較
以太坊爱好者
2019-06-22 12:39
本文约11287字,阅读全文需要约45分钟
ブロックチェーンのいくつかの時代。

編集者注: この記事は以下から引用しましたイーサリアム愛好家編集者注: この記事は以下から引用しましたPreethi Kasireddyイーサリアム愛好家

(WeChat ID: ethfa​​ns)、原著者: Preethi Kasireddy、出典:

編集者注: この記事では、Cosmos ネットワークのブロックチェーンとビットコインおよびイーサリアムの詳細な比較を提供します。著者は、ブロックチェーンシステムのスタック層からスタートし、異なるスタック層でビットコインとイーサリアムの技術的なポイントを分析し、最後にコスモスネットワークのブロックチェーンに戻るという、特に明確な概念的説明は、稀有な解説技術です。

目次


  • 記事が長すぎるため、記事の冒頭に目次を添付しました。

  • 目次

  • コスモスとは何ですか?

  • ブロックチェーン構造の概要

  • ビットコインのスタック層構造

  • イーサリアムのスタック層構造

  • ビットコインとイーサリアムでアプリケーションを構築する

  • Cosmosブロックチェーンの構造

  • コスモスネットワーク層

  • 結論は


Cosmosアプリケーション層

結論は

仮想通貨業界は決して止まらない。

すべては2010年のビットコインの出現から始まりました。ビットコインが初めて登場したとき、誰もがそれがデジタル通貨の聖杯だと考えました。かつては不可能だと考えられていたことが今では現実になりました。初のピアツーピア (P2P) 決済ネットワークが登場しました。

今日でも、物事に対する信頼は、最もとらえどころのない、最も貴重な資産です。ビットコインは、最初の「トラストレス」システムを作成することでこの問題を回避しました。しかし、これはほんの始まりにすぎません。

それ以来、ビットコインは、イーサリアム、ライトニング ネットワーク、EOS、Tezos、Maker など、一連の新しい分散型システムや金融インフラストラクチャにつながる暗号化における広範なイノベーションの触媒となってきました。リストはまだ増え続けています。

しかし、1 つのプロジェクトが際立っています。それは Cosmos です。

ブロックチェーンの分野では、Cosmos は「生まれたばかり」です。そのコンセプトはしばらく前から存在していましたが、開発チームは Cosmos の設計と実装が正確であることを保証するために舞台裏でゆっくりと開発を進めてきました。このため、Cosmos が一般公開されたのは最近になってからです。

したがって、多くの人が Cosmos プロジェクトを見ても理解できないのも不思議ではありません。 Cosmos 関連の資料を閲覧するだけでは、Cosmos を直観的に理解することはできず、さらに多くの疑問を持つようになります。

コスモスとは何ですか?

コスモスはどのように機能しますか?

コスモスはビットコインやイーサリアムとどう違うのですか?

コスモスの特徴は何ですか?

私は Cosmos チームを約 2 年間知っています。正直に言うと、彼らが何をしているのかを最初に聞いたとき、私は他の人たちと同じようにそのコンセプトについてまったく知りませんでした。

しかし、Cosmos について詳しく知るにつれて、Cosmos の良さがとても分かるようになりました。そして、私はただ注意を引くためにこれを言っているのではなく、本当に心からそう思っています。

私は Cosmos にとても魅了されているので、TruStory アプリを Cosmos ブロックチェーン アプリとして構築することにしました。 (間奏: この決定を下した理由については、今後の記事で詳しく説明します)

それでも、宇宙については混乱がたくさんあります。そこで、そのためだけに記事を書くことにしました。私は読者に、Cosmos とは何か、そしてブロックチェーン世界における Cosmos の位置についてより深く理解してもらいたいと考えています。

始める準備はできていますか?心をクリアにして、考える帽子をかぶって、バックルを締めてください。私たちは車で行きます

コスモスとは何ですか?

Cosmos は自分自身を次のように定義します。

「複数の独立した並列ブロックチェーンで構成される分散型ネットワーク。それぞれが BFT コンセンサス アルゴリズム (例: Tendermint コンセンサス) を使用します。」

うわー、なんて一口でしょう!この定義を理解しやすい部分に分解してみましょう。

「独立した並列ブロックチェーンの分散型ネットワーク」

ここでは、読者がブロックチェーンについてすでによく知っていることを前提としています。それでも、簡単に要約すると、

簡単に言えば、ブロックチェーンは多くのコンピューターに分散されたデータベースであり、各コンピューター上のデータベースは同じ状態を維持します。つまり、各コンピュータ上のデータベースにはまったく同じデータが含まれています。これらのコンピューターは一緒になって、「ブロックチェーン ネットワーク」として知られるものを構成します。

ビットコインとイーサリアムはどちらもブロックチェーンであり、Cosmos は、並列実行される多数のブロックチェーンで構成されるブロックチェーン ネットワークです。

私が今言ったことを完全に理解できない場合は、Cosmos の仕組みについて詳しく学ぶ前に、ブロックチェーンについての基本を読んだほうがよいでしょう。 (編集者注: 中国語訳については、「ブロックチェーンとは一体何なのか」の記事の最後にあるハイパーリンクを参照してください)

「各ブロックチェーンはBFTコンセンサスアルゴリズムを採用」

BFT は「Byzantine Fault-Tolerant」の頭字語です。ビザンチンフォールトトレラントブロックチェーンは、ネットワーク内の一部のノードがダウンしたり悪事を働いたりした場合(いわゆる「ビザンチンノード」)、ネットワークが「セキュリティ」と「アクティビティ」の特性を維持していることを保証します。セキュリティとアクティビティにより、ブロックチェーン ネットワーク内の各ノードが同じ状態を維持することが保証されます。

幕間: 安全性と生存性についてさらに深く理解したい場合は、分散型コンセンサスに関する私の記事を読んでください。 (編集者注: 中国語訳については、記事「分散コンセンサスのしくみ、パート 2」の最後にあるハイパーリンクを参照してください)

したがって、「BFT コンセンサス アルゴリズム」は、ブロックチェーンのビザンチン フォールト トレラントを実現する、コンピューター間の通信と調整を定義するアルゴリズムです。 Cosmos ネットワーク内のすべてのブロックチェーンは、ある種の BFT コンセンサス アルゴリズムを採用しています。

ビットコインとイーサリアムのコンセンサス アルゴリズムは、典型的な BFT アルゴリズムではありません。したがって、それらは Cosmos ネットワークにおけるブロックチェーンの定義には当てはまりません。 (ビザンチン フォールト トレラントではありませんが、ビットコインやイーサリアムのようなブロックチェーンは、いくつかの追加手順を実行するだけで Cosmos ネットワークに参加できることは注目に値します。これを不可解に感じても、心配しないでください。後ほど説明します。それについては後で説明します。これについてはさらに詳しく調べてください。)

間奏: BFT が何なのかまだわからない場合は、この記事で明確に説明しました。 (編集者注: 中国語訳については、記事「分散コンセンサスのしくみ、パート 3」の最後にあるハイパーリンクを参照してください)

「テンダーミントコンセンサスアルゴリズム」

Tendermint は、Cosmos 開発者によって提案および構築された BFT コンセンサス アルゴリズムです。 Cosmos ネットワークのブロックチェーンは、Tendermint コンセンサスまたはその他の BFT コンセンサス アルゴリズムを使用できます。 Tendermint については、この記事で後ほど詳しく説明します。

簡単に言えば、Cosmos ネットワークは、並行して実行される複数の独立したビザンチン フォールト トレラント ブロックチェーンで構成されるエコシステムです。これらのブロックチェーンは独立して動作し、他のブロックチェーンと相互運用できます。

ここで、「なぜブロックチェーンが相互運用できるのでしょうか?」と考えているかもしれません。

良い質問!それについてはすぐに説明します。しかし、その前にブロックチェーンの構造を見直す必要があります。

ブロックチェーン構造の概要

Cosmos エコシステム内でブロックチェーンがどのように機能し相互運用するかを詳しく説明する前に、ブロックチェーン構造の基本を確認してみましょう。

前に説明したように、ブロックチェーンは複数のコンピューターで複製されたデータベースであり、各コンピューター上で同じデータを維持します。このタイプの分散システムは、「複製されたステート マシン」としても知られています。

複製されたステート マシンは、複数のマシンで複製された決定論的ステート マシンですが、ネットワーク内の各コンピューターは同じ状態を維持するため、単一のマシンのように機能します。

おなじみですね。上記のブロックチェーンの定義を振り返ってみると、ここでの定義は「データベース」を「ステートマシン」に、「データ」を「状態」に置き換えただけなので、意味が理解できると思います。

「決定的」とは、特定の入力が与えられると、ステート マシンが常に同じ出力を生成すると単純に理解できます。ブロックチェーン システムにおける「決定性」とは、特定の状態から開始して同じ一連のトランザクションを実行すると、最終的には常に同じ最終状態になることを意味します。

複製されたステート マシンは特定の状態から開始します。有効なトランザクションごとに、システム状態が次の状態に遷移します (これはデータベース内のエントリを更新するのと同じです。エントリを更新すると、データベースは更新されたデータ エントリを含む新しい状態に移行します)。

レプリケートされたステート マシンには概念的に 3 つのスタック層があります。

1) アプリケーション層

アプリケーション層は、状態遷移を定義し、トランザクションの発生後にステート マシンの状態を更新する責任を負います。

2) ネットワーク層

ネットワーク層は、1 つのステート マシンで実行されたトランザクションをネットワーク内の他のすべてのステート マシンに伝播する責任を負います。

3) コンセンサス層

コンセンサス層は、トランザクションの実行後に各ステート マシンが同じ状態を保存することを保証するアルゴリズムで構成されます (つまり、ステート マシンは存在しないトランザクションを偽造できません)。

3a) アンチシビル層

分散型パブリック ネットワーク上で実行しようとする複製されたステート マシンには、単一のステート マシンがネットワークを破壊できないようにするための 4 番目の層 (「シビル耐性層」) も必要です。この層がないと、ステート マシンが多くの偽の ID を作成してステートを改ざんし、投資に不釣り合いな影響力や利益を得る (つまり、Sybil 攻撃を開始する) 可能性があります。

要約すると、アプリケーション層は状態の定義と状態遷移の管理を担当します。ネットワーク層とコンセンサス層は、各マシンの状態を一貫した状態に保つ (つまり、ネットワーク内の各データベースのデータが一貫していることを保証する) 責任を負います。 Anti-Sybil 層は (明らかに) Sybil 攻撃を回避する責任があります。

ここで、これらのスタック層がビットコインとイーサリアムのブロックチェーンでどのように定義され、実装されるかを見てみましょう。

ビットコインのスタック層構造

1) アプリケーション層

ビットコインの主な用途は P2P トランザクションです。ビットコインは、スクリプト (スタックされた非チューリング完全言語) を使用してトランザクションを定義し、実行します。送信者がトランザクションを通じてビットコインを送信するとき、送信者はスクリプトを使用して資金の管理者が誰であるかをエンコードします。スクリプトには、送信者がビットコインを使用するために満たす必要のある条件を指定するために使用できる一連のオペコード、またはコマンドが含まれています。

2) ネットワーク層

送信者が受信者にビットコインを送信する場合、マイナーがビットコインをブロックに含めるために、その転送をネットワークにブロードキャストする必要があります。ビットコインは「ゴシッププロトコル」を使用して、各ノードが受信したすべての新しいブロックまたはトランザクションを近隣ノード(ピア)に確実に送信します。ゴシップ プロトコルは、すべてのノード間でのメッセージの配布を保証する P2P プロトコルです。ビットコイン ネットワーク内のすべてのノードは、新しく受信した有効なトランザクションをすぐに近隣ノードに送信するため、パッケージ化されるトランザクションは数秒以内にピアツーピア ネットワークを通じてほとんどのノードに伝播されます。

3) コンセンサス層

トランザクションがネットワークに中継された後、転送を完了するにはトランザクションをブロックチェーンに追加する必要があります (つまり、ネットワーク内のコンピューターにトランザクションを実行させます)。トランザクションを検証してブロックに詰め込むプロセスは、「ナカモト コンセンサス」と呼ばれます。ナカモト コンセンサスの動作原理は、他のフォーラムや記事で見つけることができます。この記事は、より深く掘り下げたい場合の優れた入門書です。

3a) アンチシビル層

ナカモトのコンセンサスは、シビル攻撃を防ぐために「Proof-of-Work」に依存しています。基本的に、新しいブロックを生成するために必要な計算能力により、ビットコイン コンセンサス プロトコル自体が Sybil 攻撃に対して耐性になります。マイナーは次のブロックを生成するために大量の計算能力を必要とするため、大量の計算能力 (および資金) を投資することなく複数の ID を「偽装」することはできません。

イーサリアムのスタック層構造

1) アプリケーション層

ビットコインとは異なり、イーサリアムは元々、分散型アプリケーションを実行できるプラットフォームとして設計されました。イーサリアムには、開発者がスマート コントラクトを記述することで分散アプリケーションの特定の機能を定義できる高水準言語 (つまり、Solidity) が含まれています。 EVM(イーサリアム仮想マシン、イーサリアム仮想マシン)は、イーサリアムアプリケーション層の中核です。 EVM は EVM コンパイラを使用してスマート コントラクト コードをバイトコードにコンパイルします。ユーザーはバイトコードをトランザクションの形式でブロックチェーンにアップロードでき、EVM はこれらのバイトコードを実行して、分散型アプリケーションを変更できます。状態 (つまり、関連する状態を更新します)このスマート コントラクトはイーサリアム ノードによって保存されます)。 Ethereum ネットワーク内のすべてのノードが EVM を実行するため、これによりすべてのノードの状態が一貫していることも保証されます。

2) ネットワーク層

ビットコインと同様に、イーサリアムもゴシップ プロトコルを使用しており、これによりノードが近隣ノードと通信できるようになります。

3) コンセンサス層

コンセンサスを達成するために、イーサリアムはナカモトコンセンサスと同様の「Ethash」を使用しますが、Ethashにはナカモトコンセンサスとはいくつかの重要な違いがあります。イーサリアムのコンセンサスアルゴリズムがどのように機能するかを理解する必要がある場合は、私の以前の記事を読んでください。 (編集者注: 中国語訳については、記事の最後にあるハイパーリンク「イーサリアムのしくみ」を参照してください)

3a) アンチシビル層

ビットコインと同様に、Ethash は Sybil 攻撃に対抗するために Proof of Work (これまでのところ、翻訳者注: イーサリアム 2.0 は将来 PoS コンセンサスメカニズムに切り替わる予定です) に依存しています。

ビットコインとイーサリアムでアプリケーションを構築する

以上でブロックチェーンの構造をある程度理解していただけたでしょうか。 「ビットコイン」や「イーサリアム」について話すとき、これらの名前は関連するすべてのスタック層を指します。なぜなら、ビットコインとイーサリアムはこれらのスタック層で全体が構成されているからです。

Ethereum スマート コントラクトをその基礎となる Ethhash コンセンサス層から分離することはできないため、これら 2 つのトピックを個別に議論することは意味がありません。同じことがビットコインにも当てはまり、ナカモト コンセンサスとプルーフ オブ ワークを使用せずにビットコイン取引を行うことはできません。

一方、Cosmos は少し異なるモデルに従っています。つまり、アプリケーション層をコンセンサス層やネットワーク層から分離しています。

Cosmos の目標はブロックチェーン ネットワークを構築することなので、このように設計するのは理にかなっています。このブロックチェーン ネットワークでは、各ブロックチェーンは独立しており、独自のニーズと要件 (つまり、独自のアプリケーション) を持っています。この場合、すべてのブロックチェーンに万能のアプリケーション層を提案することは現実的ではありません。その理由をいくつかの例で調べてみましょう。

ビットコインの制限の例

通貨アプリケーションを構築するとします。この場合、Bitcoin Scrypt のような単純なスタックベースのスクリプト言語が最良の選択です。ビットコイン スクリプト言語は、あるアドレスから別のアドレスに値を転送するのに適しているだけでなく、非常に単純でチューリング完全ではありません。

そのため、チューリング完全プログラミング言語に深刻な影響を与える可能性のあるさまざまな種類のセキュリティ上の欠陥の影響を受けにくくなります。これはまさに、お金や価値の保存を扱うときに私たちが望んでいることです。しかし、この単純さには限界があります。

Scrypt を使用してより複雑なこと (例: 分散型予測市場) を実行することは非常に困難です。ビットコインスクリプト言語は、実行可能コードの複雑さによって制限されるだけでなく、開発者にとって非常に不親切です。さらに悪いことに、ビットコイン ブロックチェーン上のトランザクションの処理は遅いです (1 秒あたり約 7 トランザクション)。したがって、高いトランザクション スループットを必要とするアプリケーションをビットコイン ブロックチェーン上に直接構築するのは非現実的です。

イーサリアムの制限の例

ビットコインとは対照的に、イーサリアムの EVM とスマート コントラクト言語 (Solidity) は、より柔軟なアプリケーションをサポートするように設計されています。 Solidity はチューリング完全プログラミング言語であるため、理論的には任意のアルゴリズム複雑さのコードを実行できます。

実際のアプリケーションでは、Solidity はエラーが発生しやすく、セキュリティ攻撃に対して脆弱であるため、Solidity を使用して任意の複雑さのプログラムを開発することは非常に困難です。この特性は、セキュリティが最優先される価値の転送を処理するアプリケーションとは相反するものです。

さらに、スマートコントラクトはアップグレードも非常に難しく、反復的な開発が非常に困難になります。契約がチェーンに展開されたら、後はそれがスムーズに実行されることを祈るだけです。ビットコインと同様、イーサリアムのトランザクション処理速度は非常に低い (1 秒あたり約 15 トランザクション) ため、イーサリアム ブロックチェーン上で高いトランザクション スループットを必要とするアプリケーションを構築するのは現実的ではありません。

Cosmos は、この目的のためにいくつかの大きな犠牲を払いましたが、この実際のビジネス ニーズを満たすために提案されました。次に具体的に見ていきます。しかしその前に、Cosmos のブロックチェーンの 3 つのスタック層がどのようなものであるかを理解する必要もあります。

Cosmosブロックチェーンの構造

まず、Cosmos でのアプリケーション開発が Bitcoin や Ethereum の使用とどのように異なるかをより深く理解するために、コンセンサス層から始めて Cosmos を見ていきます。

コスモスコンセンサスレイヤー

Cosmos ネットワークのブロックチェーンは、Tendermint コンセンサス アルゴリズムを使用します。 Tendermint は 2014 年に誕生したオープンソース プロジェクトで、「ビットコイン Proof-of-Work (PoW) コンセンサス アルゴリズムの速度、スケーラビリティ、環境問題を解決するために設計された」ものです。

Tendermint コンセンサス アルゴリズムは、「アプリケーションに依存しないコンセンサス エンジン」です。これは基本的に、どのブロックチェーンでも Tendermint コンセンサス アルゴリズムを使用でき、ビザンチン フォールト トレラントであり、PoS アルゴリズムを使用して Sybil 攻撃に対抗できることを意味します。

またまた専門用語がたくさん!それについて話しました。

復習すると、コンセンサス アルゴリズムは、トランザクションの実行後、ステート マシンに保存された状態が一貫していることを保証するために存在し、Tendermint コンセンサス アルゴリズムは、「すべてのノードが次のブロックでコンセンサスに達することを許可する」ルールを定義します。

検証者

相関係数とルールがどのように機能するかを見てみましょう。

検証者

州の合意に達する責任を負うノードは「バリデータ」と呼ばれます。ネットワーク全体が合意に達するのを支援する意欲のある参加ノードはバリデーターになることができ、その見返りとして、バリデーターはトランザクション手数料とブロック報酬を受け取ります。 Tendermint は、これらのバリデーターの投票を集計して、次のブロックの正しい状態を決定します。

ステーキングでシビル攻撃と戦う

各バリデーターの投票には独自の投票重みがあり、通常、投票重みはジェネシス ブロックの生成時、または実行開始後にアプリケーション層開発者が設計したロジックに従って決定されます。一般に、投票の重みは、バリデーターによって (担保として) システムにロックされているトークン (「債券」とも呼ばれます) の量によって決まります。


  • コンセンサス

  • ルールによれば、検証者はラウンドごとに各ブロックについて合意に達する必要があります。各ラウンドは、提案、事前投票、事前コミットの 3 つの基本ステップと、それに続く 2 つのステップ (コミット、NewHeight) で構成されます。抽象的な観点から、バリデーターは、次のプロトコル規則に従って、次の高さでどのブロックを使用するかを共同で決定します。

  • 1 つ目は提案フェーズです。ここでは、指定されたバリデーターがブロックを提案します。各ラウンドの提案者は、投票の重みに比例して順序付きリストから決定的に選択されます。

  • 次に、事前投票フェーズが始まります。各バリデーターはそれぞれの事前投票をブロードキャストします。

  • ラウンド内のブロックが事前投票の 2/3 以上を獲得した場合、それを「ポルカ」と呼びます。 「ポルカ」が表示されたらすぐに次のステージに進みます。

  • コミット前のフェーズに入ると、各バリデーターはコミット前の投票をブロードキャストします。


特定のブロックが事前投票の 2/3 以上を受け取った場合、そのブロックはコミット フェーズに入り、ブロックがブロックチェーンに追加され、ブロックの高さが増加します。新しいブロックがブロックチェーンに追加されるたびに、ブロックチェーンのブロックの高さは +1 されます。


  • 失敗した場合は、投票前フェーズまたはコミット前フェーズに戻ります。

  • どの高さでも、ブロックをコミットするには複数ラウンドの投票が必要になる場合があることに注意してください。次のような状況が発生する可能性があるためです。

  • ブロックが提案されるはずのときに、指定された「提案者」がオフラインになる


提案者によって提案されたブロックは、いくつかの事前定義されたルールに違反しています

Tendermint は、タイムアウト メカニズムを利用して、ブロックチェーンがブロックを生成する際に遅延が発生しないようにします。提案されたブロックがタイムアウト前に事前投票の 2/3 を超える数を受け取らなかった場合、新しい提案者は提案されたブロックのプロセスを再度続行します。

契約の詳細については、こちらをご覧ください。

一般に、テンダーミントは、ビットコインのナカモト コンセンサスやイーサリアムのイーサッシュとは異なるルートを選択しています。

決定論的 vs 確率的

ナカモト・コンセンサスやイーサッシュなどの確率論的なコンセンサスとは異なり、テンダーミントは決定論的なコンセンサスです。つまり、「おそらく」確定ステータスにすぎないビットコインのブロックとは異なり、テンダーミントの各ブロックは確定しています。

ナカモトのコンセンサスを確認してみましょう。ブロックは常に「未決定」状態にあります。ブロックが「最長チェーン」上にあることを確認することによってのみ、ブロックが完了していると確信できます。これが、ビットコインのトランザクションが待機する必要がある理由です。 「6ブロック確認」用。

Tendermint では、検証者が投票とコミットに成功した直後にブロックが確認されます。

固定バリデータと可変バリデータ

ナカモト・コンセンサスとイーサッシュを使用すると、マイナーは他のマイナーに事前に知らせる必要がなく、いつでも参加または終了を選択できます。対照的に、Tendermint コンセンサスでは、公開キーによって識別される、事前に知られている固定のバリデーターのセットを維持する必要があります。

リーダー vs リーダーなし

ナカモト・コンセンサスとイーサッシュには、次のブロックを提案する指定されたリーダーがいません(つまり、どのマイナーでも次のブロックをマイニングできます)。一方、テンダーミントは、次のブロックを提案する責任を負うリーダー、つまり提案者を選出します。

明示的なタイムアウト メカニズムと曖昧なタイムアウト メカニズム

nakamoto Consensus と Ethash は、マイナーがブロックを生成できることを保証するタイムアウト メカニズムを使用していませんが、Tendermint は、ブロックチェーンのブロック生成プロセスに遅延が発生しないことを保証する明確なタイムアウト メカニズムを備えています。

100 人のバリデーター 対 1000 人のバリデーター

Tendermint は従来のコンセンサス コンセンサス アルゴリズムに従い、各バリデータは相互に通信する必要があります。通信オーバーヘッドを考慮すると、Tendermint はビットコインやイーサリアムのようなバリデーターを無限に増やすことはできません。 Tendermint コンセンサスでは、100 人のバリデーターをスケジュールします。

したがって、Tendermint の欠点の 1 つは、ビットコインやイーサリアムとは異なり、すべてのバリデーターに関する事前知識が必要であり、バリデーターがいつでも参加または離脱することを許可していないことです。

さらに、Tendermint は、システム全体が統一クロックを維持することも要求します。実際には、Tendermint は各ノードのタイムスタンプを統合することで統一クロックを維持できることを証明しましたが、時間の同期が非常に複雑な理論上の問題であることは誰もが知っています。

Tendermint はビットコインよりも検証者の数が少なく、一連の検証者の事前知識が必要なため、Tendermint コンセンサスプロトコルが「十分に分散化されていない」と疑問に思う人もいるかもしれません。

ただし、地方分権は意見の問題です。恥ずかしがらずに言いたいのは、地方分権は目的そのものではなく、ある目的を達成するための手段であって、地方分権の目的を理解せずに判断するのは好きではないということです。

システムを破壊するコストが十分に高く、攻撃者に対する防御とペナルティがある限り、バリデータのセットについての固定的な事前知識を要求するという Tendermint の保守的なアプローチは、多くの場合 (またはほとんどの場合) で実現可能だと思います。 。

予測市場の例に戻ると、分散型予測市場アプリケーションは、健全な通貨や価値の保存アプリケーションと同じレベルの分散化を行う必要はなく、10、20、または 100 個のバリデーターで十分であると言えます。続ける。

TruStory を例に挙げると、Cosmos SDK を使用してバックエンド アプリケーション ロジックを構築し、アプリケーションの状態とロジックをブロックチェーン上に保存しますが、フロントエンドはある程度プライベートです。Cosmos SDK を使用すると、次のことが可能になります。勧善懲悪のシステムを構築する システムにインセンティブを与え、データ層を透過的に表示し、ユーザーがネットワークの所有権とガバナンスを共有できるようにし、今後のことを共同で決定し、悪意のあるユーザーを追い出し、ユーザーのためにネットワークを設計する個人の好みに応じてレイヤーまたはベースレイヤーを選択します。開発者は、バックエンドのブロックチェーン ロジックに基づいて独自の開発ツールやサービスを構築することもできます。したがって、トランザクションを実行して検証する 10 人または 100 人の検証者がいれば、ユーザーと開発者の透明性、所有権、説明責任のニーズを保証できます。

Tendermint が「固定の既知のバリデーターのセットを選択する」という犠牲の利点を理解できれば、他の方法では実現不可能なこれらの魔法の機能に感心するでしょう。

安全性とアクティビティ

Tendermint のプロトコルは、セキュリティと生存性を保証します。検証者の投票重みの 2/3 以上がビザンチン検証者の手に渡っていないと仮定すると (つまり、検証者の 2/3 以上が合意を遵守している)、言い換えれば、投票が悪意のあるものである場合、プロトコルはネットワークのセキュリティとアクティビティを保証できます (つまり、検証者は同じブロック高さで競合するブロックを提案することはなく、ブロックチェーンは常に正常にブロックを生成します)。

ハイパフォーマンス

Tendermint コンセンサスのブロック生成時間はわずか 1 秒で、1 秒あたり数千件のトランザクションを処理する速度に達するため、Tendermint は頻繁なトランザクションを必要とするアプリケーションにより適しています。

即時確認

ブロックチェーンの世界では、ファイナリティとは、ブロックがチェーンに送信されると、そのブロックに至るまでのブロックチェーン全体の状態を判断できることを意味します。

先ほど述べたように、ナカモトのコンセンサスには確率的な性質があるため、最終性を保証する方法はありません。トランザクションが存在するフォーク チェーンがコンセンサス チェーンであることを保証できるのは、ほとんどのマイナーがそのフォークでまだマイニングを行っている確率に基づいてのみです。

ただし、Tendermint では、バリデーターが各ブロックに投票して最終決定する必要があります。したがって、悪意のあるバリデータが 1/3 未満であれば、トランザクションは「即座に確認」できると言えます。ブロックが作成されると、ユーザーは自分のトランザクションが確認されたことを知ります。

責任体制

Tendermint は、PoS を反 Sybil メカニズムとして使用し、ノードが複数の偽のアカウントを作成してシステムを不正行為できないようにするために、バリデーターにトークン (つまり、「結合」) をステークするよう要求します。

PoS は PoW よりもエネルギー効率が高くなります (PoW の証明は、マイナーが次のブロックのハッシュを解決するために消費する計算能力から得られます) が、その固有の「ノーステーク」欠陥により、検証者が簡単に不正行為を行うことができます。

Tendermint は、無関心な問題を避けるためにデポジットを削減することで、プロトコルのルールに違反したバリデーター (競合するブロックに投票したり、未検証の投票をブロードキャストしたりするなど) に罰則を与えます。より具体的には、このプロトコルには、特定のブロックに投票するときに各バリデーターが実行できることを規制する「ロック ルール」があります。たとえば、バリデーターが投票を事前コミットすると、そのブロック内で「ロック」されます。バリデーターは、次のラウンドピースで別のブロックポルカを作成したい場合にのみ、別のブロックのロックを解除して事前コミットできます。ロック規則に違反した場合、バリデーターには保証金の没収とともに罰金が科せられます。

よりシンプルなライトクライアント

ライト クライアントは、ブロックチェーンのすべての状態を保存せず、ブロック ヘッダーのみを保存するため、フル ノードよりも「軽量」です。検証とブロック生成を担当するマイニング ノード、またはバリデータ ノードでない限り、ほとんどのノードは実際にはブロックチェーンの完全な状態を保存する必要はありません。

ライト クライアントは、チェーン全体をダウンロードして保存するのではなく、ジェネシス ブロックから現在のブロックにブロック ヘッダーをダウンロードします。フル ノードと比較して、ライト クライアントでは、特定のトランザクションの有効性を検証するにはブロック ヘッダーで十分であるため、少量のデータのみを保存する必要があります。

最も優れている点は、Tendermint ベースのブロックチェーンのライト クライアントはすべてのブロック ヘッダーを同期する必要さえなく、ブロック ヘッダーを定期的にダウンロードするだけであることです。

前に説明したように、Tendermint はビットコインやイーサリアムとは異なり、すべてのブロックが投票され、最終的に確認される必要があります。各ブロックが最終的に確認されるため、ライト クライアントはバリデータ セットの変更に注意を払うだけで済みます。最新のバリデーターのセットが既知であるため、ライトクライアントは最新のブロックヘッダーをダウンロードし、これらのブロックに 2/3 を超えるバリデーター投票があることを検証できます。

コスモスネットワーク層

上で述べたように、Tendermint のコンセンサスは、各ラウンドでの投票を行うバリデーターに依存しています。したがって、ネットワーク内のすべての参加者が同じデータを確実に参照できるように、ノードは通信してメッセージを転送できなければなりません。

ビットコインやイーサリアムと同様に、Tendermint はゴシップ プロトコルを使用して最新のブロックチェーンの状態を迅速に伝達します。

ネットワーク内のノードは、ネットワークの合意プロセスで役割を果たすためにバリデータである必要はありません。たとえば、ノードはバリデーターの代わりにライト ノードまたはフル ノードにすることができ、そのようなノードは「非バリデーター ノード」とも呼ばれます。

バリデーターノードと非バリデーターノードは、すべてのノードがシステムによって生成される情報とトランザクションを確実に受信できるようにするために、データ (提案データ、ブロックデータ、投票データなど) を配信する責任があります。

Cosmosアプリケーション層

現在、私たちは Tendermint ネットワーク層とコンセンサス層のコア コンポーネントを理解しています。ネットワーク層はネットワーク内のすべてのコンピュータ間のトランザクションの送信を担当し、Tendermint コンセンサス アルゴリズムはステート マシン (つまり、状態マシン) の一貫性を保証します。 、すべてのノードのブロックチェーンは一貫しています)。


  • しかし、どのようなトランザクションを渡して検証するのでしょうか?ここでアプリケーション層が登場します。

  • ブロックチェーンに記録する必要があるトランザクションを定義して送信する


コンセンサス層を通じてトランザクションがコミットされた後、ブロックチェーンの状態を継続的に更新します

文章

Cosmos SDK は、ブロックチェーンの世界における Ruby-on-Rails と同じように、アプリケーション層を構築するためのフレームワークを提供します (Ruby-on-Rails は、開発者がデフォルト設定で Web 側のアプリケーションを簡単に構築できるようにするフレームワークです)。また、Cosmos SDK も提供しますTendermint カーネルに基づいて安全なブロックチェーン アプリケーションを構築するためのフレームワークを備えた開発者。

ブロックチェーンは、すべてのノードにわたって同じ状態のバックアップを持つステート マシンであり、Cosmos SDK を使用すると、複数のノードにわたってレプリケートされる実際のステート マシンを構築できることに注意してください。 SDK を使用すると、アプリケーションの状態、トランザクション タイプ、状態遷移機能に必要な関数とツールをカスタマイズできます。

文章

Cosmos アプリケーションの仕組み (抽象的な観点)


  • Cosmos SDK は、アプリケーション層ステート マシンの状態を定義および維持するための「マルチストア」メカニズムを提供します。マルチストアは、アプリケーション層の状態をさまざまなコンポーネントに分割し、それぞれの「モジュール」を通じてそれらを管理します。

  • Cosmos SDK の強みは、その独自のモジュール設計であり、各モジュールは完全なブロックチェーンを構成する状態のサブセットを定義して維持します。例えば:

  • バンキング モジュール: アプリ内でトークンを保持し、トークンを転送できるようにします。


権限モジュール: アカウントと署名を作成および管理できます。

ステーキングおよびスラッシュ モジュール: コーディングを通じて PoS コンセンサス メカニズムを構築できます。

各モジュールは小さなステート マシンであり、これらを集約して全体のステート マシンを生成できます。

アプリケーション開発者は、各モジュールの慣用的なロジックと変更状態に従ってサブセットを定義し、Cosmos SDK によって提供されるモジュールに加えて、サードパーティのモジュールを呼び出すこともできます。

ブロックチェーン アプリケーションを構築するためのこのプラグイン モジュールは、開発者に SDK または外部モジュールを柔軟に使用できるため、非常に強力です。

アプリケーション層のトランザクションは、アプリケーション ブロックチェーン インターフェイス (ABCI、アプリケーション ブロックチェーン インターフェイス) を通じて Tendermint コンセンサスおよびネットワーク層と通信します。

ABCI は、Tendermint コア (コンセンサス + ネットワーク) とアプリケーションを接続するソケット通信プロトコルです。これは、あらゆるプログラミング言語と互換性があります。つまり、Cosmos SDK を使用して構築されたブロックチェーン アプリケーションは、理論的には、Tendermint の基盤となるコンセンサス層やネットワーク層で使用されるプログラミング言語だけでなく、あらゆる言語で記述できることになります。

文章

注: Cosmos の現在のバージョンは主に Golang をサポートしており、将来的にはさらに多くの言語が追加される予定です。

全体として、Cosmos SDK を使用すると、開発者は Tendermint コアに基づいて分散型アプリケーションを構築できます。このアプリケーションは理論的には任意の言語で開発でき、ABCI を通じて Tendermint コンセンサス エンジンに接続できます。

アプリケーション層 (Cosnos SDK、ABCI) をネットワーク層およびコンセンサス層 (Tendermint コア) から分離することで、開発者はさまざまな種類のアプリケーションをより柔軟に開発できるようになり、Cosmos SDK を使用すると、これらのアプリケーションを任意の言語で開発できるようになります (Golang など)。ブロックチェーン アプリ開発プロセスを通常のアプリケーション開発に近づけます。

これは、Ethereum でのアプリケーション開発とはまったく対照的です。後者では、開発者が新しい言語 Solidity を学習し、Solidity の多くの制限や欠陥を克服する必要があり、Golang には Solidity よりも多くの開発ツールがあり、開発エクスペリエンスは 10 倍優れています。

さらに、すべてのイーサリアム アプリは単一のネットワーク上で動作します。この利点は、これらのアプリがイーサリアム標準とそれに対応するスケール効果を共有できることです。欠点は、これらすべてのアプリがイーサリアム コンセンサス層を共有し、サイズの影響を受けることです。新しく追加されたアプリケーションの。さらに、ネットワーク全体をガバナンスの哲学やイデオロギーの違いに縛られた巨大な単位として管理する必要があるため、スケーリングが困難になります。

もちろん、そのような利点には一定の犠牲が伴います。Cosmos ネットワーク内の各ブロックチェーン アプリケーションは、独自の検証者、コミュニティ、および経済システムをインポートする必要があります。すべての検証者、強力なコミュニティ、および既存の経済システムを直接使用することは不可能です。


結論は

最初のレベルのタイトル

結論は

以太坊爱好者
作者文库