Bitcoinは2017年8月にSegWitがアクティベートされました。SegWitはBIP141で定義されています。
SegWitに対応したアドレスの初期フォーマットはBIP142で定義されていたのもでしたが、BIP173が新仕様として採用されています。これがBech32フォーマットです。
そもそもSegWitとは
SegWit導入前の問題点
SegWit導入以前のトランザクションはトランザクション展性（マリアビリティ）があるため問題がありました。
マリアビリティはトランザクションに含める署名データを署名検証が通るものに変更することでトランザクションIDが変更される問題です。
この問題を解決するために、SegWitはトランザクションインプット（txins）に含まれる署名データを新たに作ったwitness部分に移し、署名部分は改ざんされないように常に空にします。txidはwitness部分を使わない以前と同じ方法で導出するので改ざんされなくなります。
詳細なSegWitの説明は下記スライドを見るのが一番理解が早いのでおすすめです。
SegWitは何を解決するのか
上記で説明したマリアビリティの他に、１ブロック当たりに含められるトランザクション数の増加、未署名トランザクションが作れることによるLightningNetworkの実現が可能になりました。
SegWit導入前はブロックのデータサイズが1MBまでしかはいりませんでしたが、SegWit導入後はブロックサイズではなくBlock Wightというものが導入されました。
BlockWeightの計算式は（Witness部分を含まないトランザクション×3) + Witnessを含むトータルのブロックサイズとなりました。これによりWitnessに署名を移すSegWitはトランザクションあたりのweightを抑えてBlock Wightを小さくすることができます。
これはなぞなんですが、最終的なブロックサイズって変わらないんじゃなかと思ったりしてるんですが、Block Weightを基準に考えることでブロックサイズを削減できる理由を説明できる方がいたら教えていただきたいです。
Bech32のフォーマット
本題のBech32ですが、フォーマットの構成はシンプルで下記二つに分けられます。この二つはアドレス内の最後に現れた1をセパレータとして２つに分けます。
- Human Readable Part：mainnetはbc、testnetはtb固定
- Data Part：１文字目がwitness version、最後の6文字がchecksum、それ以外がwitness programといいBIP141で定義されています。
bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4 ← このアドレスを例にするとbcがHuman Readable Part、qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4がData Partです。
さらにqがwitness version、w508d6qejxtdg4y5r3zarvary0c5xw7kがwitness program、v8f3t4がchecksumになります。
エンコード、デコード、checksumの計算方法は後日まとめたいと思います。
髙妻智一
最新記事 by 髙妻智一 (全て見る)
- Polkadot(Substrate)のアドレスとトランザクションについて - 2023-03-09
- 【無料公開】「Goで始めるBitcoin」3章 Bitcoinノードとの通信 技術書典8 - 2020-03-08
- エンジニアがゼロから技術ブログを書くための方法をまとめました - 2019-05-25
コメントを残す