Weight units
'Weight unit' 'は、consensusが強制した最大ブロックサイズ制限に比例して、異なるBitcoinトランザクションのサイズを互いに比較するために使用される測定値です。ウェイト単位は、ブロックヘッダーなど、他のブロックチェーンデータのサイズを測定するためにも使用されます。 Bitcoin Core 0.13.0（2016年8月リリース）<ref> Bitcoin Core 0.13.0リリースノート </ ref>から、各ウェイト単位は1 /ブロックの最大サイズの400万分の1。
'仮想バイト' '（vbytes）とも呼ばれる仮想サイズ' '（vsize）は、1つのvbyteが4つの重み単位に等しい別の測定値です。つまり、vsizeで測定された最大ブロックサイズは100万vbyです。
歴史
Bitcoinは、P2Pプロトコル blockメッセージの最大許容サイズである32Mb（32Mb）という暗黙的な最大ブロックサイズの制限でリリースされました<ref> / code>、 src / main.h：17 </ code>、中本聡（寄稿）、2008年11月（2012年3月10日公開）</ ref>有効ブロック79,400 （2010年9月7日）、これは明示的に1メガバイト（1 MB）に制限されました。<ref> [https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin commit 8c9479c、中本聡、2010年9月7日< / ref>
どちらの場合も、トランザクションやその他のデータがこれらの最大ブロックサイズ制限にどれくらいの割合で集計されたかを計算するには、 P2Pプロトコルの「ブロック」メッセージで使用される形式のデータを入れ、バイト。
2015年後半のソフトフォーク（[segregated witness | segwit]）アイデアの導入<ref> [1]、Pieter Wuille、2015-12-07 </ ref>は、過去のブロックサイズ制限から除外される新しいフィールドでトランザクションフォーマットを拡張できることを意味し、最大ブロックサイズの増加を可能にしました。しかし、この増加は、新しいフィールドが元のトランザクションフォーマットのフィールドよりも最大ブロックサイズに寄与していない場合にのみソフトフォークで可能でした。
一部の人々はそれが不公平であると不満を訴えましたが、Jihan Wu、Twitter.com、2017-05-27は、2017-01- 17 </ ref>、多くのBitcoinプロトコル開発者は、新しいフィールドを有利にするために値引きを行うことを検討していました<ref> [2]、Segwit.org、2017-01-10、検索2017-01-17 </ ref> <ref> -2-or-8-bbcebe91721eなぜ割引係数4？、Segwit.org、2017-01-13、2017-01-17を検索しました。</ ref>新しいフィールドには、トランザクション署名やその他のデータである目撃情報が格納されます特定のビットコインの消費者を認証するために必要です。目撃者は、トランザクションの他の部分とは異なり、処理された後にすべての完全なノードによって格納される必要はないので、ノード操作のコストに影響が少なく、（恐らく）割引を保証する。
特定の取引の特定の分野に対する割引の導入は、割引フィールドを含むトランザクションとそうでないトランザクションとの容易な比較を可能にする「重量単位」の開発を導く。ウェイトユニットは、Segwit起動後に作成されたブロックに以前と同じくらい多くのデータを含めることができますが、Bitcoin Coreの以前のすべてのバージョンと完全に下位互換性があるように設計されています。
以前の「バイト」メトリックを使用したソフトウェアとの下位互換性については、Pieter Wuille、Bitcoin.StackExchange.com、[Pocket]、[Vsize ...]のメリット[3] 2017-08-09、retrieved 2017-01-17 </ ref>、仮想サイズ（vsize）が導入されました。 vsizeの単位は4つの重み単位に等しい。いくつかの開発者は、vbyteの名前でvsizeの単位を呼び出します。<ref> PSA：ブロックエクスプローラでの不正料金、Mark Erhardt、2017-12-12、2017-01-17 </ ref>は、トランザクション内のバイト数とvバイト数が従来のトランザクションで同じであるためです。
レガシートランザクションの重み
分離監視を使用しないトランザクション（segwit）は、現在、「レガシートランザクション」と呼ばれています。これらのトランザクションでは、トランザクション内のウェイト単位の数を計算するのは、P2Pプロトコルの「ブロック」メッセージで使用される形式にトランザクションを置き、バイト数を数え、4を掛けることと同じくらい簡単です。
たとえば、書面（2018年1月）の時点で、ブロックチェーン内で最も一般的に見られるトランザクションテンプレートは、1つの入力（[[圧縮されたpubkey]を持つP2PKHを使用）と2つのP2PKH出力、バイト。そのトランザクションテンプレートのバイトマップは次のとおりです。
バイトからウェイト単位に変更するには、すべてを4倍にスケールアップするだけです。
904の重みでは、ブロック内に上記のトランザクションを含めるには、使用可能な最大ブロック・スペースの0.0226％を消費します。
ウェイト単位をvbyteに変換するには、合計を4で割ってください。レガシートランザクションの場合、これはvbytesがバイトに等しいことを意味します。
segwitトランザクションの重み
分離された目撃者を使用するトランザクションは、「segwitトランザクション」と呼ばれます。これらのトランザクションでは、トランザクション内のウェイト単位の数を計算する方が複雑です。
- トランザクションは、P2Pプロトコルの 'ブロック'メッセージ（segwit対応）によって使用される形式になります。
- segwitマーカー、フラグ、および証人フィールドの各バイトは1つの重み単位としてカウントされます
- トランザクション内の他のフィールドの各バイトは、4つの重み単位
たとえば、上記の「従来の」セクションで分析されたP2PKHトランザクションに相当するsegwitは、1つの入力（P2WPKHを使用）と2つのP2WPKH出力、つまり約222バイトのトランザクションです。このトランザクションテンプレートのバイトマップには、segwit固有のフィールドが青色で強調表示されています。
バイト単位からウェイト単位に変更するには、ハイライトされたフィールドが同じサイズのまま残り、他のフィールドに4が掛けられた上記の方法を使用します。同じ縮尺で表示されると、segwitフィールドが縮小されたように見えます。
上記のトランザクションを1つのブロックに含める561の重量単位で、使用可能な最大ブロック・スペースの0.014025％を消費します。これは、前述の同等の従来のトランザクションと比較して61％の削減です。レガシートランザクションからセグウィットトランザクションへの変換によって節約される正確な領域は、さまざまなトランザクションの詳細によって異なります。
ウェイト単位をvbyteに変換するには、4で除算します。上記の例のトランザクションでは、トランザクションは140.25 vbytesになります。分数vbytesも可能ですが、整数値のみを必要とするレガシーアプリケーションとは互換性がない可能性があるので、<ref> Segwit wallet devガイド：料金見積もり、BitcoinCore.org寄稿者、BitcoinCore.org、2018-01-17 </ ref>を検索して切り上げます。たとえば、Bitcoin Coreは、このトランザクションが141 vbytesのvsizeを持つと報告します。
誤解
おそらく、vbytesのメトリックのために、segwitが何らかの形でトランザクションをもっと小さくするのはよくある誤解ですが、これは間違っています。 300バイトのトランザクションは、300バイトのディスク上およびオーバー・ザ・ワイヤーです。 Segwitは、これらのバイトを、最大ブロックサイズの4Mウェイト単位に向かって別々にカウントします。
バイト単位のブロックの最大サイズは、ブロックウェイト単位の最大サイズとほぼ同じです。したがって、4Mウェイト単位では、ほぼ4Mバイト（4MB）のブロックが許可されます。これは何らかの形で作られたサイズではありません。最大ブロックサイズは実際にはディスク上でおよそ4MB、オーバー・ザ・ワイヤーです。しかし、ブロックが非常に奇妙にフォーマットされたトランザクションでいっぱいである場合にのみ、この最大値に達することができるので、通常は見られません。
ブロックの典型的なサイズは、そのブロック内のトランザクションの構成に依存します。 2017年時点で、平均トランザクション構成は、すべてのトランザクションがセグジットトランザクションであった場合、4Mの重量単位のブロックが約2.3MBのブロックにつながります。
詳細な例
このトランザクションを考えてみましょう：
0100000000010115e180dc28a2327e687facc33f10f2a20da717e5548406f7ae8b4c8 11072f85603000000171600141d7cd6c75c2e86f4cbf98ea221b30bd9a0b928ffff ffff019caef505000000001976a9141d7cd6c75c2e86f4cbf98eaed221b30bd9a0b92 888ac02483045022100f764287d3e99b1474da9bec7f7ed236d6c81e793b20c4b5aa1 f3051b9a7daa63022016a198031d5554dbb855bdbe8534776a4be6958bd8d530dc001 c32b828f6f0ab0121038262a6c6cec93c2d3ecd6c6072efea86d02ff8e3328bbd0242 b20af3425990ac00000000 </ pre>
| -
！データ ！説明 ！生のバイト数 ！タイプ（乗数） ！セクション合計重量 ！総重量の積算 |
- | 01000000 </ tt> | バージョン1 | 4 | 非証人（4倍） | 16 | 16 | - | <tt> 00 </ tt> | SegWitマーカー | 1 | 証人（1倍） | 1 | 17 | - | <tt> 01 </ tt> | SegWitフラグ | 1 | 証人（1倍） | 1 | 18 | - | <tt> 01 </ tt> | 入力数（1） | 1 | 非証人（4倍） | 4 | 22 | - | <tt> 15..56 </ tt> | 以前の出力ハッシュ | 32 | 非証人（4倍） | 128 | 150 | - | <tt> 03000000 </ tt> | 以前の出力指数（3） | 4 | 非証人（4倍） | 16 | 166 | - | <tt> 17 </ tt> | スクリプトの長さ（23バイト） | 1 | 非証人（4倍） | 4 | 170 | - | <tt> 16..28 </ tt> | スクリプト：P2SHで囲まれたP2WPKH証人プログラム | 23 | 非証人（4倍） | 92 | 262 | - | <tt> ffffffff </ tt> | シーケンス | 4 | 非証人（4倍） | 16 | 278 | - | <tt> 01 </ tt> | 出力回数（1） | 1 | 非証人（4倍） | 4 | 282 | - | <tt> 9caef50500000000 </ tt> | 出力値（0.99987100 BTC） | 8 | 非証人（4倍） | 32 | 314 | - | <tt> 19 </ tt> | 出力スクリプトサイズ（25） | 1 | 非証人（4倍） | 4 | 318 | - | <tt> 76..ac </ tt> | スクリプト：DUP HASH160 0x1d7c ... EQUALVERIFY CHECKSIG | 25 | 非証人（4倍） | 100 | 418 | - | <tt> 02 </ tt> | 入力用スタック項目数0（2） | 1 | 証人（1倍） | 1 | 419 | - | <tt> 48 </ tt> | スタック項目のサイズ0（72） | 1 | 証人（1倍） | 1 | 420 | - | <tt> 304 ... ab01 </ tt> | スタックアイテム0、署名 | 72 | 証人（1倍） | 72 | 492 | - | <tt> 21 </ tt> | スタックアイテム1のサイズ（33） | 1 | 証人（1倍） | 1 | 493 | - | <tt> 03..ac </ tt> | スタックアイテム1、pubkey | 33 | 証人（1倍） | 33 | 526 | - | <tt> 00000000 </ tt> | ロックタイム（0） | 4 | 非証人（4倍） | 16 | 542 |
ディスク上およびネットワーク上のトランザクションの実際のサイズは218バイトです。これは、上に示したトランザクション全体のバイト単位のサイズ（16進数）です。重量は常に実際のサイズより大きく、この場合542重量単位です。 vbytesのサイズは135.5です。
参考文献
<リファレンス/>
