Ordinals の議論から 2014 年の OP_Return の議論を振り返る: Dapps 対ビットコイン取引

出典: BitMEX Research

;2014; の ;OP_RETURN; の議論は業界内で注目に値する分裂であり、今日の ;Ordinals; の議論と多くの類似点があります。振り返ってみると、;OP_RETURN; の議論は今日特に意味があります。

  • ビットコイン ブロックチェーン上でこの種のアクティビティを単純に望まないビットコイン愛好家やビットコイン開発者の中には、この種のアクティビティをブロックすることに成功した人もいます。一方、イーサリアムのような他のチェーンのプロモーターは、エコシステムが牽引力を得るのを助けるために、ビットコイン開発者のこの明らかな姿勢を利用し、誇張した可能性があります。

## 概要

「分散型取引所などの Dapps は、なぜ通常ビットコインではなくイーサリアムを使用するのですか?」という質問をよく受けます。結局のところ、分散型取引所、ドメイン名システム、代替トークンなど、ビットコイン上に Dapps を構築することはもちろん可能です。もちろん、これにはいくつかの理由があります: i. イーサリアムのより柔軟なネイティブ スクリプト言語により Dapps の構築が容易になる、ii. イーサリアムのより速いブロック時間により Dapps がより使いやすくなる、または iii. イーサリアムよりもブロック サイズ制限が保守的である、その結果、ビットコインの手数料が高くなる可能性があります。上記のすべての要因は確かに影響を及ぼしますが、その影響はしばしば誇張されていると考えられます。最も重要な要素は文化です。一部のビットコイン愛好家やビットコイン開発者は、ビットコイン ブロックチェーン上でそのような活動を単に望んでいないため、それをブロックすることに成功しました。これは主に 2014 年 3 月頃に起こったようで、その頃に何が起こったかがこの記事の主題です。一方、イーサリアムのような他のチェーンのプロモーターは、エコシステムが牽引力を得るのを助けるために、ビットコイン開発者のこの明らかな姿勢を利用し、誇張した可能性があります。

カウンターパーティプロトコル

2020 年 9 月のレポートで述べたように、Counterparty は 2014 年初頭に立ち上げられました。 Counterparty は、新しいトークンの作成や分散取引所でのトークンの取引などの機能を可能にする、ビットコイン上のプロトコル層です。このシステムは、ビットコイン取引データの一部を取得し、トークンの作成、トークンの送信、分散型取引所でのトークンの市場入札などの機能としてカウンターパーティ契約で使用することによって機能します。

より簡潔に言うと、カウンターパーティは当初、ビットコイン オペコード OP_CHECKMULTISIG を使用して、カウンターパーティ関連データをビットコイン ブロックチェーンに組み込みました。このオペコードは、Payment Script Hash (P;2 SH) マルチ署名トランザクションの署名を検証するために使用する必要があります。 2014 年 7 月のカウンターパティ取引のサンプルは、ここでご覧いただけます。このトランザクションは、ビットコインを送信元のアドレスに送り返します。また、3 つの追加出力もあり、出力スクリプトは取引相手の契約に関連するデータです。この場合、TICKET という新しいトークンが作成されます。 OP_CHECKMULTISIG の使用は、オペコードの意図された用途ではないため、ハッキングとみなされる可能性があります。カウンターパーティは現在、ビットコインの OP_Return オペコードを使用してデータを保存していますが、これは開発者の意図により多少沿っています。たとえば、OP_Return を使用するこの更新されたカウンターパーティ トランザクションを参照してください。

2014 年の初め、Mastercoin と呼ばれるライバル プラットフォームに先駆けて、Counterparty の周りでは多くの実験、開発者の活動、革新、そして興奮が起こっていました。

OP_Return とは何ですか?

OP_Return は、ビットコインでの明らかに消費できないトランザクション出力です。この機能は、ビットコインを書き込んだり、ビットコイン ブロックチェーンに任意のデータを保存したりするために使用できます。データは UTXO セットの一部ではないため、プルーニングに参加しているノードは OP_Return データを保存する必要がないため、この方法でデータを保存するとビットコインのスケールに役立つと言われています。

ビットコインのコンセンサス ルールでは、最大 OP_Return サイズが 10,000 バイトまで許可されています。たとえば、2013 年 5 月に、この機能は次のトランザクションで悪用されました。このトランザクションの OP_Return 出力には、リックローリング ミームに関連するリック アストリーの 1987 年の曲「Never Gonna Give You Up」の歌詞が含まれています。

序数討論からの 2014 年 OP_Return 討論のレビュー: Dapps 対ビットコイントランザクション対決

2014 年以前は、OP_Return を含むトランザクションは非標準であり、通常のビットコイン ノードによって中継されませんでした。ただし、マイナーがこれらのトランザクションを含める場合、それらは有効であるとみなされます。 2014 年 3 月に、Bitcoin Core 0.9.0 がリリースされました。これには、標準トランザクション タイプとして OP_Return 関数が含まれており、トランザクションはデフォルトでリレーされます。当時のリリースノートは以下の通り。

この変更は、ブロックチェーン上にデータを保存することを推奨するものではありません。 OP_RETURN の変更は、任意のデータ (画像など) を決して利用できない TX 出力として保存し、ビットコインの UTXO データベースを肥大化させるデータ ストレージ スキーム (一部は既にデプロイされている) を回避するために、明らかにプルーナブルな出力を作成します。任意のデータをブロックチェーンに保存するのは依然として悪い考えであり、非金銭的なデータを別の場所に保存する方が安価で効率的です。

ソース:

Bitcoin Core 0.9.0 は、OP_Return が 40 バイト以下のトランザクションのみを中継します。データがこれより大きい場合、トランザクションは有効ですが、中継されません。当初の制限は 80 バイトでしたが、多くの議論の結果、開発者は 40 バイトに落ち着きました。

2016 年に、Bitcoin Core 0.11.1 でリレーの制限がついに 80 バイトに増加し、2016 年後半の Bitcoin Core 0.12.0 リリースでは、現在の制限である 83 バイトに増加しました。これは、今日 83 バイトを超える OP_Return 出力を持つトランザクションが必要な場合は、ブロックを自分でマイニングするか、マイナーに直接送信する必要があることを意味します。

OP_帰還戦争

2014 年 3 月 20 日、当時のビットコインへの主要な貢献者の 1 人である Jeff Garzik が、Bitcointalk フォーラムのカウンターパーティ セクションに投稿を開始しました。ジェフはカウンターパーティによるブロックチェーン空間の使用を批判した。

これまでのところ、単純なハッシュに安全に置き換えることができないブロックチェーン データ ダンプ スキームを見たことがありません。データをブロックチェーンに保存する必要はありません。それは純粋な知的怠惰です。タイムスタンプ付きのハッシュ (データ) は、より効率的でありながら、同様に安全です。さらに、セカンダリ チェーンはビットコインに固定されている可能性があります。

ソース:

ジェフは続けてこう言いました。

CheckMultiSig は、任意のデータではなく、ECDSA 公開キーを使用して動作することは明らかです。意図された目的以外の目的で操作を使用すると、マイナスの、場合によっては意図しない、または未知の結果が生じる可能性があることは驚くべきことではありません。カウンターパーティのトランザクションは「ビットコイン プロトコルに従って」いるのではなく、このような方法でこの機能を使用することは予期されていなかったため、トランザクションが実行されます。

ソース:

ジェフがこのような見解を持っているのは奇妙だと思う人もいるかもしれない。なぜなら彼は2017年の時点で「ビッグブロック支持者」であるようであり、ブロックスペースの保守的な使用に関するこの見解はラージブロックの見解と矛盾しているように見えるからである。しかし、この明らかな矛盾は 2014 年にはまったく生じませんでした。当時、Jeff の見解は、後に大きなブロックの責任者になった人たちも含め、当時活動していたほぼすべての開発者によってある程度認められていました。私たちが知る限り、ブロック サイズ制限に対する人々の認識とこの質問の間に単純な対応関係はありません。 Jeff は当時尊敬されていた開発者であり、この記事はカウンターパーティの開発者とユーザーの両方から多くの注目を集めました。

「BitcoinTangibleTrust」という仮名を持つカウンターパーティの開発者は、ジェフに次のように返信しました。

あなたは、絶対に正しい。データをブロックチェーンに保存する必要はありません。タイムスタンプ付きのハッシュ (データ) は、より効率的でありながら、同様に安全です。セカンダリチェーンはビットコインに固定されている可能性があります。ただし、以下の PhantomPhreak の [Counterparty 共同創設者兼主任開発者] によると、Counterparty は 3 つのマルチシグ トランザクションに 1 つでブロックチェーンにデータを保存するために 256 バイトを使用しています。また、これらのマルチシグ トランザクションはすべてマイナーによって処理されます。

開発者は続けて、OP_Return を 80 バイトではなく 40 バイトに制限する計画を立てているビットコイン開発者を批判しました。

OP_RETURN がマルチシグの動作 (未使用の出力) を停止/削減し、ブロックチェーンの肥大化を軽減することを目的としている場合、OP_RETURN のサイズを 80 バイトから 40 バイトに減らすことで、誤ってマルチシグをより魅力的なものにしてしまうのではないかと心配しています。すべてのメタプロトコルでは、OP_RETURN の魅力が低下しています。

「PhantomPhreak」として知られるカウンターパーティの主任開発者兼共同創設者は、次のように声をかけました。

そのアイデアは、データを 2 番目のブロックチェーンに保存し、そのタイムスタンプ データのハッシュをビットコインに入れることであり、それらのハッシュも 40 バイト未満になります。これを行わなかった理由は「知的怠惰」ではなく、実装の複雑さでした。 Counterparty はコンピューター サイエンス プロジェクトではありません。開発速度を高めるために、できるだけシンプルになるように設計されました。データをマルチシグネチャ出力に保存する必要がある場合でも、小さすぎる OP_RETURN 出力ではありません。この分野では、悪いほうが間違いなく優れています。

ジェフは翌日、こう答えた。

これはヒッチハイクです。ビットコインのブロックチェーン アプリケーションの大部分 (>90%;) が通貨の使用であることを考えると、完全なノードをダム データ ストレージ端末として使用することは、完全に自発的なネットワーク リソースの乱用にすぎません。ネットワークはトランザクション データを複製するので、なぜフリーライドしないのでしょうか?マスターコインとカウンターパーティは、既存のコミュニティに参加する代わりに、単純に「オン」スイッチを切り替え、ビットコイン P;2 P ノードを不要なデータ ストレージとして使用し始めました。未使用のトランザクション出力は、任意のデータ ストレージとして使用することを意図したものではありません。悪用される可能性があるという事実は、それが正しい、または遠隔で効果的である、または最良の解決策であるとは限りません。 UTXO (Unspent Transaction Output) データベースは、ネットワーク全体に高速アクセスできるデータベースです。ネットワーク トランザクションを最適に処理するために、各ノードはこのデータベースをできるだけ小さくする必要があります。任意のデータを未消費の出力にエンコードすることは、単純かつネットワーク全体にわたる悪用です。ネットワーク全体がこの価格を負担します。

ソース:

コミュニティ内での Jeff の地位が高いため、Counterparty コミュニティのほとんどの人々が関与して問題を解決することに熱心であるようです。たとえば、BitcoinTangibleTrust は次のように答えました。

あなたの考えを共有してくれてありがとう、ジェフ。それで、既存のビットコインコア開発コミュニティとの関わりを始めるのを手伝ってくれませんか?私たちが生き残るためにはビットコインブロックチェーンが必要であるため、責任あるパートナーとして行動することはカウンターパーティの利益になります。これらの問題について協力を始める方法を教えていただけますか?

ソース:

別のカウンターパーティ開発者は別の点を指摘しました。

ビットコイン プロトコルが、他に何も壊さずに XCP の使用方法を停止する方法はありますか?

もしビットコイン開発者がカウンターパーティ関連の取引を防ぐ方法がなかったとしたら、おそらくこの異議は問題にならず、カウンターパーティは許可なくビットコインを使用し続ける可能性があります。その後、ビットコイン開発者であり、その後マイニングプール運営者でもあったルーク・ジュニア氏が次のように議論に加わった。

マイナーは悪用を排除する必要があります。

ソース:

次に、Luke-Jr 氏は、この種のシステムはマージマイニングされたサイドチェーン タイプの構造を使用して構築でき、ブロックチェーンの肥大化を回避できると提案しました。

問題は新しい層ではなく、人々の意志に反した押し付けである。新しいレイヤーは、ブロックチェーンを汚染したり、非参加者にデータの保存を強制したりすることなく、オプトインベースで実行できます。

Luke 氏はまた、ビットコイン開発者が予想される OP_Return リレーのサイズを、当初提案されていた 80 バイトの制限と比較して 40 バイトに削減した理由も尋ねられました。ルークは次の3点で答えました。

  • OP_RETURN は関数であり、使用する必要があると考えている人が多すぎます。それは決してそのような意図ではなく、「誰かが侵入したときにガラスを交換する必要がないように、窓のロックを解除したままにしておく」という単なる方法でした。それは、人々がビットコインを悪用することによって引き起こされる被害を軽減することです。
  • データをトランザクションにバインドするためのすべての法的ニーズには 40 バイトで十分です。ハッシュ用に 32 バイトが得られ、さらに、ある種の一意の識別子用に 8 バイトが得られます (これも実際には必要ありません!)。
  • 元の 80 バイトの提案は 512 ビット ハッシュを対象としていましたが、不要であると判断されました。

ルーク・ジュニアはこう続けた。

マイニングが分散化に戻るにつれて、OP_RETURN の亜種であろうとなかろうと、不正行為やスパムのトランザクションに対する許容度が低下することが期待されます。さて、誰かが実際にトランザクションでハッシュを保存するための有効で必要なユースケースを持っているのであれば、明らかにマイナーはマイニングを真剣に検討する必要があります。

ソース:

当時の Luke のマイニングプールは、カウンターパーティ関連のトランザクションもフィルタリングし始めました。これは、カウンターパーティコミュニティで恐怖と不確実性が高まり始めたときです。 OP_Return を 80 バイトにする必要があります。そうでない場合は、OP_CHECKMULTISIG オペコードの使用を継続することが強制されます。 Luke のコメントを考慮すると、80 バイトに達する可能性は低いと思われます。さらに、開発者が制限をさらに引き下げ、Counterparty をネットワークから排除する可能性があると懸念する人もいます。ビットコイン開発者はカウンターパーティに対して特に友好的ではないようなので、ビットコインプロトコルを使い続けるのは難しいのではないかと考える人もいるかもしれません。

2014年3月25日、イーサリアムの主な創設者であるヴィタリック・ブテリン氏も同調し、議論はもっと手数料を中心に展開されるべきであり、十分な手数料を支払えば、あなたの取引は法的にブロックに含めるべきだと主張した。現在、イーサリアムの手数料アルゴリズムは非常に複雑であり、さまざまなブロックチェーンの用途に応じてさまざまな手数料バケットとレートがあり、これにより OP_Return 問題が根本的に解決されます。ビットコインの SegWit もこの問題をある程度軽減すると主張する人もいるでしょう。

これはプロトコルの欠陥であり、OPRETURN の戦いはそのような問題です。理想的な世界では、「悪用」という概念はまったく存在せず、料金は必須であり、特定のトランザクションがネットワークに課す実際のコストに厳密に一致するように慎重に設計されています。」と同氏は述べた。完了しているのであれば、質問する必要はありません。 」

ソース:

2014 年 3 月 27 日、カウンターパーティは、Luke-Jr のマイニング フィルターをバイパスするように取引方法を変更しました。しかし翌日、ルークは次のようにコメントした。

良いニュースです! 1 行のコードを 5 分もかからずに、この無駄なものをブロックするフィルターを追加できます。

ソース:

Luke-Jr 氏は、Counterparty を一種の虐待に例えています。

これは、他人の自由な選択に従ってあなたのデータをダウンロード/保存することを強制するため、不正行為です。すべての完全なノードは完全なブロックチェーンをダウンロードする必要があります (プルーニング可能かどうかに関係なく)。すべての完全なノードは、金融トランザクションをダウンロードして保存することに同意します。すべてのフルノードが他のものを保存することに同意するわけではありません。そのためには、一部のグループ (つまり、マイナーや開発者ではない) だけでなく、あるいは過半数でもなく、100% のコンセンサスが必要です。また、誰もがブロックチェーンにないデータを自由に保存できます。それをブロックチェーンに置くことにメリットはなく、それを望まない人々にそれを強制しているだけです。これが虐待ではないことを説明してください...

ソース:

ビットコイン開発者に対する怒り

ご想像のとおり、ビットコイン開発者の懸念は、最終的に一部のカウンターパーティ開発者やユーザーからの不満と怒りに見舞われました。以下に彼らのレビューの一部を紹介します。まず、Luke-Jr のプールがカウンターパーティ取引をブロックしていることに関する「porqupine」という名前のユーザーからのコメントです。

解決策を見つけることに責任を持って取り組んでいる開発者に比べれば、それは問題ありません。あなたはいたちごっこを推進していることになります。ネット中立性についても話していることに気づきましたか?そして人々がブロックチェーン上で行うべき取引と行うべきではない取引を民間の手に委ねようとしている。嫌いな人を制裁する次のステップは何ですか?政府の外交政策を支持しない国のノードでの放送取引に対する制裁?

ソース:

2014 年 3 月 21 日、ヤマアラシは次のように続けました。

「すべてのノードが、タイプ Y データの代わりにタイプ X データを保存することに同意する」と決定したら、ちょっと待ってください。おそらく、マネーロンダリング、違法薬物や武器、人間の奴隷制度などのために取引を保存することにも同意できないでしょう。あなたは基本的にプロトコルの中立性を否定し、あなただけでなく、プロトコルを保存するために何を使用すべきか、すべきではないかを決定しているのです。一人称で話さず、代名詞「私たち」を使用して、すべてのマイナーまたはマイナーを代表しているかのような印象を与えます。プロトコルのユーザーが全体として発言します。

ソース:

他の人は、ジェフとルークが特定の使用例をブロックするために他者を回避する権限をなぜ持っているのかについて懸念を表明しました。

この態度が信じられない。ビットコインに所有者がいるとは知りませんでした。私と他の約100万人が所有者だと思っていた

Counterpartyの共同創設者PhantomPhreak氏は次のように述べています。

まず、カウンターパーティ取引は金融取引です。次に、すべてのフルノードがビットコインブロックチェーンをダウンロードして保存することに同意します。つまり、ビットコインプロトコルに準拠したトランザクション、カウンターパーティトランザクションは明らかに準拠しています。念のため、サトシはジェネシスブロックに政治的メッセージを埋め込みました...あなたはビットコインの可能なユースケースについて他の誰よりもはるかに狭い視野を持っています。

ソース:

彼または彼女はこう続けます。

ビットコインは意図されていないことをたくさん行っています。はい、現在あるものよりもさらに洗練されたソリューションを使用したいと考えています。 Counterparty は元々、OP_RETURN 出力を使用してすべてのメッセージ データを保存するように設計されていました。これは非常に洗練されており、ブロックチェーンへの影響は最小限であると思います。私たちは、Gavin が公式 Bitcoin ブログで発表した 80 バイト制限を中心にすべてのメッセージをフォーマットする予定です。選択の余地がないため、マルチシグネチャ出力のみを使用します。私たちはビットコインプロトコルを拡張したくありません。私たちは、安定性やセキュリティなどのメリットを得るために、完全にその中で何かを行い、できるだけシンプルかつ簡単にしたいと考えています。

ソース:

同様に、私たちは金融取引のみをブロックチェーンに保存し、使用したスペースに対して料金を支払います。 OP_RETURN 出力の金融トランザクションは、ノード全体のストレージにとっては他の何よりも苦痛ではありません。

ソース:

「bitwhizz」という名前の別のユーザーは次のように述べています。

保存したくない場合は、保存しないでください。非常に単純ですが、ビットコインを使用せず、ブロックチェーンをダウンロードしないでください。あなたのスコットは無料です。しかし、私の同意は、ビットコインにはトランザクション機能があるだけでなく、誰もそれを持っておらず、OP_RETURN関数があるという事実に基づいて、なぜこの関数を根絶する必要があるのかわかりません。保存したくないデータは、すでに自由に選択できます。

ソース:

「アナタラノン笑」はこう言った。

どうしてカウンターパーティ取引が金融取引に該当しないのか本当に理解できません。また、その観点も理解できません。なぜなら、1000 個に 1 個のノードがこのデータを受け入れたがらず、デフォルトで禁止されるべきだからです。 mt.gox の最近の悪夢と、残高を集中管理されたエンティティに保存することによって引き起こされた数多くのハッキング、盗難、シャットダウン、損失の後、Counterparty は、この問題に対する集中型のトラストレスなソリューションを可能にするソリューションを考え出したようです。

ソース:

「バッドウ」はこう言った。

実際、誰でもいつでも任意のデータをブロックチェーンに保存できます。この目的のためにこれまでも使用されてきましたし、現在も使用されています。 Bitcoin ノードを実行している人なら誰でもこのことをすでに知っているはずです。そうでない場合は、Bitcoin-QT をインストールしたときに表示される通知の一部であるはずです (通知があった場合。私はそれを見た覚えがありません)。あらゆるビットコイン取引は、単純なお金の移動、ラブレター、または爆弾を爆発させる引き金となる可能性があります。その可能性を排除すれば、ビットコインは消滅することになる。

ソース:

バドウはこう続けた。

コンピューティングの歴史 (そして実際には人類のテクノロジーの歴史全体) における偉大な発展の多くは、発明者が使用する意図のなかったものを人々が発見した結果です。良いことは、ほとんどの発明家は自分の発明をそれほど保護せず、他の人が新しいものにそれを使用することを拒否しないことです。達成した人たちは、自分たちがすぐに超えてしまったことに気づきました。

ソース:

これらのコメントから、多くのカウンターパーティユーザーと開発者がビットコイン開発者の立場に驚き、失望していることは明らかです。プロジェクトは継続し、マスターコインも継続しますが、良くも悪くも、結果として一部の開発者がビットコインを離れ、イーサリアムなどの他のブロックチェーンシステムでプロトコルを構築する可能性があります。私たちの見解では、2014 年のこの瞬間が他のどの瞬間よりも重要です。ただし、他の人は違う見方をするかもしれません。

マージマイニングされたサイドチェーン

OP_Return の議論を通じて、カウンターパーティやブロックチェーンの肥大化に反対する者は通常、Dapps のソリューションとして何らかの形式のマージされたマイニング サイドチェーンに言及します。実際、サトシ・ナカモトはこのパスを気に入ったと言われており、2010 年 12 月にドメイン名システムでの使用を承認したと言われています。

BitDNS を完全に別個のネットワークと別個のブロックチェーンにして、CPU パワーをビットコインと共有することは可能だと思います。唯一重複するのは、マイナーが両方のネットワークを同時に検索できるようにするプルーフ・オブ・ワークです。

ソース:

これらの Dapp システムをサイドチェーンとして実装するには多くの困難がありますが、多くの人が単に機能すると考えていた 2014 年よりも、私たちはこれらの弱点をよりよく理解しています。

  • 複雑さ - 最も重要な弱点の 1 つは、サイドチェーン ソリューションの実装と構築の複雑さです。プロトコルを早期にローンチして市場シェアを獲得するために、これらのプロジェクトにはサイドチェーンを構築したり、ビットコインと統合されたマイニングシステムを構築したりする時間がありません。
  • ネイティブ資産としてのビットコイン - トラストレスな双方向ペッグを確立できない可能性があるため、非保管ビットコインをサイドチェーン上の運用資産として使用することはできない場合があります。これは多くの Dapps にとって大きな弱点です。たとえば、分散型取引所の主要な取引ペアとしてビットコインを使用したいと考える場合があります。この弱点は 2014 年時点では十分に理解されていないようで、多くの人はそれが何らかの形で機能すると考えています。
  • スケーリングの利点が限られている - サイドチェーンを使用する利点はユースケースによって異なる場合があります。たとえば、分散型取引所が構築される場合、すべての入札、オファー、およびマッチングにはメイン チェーンのすべてのセキュリティが必要になる可能性があります。メインチェーンの用途が非常に多いため、取引所でのすべてのユーザーのあらゆるアクションに対して、サイドチェーン システムのスケーリング上の利点は非常に限られている可能性があります。オンチェーンでローカルに入札を送信すると、約 90 バイトしか使用されない可能性がありますが、注文情報のハッシュと、それを識別するために必要な構造とオーバーヘッドの保存はオンチェーンで約 50 バイトになる可能性があるため、あまりスペースを節約できません。

2014 年 3 月、Counterparty 開発者 (xnova) はサイドチェーンに対する反対の概要を次のように述べました。

また、ここで何かを見落としていない限り、保存するデータを取得するには、(少なくともビットコインまたはビットコイン派生の実装であると仮定して) 2 番目のブロックチェーンのブロックからデータを解析する必要があります。したがって: * カウンターパーティーが提供するカラーコイン機能 (つまり、DEx、賭け、資産コールバック、配当、CFD など) のため、SPV タイプのカウンターパーティークライアントは有効になりません。 * カウンターパーティー取引のセキュリティが低下します。これにより、実装の複雑さが大幅に増加します (つまり、バグやバグが発生する可能性が増加します)。唯一疑わしい利点は、ブロックチェーンのストレージ要件がわずかに * 削減されることです (つまり、トランザクションごとに 20 ~ 40 バイト減るでしょうか?)。 。ここではそれが何を意味するのかわかりません。もう 1 つのポイント: カウンターパーティはビットコインに多大な利益をもたらす可能性があり、それはイーサリアム (および他の同様の非ビットコイン メタ ";2.0;" タイプのコイン) が登場すれば、より明らかになるでしょう。少なくとも私の個人的な感覚では、ビットコインは、イーサリアムや(将来の)群衆の機能リストと魅力的に効果的に競争するには、エコシステム内でこの機能を備えた製品が必要になる可能性が高い、または少なくともリスクが排除されるということですが、これは少なくとも投資家と金融市場運営者の間では当てはまります、そしてこれにより、ビットコインエコシステムがより多くの認識、信頼、マインドシェアを得るにつれて、数十億ドル、さらには数兆ドルをもたらすことができます。

ソース:

ソリューションとしてサイドチェーンをサポートしている人の中には、多くの dapp アプリケーションに特に興味がなく、試したこともない人もいるようです。したがって、分散型取引所を構築することの複雑さや、すべてのユーザーのほぼすべてのアクションに対するセキュリティの必要性についてはまったく考慮していませんでした。ほとんどのビットコイン開発者は、自分たちが興味を持っているものに対してオープンであり、検閲に強いお金、非政治的なお金、電子現金など、自分たちが何を望んでいるのかについてよく理解しているようです...

## 結論は

2014 年頃以降、Dapps に興味を持ったほとんどの開発者は、ビットコインではなく、イーサリアムやその他のシステムを構築することに重点を置きました。その後、イーサリアムは開発者の多くの関心と勢いを獲得しましたが、ビットコインでの Dapp 開発は最小限でした。この投稿の要点は、これの主な要因は必要な手数料ではなく、イーサリアムの仮想マシンやイーサリアムの優れた技術的能力でもありません。ただ、多くのビットコイナーやビットコイン開発者がビットコインでの Dapps を望んでいないだけである、ということを強調することです。ビットコインには興味がない。これらの機能。良くも悪くも、一部のビットコイナーはこれらの Dapp 開発者の多くを意図的に追い出しました。ビットコイン支持者の中には、ほとんどの dapp アクティビティは持続不可能な詐欺に関連している、またはセキュリティやその他の理由からビットコインではそのようなアクティビティは望ましくない、と主張する人もいます。

2014 年以降、多くの人の見方が変わりました。ビットコインが存続するには取引手数料が必要です。 2016 年以降の環境では、フルブロックが多く、手数料が高額になり、あらゆる支払い取引は「正当」であるという認識がより一般的になりました。 Uniswap のような取引所や、AAVE や Compound のような融資プロトコルなど、イーサリアム上の特定の Dapps は、ある程度の成功と興味深いことが証明されています。それでも、ビットコイナーがビットコインのこれらのプロトコルを十分に気にしているかどうか、ましてや実際に誰かがプロトコルを構築して使用しているかどうかは未解決の疑問です。

原文表示
内容は参考用であり、勧誘やオファーではありません。 投資、税務、または法律に関するアドバイスは提供されません。 リスク開示の詳細については、免責事項 を参照してください。
  • 報酬
  • コメント
  • 共有
コメント
0/400
コメントなし
  • ピン
いつでもどこでも暗号資産取引
qrCode
スキャンしてGateアプリをダウンロード
コミュニティ
日本語
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)