「Weight units」の版間の差分

提供: tezos-wiki
移動先: 案内、 検索
細 (1版 をインポートしました)
1行目: 1行目:
  
−
'''Weight units''' are a measurement used to compare the size of different Bitcoin transactions to each other in proportion to the [[consensus]]-enforced [[maximum block size limit]].  Weight units are also used to measure the size of other block chain data, such as [[block headers]].  As of Bitcoin Core 0.13.0 (released August 2016)<ref>[https://bitcoincore.org/en/releases/0.13.0/ Bitcoin Core 0.13.0 release notes]</ref>, each weight unit represents 1/4,000,000th of the maximum size of a block.
+
'' 'Weight unit' 'は、[[consensus]]が強制した[[最大ブロックサイズ制限]]に比例して、異なるBitcoinトランザクションのサイズを互いに比較するために使用される測定値です。ウェイト単位は、[[ブロックヘッダー]]など、他のブロックチェーンデータのサイズを測定するためにも使用されます。 Bitcoin Core 0.13.0（2016年8月リリース）<ref> [https://bitcoincore.org/en/releases/0.13.0/ Bitcoin Core 0.13.0リリースノート] </ ref>から、各ウェイト単位は1 /ブロックの最大サイズの400万分の1。
  
−
'''Virtual size''' (vsize), also called '''virtual bytes''' (vbytes), are an alternative measurement, with one vbyte being equal to four weight units.  That means the maximum block size measured in vsize is 1 million vbytes.
+
'' '仮想バイト' '（vbytes）とも呼ばれる仮想サイズ' '（vsize）は、1つのvbyteが4つの重み単位に等しい別の測定値です。つまり、vsizeで測定された最大ブロックサイズは100万vbyです。
  
−
== History ==
+
==歴史==
  
−
Bitcoin was released with an implicit maximum block size limit of 32 mibibytes (32 MiB), which was the maximum allowed size of a P2P protocol [[Protocol_documentation#block|block]] message.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], <code>src/main.h:17</code>, Satoshi Nakamoto (attributed), November 2008 (published 10 March 2012)</ref> Effective block 79,400 (7 September 2010), this became an explicit limit of 1 megabyte (1 MB).<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref>
+
Bitcoinは、P2Pプロトコル[[Protocol_documentation＃block | block]]メッセージの最大許容サイズである32Mb（32Mb）という暗黙的な最大ブロックサイズの制限でリリースされました<ref> [https://bitcointalk.org / code>、<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>
  
−
In both cases, to calculate how much a transaction or other data counted towards these maximum block size limits, you simply put the data in the format used by the [[Protocol documentation|P2P protocol's]] ''block'' message and counted the bytes.
+
どちらの場合も、トランザクションやその他のデータがこれらの最大ブロックサイズ制限にどれくらいの割合で集計されたかを計算するには、[[プロトコルドキュメント| P2Pプロトコル]]の「ブロック」メッセージで使用される形式のデータを入れ、バイト。
  
−
The introduction of a soft-fork [[Segregated Witness|segregated witness]] (segwit) idea in late 2015<ref>[https://youtu.be/fst1IK_mrng?t=36m Segregated witness and its impact on scalability (presentation video)], Pieter Wuille, 2015-12-07</ref> meant that the transaction format could be extended with new fields that would be excluded from the historic block size limits—allowing an increase in the maximum block size. But that increase was only possible in a [[Softfork|soft fork]] if the new fields contributed less towards the maximum block size than the fields in the original transaction format.
+
2015年後半のソフトフォーク（[segregated witness | segwit]）アイデアの導入<ref> [https://youtu.be/fst1IK_mrng?t=36m分離された証人とそのスケーラビリティへの影響（プレゼンテーションビデオ）]、Pieter Wuille、2015-12-07 </ ref>は、過去のブロックサイズ制限から除外される新しいフィールドでトランザクションフォーマットを拡張できることを意味し、最大ブロックサイズの増加を可能にしました。しかし、この増加は、新しいフィールドが元のトランザクションフォーマットのフィールドよりも最大ブロックサイズに寄与していない場合にのみ[[Softfork |ソフトフォーク]]で可能でした。
  
−
Although some people complained about that being unfair<ref>[https://twitter.com/JihanWu/status/868896110760181760 SegWit tx is unfairly cheap], Jihan Wu, Twitter.com, 2017-05-27, retrieved 2017-01-17</ref>, many Bitcoin Protocol developers considered discounting the new fields to be advantageous.<ref>[https://segwit.org/what-is-behind-the-segwit-discount-8515a8d3bca9 What is behind the segwit discount?], Segwit.org, 2017-01-10, retrieved 2017-01-17</ref><ref>[https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e Why a discount factor of 4?], Segwit.org, 2017-01-13, retrieved 2017-01-17</ref> The new fields store witnesses, which are transaction signatures and other data necessary to authenticate the spender of certain bitcoins.  Witnesses do not need to be stored by all full nodes after they are processed, unlike other parts of a transaction, so they have less effect on the [[cost of node operation]] and (arguably) warrant a discount.
+
一部の人々はそれが不公平であると不満を訴えましたが、Jihan Wu、Twitter.com、2017-05-27は、2017-01- 17 </ ref>、多くのBitcoinプロトコル開発者は、新しいフィールドを有利にするために値引きを行うことを検討していました<ref> [https://segwit.org/what-is-behind-the-segwit-discount-8515a8d3bca9セグウィットディスカウントの背景？]、Segwit.org、2017-01-10、検索2017-01-17 </ ref> <ref> [https://segwit.org/why-a-discount-factor-of-4-why-not -2-or-8-bbcebe91721eなぜ割引係数4？]、Segwit.org、2017-01-13、2017-01-17を検索しました。</ ref>新しいフィールドには、トランザクション署名やその他のデータである目撃情報が格納されます特定のビットコインの消費者を認証するために必要です。目撃者は、トランザクションの他の部分とは異なり、処理された後にすべての完全なノードによって格納される必要はないので、[[ノード操作のコスト]]に影響が少なく、（恐らく）割引を保証する。
  
−
This introduction of a discount for certain fields in certain transactions lead to the development of the ''weight unit'' which allows easy comparison between transactions that contain the discounted fields and those that don't.  Weight units were designed to be fully backwards compatible with all previous versions of Bitcoin Core even though blocks created after segwit activated may include up to almost four times as much data as they could previously.
+
特定の取引の特定の分野に対する割引の導入は、割引フィールドを含むトランザクションとそうでないトランザクションとの容易な比較を可能にする「重量単位」の開発を導く。ウェイトユニットは、Segwit起動後に作成されたブロックに以前と同じくらい多くのデータを含めることができますが、Bitcoin Coreの以前のすべてのバージョンと完全に下位互換性があるように設計されています。
  
−
For backwards compatibility with software using the earlier ''bytes'' metric<ref>[https://bitcoin.stackexchange.com/a/57800 The advantage of using vsize...], Pieter Wuille, Bitcoin.StackExchange.com, 2017-08-09, retrieved 2017-01-17</ref>, virtual size (vsize) was introduced.  A unit of vsize is equal to four weight units.  Some developers call a unit of vsize by the name of vbyte<ref>[https://medium.com/@murchandamus/psa-wrong-fee-rates-on-block-explorers-48390cbfcc74 PSA: Wrong fee rates on block explorers], Mark Erhardt, 2017-12-12, retrieved 2017-01-17</ref> because the number of bytes and vbytes in a transaction are identical for legacy transactions.
+
以前の「バイト」メトリックを使用したソフトウェアとの下位互換性については、Pieter Wuille、Bitcoin.StackExchange.com、[Pocket]、[Vsize ...]のメリット[https://bitcoin.stackexchange.com/a/57800] 2017-08-09、retrieved 2017-01-17 </ ref>、仮想サイズ（vsize）が導入されました。 vsizeの単位は4つの重み単位に等しい。いくつかの開発者は、vbyteの名前でvsizeの単位を呼び出します。<ref> [https://medium.com/@murchandamus/psa-wrong-fee-rates-on-block-explorers-48390cbfcc74 PSA：ブロックエクスプローラでの不正料金]、Mark Erhardt、2017-12-12、2017-01-17 </ ref>は、トランザクション内のバイト数とvバイト数が従来のトランザクションで同じであるためです。
  
−
== Weight for legacy transactions ==
+
==レガシートランザクションの重み==
  
−
Transactions that don't use segregated witness (segwit) are currently called ''legacy transactions''.  For these transactions, calculating the number of weight units in a transaction is as easy as putting the transaction into the format used in a P2P protocol ''block'' message, counting the number of bytes, and multiplying by four.
+
分離監視を使用しないトランザクション（segwit）は、現在、「レガシートランザクション」と呼ばれています。これらのトランザクションでは、トランザクション内のウェイト単位の数を計算するのは、P2Pプロトコルの「ブロック」メッセージで使用される形式にトランザクションを置き、バイト数を数え、4を掛けることと同じくらい簡単です。
  
−
For example, at the time of writing (January 2018), the most commonly seen transaction template in the block chain is a legacy transaction with one input (using P2PKH with a [[compressed pubkey]]) and two P2PKH outputs, or about 226 bytes.  Here's a byte map of that transaction template:
+
たとえば、書面（2018年1月）の時点で、ブロックチェーン内で最も一般的に見られるトランザクションテンプレートは、1つの入力（[[圧縮されたpubkey]を持つP2PKHを使用）と2つのP2PKH出力、バイト。そのトランザクションテンプレートのバイトマップは次のとおりです。
  
−
[[File:p2pkh-1in-2out_bytes.png|center]]
+
[[File：p2pkh-1in-2out_bytes.png | center]]
  
−
To change from bytes to weight units, we simply scale everything up by a factor of four:
+
バイトからウェイト単位に変更するには、すべてを4倍にスケールアップするだけです。
  
−
[[File:p2pkh-1in-2out_weight.png|center]]
+
[[File：p2pkh-1in-2out_weight.png | center]]
  
−
At 904 weight, to include the above transaction in a block consumes 0.0226% of the available maximum block space.
+
904の重みでは、ブロック内に上記のトランザクションを含めるには、使用可能な最大ブロック・スペースの0.0226％を消費します。
  
−
To convert from weight units to vbytes, divide the total by four.  For legacy transactions, this means that vbytes are equal to bytes.
+
ウェイト単位をvbyteに変換するには、合計を4で割ってください。レガシートランザクションの場合、これはvbytesがバイトに等しいことを意味します。
  
−
== Weight for segwit transactions ==
+
== segwitトランザクションの重み==
  
−
Transactions that use segregated witnesses are called ''segwit transactions.''  For these transactions, calculating the number of weight units in a transaction is more complicated.
+
分離された目撃者を使用するトランザクションは、「segwitトランザクション」と呼ばれます。これらのトランザクションでは、トランザクション内のウェイト単位の数を計算する方が複雑です。
  
−
* The transaction is put into the format used by a P2P protocol ''block'' message (segwit-enabled)
+
*トランザクションは、P2Pプロトコルの 'ブロック'メッセージ（segwit対応）によって使用される形式になります。
−
* Each byte of the segwit marker, flag, and witness fields counts as one weight unit
+
* segwitマーカー、フラグ、および証人フィールドの各バイトは1つの重み単位としてカウントされます
−
* Each byte of the other fields in the transaction counts as four weight units
+
*トランザクション内の他のフィールドの各バイトは、4つの重み単位
  
−
For example, the segwit equivalent to the P2PKH transaction analyzed in the ''legacy'' section above would be a transaction with one input (using P2WPKH) and two P2WPKH outputs, or about 222 bytes.  Here's a byte map of that transaction template with the segwit-specific fields highlighted in blue:
+
たとえば、上記の「従来の」セクションで分析されたP2PKHトランザクションに相当するsegwitは、1つの入力（P2WPKHを使用）と2つのP2WPKH出力、つまり約222バイトのトランザクションです。このトランザクションテンプレートのバイトマップには、segwit固有のフィールドが青色で強調表示されています。
  
−
[[File:p2wpkh-1in-2out_bytes.png|center]]
+
[[File：p2wpkh-1in-2out_bytes.png | center]]
  
−
To change from bytes to weight units, we use the method described above where the highlighted fields stay the same size but the other fields are multiplied by four.  When displayed at the same scale, this makes it appear that the segwit fields have shrunk:
+
バイト単位からウェイト単位に変更するには、ハイライトされたフィールドが同じサイズのまま残り、他のフィールドに4が掛けられた上記の方法を使用します。同じ縮尺で表示されると、segwitフィールドが縮小されたように見えます。
  
−
[[File:p2wpkh-1in-2out_weight.png|center]]
+
[[File：p2wpkh-1in-2out_weight.png | center]]
  
−
At 561 weight units, to include the above transaction in a block consumes 0.014025% of the available maximum block space, a 61% reduction compared to the equivalent legacy transaction described previously.  The exact amount of space saved by converting from legacy transactions to segwit transactions will vary depending on various transaction details.
+
上記のトランザクションを1つのブロックに含める561の重量単位で、使用可能な最大ブロック・スペースの0.014025％を消費します。これは、前述の同等の従来のトランザクションと比較して61％の削減です。レガシートランザクションからセグウィットトランザクションへの変換によって節約される正確な領域は、さまざまなトランザクションの詳細によって異なります。
  
−
To convert from weight units to vbytes, divide by four.  For the example transaction above, this makes the transaction 140.25 vbytes.  Note that fractional vbytes are possible, but they may not be compatible with legacy applications that expect only integer values, so it is recommended<ref>[https://bitcoincore.org/en/segwit_wallet_dev/#transaction-fee-estimation Segwit wallet dev guide: fee estimation], BitcoinCore.org contributors, BitcoinCore.org, retrieved 2018-01-17</ref> to round up.  For example, Bitcoin Core reports this transaction as having a vsize of 141 vbytes.
+
ウェイト単位をvbyteに変換するには、4で除算します。上記の例のトランザクションでは、トランザクションは140.25 vbytesになります。分数vbytesも可能ですが、整数値のみを必要とするレガシーアプリケーションとは互換性がない可能性があるので、<ref> [https://bitcoincore.org/en/segwit_wallet_dev/#transaction-fee-estimation Segwit wallet devガイド：料金見積もり]、BitcoinCore.org寄稿者、BitcoinCore.org、2018-01-17 </ ref>を検索して切り上げます。たとえば、Bitcoin Coreは、このトランザクションが141 vbytesのvsizeを持つと報告します。
  
−
== Misconceptions ==
+
==誤解==
  
−
Possibly because of the vbytes metric, it is a common misconception that segwit somehow makes transactions much smaller—but this is incorrect. A 300-byte transaction is 300 bytes on-disk and over-the-wire. Segwit just counts those bytes differently toward the maximum block size of 4M weight units.
+
おそらく、vbytesのメトリックのために、segwitが何らかの形でトランザクションをもっと小さくするのはよくある誤解ですが、これは間違っています。 300バイトのトランザクションは、300バイトのディスク上およびオーバー・ザ・ワイヤーです。 Segwitは、これらのバイトを、最大ブロックサイズの4Mウェイト単位に向かって別々にカウントします。
  
−
The maximum size of a block in bytes is nearly equal in number to the maximum amount of block weight units, so 4M weight units allows a block of almost 4M bytes (4MB). This is not a somehow "made-up" size; the maximum block size is really almost 4MB on-disk and over-the-wire. However, this maximum can only be reached if the block is full of very weirdly-formatted transactions, so it should not usually be seen.
+
バイト単位のブロックの最大サイズは、ブロックウェイト単位の最大サイズとほぼ同じです。したがって、4Mウェイト単位では、ほぼ4Mバイト（4MB）のブロックが許可されます。これは何らかの形で作られたサイズではありません。最大ブロックサイズは実際にはディスク上でおよそ4MB、オーバー・ザ・ワイヤーです。しかし、ブロックが非常に奇妙にフォーマットされたトランザクションでいっぱいである場合にのみ、この最大値に達することができるので、通常は見られません。
  
−
The typical size of a block depends on the make-up of transactions in that block. As of 2017, the average transaction make-up would lead to blocks with 4M weight units being about 2.3MB in size if all transactions were segwit transactions.
+
ブロックの典型的なサイズは、そのブロック内のトランザクションの構成に依存します。 2017年時点で、平均トランザクション構成は、すべてのトランザクションがセグジットトランザクションであった場合、4Mの重量単位のブロックが約2.3MBのブロックにつながります。
 +
===詳細な例===
  
−
===Detailed example===
+
このトランザクションを考えてみましょう：
  
−
Consider this transaction:
+
<pre> 0100000000010115e180dc28a2327e687facc33f10f2a20da717e5548406f7ae8b4c8
−
 
+
11072f85603000000171600141d7cd6c75c2e86f4cbf98ea221b30bd9a0b928ffff
−
<pre>0100000000010115e180dc28a2327e687facc33f10f2a20da717e5548406f7ae8b4c8
 
−
11072f85603000000171600141d7cd6c75c2e86f4cbf98eaed221b30bd9a0b928ffff
 
 
ffff019caef505000000001976a9141d7cd6c75c2e86f4cbf98eaed221b30bd9a0b92
 
ffff019caef505000000001976a9141d7cd6c75c2e86f4cbf98eaed221b30bd9a0b92
 
888ac02483045022100f764287d3e99b1474da9bec7f7ed236d6c81e793b20c4b5aa1
 
888ac02483045022100f764287d3e99b1474da9bec7f7ed236d6c81e793b20c4b5aa1
 
f3051b9a7daa63022016a198031d5554dbb855bdbe8534776a4be6958bd8d530dc001
 
f3051b9a7daa63022016a198031d5554dbb855bdbe8534776a4be6958bd8d530dc001
 
c32b828f6f0ab0121038262a6c6cec93c2d3ecd6c6072efea86d02ff8e3328bbd0242
 
c32b828f6f0ab0121038262a6c6cec93c2d3ecd6c6072efea86d02ff8e3328bbd0242
−
b20af3425990ac00000000</pre>
+
b20af3425990ac00000000 </ pre>
  
 
{|
 
{|
−
|-
+
| -  
−
! Data
+
！データ
−
! Description
+
！説明
−
! Raw byte count
+
！生のバイト数
−
! Type (multiplier)
+
！タイプ（乗数）
−
! Section total weight
+
！セクション合計重量
−
! Running total weight
+
！総重量の積算
−
|-
+
| -  
−
| <tt>01000000</tt>
+
| <tt> 01000000 </ tt>
−
| Version 1
+
|バージョン1
 
| 4
 
| 4
−
| Non-witness (4x)
+
|非証人（4倍）
 
| 16
 
| 16
 
| 16
 
| 16
−
|-
+
| -  
−
| <tt>00</tt>
+
| <tt> 00 </ tt>
−
| SegWit marker
+
| SegWitマーカー
 
| 1
 
| 1
−
| Witness (1x)
+
|証人（1倍）
 
| 1
 
| 1
 
| 17
 
| 17
−
|-
+
| -  
−
| <tt>01</tt>
+
| <tt> 01 </ tt>
−
| SegWit flag
+
| SegWitフラグ
 
| 1
 
| 1
−
| Witness (1x)
+
|証人（1倍）
 
| 1
 
| 1
 
| 18
 
| 18
−
|-
+
| -  
−
| <tt>01</tt>
+
| <tt> 01 </ tt>
−
| Number of inputs (1)
+
|入力数（1）
 
| 1
 
| 1
−
| Non-witness (4x)
+
|非証人（4倍）
 
| 4
 
| 4
 
| 22
 
| 22
−
|-
+
| -  
−
| <tt>15..56</tt>
+
| <tt> 15..56 </ tt>
−
| Previous output hash
+
|以前の出力ハッシュ
 
| 32
 
| 32
−
| Non-witness (4x)
+
|非証人（4倍）
 
| 128
 
| 128
 
| 150
 
| 150
−
|-
+
| -  
−
| <tt>03000000</tt>
+
| <tt> 03000000 </ tt>
−
| Previous output index (3)
+
|以前の出力指数（3）
 
| 4
 
| 4
−
| Non-witness (4x)
+
|非証人（4倍）
 
| 16
 
| 16
 
| 166
 
| 166
−
|-
+
| -  
−
|<tt>17</tt>
+
| <tt> 17 </ tt>
−
| Script length (23 bytes)
+
|スクリプトの長さ（23バイト）
 
| 1
 
| 1
−
| Non-witness (4x)
+
|非証人（4倍）
 
| 4
 
| 4
 
| 170
 
| 170
−
|-
+
| -  
−
|<tt>16..28</tt>
+
| <tt> 16..28 </ tt>
−
| Script: P2SH-enclosed P2WPKH witness program
+
|スクリプト：P2SHで囲まれたP2WPKH証人プログラム
 
| 23
 
| 23
−
| Non-witness (4x)
+
|非証人（4倍）
 
| 92
 
| 92
 
| 262
 
| 262
−
|-
+
| -  
−
|<tt>ffffffff</tt>
+
| <tt> ffffffff </ tt>
−
| Sequence
+
|シーケンス
 
| 4
 
| 4
−
| Non-witness (4x)
+
|非証人（4倍）
 
| 16
 
| 16
 
| 278
 
| 278
−
|-
+
| -  
−
|<tt>01</tt>
+
| <tt> 01 </ tt>
−
| Output count (1)
+
|出力回数（1）
 
| 1
 
| 1
−
| Non-witness (4x)
+
|非証人（4倍）
 
| 4
 
| 4
 
| 282
 
| 282
−
|-
+
| -  
−
|<tt>9caef50500000000</tt>
+
| <tt> 9caef50500000000 </ tt>
−
| Output value (0.99987100 BTC)
+
|出力値（0.99987100 BTC）
 
| 8
 
| 8
−
| Non-witness (4x)
+
|非証人（4倍）
 
| 32
 
| 32
 
| 314
 
| 314
−
|-
+
| -  
−
|<tt>19</tt>
+
| <tt> 19 </ tt>
−
| Output script size (25)
+
|出力スクリプトサイズ（25）
 
| 1
 
| 1
−
| Non-witness (4x)
+
|非証人（4倍）
 
| 4
 
| 4
 
| 318
 
| 318
−
|-
+
| -  
−
|<tt>76..ac</tt>
+
| <tt> 76..ac </ tt>
−
| Script: DUP HASH160 0x1d7c... EQUALVERIFY CHECKSIG
+
|スクリプト：DUP HASH160 0x1d7c ... EQUALVERIFY CHECKSIG
 
| 25
 
| 25
−
| Non-witness (4x)
+
|非証人（4倍）
 
| 100
 
| 100
 
| 418
 
| 418
−
|-
+
| -  
−
|<tt>02</tt>
+
| <tt> 02 </ tt>
−
| Number of stack items for input 0 (2)
+
|入力用スタック項目数0（2）
 
| 1
 
| 1
−
| Witness (1x)
+
|証人（1倍）
 
| 1
 
| 1
 
| 419
 
| 419
−
|-
+
| -  
−
|<tt>48</tt>
+
| <tt> 48 </ tt>
−
| Size of stack item 0 (72)
+
|スタック項目のサイズ0（72）
 
| 1
 
| 1
−
| Witness (1x)
+
|証人（1倍）
 
| 1
 
| 1
 
| 420
 
| 420
−
|-
+
| -  
−
|<tt>304...ab01</tt>
+
| <tt> 304 ... ab01 </ tt>
−
| Stack item 0, signature
+
|スタックアイテム0、署名
 
| 72
 
| 72
−
| Witness (1x)
+
|証人（1倍）
 
| 72
 
| 72
 
| 492
 
| 492
−
|-
+
| -  
−
|<tt>21</tt>
+
| <tt> 21 </ tt>
−
| Size of stack item 1 (33)
+
|スタックアイテム1のサイズ（33）
 
| 1
 
| 1
−
| Witness (1x)
+
|証人（1倍）
 
| 1
 
| 1
 
| 493
 
| 493
−
|-
+
| -  
−
|<tt>03..ac</tt>
+
| <tt> 03..ac </ tt>
−
| Stack item 1, pubkey
+
|スタックアイテム1、pubkey
 
| 33
 
| 33
−
| Witness (1x)
+
|証人（1倍）
 
| 33
 
| 33
 
| 526
 
| 526
−
|-
+
| -  
−
|<tt>00000000</tt>
+
| <tt> 00000000 </ tt>
−
| Locktime (0)
+
|ロックタイム（0）
 
| 4
 
| 4
−
| Non-witness (4x)
+
|非証人（4倍）
 
| 16
 
| 16
 
| 542
 
| 542
 
|}
 
|}
  
−
The transaction's real size on disk and over the network is 218 bytes, which is the size in bytes of the whole transaction expressed above in hexadecimal. The weight is always greater than the real size, in this case 542 weight units.  The size in vbytes would be 135.5.
+
ディスク上およびネットワーク上のトランザクションの実際のサイズは218バイトです。これは、上に示したトランザクション全体のバイト単位のサイズ（16進数）です。重量は常に実際のサイズより大きく、この場合542重量単位です。 vbytesのサイズは135.5です。
  
−
== References ==
+
==参考文献==
  
−
<references />
+
<リファレンス/>
  
−
[[Category:Technical]]
+
[[Category：技術]]

2018年4月13日 (金) 02:02時点における版

'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出力、バイト。そのトランザクションテンプレートのバイトマップは次のとおりです。

center

バイトからウェイト単位に変更するには、すべてを4倍にスケールアップするだけです。

center

904の重みでは、ブロック内に上記のトランザクションを含めるには、使用可能な最大ブロック・スペースの0.0226％を消費します。

ウェイト単位をvbyteに変換するには、合計を4で割ってください。レガシートランザクションの場合、これはvbytesがバイトに等しいことを意味します。

segwitトランザクションの重み

分離された目撃者を使用するトランザクションは、「segwitトランザクション」と呼ばれます。これらのトランザクションでは、トランザクション内のウェイト単位の数を計算する方が複雑です。

  • トランザクションは、P2Pプロトコルの 'ブロック'メッセージ（segwit対応）によって使用される形式になります。
  • segwitマーカー、フラグ、および証人フィールドの各バイトは1つの重み単位としてカウントされます
  • トランザクション内の他のフィールドの各バイトは、4つの重み単位

たとえば、上記の「従来の」セクションで分析されたP2PKHトランザクションに相当するsegwitは、1つの入力（P2WPKHを使用）と2つのP2WPKH出力、つまり約222バイトのトランザクションです。このトランザクションテンプレートのバイトマップには、segwit固有のフィールドが青色で強調表示されています。

center

バイト単位からウェイト単位に変更するには、ハイライトされたフィールドが同じサイズのまま残り、他のフィールドに4が掛けられた上記の方法を使用します。同じ縮尺で表示されると、segwitフィールドが縮小されたように見えます。

center

上記のトランザクションを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です。



参考文献


<リファレンス/>

Category：技術

「http://tezos-wiki.jp/wiki/index.php?title=Weight_units&oldid=19656」から取得