在交易的默克爾樹中散列的數據範例
所以我在比特幣默克爾樹上閱讀這個（優秀的資源）進行交易。
默克爾樹是自下而上建構的。在下面的範例中，我們從四個事務開始，A、B、C 和 D，它們構成 merkle 樹的葉子，如計算 merkle 樹中的節點所示。交易不儲存在默克爾樹中；相反，它們的數據經過雜湊處理，生成的雜湊值以 HA、HB、HC 和 HD 的形式儲存在每個葉節點中：
HA = SHA256(SHA256(Transaction A))然後通過連接兩個散列並將它們散列在一起，在父節點中匯總連續的葉節點對。例如，要構造父節點 HAB，將子節點的兩個 32 字節雜湊連接起來創建一個 64 字節字元串。然後對該字元串進行雙重雜湊以生成父節點的雜湊：
HAB = SHA256(SHA256(HA + HB))該過程一直持續到頂部只有一個節點，該節點稱為默克爾根。該 32 字節雜湊儲存在塊頭中，並彙總了所有四筆交易中的所有數據。
這是有道理的，但我有幾個問題。首先是像事務 A 這樣的事務是如何被散列的，以及在實踐中事務中包含的內容。例如，如果它是字元串化的 JSON 對象，或者 JavaScript 中的 byteArray，或者數據必須採用特定格式等。我想看看例如如何對記錄進行雜湊處理，比如
{ a: 'foo', b: 'bar', c: 123, ... }或類似的東西。其次，如果這就是Patricia Merkle Tree（或者甚至是我在某處看到的 Merkle DAG）的想法的用武之地，因為雜湊不完全重疊，所以縮短了必須儲存在記憶體中的內容量所以會有很多空的樹節點。
最後，一組範例交易在單個區塊中的樣子，他們說平均有 1900 筆交易。這將是一個非常深的默克爾樹，我想看看這些交易實際上被稱為什麼以及有關它們的資料結構的更多資訊。例如，如果它們一直深入到 ISA（指令集架構）操作，或者它們的級別要高得多。這基本上就是我想知道的。我還沒有在上面連結的書中看到這一點，但會仔細看看。
merkle 樹中的葉子是交易的交易 ids
txid( .同一本書的 Ch06 描述了
txin和txout結構的序列化。我不確定為什麼書中似乎沒有交易格式本身。事務是序列txin和txout結構的序列化，具有附加版本和鎖定時間。tx { version : int32 txin_count : VarInt txins : txin[] txout_count : VarInt txouts : txout[] nLockTime : uint32 }與書中
VarInt使用的相同。在比特幣核心原始碼中，它被稱為CompactSize.支持該格式的客戶使用見證交易的另一種格式，該格式使用
txin_count通常必須使用的技巧，>= 1因為所有交易都必須花費現有的輸入（除了 coinbase tx）。因此，如果txin_count上面預期的字節具有值0，則表明存在見證交易，其中還有一些附加欄位。witness_tx { version : int32 witness_marker : byte //always 0 witness_flag : byte txin_count : VarInt txins : txin[] txout_count : VarInt txouts : txout[] witnesses : witness[] //list always has the same length of txin_count nLockTime : uint32 }即使交易是見證交易，該
tx格式也會用於txid為該交易生成用於計算默克爾根的交易。這是為了確保見證交易向後兼容舊的交易格式。支持 SegWit 的客戶端與不支持 SegWit 的客戶端通信時，會將tx格式而不是格式發送給他的對等方以進行見證交易witness_tx。