Ⅰ Quorum介紹
Quorum和以太坊的主要區別:
Quorum 的主要組件：
1,用其自己實現的基於投票機制的共識方式 來代替原來的 「Proof of work」 。
2,在原來無限制的P2P傳輸方式上增加了許可權功能。使得P2P傳輸只能在互相允許的節點間傳輸。
3, 修改區塊校驗邏輯使其能支持 private transaction。
4, Transaction 生成時支持 transaction 內容的替換。這個調整是為了能支持聯盟中的私有交易。
Constellation 模塊的主要職責是支持 private transaction。Constellation 由兩部分組成：Transaction Manager 和 Enclave。Transaction Manager 用來管理和傳遞私有消息，Enclave 用來對私有消息的加解密。
在私有交易中，Transaction Manager 會存儲私有交易的內容，並且會將這條私有交易內容與其他相關的 Transaction Manager 進行交互。同時它也會利用 Enclave 來加密或解密其收到的私有交易。
為了能更有效率的處理消息的加密與解密，Quorum 將這個功能單獨拉出並命名為 Enclave 模塊。Enclave 和 Transaction Manager 是一對一的關系。
在 Quorum 中有兩種交易類型，」Public Transaction」 和 「Privat Transaction」。在實際的交易中，這兩種類型都採用了以太坊的 Transaction 模型，但是又做了部分修改。Quorum 在原有的以太坊 tx 模型基礎上添加了一個新的 「privateFor」 欄位。同時，針對一個 tx 類型的對象添加了一個新的方法 「IsPrivate」。用 「IsPrivate」 方法來判斷 Transaction是 public 還是 private，用 「privateFor」 來記錄 事務只有誰能查看。
Public Transaction 的機理和以太坊一致。Transaction中的交易內容能被鏈上的所有人訪問到。
Private Transaction 雖然被叫做 「Private」，但是在全網上也會出現與其相關的交易。只不過交易的明細只有與此交易有關系的成員才能訪問到。在全網上看到的交易內容是一段hash值，當你是交易的相關人員時，你就能利用這個hash值，然後通過 Transaction Manager 和 Enclave 來獲得這筆交易的正確內容。
Public Transaction的處理流程和以太坊的Transaction流程一致。Transaction 廣播全網後，被礦工打包到區塊中。節點收到區塊並校驗區塊中的 事務 信息。然後根據 Transaction信息更新本地的區塊
Private Transaction也會將 Transaction 廣播至全網。但是它的 Transaction payload已經從原來的真實內容替換為一個hash值。這個hash值是由Transaction Manager提供的。
有兩個共識機制：QuorumChain Consensus 和 Raft-Based Consensus。
在 Quorum 1.2 之前的 Release 版本都採用了 QuorumChain。
從 2.0 版本開始，Quorum 廢棄了 QuorumChain 轉而只支持 Raft-based Consensus。
QuorumChain Consensus 是一個基於投票的共識演算法。其主要特點有：
相比較以太坊的POW，Raft-based 提供了更快更高效的區塊生成方式。相比 QuorumChain，Raft-based 不會產生空的區塊，而且在區塊的生成上比前者更有效率。
要想了解Raft-based Consensus，必須先了解Raft演算法
Raft演算法
Raft是一種一致性演算法，是為了確保容錯性，也就是即使系統中有一兩個伺服器當機，也不會影響其處理過程。這就意味著只要超過半數的大多數伺服器達成一致就可以了，假設有N台伺服器，N/2 +1 就超過半數，代表大多數了。
Raft的工作模式：
raft的工作模式是一個Leader和多個Follower模式，即我們通常說的領導者-追隨者模式。除了這兩種身份，還有Candidate身份。下面是身份的轉化示意圖
1，leader的選舉過程
raft初始狀態時所有server都處於Follower狀態，並且隨機睡眠一段時間，這個時間在0~1000ms之間。最先醒來的server A進入Candidate狀態，Candidate狀態的server A有權利發起投票，向其它所有server發出投票請求，請求其它server給它投票成為Leader。
2，Leader產生數據並同步給Follower
Leader產生數據，並向其它Follower節點發送數據添加請求。其它Follower收到數據添加請求後，判斷該append請求滿足接收條件（接收條件在後面安全保證問題3給出），如果滿足條件就將其添加到本地，並給Leader發送添加成功的response。Leader在收到大多數Follower添加成功的response後。提交後的log日誌就意味著已經被raft系統接受，並能應用到狀態機中了。
Leader具有絕對的數據產生權利，其它Follower上存在數據不全或者與Leader數據不一致的情況時，一切都以Leader上的數據為主，最終所有server上的日誌都會復製成與Leader一致的狀態。
Raft的動態演示： http://thesecretlivesofdata.com/raft/
安全性保證，對於異常情況下Raft如何處理：
1，Leader選舉過程中，如果有兩個FollowerA和B同時醒來並發出投票請求怎麼辦？
在一次選舉過程中，一個Follower只能投一票，這就保證了FollowerA和B不可能同時得到大多數（一半以上）的投票。如果A或者B中其一幸運地得到了大多數投票，就能順利地成為Leader，Raft系統正常運行下去。但是A和B可能剛好都得到一半的投票，兩者都成為不了Leader。這時A和B繼續保持Candidate狀態，並且隨機睡眠一段時間，等待進入到下一個選舉周期。由於所有Follower都是隨機選擇睡眠時間，所以連續出現多個server競選的概率很低。
2，Leader掛了後，如何選舉出新的Leader？
Leader在正常運行時候，會周期性的向Follower節點發送數據的同步請求，同時也是起到一個心跳作用。Follower節點如果在一段時間之內（一般是2000ms左右）沒有收到數據同步請求，則認為Leader已經死了，於是進入到Candidate狀態，開始發起投票競選新的Leader，每個新的Leader產生後就是一個新的任期，每個任期都對應一個唯一的任期號term。這個term是單調遞增的，用來唯一標識一個Leader的任期。投票開始時，Candidate將自己的term加1，並在投票請求中帶上term；Follower只會接受任期號term比自己大的request_vote請求，並為之投票。 這條規則保證了只有最新的Candidate才有可能成為Leader。
3，Follower的數據的生效時間
Follower在收到一條添加數據請求後，是否立即保存並將其應用到狀態機中去？如果不是立即應用，那麼由什麼來決定該條日誌生效的時間？
首先會檢查這條數據同步請求的來源信息是否與本地保存的leader信息符合，包括leaderId和任期號term。檢查合法後就將日誌保存到本地中，並給Leader回復添加log成功，但是不會立即將其應用到本地狀態機。Leader收到大部分Follower添加log成功的回復後，就正式將這條日誌commit提交。Leader在隨後發出的心跳append_entires中會帶上已經提交日誌索引。Follower收到Leader發出的心跳append_entries後，就可以確認剛才的log已經被commit(提交)了，這個時候Follower才會把日誌應用到本地狀態機。下表即是append_entries請求的內容，其中leaderCommit即是Leader已經確認提交的最大日誌索引。Follower在收到Leader發出的append_entries後即可以通過leaderCommit欄位決定哪些日誌可以應用到狀態機。
4，向raft系統中添加新機器時，由於配置信息不可能在各個系統上同時達到同步狀態，總會有某些server先得到新機器的信息，有些server後得到新機器的信息。比如在raft系統中有三個server，在某個時間段中新增加了server4和server5這兩台機器。只有server3率先感知到了這兩台機器的添加。這個時候如果進行選舉，就有可能出現兩個Leader選舉成功。因為server3認為有3台server給它投了票，它就是Leader，而server1認為只要有2台server給它投票就是Leader了。raft怎麼解決這個問題呢？
產生這個問題的根本原因是，raft系統中有一部分機器使用了舊的配置，如server1和server2，有一部分使用新的配置，如server3。解決這個問題的方法是添加一個中間配置(Cold, Cnew)，這個中間配置的內容是舊的配置表Cold和新的配置Cnew。這個時候server3收到添加機器的消息後，不是直接使用新的配置Cnew，而是使用(Cold, Cnew)來做決策。比如說server3在競選Leader的時候，不僅需要得到Cold中的大部分投票，還要得到Cnew中的大部分投票才能成為Leader。這樣就保證了server1和server2在使用Cold配置的情況下，還是只可能產生一個Leader。當所有server都獲得了添加機器的消息後，再統一切換到Cnew。raft實現中，將Cold，(Cold,Cnew)以及Cnew都當成一條普通的日誌。配置更改信息發送Leader後，由Leader先添加一條 (Cold, Cnew)日誌，並同步給其它Follower。當這條日誌(Cold, Cnew)提交後，再添加一條Cnew日誌同步給其它Follower，通過Cnew日誌將所有Follower的配置切換到最新。
Raft演算法和以太坊結合
所以為了連接以太坊節點和 Raft 共識，Quorum 採用了網路節點和 Raft 節點一對一的方式來實現 Raft-based 共識
一個Transaction完整流程
1，客戶端發起一筆 Transaction並通過 RPC 來呼叫節點。
2，節點通過以太坊的 P2P 協議將節點廣播給網路。
3，當前的 Raft leader 對應的以太坊節點收到了 Transaction後將它打包成區塊。
區塊被 編碼後傳遞給對應的 Raft leader。
leader 收到區塊後通過 Raft 演算法將區塊傳遞給 follower。這包括如下步驟：
3.1，leader 發送 AppendEntries 指令給 follower。
3.2，follower 收到這個包含區塊信息的指令後，返回確認回執給 leader。
3.3，leader 收到不少於指定數量的確認回執後，發送確認 append 的指令給 follower。
3.4，follower 收到確認 append 的指令後將區塊信息記錄到本地的 Raft log 上。
3.5，Raft 節點將區塊傳遞給對應的 Quorum 節點。Quorum 節點校驗區塊的合法性，如果合法則記錄到本地鏈上。
參考鏈接： http://blog.csdn.net/about_blockchain/article/details/78684901
Ⅱ 打包區塊是什麼意思
意思如下
在其他區塊鏈系統中,區塊打包是有時間限制的,在一段時間內區塊能打包多少交易就打包多少,時間到了就會生成區塊。如果有剩餘的交易,那就等下次嘍。
Ⅲ 以太坊怎麼維護
以太坊的維護是通過礦工節讓激點進行的坦洞襪。礦工節點是指通過計算機挖礦獲得以太幣的節點，在維護以太坊網路的同時也在為自己獲取收益。這些礦工節點會通過算力競賽的方式來爭奪下一個區塊的產生權，通過解決數學難題來獲得下一個區塊的產生權，並將新的區塊添加到區塊鏈中。在添加新的區塊時，礦工節點需要驗證該區塊中的所有交易是否合法，例如是否滿足賬戶余額的要求、是否滿足智能合約的要求等。如果驗證通過，該區塊就會被添加到區塊鏈中，否則就會被拒絕。
除了礦工節點的維護，以太坊還有一些其他的維護措施，例如節點管理、智能合約審核等。節點管理是指通過增加節點數量來提高網路的穩定性和安全性。智能合約審核是指對新的智能合約進行審核和測試，確保其符合規范並且沒有漏洞，以避免因為智能合約問題導致的安全事故。
總之，以太坊的維護是通過礦工節點、節點管理和顫橡智能合約審核等多種措施來保證網路的安全性和穩定性。
Ⅳ 【ETH錢包開發03】web3j轉賬ETH
在之前的文章中，講解了創建、導出、導入錢包。
【ETH錢包開發01】創建、導出錢包
【ETH錢包開發02】導入錢包
本文主要講解以太坊轉賬相關的一些知識。交易分為ETH轉賬和ERC-20 Token轉賬，本篇先講一下ETH轉賬。
1、解鎖賬戶發起交易。錢包keyStore文件保存在geth節點上，用戶發起交易需要解鎖賬戶，適用於中心化的交易所。
2、錢包文件離線簽名發起交易。錢包keyStore文件保存在本地，用戶使用密碼+keystore的方式做離線交易簽名來發起交易，適用於dapp，比如錢包。
本文主要講一下第二種方式，也就是錢包離線簽名轉賬的方式。
交易流程
1、通過keystore載入轉賬所需的憑證Credentials
2、創建一筆交易RawTransaction
3、使用Credentials對象對交易簽名
4、發起交易
注意以下幾點：
1、Credentials
這里，我是通過獲取私鑰的方式來載入 Credentials
還有另外一種方式，通過密碼+錢包文件keystore方式來載入 Credentials
2、nonce
nonce是指發起交易的賬戶下的交易筆數，每一個賬戶nonce都是從0開始，當nonce為0的交易處理完之後，才會處理nonce為1的交易，並依次加1的交易才會被處理。
可以通過 eth_gettransactioncount 獲取nonce
3、gasPrice和gasLimit
交易手續費由gasPrice 和gasLimit來決定，實際花費的交易手續費是 gasUsed * gasPrice 。所有這兩個值你可以自定義，也可以使用系統參數獲取當前兩個值
關於 gas ，你可以參考我之前的一篇文章。
以太坊（ETH）GAS詳解
gasPrice和gasLimit影響的是轉賬的速度，如果gas過低，礦工會最後才打包你的交易。在app中，通常給定一個默認值，並且允許用戶自己選擇手續費。
如果不需要自定義的話，還有一種方式來獲取。獲取以太坊網路最新一筆交易的 gasPrice ,轉賬的話， gasLimit 一般設置為21000就可以了。
Web3j還提供另外一種簡單的方式來轉賬以太幣,這種方式的好處是不需要管理nonce，不需要設置gasPrice和gasLimit，會自動獲取最新一筆交易的gasPrice，gasLimit 為21000（轉賬一般設置成這個值就夠用了）。
這個問題，我想是很多朋友所關心的吧。但是到目前為止，我還沒有看到有講解這方面的博客。
之前問過一些朋友，他們說可以通過區塊號、區塊哈希來判斷，也可以通過Receipt日誌來判斷。但是經過我的一番嘗試，只有 BlockHash 是可行的，在web3j中根據 blocknumber 和 transactionReceipt 都會報空指針異常。
原因大致是這樣的：在發起一筆交易之後，會返回 txHash ，然後我們可以根據這個 txHash 去查詢這筆交易相關的信息。但是剛發起交易的時候，由於手續費問題或者乙太網絡擁堵問題，會導致你的這筆交易還沒有被礦工打包進區塊，因此一開始是查不到的，通常需要幾十秒甚至更長的時間才能獲取到結果。我目前的解決方案是輪詢的去刷 BlockHash ，一開始的時候 BlockHash 的值為0x00000000000，等到打包成功的時候就不再是0了。
這里我使用的是rxjava的方式去輪詢刷的，5s刷新一次。
正常情況下，幾十秒內就可以獲取到區塊信息了。
區塊確認數=當前區塊高度-交易被打包時的區塊高度。
Ⅳ ETH開發實踐——批量發送交易
在使用同一個地址連續發送交易時，每筆交易往往不可能立即到賬， 當前交易還未到賬的情況下，下一筆交易無論是通過 eth.getTransactionCount() 獲取nonce值來設置，還是由節點自動從區塊中查詢，都會獲得和前一筆交易同樣的nonce值，這時節點就會報錯 Error: replacement transaction underpriced
在構建一筆新的交易時，在交易數據結構中會產生一個nonce值， nonce是當前區塊鏈下，發送者(from地址)發出的交易(成功記錄進區塊的)總數， 再加上1。例如新構建一筆從A發往B的交易，A地址之前的交易次數為10，那麼這筆交易中的nonce則會設置成11， 節點驗證通過後則會放入交易池（txPool）,並向其他節點廣播，該筆交易等待礦工將其打包進新的區塊。
那麼，如果在先構建並發送了一筆從地址A發出的，nonce為11的交易，在該交易未打包進區塊之前， 再次構建一筆從A發出的交易，並將它發送到節點，不管是先通過web3的eth.getTransactionCount(A)獲取到的過往的交易數量，還是由節點自行填寫nonce， 後面的這筆交易的nonce同樣是11， 此時就出現了問題：
實際場景中，會有批量從一個地址發送交易的需求，首先這些操作可能也應該是並行的，我們不會等待一筆交易成功寫入區塊後再發起第二筆交易，那麼此時有什麼好的解決辦法呢？先來看看geth節點中交易池對交易的處理流程
如之前所說，構建一筆交易時如果不手動設置nonce值，geth節點會默認計算發起地址此前最大nonce數（寫入區塊的才算數），然後將其加上1， 然後將這筆交易放入節點交易池中的pending隊列，等到節點將其打包進區塊。
構建交易時，nonce值是可以手動設置的，如果當前的nonce本應該設置成11， 但是我手動設置成了13， 在節點收到這筆交易時， 發現pending隊列中並沒有改地址下nonce為11及12的交易， 就會將這筆nonce為13的交易放入交易池的queued隊列中。只有當前面的nonce補齊（nonce為11及12的交易被發現並放入pending隊列）之後，才會將它放入pending隊列中等待打包。
我們把pending隊列中的交易視為可執行的，因為它們可能被礦工打包進最新的區塊。 而queue隊列因為前面的nonce存在缺失，暫時無法被礦工打包，稱為不可執行交易。
那麼實際開發中，批量從一個地址發送交易時，應該怎麼辦呢？
方案一：那麼在批量從一個地址發送交易時， 可以持久化一個本地的nonce，構建交易時用本地的nonce去累加，逐一填充到後面的交易。（要注意本地的nonce可能會出現偏差，可能需要定期從區塊中重新獲取nonce，更新至本地）。這個方法也有一定的局限性，適合內部地址（即只有這個服務會使用該地址發送交易）。
說到這里還有個坑，許多人認為通過 eth.getTransactionCount(address, "pending") ，第二個參數為 pending ， 就能獲得包含本地交易池pending隊列的nonce值，但是實際情況並不是這樣， 這里的 pending 只包含待放入打包區塊的交易， 假設已寫入交易區塊的數量為20， 又發送了nonce為21，22，23的交易， 通過上面方法取得nonce可能是21（前面的21，22，23均未放入待打包區塊）， 也可能是22（前面的21放入待打包區塊了，但是22，23還未放入）。
方案二是每次構建交易時，從geth節點的pending隊列取到最後一筆可執行交易的nonce, 在此基礎上加1，再發送給節點。可以通過 txpool.content 或 txpool.inspect 來獲得交易池列表，裡面可以看到pending及queue的交易列表。
啟動節點時，是可以設置交易池中的每個地址的pending隊列的容量上限，queue隊列的上容量上限， 以及整個交易池的pending隊列和queue隊列的容量上限。所以高並發的批量交易中，需要增加節點的交易池容量。
當然，除了擴大交易池，控制發送頻率，更要設置合理的交易手續費，eth上交易寫入區塊的速度取決於手續費及eth網路的擁堵狀況，發送每筆交易時，設置合理的礦工費用，避免大量的交易積壓在交易池。
Ⅵ Gas 機制是如何運作的
以太坊是目前第二大公鏈，它和比特幣不一樣，以太坊上的可以實現的功能更多，如果比特幣是一個可以進行加減乘除的計算器，那麼以太坊就是一台功能完備的計算機。以太坊系統的復雜度超過比特幣好幾個數量級。
在以太坊中，用戶可以自己寫一個智能合約，然後把智能合約放到以太坊中執行。智能合約的執行需要消耗資源，而以太坊上的資源是有限的。
在計算機系統中，停機問題（https://zh.wikipedia.org/wiki/停機問題）目前還沒有辦法完全證明。這個問題簡單來說就是沒辦法判斷一個程序是否能夠在有限的時間內結束運行。
如果一個用戶提交了一個死循環程序到以太坊中，那麼就會無限的執行下去，從而將以太坊網路擊垮。而使用 gas 機制則可以解決這個問題，智能合約中，每段代碼的執行都會消耗一定量的 gas，在用戶提交交易的時候需要指定好。如果 gas 消耗完了，那麼智能合約就必須停止，交易也會被撤銷，如果智能合約執行完成， gas 還有剩餘，就會退還給用戶。
需要特別說明的是，即使交易失敗，用戶也需要支付 gas 費用，因為以太坊為這些錯誤的交易也付出了計算資源。
除了這點之外，gas 還可以用來激勵礦工，用戶提交交易所消耗的 gas 費用最後都會給到礦工，礦工會優先去打包那些提供了更高 gas 價格的交易，在以太坊中，如果希望自己的交易早點被打包，可以設置更高的 gas 價格。
g as 機制是以太坊系統的命脈。
gas 本質就是維護以太坊網路安全，這是從兩個方面來做到的，一方面通過 gas 來衡量計算量，一方面使用 gas 來吸引更多的礦工，礦工的數量越多，以太坊網路就越安全。
gas 只能用於交易中，用戶不會接觸到 gas，gas 會在交易的提交的時候直接通過以太幣來兌換。
智能合約中，每個操作都會消耗一定的 gas 。每個操作都對應一個 Opcode，下面是一些常見的 gas 消耗，完整的 gas 消耗說明看這里：https://github.com/crytic/evm-opcodes
以太坊中的交易最後會被確認，打包成區塊，這樣交易才算是完成，但是在一個區塊中，可以打包的交易是有限的，以太坊通過 gas 來限制可以打包的交易數。這樣就讓被打包的機會成為了一個稀缺的資源。
用戶提交一個交易後，gas 量可以看做是一個固定的值，礦工為了做到最大收益，就會選擇那些 gas 價格更高的交易。
很多以太坊的用戶經常吐槽 gas 費過高，其實這里的過高不是指 gas 本身過高，而是指 gas 對應的以太坊價格過高。
因為 Gas 的價格不是固定的，而是波動的，簡單來說就是根據供需關系來決定的，如果同時需要用以太坊的用戶多，那麼Gas 的價格就貴，如果用戶的人少，那麼 Gas 的費用就會少。
以太幣的最基本單位是 wei，1 ETH = 10 ^18 wei，而衡量 gas 價格的單位則是 gwei，1 ETH = 10 ^ 9 gwei。
在提交交易的時候，需要設定兩個參數，一個是 gas 的最大消耗量（gas limited）和 gas 的價格，gas 的消耗量通常情況下會比較固定，不會有太大的變化，主要是 gas 的價格會波動很大。
在上面我們說到礦工會挑選那些 gas 費用比較高的交易進行打包。所以 gas 的價格設置得越高，那麼總的 gas 費用就會越高。如果想讓當前的交易盡快被確認，那麼就需要設置一個當前相對來說比較高的 gas 價格。
其實對當前 gas 價格最清楚的就是那些礦工，所以礦工們也提供了一些服務，讓用戶可以實時地了解到當前 gas 價格的分布。比如 GasNow 就是一個比較常用的服務，現在很多錢包中都在使用這個來為錢包的用戶提供 gas 價格建議。
如果你提交的交易不緊急，那麼使用當前的平均 gas 價格就可以，如果需要提交緊急的交易，那麼就需要設置更高的 gas 價格。
文 / Rayjun
Ⅶ 交易是如何打包進區塊的
一直以來有困惑
1.私鑰確定是完全不能重復的嗎？雖然是256位二進制。
2.節點說的是礦工節點嗎，還是所有的節點
3.礦工是如何一邊打包交易一邊破解隨機數的，交易被確認的過程不是在網路中廣播的過程嗎？
比如，我在打包，你也在打包，咱們倆是打的同一個嗎？
還是各自打包各自的，誰破解謎題了誰的區塊就得到認可。
或者說咱們面對的是同一個交易池嗎？
我不能理解的是交易是如何被打包進區塊的，比如有一萬筆交易，只有1000筆被確認，但是這一萬筆都被廣播了，莫非會有一些處於「未確認」的狀態？等待著被打包進下一個區塊？
在區塊鏈研習社咨詢後，思路清晰了許多。
1、私鑰並不是完全不重復，只是說在地球上，這種重復的概率幾乎為0 ；
私鑰是程序生成的256位二進制的隨機數。他的大小是10^76這個量級的。宇宙所有原子的量級大概是10^80。重復的概率微乎其微。
2、節點就是礦工，你的電腦也可以作為一個節點，雖然算力很小；
3、交易在一個內存池（隊列）里，礦工嘗試打包，取出交易，計算難題，計算出來了，於是加上自己的簽名，完成確認過程。沒有準確的時間先後的問題。
但是我還有疑惑，是不是可以這樣理解，在未找到答案之前，有許多區塊，誰找到答案，誰的區塊就被打到區塊鏈中，進而區塊中的交易被確認，並且可以進行下一步的交易。
接著就有了下面的回答：
一個交易可能在不同的節點上的隊列里 ，就像你在一班排第三，在三班可能排第九。
然後有一個區塊打包會包含這個交易，其他節點處理是會把交易拋棄掉。所以，一個交易只能被包含到一個區塊里。
區塊提交後，其他節點進行同步，同步該區塊，並對區塊中的每個交易進行驗證，如果發現有交易是本地隊列已經有的，就將該交易從自己的隊列里剔除。
又有了新的困惑，不是說驗證只需要查默克爾樹嗎，為何要對每筆交易都驗證？按理說是需要驗證每筆交易，這樣才能有效剔除自己隊列中的交易。那麼，是不是在後期查詢中需要默克爾樹呢？
下一步的解惑。