Thời gian lan truyền và xác minh các khối phức tạp trên Signet

Tác giả: b10c

Nguồn: https://b10c.me/observations/16-slow-block-propagation-validation-signet/

Bài báo gốc được xuất bản vào tháng 4 năm 2026.

Trong sự kiện " Signet Hard Block Demo " tuần trước, tôi đã chạy một máy trạm P2P tùy chỉnh kết nối với tất cả (khoảng 190) nút Signet đang chạy trên IPv4 và Tor. Mục tiêu của tôi là đo tốc độ lan truyền các khối trên mạng và tốc độ mỗi nút xác minh một khối .

Bài viết này ban đầu được đăng trên bnoc.xyz .

Các số liệu cho thấy tốc độ lan truyền khối bị ảnh hưởng đáng kể vì nút phải chờ nút đã nhận được khối trước đó hoàn tất quá trình xác minh trước khi nhận được thông báo phản hồi blocktxn và bất kỳ giao dịch nào bị thiếu cục bộ, cho phép chúng bắt đầu tái tạo, xác minh và chuyển tiếp khối. Đối diện những khối khó khăn này, dù không phải là trường hợp xấu nhất, tốc độ xác minh đã giảm khoảng 160 lần trên nút hàng trung bình có thể quan sát được. Nút trung bình này mất 20 giây (s) để xác minh một khối khó khăn, trong khi việc xác minh một khối bình thường trên Signet chỉ mất 176 mili giây (ms).

(Ghi chú của người dịch: "Signet" là một mạng thử nghiệm Bitcoin sử dụng trình ký khối chuyên dụng. "Khối Hardcore" đề cập đến một khối có quá trình xác minh đặc biệt chậm.)

Phương pháp luận

Để đo tốc độ lan truyền và xác minh khối, hai loại sự kiện thông báo từ nút ngang hàng đặc biệt quan trọng:

Đầu tiên, thông báo khối dày đặc băng thông cao BIP-152 . Sau khi chúng tôi yêu cầu một khối dày đặc băng thông cao từ nút bằng cách sử dụng thông báo sendcmpct(1) , các nút sẽ gửi cho chúng tôi một thông báo cmpctblock càng sớm càng tốt sau khi chúng đã xây dựng khối và trước khi chúng xác minh nó. Khi máy trạm của chúng tôi nhận được một thông báo cmpctblock từ một nút, nó sẽ yêu cầu một giao dịch bằng cách gửi một thông báo getblocktxn . Sau khi máy nút đã xác minh khối, nó sẽ phản hồi bằng một thông báo blocktxn . Bằng cách ghi lại dấu thời gian của thông báo cmpctblock và thông báo blocktxn đến cục bộ, chúng ta có thể suy đoán thời gian xác minh. Dấu thời gian của cmpctblock cũng cho biết tốc độ lan truyền khối (không bao gồm thời gian xác minh).

Thứ hai, thông báo INV khối dày đặc băng thông thấp (hoặc Block HeaderBIP-130 tương tự) cũng chứa thông tin. Những thông báo này xuất hiện sau khi nút đã xác minh khối.

Máy trạm P2P tùy chỉnh của chúng tôi cũng ghi lại ping gian khứ pong (RTT) của giao thức Bitcoin của mỗi nút , do đó cho phép điều chỉnh dấu thời gian của thông báo để bù đắp độ trễ ở lớp mạng và lớp ứng dụng.

Thời gian lan truyền khối là sự khác biệt giữa dấu thời gian của thông báo và dấu thời gian của thông báo đầu tiên về khối mà chúng ta nhận được. Cả hai dấu thời gian đều được điều chỉnh bằng RTT, với số hạng điều chỉnh là $\frac{1}{2}$ RTT: $\textit{ts_adjusted} = \textit{ts_raw} - \frac{1}{2} \textit{RTT}$. Chúng ta giả định rằng RTT đối xứng với ¹ .

Thời gian xác minh khối là sự khác biệt về thời gian giữa việc một nút ngang hàng gửi cho chúng ta thông báo khối dày đặc băng thông cao và việc nó gửi thông tin phản hồi blocktxn tương ứng, được biểu thị là ^2. Chúng ta không biết dấu thời gian của nút ngang hàng gửi tin nhắn cho chúng ta, nhưng chúng ta có thể tính toán nó từ dấu thời gian nhận tin nhắn và RTT. Toàn bộ quá trình tuân theo trình tự thời gian này:

Sơ đồ trình tự sự kiện này thể hiện khoảng thời gian mà chúng tôi đã đo được.

• $t_0$: Nút ngang hàng đã hoàn thành việc tái tạo khối và gửi cho chúng tôi thông báo khối dày đặc băng thông cao.
• $t_1$: Chúng tôi đã nhận được thông báo khối dày đặc băng thông cao ($t_0$ theo sau là $\frac{1}{2} RTT$).
• $t_2$: Chúng ta gửi yêu cầu getblocktxn (giả sử nó diễn ra tức thời).
• $t_3$: Nút ngang hàng đã nhận được yêu cầu getblocktxn ($t_2$ theo sau là $\frac{1}{2} RTT$).
• $t_4$: Nút ngang hàng hoàn tất xác minh khối và gửi blocktxn (thời gian không xác định).
• $t_5$: Chúng tôi đã nhận được blocktxn ($t_4$ tiếp theo là $\frac{1}{2} RTT$)

Chúng ta muốn đo khoảng thời gian giữa hai điểm thời gian $t_0$ và $t_4$ ($= d$). Đối diện một nút ngang hàng, ta có $t_1$ (và $t_2$), $t_5$ và RTT. Tuy nhiên, vì một chu trình truyền tin khứ hồi hoàn chỉnh phải được hoàn thành giữa $t_0$ và $t_4$, khi thời gian xác minh khối ngắn hơn RTT, ta chỉ có thể thu được giới hạn trên của khoảng thời gian xác minh. Trong trường hợp này, $d ≈ RTT$.

$$
\begin{align}
t_0 &= t_1 - \frac{1}{2} \textit{RTT} \\
t_2 &= t_1 \\
t_3 &= t_1 + \frac{1}{2} \textit{RTT} \\
t_4 &= t_5 - \frac{1}{2} \textit{RTT} \\
d &= t_4 - t_0 \\
\textit{dài hơn rtt} &= d > \textit{RTT}
\end{align}
$$

Đối với riêng RTT, chúng tôi sử dụng giá trị trung vị của RTT được ghi nhận trong suốt thời gian hoạt động kết nối.

kết quả

Sự lan truyền khối

Về việc lan truyền khối, chúng tôi đã quan sát thời gian cần thiết để một nút ngang hàng thông báo về một khối sử dụng khối dày đặc băng thông cao và thời gian cần thiết để thông báo khối thông qua tin nhắn INV. Chúng tôi cũng phân biệt giữa các khối thông thường và các khối phức tạp được xây dựng đặc biệt.

- Tốc độ lan truyền INV của các khối thông thường và các khối phức tạp được xây dựng đặc biệt, và tốc độ lan truyền ECDF của các khối dày đặc -

Trên cả hai loại khối—khối thông thường và khối phức hợp được xây dựng đặc biệt—thông báo khối dày đặc băng thông cao lan truyền nhanh hơn thông báo INV. Điều này là điều dễ hiểu vì thông báo khối dày đặc băng thông cao được gửi trước khi khối được xác minh, trong khi thông báo INV chỉ được gửi sau khi khối đã được xác minh.

Thời gian lan truyền của các khối thông thường trên Signet (đường màu xanh lá cây) và thời gian lan truyền của các khối dày đặc (đường màu xanh lam) là tương tự nhau. Các kênh khối thông thường trên Signet không chứa nhiều giao dịch và có thể được xác minh nhanh chóng. Nút nằm trong nhóm 25% đầu tiên sẽ thông báo khối của chúng cho chúng tôi sau 150ms; nút ở vị trí trung bình chậm hơn một chút, hơn 200ms; nút ở nhóm 75% chậm hơn 300ms; sau 600ms, 90% nút ngang hàng đã xác minh khối của chúng và gửi thông báo cho chúng tôi.

- (Chỉ áp dụng cho các khối khó) ECDF lan truyền khối-

Sự lan truyền của các khối khó có sự khác biệt đáng kể. Trong khi các thông báo khối dày đặc băng thông cao (đường màu vàng) đến trước các thông báo INV, nút ở phân vị thứ 25 gửi cho chúng ta thông báo khối dày đặc băng thông cao khoảng 14 giây sau đó; các thông báo INV nút đến sau 27,5 giây. Nút trung vị gửi thông báo khối dày đặc của nó khoảng 26 giây sau đó, tiếp theo là thông báo INV của nó sau 31,7 giây. Nút ở phân vị thứ 75 gửi thông báo khối dày đặc của nó sau 31,7 giây và thông báo INV của nó sau 55 giây. Nút ngang hàng ở phân vị thứ 90 thông báo khối khó của nó là một khối dày đặc sau 58 giây và sau đó thông báo nó thông qua một thông báo INV sau 114 giây.

Điều này cho thấy tốc độ lan truyền khối phụ thuộc vào hiệu suất xác minh. Các khối dễ xác minh hơn sẽ lan truyền nhanh hơn, và các khối khó xác minh hơn sẽ lan truyền chậm hơn. Điều này có vẻ dễ hiểu, vì nút cần xác minh một khối trước khi lan truyền nó. Tuy nhiên, điều quan trọng cần lưu ý là sự chậm lại này chỉ xảy ra khi nút cần yêu cầu một giao dịch bằng cách sử dụng getblocktxn . Nếu nút không cần yêu cầu một giao dịch, ví dụ, vì nhóm giao dịch của nó chứa tất cả các giao dịch trong khối, nó có thể ngay lập tức xây dựng lại khối và bắt đầu xác minh nó sau khi nhận được thông báo cmpctblock . Các giao dịch khó trong các khối chậm là không chuẩn và yêu cầu getblocktxn để yêu cầu. Nếu kỹ thuật "điền trước khối dày đặc" được triển khai, như bài đăng này đã nêu, thì các khối khó cũng có thể lan truyền nhanh hơn. Trong bản trình diễn lần, tất cả các khối khó này chỉ chứa một giao dịch khó duy nhất có kích thước 999kvB. Việc điền trước giao dịch này có thể không giúp ích gì, vì nó đơn giản là quá lớn.

Xác minh khối

Để đo thời gian xác thực khối, chúng tôi chỉ quan sát các thông báo khối dày đặc băng thông cao và các phản hồi blocktxn . Cụ thể, khoảng thời gian d của chúng tôi được định nghĩa là d = t4 - t0 (như đã nêu trước đó). Khi thời gian xác thực thực tế thấp hơn RTT, giá trị chúng tôi đo được sẽ là giới hạn trên của thời gian xác thực thực sự. Điều này có nghĩa là thời gian xác thực thực tế có thể ngắn hơn giá trị chúng tôi đo được.

- Phân bổ thời gian xác thực cho các khối thông thường và các khối khó -

Biểu đồ trên thể hiện thời gian xác thực cho các khối thông thường và các khối phức hợp được xây dựng đặc biệt. Đối với một số khối thông thường, chúng ta chỉ đo giới hạn trên; thời gian xác thực thực tế có thể rộng hơn.

Thời gian xác thực đối với các khối thông thường trên Signet dao động từ 10ms đến 2s, trong khi thời gian xác thực đối với các khối gặp sự cố dao động từ 2,5s đến 5 phút.

- ECDF cho thời gian xác minh khối -

Đối với các khối thông thường (bao gồm cả những khối chỉ đo giới hạn trên của thời gian xác thực), phân vị thứ 25 của thời gian xác thực khối là 37ms; phân vị thứ 50 là 176ms; phân vị thứ 75 là 447ms; và phân vị thứ 90 là 740ms. Phần lớn nút lắng nghe trên mạng Signet có thể xác thực các khối thông thường trong vòng 1 giây.

Đối với các khối khó, giá trị ở phân vị thứ 25 là 8,2 giây; giá trị ở phân vị thứ 50 là 19,7 giây; giá trị ở phân vị thứ 75 là 32 giây; và giá trị ở phân vị thứ 90 là 78,3 giây.

Để hình dung tốc độ xác thực này một cách trực quan, chúng ta có thể sử dụng thời gian xác thực trung bình của các khối thông thường trên nút ngang hàng làm chuẩn. Sau đó, chúng ta so sánh nó với thời gian xác thực trung bình của các khối khó đối với nút đó và tính toán hệ số nhân.

- Làm chậm thời gian xác minh cho các khối phức tạp (ECDF) -

Trong số nút, nhóm có nút thứ 10 chậm hơn 13,5 lần; nhóm ở phân vị thứ 25 chậm hơn 31 lần; nhóm ở phân vị thứ 50 chậm hơn 159,4 lần; nhóm ở phân vị thứ 75 chậm hơn 793 lần; và nút thứ 90 chậm hơn 1156 lần. Có vẻ như có sự khác biệt đáng kể về hiệu suất giữa nút lắng nghe trên mạng Signet khi xác thực các khối phức tạp này.

Khi phân tích dữ liệu này, chúng ta phải nhớ rằng đây chỉ là những khối dữ liệu khó mà Antoine đã chọn để tiết lộ, và chúng còn xa mới là những khối dữ liệu khó nhất có thể được tạo ra để xác minh.

Độ chính xác của phương pháp đo này

Để kiểm chứng độ chính xác của phương pháp đo, chúng ta có thể xem tệp debug.log của Bitcoin Core trong tab khởi động -debug=bench -debug=validation -debug=net -logtimemicros=1 , sau đó so sánh thời gian xác thực thực tế với thời gian xác thực đã đo được.

Ảnh chụp màn hình debug.log bên dưới hiển thị khối cứng đầu tiên trong vòng đầu tiên của bản demo mà nút theo dõi của tôi đã trải nghiệm (xem delvingbitcoin.org để biết chi tiết). Tôi cũng đã thêm bốn đánh dấu( [m1] [m2] [m3] [m4] ).

 2026-04-08T14:05:12.292703Z [msghand] [cmpctblock] Successfully reconstructed block 0000000eb552c9f26e712d546c71297fd0623890299b40e7ada81d2dc32f5d0b with 1 txn prefilled, 0 txn from mempool (incl at least 0 from extra pool) and 1 txn (999557 bytes) requested2026-04-08T14:05:12.292795Z [msghand] [cmpctblock] Reconstructed block 0000000eb552c9f26e712d546c71297fd0623890299b40e7ada81d2dc32f5d0b required tx 1b44e7f59d39e4d53b4c4a77a650561de1871fe962fe6a17d1a302b877b2cb48[m1] 2026-04-08T14:05:12.422939Z [msghand] [validation] NewPoWValidBlock: block hash=0000000eb552c9f26e712d546c71297fd0623890299b40e7ada81d2dc32f5d0b2026-04-08T14:05:12.423680Z [msghand] [net] PeerManager::NewPoWValidBlock sending header-and-ids 0000000eb552c9f26e712d546c71297fd0623890299b40e7ada81d2dc32f5d0b to peer=52026-04-08T14:05:12.423794Z [msghand] [net] sending cmpctblock (358 bytes) peer=52026-04-08T14:05:12.543864Z [msghand] [bench] - Using cached block2026-04-08T14:05:12.543926Z [msghand] [bench] - Load block from disk: 0.07ms2026-04-08T14:05:12.543962Z [msghand] [bench] - Sanity checks: 0.01ms [0.00s (0.01ms/blk)]2026-04-08T14:05:14.166485Z [msghand] [bench] - Fork checks: 1622.48ms [1.96s (93.29ms/blk)]2026-04-08T14:05:14.643331Z [msghand] [bench] - Connect 2 transactions: 476.84ms (238.419ms/tx, 1.189ms/txin) [0.69s (32.64ms/blk)]2026-04-08T14:06:33.383188Z [msghand] [bench] - Verify 401 txins: 79216.70ms (197.548ms/txin) [79.43s (3782.32ms/blk)]2026-04-08T14:06:33.385563Z [msghand] [bench] - Write undo data: 2.39ms [0.07s (3.19ms/blk)]2026-04-08T14:06:33.385643Z [msghand] [bench] - Index writing: 0.11ms [0.00s (0.08ms/blk)]2026-04-08T14:06:33.385754Z [msghand] [validation] BlockChecked: block hash=0000000eb552c9f26e712d546c71297fd0623890299b40e7ada81d2dc32f5d0b state=Valid2026-04-08T14:06:33.385862Z [msghand] [bench] - Connect total: 80841.94ms [81.46s (3879.22ms/blk)]2026-04-08T14:06:33.832999Z [msghand] [bench] - Flush: 447.07ms [0.51s (24.52ms/blk)]2026-04-08T14:06:33.833198Z [msghand] [bench] - Writing chainstate: 0.27ms [0.00s (0.19ms/blk)]2026-04-08T14:06:33.833668Z [msghand] [validation] Enqueuing MempoolTransactionsRemovedForBlock: block height=299177 txs removed=02026-04-08T14:06:33.833839Z [msghand] UpdateTip: new best=0000000eb552c9f26e712d546c71297fd0623890299b40e7ada81d2dc32f5d0b height=299177 version=0x20000000 log2_work=43.630312 tx=29147716 date='2026-04-08T14:03:39Z' progress=1.000000 cache=15.3MiB(114240txo)2026-04-08T14:06:33.833856Z [msghand] [bench] - Connect postprocess: 0.66ms [1.57s (74.55ms/blk)][m2] 2026-04-08T14:06:33.833868Z [msghand] [bench] - Connect block: 81290.01ms [83.55s (3978.55ms/blk)]2026-04-08T14:06:33.833926Z [msghand] [validation] Enqueuing BlockConnected: block hash=0000000eb552c9f26e712d546c71297fd0623890299b40e7ada81d2dc32f5d0b block height=2991772026-04-08T14:06:33.833962Z [msghand] [validation] Enqueuing UpdatedBlockTip: new block hash=0000000eb552c9f26e712d546c71297fd0623890299b40e7ada81d2dc32f5d0b fork block hash=0000000bc5d91380fa9188acfabd6a59244e8e6e744b0a0ef07064968027e256 (in IBD=false)2026-04-08T14:06:33.834043Z [msghand] [validation] ActiveTipChange: new block hash=0000000eb552c9f26e712d546c71297fd0623890299b40e7ada81d2dc32f5d0b block height=299177[m3] 2026-04-08T14:06:33.834887Z [msghand] [net] received: headers (82 bytes) peer=102026-04-08T14:06:33.835052Z [msghand] [net] sending ping (8 bytes) peer=102026-04-08T14:06:34.062891Z [scheduler] [validation] MempoolTransactionsRemovedForBlock: block height=299177 txs removed=02026-04-08T14:06:34.063548Z [scheduler] [validation] BlockConnected: block hash=0000000eb552c9f26e712d546c71297fd0623890299b40e7ada81d2dc32f5d0b block height=2991772026-04-08T14:06:34.063728Z [scheduler] [validation] UpdatedBlockTip: new block hash=0000000eb552c9f26e712d546c71297fd0623890299b40e7ada81d2dc32f5d0b fork block hash=0000000bc5d91380fa9188acfabd6a59244e8e6e744b0a0ef07064968027e256 (in IBD=false)[m4] 2026-04-08T14:06:34.461329Z [msghand] [net] received: headers (82 bytes) peer=42026-04-08T14:06:34.461786Z [msghand] [net] sending ping (8 bytes) peer=11... -> p2p communication continues

• [m1] : Vào lúc 2026-04-08T14:05:12.422939 , NewPoWValidBlock đánh dấu sự bắt đầu của việc xác thực khối này.
• [m2] : Vào lúc 2026-04-08T14:06:33.833868 , nhật ký nhánh hiển thị Connect block: 81290.01ms
• [m3] : Vào lúc 2026-04-08T14:06:33.834887 , kết nối P2P về cơ bản đã được khôi phục.
• [m4] : Vào lúc 2026-04-08T14:06:34.461329 , chúng tôi đã kết thúc với UpdatedBlockTip (cập nhật đầu blockchain) và quá trình liên lạc P2P đã được khôi phục hoàn toàn.

Sự khác biệt giữa [m1] và [m4] là 82038ms, trong khi giá trị chúng tôi đo được là 82049ms (chỉ cách nhau 11ms). Nhìn lại vòng đầu tiên, sự khác biệt giữa hai giá trị này không phải lúc nào cũng nhỏ như vậy.

Sai số đo lường cao hơn xảy ra ở các khối giữa, có thể là do nút ngang hàng có lượng lớn tin nhắn P2P cần được xử lý trước khi phản hồi tin nhắn getblocktxn của chúng tôi hoặc thông báo về khối dày đặc tiếp theo. Ở đây, tỷ lệ sai lệch 1% là chấp nhận được. Cũng cần lưu ý rằng điều này không có nghĩa là các phép đo của chúng tôi đối với tất cả nút ngang hàng đều chính xác.

tóm lại

Chúng tôi đã đo thành công tốc độ lan truyền của các khối dữ liệu dày đặc băng thông cao và các khai báo INV giữa nút nghe trên mạng Signet. Khi các khối dữ liệu khó xuất hiện, tốc độ lan truyền của khối dữ liệu giảm đáng kể do chúng được phát sóng đồng thời.

Chúng tôi cũng đo thời gian xác thực khối. Trong điều kiện mạng Signet bình thường, việc xác thực khối đôi khi có thể nhanh hơn thời gian truyền thông khứ hồi giữa nút. Trong những trường hợp như vậy, chúng tôi chỉ có thể đo giới hạn trên của thời gian xác thực. Đối với các khối khó, chúng tôi đã đo được mức giảm thời gian xác thực gấp 160 lần đối với nút ở phân vị thứ 50 (sử dụng khối khó được hiển thị trong bản demo lần). Các khối khó yêu cầu hơn 20 giây để xác thực.

Các nghiên cứu trong tương lai có thể bao gồm việc tìm hiểu về thời gian lan truyền và xác minh khối trên mạng chính.

----

Tôi đã đăng tải sổ tay Jupyter mà tôi đã sử dụng để tạo ra các biểu đồ này tại đây . Mọi chỉnh sửa và mở rộng cho nghiên cứu này đều được hoan nghênh.

----

1. Điều này có thể không đúng trên Tor .

2. Đôi khi, đặc biệt là khi các khối quan trọng từ nhiều khối phức tạp đến nút hàng và được xếp vào hàng đợi để xác minh, chúng ta chỉ nhận được thông báo getblocktxn sau khi tất cả các khối trong hàng đợi đã được xác minh. Trong trường hợp này, tôi sử dụng thời điểm thông báo khối dày đặc tiếp theo. Những thông báo này được gửi trước khi quá trình xác minh khối tiếp theo bắt đầu.

(qua)