@JeffChen 8 February 2021 more from that month

做個紀錄，Bitcoin目前擴容需要攻克的瓶頸在哪邊 主要就是mempool無法100%同步與區塊傳播每一個hop都要重驗證一次完才能再轉傳: 不過就算這樣目前也是可以達到100TPS以上了 https://www.reddit.com/r/btc/comments/leqhqs/roadmap_to_32mb_blocks/gmjbm5c/?utm_source=reddit&utm_medium=web2x&context=3 The current bottlenecks are not actually with the propagation of the compressed block itself. Testing that I've done over the last two years have revealed more immediate issues. The current bottlenecks are actually the following: Transaction propagation over network connections with high (e.g. 5%) packet loss tends to be limited to around 100-200 tx/sec. This usually causes mempool desynchrony when transaction production nears or exceeds this rate. (Connectivity between China and not-China usually has high packet loss.) At least in BCHN, each hop of block propagation requires block validation to be finished by the sending node before propagation can be done whenever mempool synchrony is less than 100%. For a 32 MB block, block validation can take up to 10 seconds, which results in a block propagation rate of about 11 seconds per hop, or around a minute total. This is not good. The reason why block validation completion is required is that BCHN processes all network messages from a single peer in order (serially), and the block validation thread holds the cs_main lock for a really long time, which prevents most other network messages from being processed. While a node ("Alice") can forward a Compact Blocks message to their peers (e.g. "Bob") before block validation completes, problems happen if Bob doesn't have all of the transactions in their mempool (i.e. mempool synchrony < 100%). In this scenario, Bob will request the missing transactions with a getblocktxn message sent to Alice. Unfortunately, if Alice is currently validating the block (i.e. cs_main is locked), Alice will usually be unable to process and respond to that getblocktxn message until the block validation finishes, which can be 5 or 10 seconds later. This delay happens not because cs_main is required for processing the getblocktxn request itself, but because all messages need to be processed in order, and there will almost always be another message in the queue before the getblocktxn request that requires cs_main, which prevents the node from getting to the getblocktxn request. These issues are not helped by something like Xthinner, Graphene, or Blocktorrent, and these issues need to be fixed before those techniques can provide any benefit. The first issue can be resolved either by (a) switching to a network protocol (like KCP) that is more tolerant of packet loss or (b) changing the transaction propagation code to add some randomness to the order in which transactions are forwarded -- currently each TCP connection sends transactions in exactly the same order, which means that the total transaction throughput is equal to the best TCP connection's throughput, but if each connection used a random order, then the total throughput would be nearly equal to the sum of all connections' throughputs. The second issue can be resolved either by (c) making block validation way faster (as I was doing with !793 or (d) by giving BCHN the ability to process network messages from a single peer out of order so as to avoid being blocked by cs_main. Making any one of these four changes should make blocks a bit larger than 32 MB be within our safety margins. Doing all of them would likely make blocks of about 128 MB reasonable. There are also a few other performance issues that ought to be addressed soon (e.g. getblocktemplate is really slow when the mempool is full of long transaction chains), but they are less relevant for the consensus limit on block size, and more relevant to the sizes of the blocks that miners will voluntarily choose to create. KCP協議 https://codertw.com/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/587940/ #PttDigiCurrency