サトシ・ナカモトがトランザクションデータ構造とブロックデータ構造にバージョン番号を追加したのはなぜですか?

第0章はじめに

HTML5 の 5 が何の略かご存知ですか?答えは、これはバージョン番号であるということです。 HTML はハイパーテキストマークアップ言語と呼ばれ、バージョン 2.0、3.2、4.0、4.01、5 が存在します。

ビットコインのコードにもバージョン番号があり、現在はサトシ・ナカモトが開発した当時と同じバージョン 1 です。

第1章ビットコイン取引データ構造におけるバージョン番号

ビットコインのブロックデータ構造とトランザクションデータ構造を再度移動する必要があります。写真をご覧ください。

この図はビットコインのトランザクションデータ構造です。図の太字の赤色のフィールドは、HTML5 の 5 に似た、トランザクションバージョンを識別するコードです。

サトシ・ナカモトがブロックチェーンを開発した頃から現在に至るまで、トランザクションバージョン番号は変わっていませんが、ブロックバージョン番号は何度か変更されています。 (著者注: ブロックのバージョン番号は変更されており、現在はビジョン 5 です)

第2章ビットコインのトランザクションバージョン番号は何のために使用されるのか？

これら 2 つのバージョン番号は、参照ルールを識別するために使用されます。これは HTML5 と同じで、データ参照を伝播するためのルールを識別するためにフィールドも使用します。

ソフトウェアであるため、必ず進化し、新しい機能を追加する必要があります。ビットコインは登場してほぼ 8 年になりますが、トランザクションとブロックのデータ構造は実際に大きく変化しました。ソフトフォークとハードフォークは数多くありました。しかし、バージョン番号は変更されていません。

ブロックチェーン全体のトランザクションのバージョン番号は同じです。つまり、ソフトウェアレベルではすべてが同じであると認識されます。取引ルールに大きな変更を加える場合、バージョン番号を変更する必要がありますか?

ソフトウェア業界の一般的な慣行を変更する必要があります。 HTML と同様に、これはネットワーク全体のルールが変更されたことを意味します。データ構造を変更しても、以前のブロックやトランザクションに通知しない場合は、それを回避するにはより複雑な設計が必要になります。

データ構造のバージョンが異なると、解析に異なるコードが必要になります。開発者がトランザクションを大幅に変更することを決定した場合、このコードアップグレードのルールが変更されたことを明確にするためにバージョン番号を変更するのが賢明です。その後、ビットコインネットワークでアップグレードがアクティブになると、ビットコインネットワークは古いバージョン番号を解析するソフトウェアを凍結し、新しいブロックと新しいトランザクションデータ構造を解析するために最新のコードにアップグレードすることを要求する必要が生じます。このアップグレード方法は明確であり、新しいソフトウェアと古いソフトウェアが互いに欺く必要はなく、全員が同じ目標を持ちます。このタイプのアップグレードはハードフォークとも呼ばれます。

このバージョン番号のデザインはサトシ・ナカモトが残したもので、これはサトシ・ナカモトがハードフォークを通じてソフトウェアをアップグレードしたいと考えていたことを意味します。しかし、私たちのコア開発チームは、サトシ・ナカモトの設計意図に違反し、ソフトウェア業界の一般的な設計仕様に違反しました。コードを変更するたびにソフトフォークを使用します。

ソフトフォークはトランザクションのバージョン番号を変更しませんが、トランザクションのデータ構造を変更します。バージョン番号が変更されていないため、古いノードソフトウェアも変更されたトランザクションを解析しようとします。古いノードが変更されたデータ構造を解析できるようにするには、変更全体が非常に複雑になります。この複雑さにより、技術的負債が発生します。

第3章: 分離証人ソフトフォークは無限の技術的負債を生み出す

Segregated Witness ソフトフォークは、ビットコインのトランザクションデータ構造とブロックデータ構造を大幅に変更します。トランザクションデータ構造内のロック解除スクリプトフィールドをトランザクションデータ構造から直接移動し、ブロックデータ構造からも移動します。

このような大きな変更ではトランザクションのバージョン番号は変更されません。つまり、分離された証人は、ブロックとトランザクションを変更したことを古いノードに通知するつもりはありません。代わりに、変更されたコードを非表示にして、古いノードがこれを解析可能なコードであると想定するスキームです。もちろん、実際の運用の複雑さは恐ろしいものです。 Segregated Witness のドキュメントを見ると、彼はビットコインのトランザクションとブロックのデータ構造に合計 11 の変更を加えました。

これはどれくらい怖いですか?

サトシ・ナカモトは2008年にビットコインのホワイトペーパーを公開し、その後2009年初頭にビットコインソフトウェアの最初のバージョンの開発を完了し、ジェネシスブロックをマイニングするためにネットワーク上にリリースしました。全体の開発には 1 年もかからなかったようです。そして私たちは皆、サトシ・ナカモトがそれを一人で開発していると思っていました。

しかし、SegWit はどうでしょうか? 2015 年 12 月に香港スケーリングカンファレンスで Peter Wuille 氏が Segregated Witness ソリューションを提案してから、現在は 2016 年 10 月です。SegWit は開発開始からほぼ 1 年が経過しています。しかし、まだ終わりではありません。 Core devコア開発チームの開発力は、人材、物的資源、資金のいずれの面でも、当時孤独に戦っていたサトシ・ナカモトのそれをはるかに上回っていることを知っておくべきです。しかし、サトシ・ナカモトが開発したビットコインに基づいて修正を加えるには、サトシ・ナカモトがビットコインプロジェクト全体を開発するのにかかった時間よりも長い時間がかかります。

これは、分離された証人がいかに複雑であるかを示しています。

複雑さは不安をもたらします。

さらに恐ろしいのは、Segregated Witness が起動すると、何か問題が発生した場合、緊急時対応計画がなく、このような複雑なコードに対処する方法がないことです。少なくともコア開発チームはまだこれについて言及していません。これは非常に無責任です。

第4章: Bitcoin Classic開発者によるBitcoinプロトコルのアップグレード提案

以下は、Bitcoin Classic 開発者の Tom Zander が Bitcoin プロトコルのアップグレードについて語る短いビデオです。トムはまず、従来のソフトウェア業界の慣行について話し、次にビットコインプロトコルをアップグレードする簡単な方法について話しました。孤立した証人の問題について特別なコメントがなされた。

この記事をビデオで締めくくりましょう。中国語の字幕を付けました。