摘要:截止年月號,比特幣中有個區塊,并且這些數據占據了的磁盤空間。每個比特幣節點都是路由區塊鏈數據庫挖礦錢包服務的功能集合。是比特幣的輕量級節點,它不需要下載所有的區塊鏈數據,也不需要驗證區塊和交易數據。
最終內容請以原文為準:https://wangwei.one/posts/630...引言
在這一系列文章的最開始部分,我們提到過區塊鏈是一個分布式的數據庫。那時候,我們決定跳過"分布式"這一環節,并且聚焦于"數據存儲"這一環節。到目前為止,我們幾乎實現了區塊鏈的所有組成部分。在本篇文章中,我們將會涉及一些在前面的文章中所忽略的一些機制,并且在下一篇文章中我們將開始研究區塊鏈的分布式特性。
前面各個部分內容:
基本原型
工作量證明
持久化 & 命令行
交易(UTXO)
地址(錢包)
UTXO池在 持久化 & 命令行 這篇文章中,我們研究了比特幣核心存儲區塊的方式。當中我們提到過與區塊相關的數據存儲在 blocks 這個數據桶中,而交易數據則存儲在 chainstate 這個數據桶中,讓我們來回憶一下,chainstate 數據桶的數據結構:
"c" + 32-byte transaction hash -> unspent transaction output record for that transaction
某筆交易的UTXO記錄
"B" -> 32-byte block hash: the block hash up to which the database represents the unspent transaction outputs
數據庫所表示的UTXO的區塊Hash
從那篇文章開始,我們已經實現了比特幣的交易機制,但是我們還沒有用到 chainstate 數據桶去存儲我們的交易輸出。所以,這將是我們現在要去做的事情。
chainstate 不會去存儲交易數據。相反,它存儲的是 UTXO 集,也就是未被花費的交易輸出集合。除此之外,它還存儲了"數據庫所表示的UTXO的區塊Hash",我們這里先暫且忽略這一點,因為我們還沒有用到區塊高度(這一點我們會在后面的文章進行實現)。
那么,我們為什么需要 UTXO 池呢?
一起來看一下我們前面實現的 findUnspentTransactions 方法:
/** * 查找錢包地址對應的所有未花費的交易 * * @param pubKeyHash 錢包公鑰Hash * @return */ private Transaction[] findUnspentTransactions(byte[] pubKeyHash) throws Exception { MapallSpentTXOs = this.getAllSpentTXOs(pubKeyHash); Transaction[] unspentTxs = {}; // 再次遍歷所有區塊中的交易輸出 for (BlockchainIterator blockchainIterator = this.getBlockchainIterator(); blockchainIterator.hashNext(); ) { Block block = blockchainIterator.next(); for (Transaction transaction : block.getTransactions()) { String txId = Hex.encodeHexString(transaction.getTxId()); int[] spentOutIndexArray = allSpentTXOs.get(txId); for (int outIndex = 0; outIndex < transaction.getOutputs().length; outIndex++) { if (spentOutIndexArray != null && ArrayUtils.contains(spentOutIndexArray, outIndex)) { continue; } // 保存不存在 allSpentTXOs 中的交易 if (transaction.getOutputs()[outIndex].isLockedWithKey(pubKeyHash)) { unspentTxs = ArrayUtils.add(unspentTxs, transaction); } } } } return unspentTxs; }
該方法是用來查找錢包地址對應的包含未花費交易輸出的交易信息。由于交易信息是存儲在區塊當中,所以我們現有的做法是遍歷區塊鏈中的每個區塊,然后遍歷每個區塊中的交易信息,再然后遍歷每個交易中的交易輸出,并檢查交易輸出是否被相應的錢包地址所鎖定,效率非常低下。截止2018年3月29號,比特幣中有 515698 個區塊,并且這些數據占據了140+Gb 的磁盤空間。這也就意味著一個人必須運行全節點(下載所有的區塊數據)才能驗證交易信息。此外,驗證交易信息需要遍歷所有的區塊。
針對這個問題的解決辦法是需要有一個存儲了所有UTXOs(未花費交易輸出)的索引,這就是 UTXOs 池所要做的事情:UTXOs池其實是一個緩存空間,它所緩存的數據需要從構建區塊鏈中所有的交易數據中獲得(通過遍歷所有的區塊鏈,不過這個構建操作只需要執行一次即可),并且它后續還會用于錢包余額的計算以及新的交易數據的驗證。截止到2017年9月,UTXOs池大約為 2.7Gb。
好了,讓我們來想一下,為了實現 UTXOs 池我們需要做哪些事情。當前,有下列方法被用于查找交易信息:
Blockchain.getAllSpentTXOs —— 查詢所有已被花費的交易輸出。它需要遍歷區塊鏈中所有區塊中交易信息。
Blockchain.findUnspentTransactions —— 查詢包含未被花費的交易輸出的交易信息。它也需要遍歷區塊鏈中所有區塊中交易信息。
Blockchain.findSpendableOutputs —— 該方法用于新的交易創建之時。它需要找到足夠多的交易輸出,以滿足所需支付的金額。需要調用 Blockchain.findUnspentTransactions 方法。
Blockchain.findUTXO —— 查詢錢包地址所對應的所有未花費交易輸出,然后用于計算錢包余額。需要調用
Blockchain.findUnspentTransactions 方法。
Blockchain.findTransaction —— 通過交易ID查詢交易信息。它需要遍歷所有的區塊直到找到交易信息為止。
如你所見,上面這些方法都需要去遍歷數據庫中的所有區塊。由于UTXOs池只存儲未被花費的交易輸出,而不會存儲所有的交易信息,因此我們不會對有 Blockchain.findTransaction 進行優化。
那么,我們需要下列這些方法:
Blockchain.findUTXO —— 通過遍歷所有的區塊來找到所有未被花費的交易輸出.
UTXOSet.reindex —— 調用上面 findUTXO 方法,然后將查詢結果存儲在數據庫中。也即需要進行緩存的地方。
UTXOSet.findSpendableOutputs —— 與 Blockchain.findSpendableOutputs 類似,區別在于會使用 UTXO 池。
UTXOSet.findUTXO —— 與Blockchain.findUTXO 類似,區別在于會使用 UTXO 池。
Blockchain.findTransaction —— 邏輯保持不變。
這樣,兩個使用最頻繁的方法將從現在開始使用緩存!讓我們開始編碼吧!
定義 UTXOSet:
@NoArgsConstructor @AllArgsConstructor @Slf4j public class UTXOSet { private Blockchain blockchain; }
重建 UTXO 池索引:
public class UTXOSet { ... /** * 重建 UTXO 池索引 */ @Synchronized public void reIndex() { log.info("Start to reIndex UTXO set !"); RocksDBUtils.getInstance().cleanChainStateBucket(); MapallUTXOs = blockchain.findAllUTXOs(); for (Map.Entry entry : allUTXOs.entrySet()) { RocksDBUtils.getInstance().putUTXOs(entry.getKey(), entry.getValue()); } log.info("ReIndex UTXO set finished ! "); } ... }
此方法用于初始化 UTXOSet。首先,需要清空 chainstate 數據桶,然后查詢所有未被花費的交易輸出,并將它們保存到 chainstate 數據桶中。
實現 findSpendableOutputs 方法,供 Transation.newUTXOTransaction 調用
public class UTXOSet { ... /** * 尋找能夠花費的交易 * * @param pubKeyHash 錢包公鑰Hash * @param amount 花費金額 */ public SpendableOutputResult findSpendableOutputs(byte[] pubKeyHash, int amount) { MapunspentOuts = Maps.newHashMap(); int accumulated = 0; Map chainstateBucket = RocksDBUtils.getInstance().getChainstateBucket(); for (Map.Entry entry : chainstateBucket.entrySet()) { String txId = entry.getKey(); TXOutput[] txOutputs = (TXOutput[]) SerializeUtils.deserialize(entry.getValue()); for (int outId = 0; outId < txOutputs.length; outId++) { TXOutput txOutput = txOutputs[outId]; if (txOutput.isLockedWithKey(pubKeyHash) && accumulated < amount) { accumulated += txOutput.getValue(); int[] outIds = unspentOuts.get(txId); if (outIds == null) { outIds = new int[]{outId}; } else { outIds = ArrayUtils.add(outIds, outId); } unspentOuts.put(txId, outIds); if (accumulated >= amount) { break; } } } } return new SpendableOutputResult(accumulated, unspentOuts); } ... }
實現 findUTXOs 接口,供 CLI.getBalance 調用:
public class UTXOSet { ... /** * 查找錢包地址對應的所有UTXO * * @param pubKeyHash 錢包公鑰Hash * @return */ public TXOutput[] findUTXOs(byte[] pubKeyHash) { TXOutput[] utxos = {}; MapchainstateBucket = RocksDBUtils.getInstance().getChainstateBucket(); if (chainstateBucket.isEmpty()) { return utxos; } for (byte[] value : chainstateBucket.values()) { TXOutput[] txOutputs = (TXOutput[]) SerializeUtils.deserialize(value); for (TXOutput txOutput : txOutputs) { if (txOutput.isLockedWithKey(pubKeyHash)) { utxos = ArrayUtils.add(utxos, txOutput); } } } return utxos; } ... }
以上這些方法都是先前 Blockchain 中相應方法的微調版,先前的方法將不再使用。
有了UTXO池之后,意味著我們的交易數據分開存儲到了兩個不同的數據桶中:交易數據存儲到了 block 數據桶中,而UTXO存儲到了 chainstate 數據桶中。這就需要一種同步機制來保證每當一個新的區塊產生時,UTXO池能夠及時同步最新區塊中的交易數據,畢竟我們不想頻地進行 reIndex 。因此,我們需要如下方法:
更新UTXO池:
public class UTXOSet { ... /** * 更新UTXO池 ** 當一個新的區塊產生時,需要去做兩件事情: * 1)從UTXO池中移除花費掉了的交易輸出; * 2)保存新的未花費交易輸出; * * @param tipBlock 最新的區塊 */ @Synchronized public void update(Block tipBlock) { if (tipBlock == null) { log.error("Fail to update UTXO set ! tipBlock is null !"); throw new RuntimeException("Fail to update UTXO set ! "); } for (Transaction transaction : tipBlock.getTransactions()) { // 根據交易輸入排查出剩余未被使用的交易輸出 if (!transaction.isCoinbase()) { for (TXInput txInput : transaction.getInputs()) { // 余下未被使用的交易輸出 TXOutput[] remainderUTXOs = {}; String txId = Hex.encodeHexString(txInput.getTxId()); TXOutput[] txOutputs = RocksDBUtils.getInstance().getUTXOs(txId); if (txOutputs == null) { continue; } for (int outIndex = 0; outIndex < txOutputs.length; outIndex++) { if (outIndex != txInput.getTxOutputIndex()) { remainderUTXOs = ArrayUtils.add(remainderUTXOs, txOutputs[outIndex]); } } // 沒有剩余則刪除,否則更新 if (remainderUTXOs.length == 0) { RocksDBUtils.getInstance().deleteUTXOs(txId); } else { RocksDBUtils.getInstance().putUTXOs(txId, remainderUTXOs); } } } // 新的交易輸出保存到DB中 TXOutput[] txOutputs = transaction.getOutputs(); String txId = Hex.encodeHexString(transaction.getTxId()); RocksDBUtils.getInstance().putUTXOs(txId, txOutputs); } } ... }
讓我們將 UTXOSet 用到它們所需之處去:
public class CLI { ... /** * 創建區塊鏈 * * @param address */ private void createBlockchain(String address) { Blockchain blockchain = Blockchain.createBlockchain(address); UTXOSet utxoSet = new UTXOSet(blockchain); utxoSet.reIndex(); log.info("Done ! "); } ... }
當創建一個新的區塊鏈是,我們需要重建 UTXO 池索引。截止目前,這是唯一一處用到 reIndex 的地方,盡管看起有些多余,因為在區塊鏈創建之初僅僅只有一個區塊和一筆交易。
修改 CLI.send 接口:
public class CLI { ... /** * 轉賬 * * @param from * @param to * @param amount */ private void send(String from, String to, int amount) throws Exception { ... Blockchain blockchain = Blockchain.createBlockchain(from); Transaction transaction = Transaction.newUTXOTransaction(from, to, amount, blockchain); Block newBlock = blockchain.mineBlock(new Transaction[]{transaction}); new UTXOSet(blockchain).update(newBlock); ... } ... }
當一個新的區塊產生后,需要去更新 UTXO 池數據。
讓我們來檢查一下它們的運行情況:
$ java -jar blockchain-java-jar-with-dependencies.jar createwallet wallet address : 1JgppX2xMshr35wHzvNWQBejUAZ3Te5Mdf $ java -jar blockchain-java-jar-with-dependencies.jar createwallet wallet address : 1HX7bWwCjvxkjq65GUgAVRFfTZy6yKWkoG $ java -jar blockchain-java-jar-with-dependencies.jar createwallet wallet address : 1L1RoFgyjCrNPCPHmSEBtNiV3h2wiF9mZV $ java -jar blockchain-java-jar-with-dependencies.jar createblockchain -address 1JgppX2xMshr35wHzvNWQBejUAZ3Te5Mdf Elapsed Time: 164.961 seconds correct hash Hex: 00225493862611bc517cb6b3610e99d26d98a6b52484c9fa745df6ceff93f445 Done ! $ java -jar blockchain-java-jar-with-dependencies.jar getbalance -address 1JgppX2xMshr35wHzvNWQBejUAZ3Te5Mdf Balance of "1JgppX2xMshr35wHzvNWQBejUAZ3Te5Mdf": 10 $ java -jar blockchain-java-jar-with-dependencies.jar send -from 1HX7bWwCjvxkjq65GUgAVRFfTZy6yKWkoG -to 1JgppX2xMshr35wHzvNWQBejUAZ3Te5Mdf -amount 5 java.lang.Exception: ERROR: Not enough funds $ java -jar blockchain-java-jar-with-dependencies.jar send -from 1JgppX2xMshr35wHzvNWQBejUAZ3Te5Mdf -to 1HX7bWwCjvxkjq65GUgAVRFfTZy6yKWkoG -amount 2 Elapsed Time: 54.92 seconds correct hash Hex: 0001ab21f71ff2d6d532bf3b3388db790c2b03e28d7bd27bd669c5f6380a4e5b Success! $ java -jar blockchain-java-jar-with-dependencies.jar send -from 1JgppX2xMshr35wHzvNWQBejUAZ3Te5Mdf -to 1L1RoFgyjCrNPCPHmSEBtNiV3h2wiF9mZV -amount 2 Elapsed Time: 54.92 seconds correct hash Hex: 0009b925cc94e3db8bab2958b1fc2d1764aa15531e20756d92c3a93065c920f0 Success! $ java -jar blockchain-java-jar-with-dependencies.jar getbalance -address 1JgppX2xMshr35wHzvNWQBejUAZ3Te5Mdf Balance of "1JgppX2xMshr35wHzvNWQBejUAZ3Te5Mdf": 6 $ java -jar blockchain-java-jar-with-dependencies.jar getbalance -address 1HX7bWwCjvxkjq65GUgAVRFfTZy6yKWkoG Balance of "1HX7bWwCjvxkjq65GUgAVRFfTZy6yKWkoG": 2 $ java -jar blockchain-java-jar-with-dependencies.jar getbalance -address 1L1RoFgyjCrNPCPHmSEBtNiV3h2wiF9mZV Balance of "1L1RoFgyjCrNPCPHmSEBtNiV3h2wiF9mZV": 2獎勵機制
前面的章節中我們省略了礦工挖礦的獎勵機制。時機已經成熟,該實現它了。
礦工獎勵其實是一個 coinbase 交易(創幣交易)。當一個礦工節點開始去生產一個新的區塊時,他會從隊列中取出一些交易數據,并且為它們預制一個 coinbase 交易。這筆 coinbase 交易中僅有的交易輸出包含了礦工的公鑰hash。
只需要更新 send 命令接口,我們就可以輕松實現礦工的獎勵機制:
public class CLI { ... /** * 轉賬 * * @param from * @param to * @param amount */ private void send(String from, String to, int amount) throws Exception { ... Blockchain blockchain = Blockchain.createBlockchain(from); // 新交易 Transaction transaction = Transaction.newUTXOTransaction(from, to, amount, blockchain); // 獎勵 Transaction rewardTx = Transaction.newCoinbaseTX(from, ""); Block newBlock = blockchain.mineBlock(new Transaction[]{transaction, rewardTx}); new UTXOSet(blockchain).update(newBlock); ... } ... }
還需要修改交易驗證方法,coinbase 交易直接驗證通過:
public class Blockchain { /** * 交易簽名驗證 * * @param tx */ private boolean verifyTransactions(Transaction tx) { if (tx.isCoinbase()) { return true; } ... } ... }
在我們的實現邏輯中,代幣的發送也是區塊的生產者,因此,獎勵也歸他所有。
讓我們來驗證一下獎勵機制:
$ java -jar blockchain-java-jar-with-dependencies.jar createwallet wallet address : 1MpdtjTEsDvrkrLWmMswq4K3VPtevXXnUD $ java -jar blockchain-java-jar-with-dependencies.jar createwallet wallet address : 17crpQoWy7TEkY9UPjZ3Qt9Fc2rWPUt8KX $ java -jar blockchain-java-jar-with-dependencies.jar createwallet wallet address : 12L868QZW1ySYzf2oT5ha9py9M5JrSRhvT $ java -jar blockchain-java-jar-with-dependencies.jar createblockchain -address 1MpdtjTEsDvrkrLWmMswq4K3VPtevXXnUD Elapsed Time: 17.973 seconds correct hash Hex: 0000defe83a851a5db3803d5013bbc20c6234f176b2c52ae36fdb53d28b33d93 Done ! $ java -jar blockchain-java-jar-with-dependencies.jar send -from 1MpdtjTEsDvrkrLWmMswq4K3VPtevXXnUD -to 17crpQoWy7TEkY9UPjZ3Qt9Fc2rWPUt8KX -amount 6 Elapsed Time: 30.887 seconds correct hash Hex: 00005fd36a2609b43fd940577f93b8622e88e854f5ccfd70e113f763b6df69f7 Success! $ java -jar blockchain-java-jar-with-dependencies.jar send -from 1MpdtjTEsDvrkrLWmMswq4K3VPtevXXnUD -to 12L868QZW1ySYzf2oT5ha9py9M5JrSRhvT -amount 3 Elapsed Time: 45.267 seconds correct hash Hex: 00009fd7c59b830b60ec21ade7672921d2fb0962a1b06a42c245450e47582a13 Success! $ java -jar blockchain-java-jar-with-dependencies.jar getbalance -address 1MpdtjTEsDvrkrLWmMswq4K3VPtevXXnUD Balance of "1MpdtjTEsDvrkrLWmMswq4K3VPtevXXnUD": 21 $ java -jar blockchain-java-jar-with-dependencies.jar getbalance -address 17crpQoWy7TEkY9UPjZ3Qt9Fc2rWPUt8KX Balance of "17crpQoWy7TEkY9UPjZ3Qt9Fc2rWPUt8KX": 6 $ java -jar blockchain-java-jar-with-dependencies.jar getbalance -address 12L868QZW1ySYzf2oT5ha9py9M5JrSRhvT Balance of "12L868QZW1ySYzf2oT5ha9py9M5JrSRhvT": 3
1MpdtjTEsDvrkrLWmMswq4K3VPtevXXnUD 這個地址一共收到了三份獎勵:
第一次是開采創世區塊;
第二次是開采區塊:00005fd36a2609b43fd940577f93b8622e88e854f5ccfd70e113f763b6df69f7
第三次是開采區塊:00009fd7c59b830b60ec21ade7672921d2fb0962a1b06a42c245450e47582a13
Merkle TreeMerkle Tree(默克爾樹) 是這篇文章中我們需要重點討論的一個機制。
正如我前面提到的那樣,整個比特幣的數據庫占到了大約140G的磁盤空間。由于比特幣的分布式特性,網絡中的每一個節點必須是獨立且自給自足的。每個比特幣節點都是路由、區塊鏈數據庫、挖礦、錢包服務的功能集合。每個節點都參與全網絡的路由功能,同時也可能包含其他功能。每個節點都參與驗證并傳播交易及區塊信息,發現并維持與對等節點的連接。一個全節點(full node)包括以下四個功能:
隨著越來越多的人開始使用比特幣,這條規則開始變得越來越難以遵循:讓每一個人都去運行一個完整的節點不太現實。在中本聰發布的 比特幣白皮書 中,針對這個問題提出了一個解決方案:Simplified Payment Verification (SPV)(簡易支付驗證)。SPV是比特幣的輕量級節點,它不需要下載所有的區塊鏈數據,也不需要驗證區塊和交易數據。相反,當SPV想要驗證一筆交易的有效性時,它會從它所連接的全節點上檢索所需要的一些數據。這種機制保證了在只有一個全節點的情況,可以運行多個SPV輕錢包節點。
更多有關SPV的介紹,請查看:《精通比特幣(第二版)》第八章
為了使SPV成為可能,就需要有一種方法在沒有全量下載區塊數據的情況下,來檢查一個區塊是否包含了某筆交易。這就是 Merkle Tree 發揮作用的地方了。
比特幣中所使用的Merkle Tree是為了獲得交易的Hash值,隨后這個已經被Pow(工作量證明)系統認可了的Hash值會被保存到區塊頭中。到目前為止,我們只是簡單地計算了一個區塊中每筆交易的Hash值,然后在準備Pow數據時,再對這些交易進行 SHA-256 計算。雖然這是一個用于獲取區塊交易唯一表示的一個不錯的途徑,但是它不具有到 Merkle Tree的優點。
來看一下Merkle Tree的結構:
每一個區塊都會構建一個Merkle Tree,它從最底部的葉子節點開始往上構建,每一個交易的Hash就是一個葉子節點(比特幣中用的雙SHA256算法)。葉子節點的數量必須是偶數個,但是并不是每一個區塊都能包含偶數筆交易數據。如果存在奇數筆交易數據,那么最后一筆交易數據將會被復制一份(這僅僅發生在Merkle Tree中,而不是區塊中)。
從下往上移動,葉子節點成對分組,它們的Hash值被連接到一起,并且在此基礎上再次計算出新的Hash值。新的Hash 形成新的樹節點。這個過程不斷地被重復,直到最后僅剩一個被稱為根節點的樹節點。這個根節點的Hash就是區塊中交易數據們的唯一代表,它會被保存到區塊頭中,并被用于參與POW系統的計算。
Merkle樹的好處是節點可以在不下載整個塊的情況下驗證某筆交易的合法性。 為此,只需要交易Hash,Merkle樹根Hash和Merkle路徑。
Merkle Tree代碼實現如下:
package one.wangwei.blockchain.transaction; import com.google.common.collect.Lists; import lombok.Data; import one.wangwei.blockchain.util.ByteUtils; import org.apache.commons.codec.digest.DigestUtils; import java.util.List; /** * 默克爾樹 * * @author wangwei * @date 2018/04/15 */ @Data public class MerkleTree { /** * 根節點 */ private Node root; /** * 葉子節點Hash */ private byte[][] leafHashes; public MerkleTree(byte[][] leafHashes) { constructTree(leafHashes); } /** * 從底部葉子節點開始往上構建整個Merkle Tree * * @param leafHashes */ private void constructTree(byte[][] leafHashes) { if (leafHashes == null || leafHashes.length < 1) { throw new RuntimeException("ERROR:Fail to construct merkle tree ! leafHashes data invalid ! "); } this.leafHashes = leafHashes; Listparents = bottomLevel(leafHashes); while (parents.size() > 1) { parents = internalLevel(parents); } root = parents.get(0); } /** * 構建一個層級節點 * * @param children * @return */ private List internalLevel(List children) { List parents = Lists.newArrayListWithCapacity(children.size() / 2); for (int i = 0; i < children.size() - 1; i += 2) { Node child1 = children.get(i); Node child2 = children.get(i + 1); Node parent = constructInternalNode(child1, child2); parents.add(parent); } // 內部節點奇數個,只對left節點進行計算 if (children.size() % 2 != 0) { Node child = children.get(children.size() - 1); Node parent = constructInternalNode(child, null); parents.add(parent); } return parents; } /** * 底部節點構建 * * @param hashes * @return */ private List bottomLevel(byte[][] hashes) { List parents = Lists.newArrayListWithCapacity(hashes.length / 2); for (int i = 0; i < hashes.length - 1; i += 2) { Node leaf1 = constructLeafNode(hashes[i]); Node leaf2 = constructLeafNode(hashes[i + 1]); Node parent = constructInternalNode(leaf1, leaf2); parents.add(parent); } if (hashes.length % 2 != 0) { Node leaf = constructLeafNode(hashes[hashes.length - 1]); // 奇數個節點的情況,復制最后一個節點 Node parent = constructInternalNode(leaf, leaf); parents.add(parent); } return parents; } /** * 構建葉子節點 * * @param hash * @return */ private static Node constructLeafNode(byte[] hash) { Node leaf = new Node(); leaf.hash = hash; return leaf; } /** * 構建內部節點 * * @param leftChild * @param rightChild * @return */ private Node constructInternalNode(Node leftChild, Node rightChild) { Node parent = new Node(); if (rightChild == null) { parent.hash = leftChild.hash; } else { parent.hash = internalHash(leftChild.hash, rightChild.hash); } parent.left = leftChild; parent.right = rightChild; return parent; } /** * 計算內部節點Hash * * @param leftChildHash * @param rightChildHash * @return */ private byte[] internalHash(byte[] leftChildHash, byte[] rightChildHash) { byte[] mergedBytes = ByteUtils.merge(leftChildHash, rightChildHash); return DigestUtils.sha256(mergedBytes); } /** * Merkle Tree節點 */ @Data public static class Node { private byte[] hash; private Node left; private Node right; } }
然后修改 Block.hashTransaction 接口:
public class Block { ... /** * 對區塊中的交易信息進行Hash計算 * * @return */ public byte[] hashTransaction() { byte[][] txIdArrays = new byte[this.getTransactions().length][]; for (int i = 0; i < this.getTransactions().length; i++) { txIdArrays[i] = this.getTransactions()[i].hash(); } return new MerkleTree(txIdArrays).getRoot().getHash(); } ... }
MerkleTree的根節點的Hash值,就是區塊中交易信息的唯一代表。
小結這一節我們主要是對前面的交易機制做了進一步的優化,加入UTXO池和Merkle Tree機制。
資料源碼:https://github.com/wangweiX/b...
The UTXO Set:_Data_Storage#The_UTXO_set_.28chainstate_leveldb.29)
UTXO set statistics
Merkle Tree
Why every Bitcoin user should understand “SPV security”
Script
“Ultraprune” Bitcoin Core commit
Smart contracts and Bitcoin
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/24038.html
摘要:截止年月號,比特幣中有個區塊,并且這些數據占據了的磁盤空間。每個比特幣節點都是路由區塊鏈數據庫挖礦錢包服務的功能集合。是比特幣的輕量級節點,它不需要下載所有的區塊鏈數據,也不需要驗證區塊和交易數據。 showImg(https://img.i7years.com/blog/pexels-photo-38136.jpeg); 最終內容請以原文為準:https://wangwei.one/...
摘要:本文將會簡要討論秘猿科技是如何對進行性能優化的。在區塊鏈中,的共識是一個連續的共識。預處理在傳統的類共識的區塊鏈中,共識和交易的處理都是串行的。在共識的過程中,是閑置的。減少不必要的消息。例如,在服務收到時,需要對其合法性進行驗證。 在前兩期中,秘猿小課堂給大家分享了構建高性能區塊鏈內核 CITA 背后的思考。這一期,我們深入研究 CITA 是如何進行性能優化,并且將交易處理的性能達到...
摘要:本文將基于語言構建簡化版的,來實現數字貨幣。值用于確保的安全。計算是計算敏感的操作,即使在高性能電腦也需要花費一段時間來完成計算這也就是為什么人們購買高性能進行比特幣挖礦的原因。資料源代碼精通比特幣第二版 showImg(https://segmentfault.com/img/remote/1460000013923206?w=1600&h=900); 最終內容請以原文為準:http...
摘要:本文將基于語言構建簡化版的,來實現數字貨幣。值用于確保的安全。計算是計算敏感的操作,即使在高性能電腦也需要花費一段時間來完成計算這也就是為什么人們購買高性能進行比特幣挖礦的原因。資料源代碼精通比特幣第二版 showImg(https://segmentfault.com/img/remote/1460000013923206?w=1600&h=900); 最終內容請以原文為準:http...
摘要:稀疏梅克爾樹在上文中我們已經了解到一個交易的成功的前提是需要發送方提供關于一個的完整交易歷史。因此,中使用了一種稱為稀疏梅克爾樹,的數據結構存儲交易數據,能夠在的時間復雜度驗證一個交易不存在。 本文首發于深入淺出區塊鏈社區原文鏈接:深入理解Plasma(四)Plasma Cash原文已更新,請讀者前往原文閱讀 這一系列文章將圍繞以太坊的二層擴容框架 Plasma,介紹其基本運行原理,具...
閱讀 2284·2023-04-25 16:42
閱讀 1198·2021-11-22 14:45
閱讀 2328·2021-10-19 13:10
閱讀 2821·2021-09-29 09:34
閱讀 3398·2021-09-23 11:21
閱讀 2094·2021-08-12 13:25
閱讀 2176·2021-07-30 15:15
閱讀 3488·2019-08-30 15:54