Khối phức tạp

Tác giả: BitMEX Research

Nguồn: BitMEX

Tóm tắt: Trong bài viết này, chúng ta sẽ thảo luận về “các khối được bảo mật” – các khối được thiết kế đặc biệt để khó xác minh. Các khối như vậy được hình thành khi ai đó có thái độ thù địch với Bitcoin và tạo ra“các giao dịch được bảo mật” (các giao dịch được thiết kế đặc biệt để nút mất nhiều thời gian xác minh). Khái niệm này lần đầu tiên được thảo luận vào tháng 1 năm 2013 khi một giao dịch được bảo mật có kích thước gần 1MB xuất hiện, yêu cầu khoảng 3 phút để xác minh trên một máy tính thông thường. Có những biến thể của cuộc tấn công này có thể làm trầm trọng thêm tình hình gấp nhiều lần, nhưng chúng sẽ không được thảo luận chi tiết ở đây. Đề xuất soft fork BIP-54 bao gồm một bản sửa lỗi: giới hạn tổng số mã lệnh CHECKSIG và CHECKMULTISIG có thể được sử dụng với đầu vào không phải Segregated Witness của giao dịch.

Tổng quan

Đây là bài viết thứ tư trong sê-ri về các lỗ hổng tiềm tàng Bitcoin có thể được khắc phục hoặc giảm thiểu theo BIP-54.

1. Các giao dịch trùng lặp của Bitcoin - Tháng 3 năm 2025 ( Bản dịch tiếng Trung )
2. Cuộc tấn công xuyên thời gian - Tháng 3 năm 2025 ( Bản dịch tiếng Trung )
3. Giao dịch 64 byte - Tháng 12 năm 2025 ( Bản dịch tiếng Trung )

Trong bài viết cuối cùng này, chúng ta sẽ khám phá một trong những lỗ hổng tiềm tàng nghiêm trọng nhất: khả năng xuất hiện các khối độc hại; điều này có thể khiến một nút mất rất nhiều thời gian để xác minh chúng. Vấn đề này thường được gọi là "vấn đề xác minh khối tồi tệ nhất".

Nguồn gốc của vấn đề

Vào tháng 1 năm 2013, nhà nghiên cứu bảo mật Bitcoin Sergio Lerner đã đăng trên diễn đàn Bitcointalk giải thích rằng có thể tạo ra một giao dịch Bitcoin hợp lệ mà một nút cần ít nhất 3 phút để xác minh. Phương pháp này liên quan đến việc tạo ra một giao dịch với nhiều đầu vào (xét đến dòng thời gian lịch sử, cụ thể là loại kịch bản Segregated Witness). Những đầu vào này gặp phải vấn đề được gọi là "lạm phát bậc hai của thao tác SIGHASH".

Sergio giải thích rằng một giao dịch Bitcoin có kích thước gần 1MB có thể tạo ra hơn 19GB dữ liệu băm, cần ít nhất 3 phút để xác minh trên một máy tính thông thường. Giới hạn kích thước khối 1MB hạn chế mức độ nghiêm trọng của vấn đề này; nếu không có giới hạn đó, cuộc tấn công có thể nghiêm trọng hơn nhiều. Trong ví dụ của Sergio, giao dịch không hợp lệ, nhưng cuộc tấn công vẫn được coi là nghiêm trọng vì nó buộc một nút phải dành một lượng thời gian đáng kể để xác định xem giao dịch đó hợp lệ hay không. Hơn nữa, việc dành 3 phút để xác minh một giao dịch duy nhất rõ ràng là một vấn đề nghiêm trọng. Chúng tôi đã liệt kê một số vấn đề tiềm ẩn trong bảng bên dưới.

Hậu quả tiêu cực của các giao dịch phức tạp

cuộc chiến kích thước khối

Vấn đề về các khối phức tạp cũng xuất hiện trong "Cuộc chiến kích thước khối" (kéo dài từ năm 2015 đến năm 2017), như một lý do để không tăng giới hạn kích thước khối; ít nhất, cần phải bổ sung các giới hạn mới để hạn chế tác động của vấn đề này.

Vào tháng 12 năm 2015, nhà nghiên cứu bảo mật Bitcoin Jonas Nick đã trình bày về chủ đề này tại hội nghị "Scaling II" ở Hồng Kông. Ông giải thích lý do tại sao giới hạn kích thước khối không nên được tăng lên trừ khi có thêm giới hạn sử dụng tài nguyên mới cho các khối Bitcoin để giảm thiểu tác động của các cuộc tấn công như vậy.

- Nguồn hình ảnh: https://youtu.be/vfIs_trEhao?si=oRu2x6CfWhFbxG2R&t=3692 -

Vào tháng 1 năm 2016, một bài đăng trên blog xuất hiện trên trang web dự án Bitcoin Core giải thích những lợi ích của "SegWit". Một lợi thế quan trọng của SegWit là nó đã khắc phục lỗi mở rộng phi tuyến tính trong hoạt động SIGHASH. Đây là lý do tại sao SegWit dường như là một giải pháp mạnh mẽ cho vấn đề mở rộng quy mô Bitcoin: nó duy trì giới hạn kích thước 1MB cho các định dạng giao dịch cũ hơn (có khả năng gây ra vấn đề) trong khi tăng kích thước khối cho các định dạng giao dịch không có lỗi nghiêm trọng này.

Về cơ bản, việc tăng gấp đôi kích thước giao dịch sẽ làm tăng gấp đôi cả số lượng thao tác ký và lượng dữ liệu cần được băm để xác minh mỗi chữ ký. Điều này đã được quan sát thấy trong hoàn cảnh không phải thử nghiệm: một khối đơn thông thường có thể được xác minh chỉ trong 25 giây, trong khi một giao dịch tạo ra một cách độc hại có thể mất hơn 3 phút để xác minh.

— Chế độ phúc lợi riêng biệt cho nhân chứng ( Bản dịch tiếng Trung )

Vào tháng 3 năm 2021, chúng tôi đã xuất bản một cuốn sách về cuộc chiến kích thước khối, trong đó cũng thảo luận về vấn đề xác minh khối trong trường hợp xấu nhất. Chúng tôi đã đề cập rằng việc xác minh một khối như vậy có thể mất "vài giờ" - một sự khác biệt đáng kể so với con số "3 phút" phổ biến từ năm 2013 đến năm 2016. Điều này là do một số nhà nghiên cứu bảo mật Bitcoin đã đề xuất với chúng tôi rằng họ đã tìm ra cách để tối đa hóa việc khai thác cuộc tấn công này, do đó làm trầm trọng thêm tình hình và cần vài giờ để xác minh. Tuy nhiên, mặt khác, có lẽ con số "vài giờ" của chúng tôi cũng hơi thiếu thực tế, trừ khi bạn đang sử dụng một thiết bị có cấu hình khá thấp (chẳng hạn như Raspberry Pi).

Sự gia tăng phi tuyến tính của các thao tác SIGHASH có nghĩa là khi số lượng đầu vào của một sàn giao dịch tăng lên, số lượng thao tác băm sàn giao dịch tăng theo cấp số nhân, chứ không phải phi tuyến tính. Vấn đề gia tăng này là một trở ngại cho việc tăng giới hạn kích thước khối vì (sau khi loại bỏ giới hạn) kẻ tấn công có thể tạo ra các giao dịch mất rất nhiều thời gian để xác minh, đủ lâu để làm tê liệt toàn bộ mạng lưới. Kẻ tấn công thậm chí có thể tạo ra một khối chứa nhiều giao dịch lớn như vậy, đòi hỏi một máy tính trung bình vài giờ để xác minh. Do đó, đối với nhiều người ủng hộ khối nhỏ, việc khắc phục vấn đề này là điều kiện tiên quyết để tăng giới hạn kích thước khối. Họ chế giễu những người ủng hộ khối lớn vì sự tự mãn khi không nhận thấy điểm yếu này và vì thiếu tư duy phản biện.

— Cuộc chiến kích thước khối

Phép toán số học của các khối độc hại

Trong phần này, chúng ta sẽ giải thích chi tiết hơn về cuộc tấn công này. Khi kẻ tấn công chuẩn bị các khối khó giải mã, chúng cần xem xét ba ràng buộc đồng thuận Bitcoin:

Để phục vụ mục đích tính toán, chúng tôi giải thích hình thức cơ bản nhất của cuộc tấn công này, thậm chí còn đơn giản hơn ví dụ của Sergio năm 2013 — mặc dù chắc chắn là một sự đơn giản hóa quá mức. Ý tưởng là kẻ tấn công trước tiên tạo ra một số giao dịch khởi tạo, có thể giả định được đặt trong một khối riêng biệt để tránh chiếm dụng không gian 1MB của khối thực sự kích hoạt cuộc tấn công. Trong các giao dịch khởi tạo này, kẻ tấn công tạo ra nhiều đầu ra, mỗi đầu ra chứa 200 mã lệnh OP_CHECKSIG . Với các đầu ra này, kẻ tấn công đã sẵn sàng tạo ra giao dịch tấn công thực sự. Giao dịch tấn công này sử dụng tất cả các đầu ra này làm đầu vào, và (trong kịch bản của chúng tôi) có thể dành riêng một đầu ra cho chính nó. Mỗi đầu vào chứa một CHECKSIG có ý nghĩa và 200 CHECKSIG vô nghĩa (lấp đầy không gian 10KB có sẵn cho một tập lệnh duy nhất). Điều này sử dụng tất cả không gian có sẵn, do đó tối đa hóa sức mạnh của cuộc tấn công.

Với một giao dịch tấn công như vậy, chúng ta sử dụng công thức xấp xỉ rất cơ bản sau đây để tính toán tổng lượng dữ liệu cần băm khi xác minh giao dịch tấn công. Lưu ý rằng công thức bên dưới bao gồm một số hạng bình phương cho số lượng đầu vào để phản ánh lỗi lạm phát bậc hai trong hoạt động SIGHASH: càng nhiều đầu vào, càng cần nhiều dữ liệu được băm, và đây là mối quan hệ bậc hai.

总共需要哈希的数据（KB） = 201 * N * (10KB + N)其中N 为交易输入的数量

Sử dụng công thức trên, chúng tôi đã vẽ đồ thị sau, phản ánh cách lượng dữ liệu cần được băm phụ thuộc vào số lượng đầu vào trong giao dịch tấn công. Hình dạng của đường cong này cho thấy một hàm bình phương. Công thức trên không chính xác và không tính toán chính xác lượng dữ liệu cần được băm; mục đích của nó chỉ là để minh họa: để minh họa một cách sơ lược vấn đề lạm phát này và các mối quan hệ toán học trong đó.

Số lượng dữ liệu cần băm so với số lượng đầu vào giao dịch

Trục hoành của bảng này dừng lại ở mức hơn 8.000 mục nhập vì kích thước giao dịch hiện đã gần 1MB, đây là dung lượng tối đa mà một giao dịch có thể sử dụng trước khi có Segregated Witness. Để xác minh giao dịch này, nút cần băm hơn 30GB dữ liệu. Đây là một giao dịch tấn công, và trong trường hợp rất cơ bản (và có thể không chính xác) của chúng tôi, đây là kịch bản xấu nhất mà nó có thể gây ra. Theo hiểu biết của chúng tôi, lượng dữ liệu cần được băm (không phải số lượng xác minh chữ ký ECDSA) là chỉ báo quan trọng về mức độ nguy hiểm của các giao dịch phức tạp như vậy, vì vậy chúng tôi chỉ tập trung vào chỉ báo này.

Mỗi KB mã băm mất 0,005 ms (mili giây) – một dữ liệu Jonas Nick đã đề cập trong bài thuyết trình năm 2015 trên một chiếc máy tính xách tay năm 2014 (sử dụng CPU i7 lõi ​​kép 3GHz). Biểu đồ bên dưới minh họa thời gian các giao dịch bị tấn công này có thể mất để xác minh. Trong trường hợp xấu nhất, việc xác minh một giao dịch duy nhất có thể mất hơn 150 giây, hoặc hơn hai phút rưỡi. Đây rõ ràng là một lỗ hổng nghiêm trọng. Trong một báo cáo gần đây ( bản dịch tiếng Trung ) về hiệu suất nút, nút của chúng tôi thường xác minh 15 khối mỗi giây. Do đó, các khối khó xác minh này làm chậm đáng kể tốc độ xác minh (so với các khối thông thường), khoảng 2300 lần.

Hãy kiểm tra xem thời gian dành cho việc tấn công sàn giao dịch có bằng chứng là bao nhiêu so với số lượng dữ liệu đầu vào được gửi đến sàn giao dịch tấn công hay không.

Tuy nhiên, các thiết bị hiện nay nhanh hơn nhiều so với các thiết bị năm 2015, và dữ liệu đầu vào có thể được xác thực song song. Do đó, mốc thời gian xác thực nêu trên có thể hơi thận trọng đối với các thiết bị hiện nay.

(Ghi chú của người dịch: Không phải tất cả nút trên mạng Bitcoin đều sử dụng thiết bị mới nhất; một số nút có thể có sức mạnh tính toán tương đương với CPU lõi kép i7 năm 2015.)

Các biện pháp khắc phục BIP-54

Giải pháp được đề xuất trong BIP-54 tương đối đơn giản: thêm các ràng buộc đồng thuận mới vào từng giao dịch để giới hạn số lượng các yếu tố sau:

1. Mã lệnh CHECKSIG và CHECKMULTISIG trong tất cả các đầu vào chứng thực không bị cô lập.
2. Khóa công khai của tập lệnh được xuất ra ở bước trước đó.

Nếu tổng giá trị của hai khoản mục nêu trên trong một giao dịch vượt quá 2500, giao dịch đó sẽ được coi là không hợp lệ.

Với những bản sửa lỗi này, trong kịch bản được mô tả ở trên, một giao dịch tấn công sẽ chỉ chứa 12 đầu vào, một khối sẽ chỉ yêu cầu 24MB dữ liệu có thể băm được và quá trình xác minh sẽ chỉ mất 0,1 giây. Vấn đề dường như đã được giải quyết tốt, ít nhất là trong trường hợp cơ bản nhất của chúng ta.

tóm lại

Xin nhắc lại, các phép tính và ví dụ của chúng tôi cực kỳ cơ bản và quá đơn giản. Cũng có những kỹ thuật tinh vi có thể khiến các cuộc tấn công trở nên nghiêm trọng hơn đáng kể (gấp nhiều lần). Ví dụ, việc thêm đầu ra bằng cách sử dụng các đoạn mã dài có thể làm tăng thêm lượng dữ liệu cần được băm. Trong những trường hợp cực đoan này, một khối khó xác thực có thể leo thang thành khủng hoảng cho mạng Bitcoin, vì việc xác minh chỉ một khối có thể mất hơn một giờ, có khả năng khiến một số lượng lớn nút bị ngoại tuyến hoặc không bao giờ hoạt động trở lại.

May mắn thay, kiểu tấn công này cực kỳ phức tạp để thực hiện. Thứ nhất, nó yêu cầu gửi các giao dịch không chuẩn, mà có lẽ chỉ thợ đào có thể khởi xướng các cuộc tấn công như vậy. Ngay cả khi sử dụng các dịch vụ gửi giao dịch trực tiếp đến thợ đào(như Slipstream của Matathon), thợ đào cũng có thể có logic bảo mật tích hợp và sẽ không ngồi chờ hàng giờ để xác minh giao dịch đã gửi. Thứ hai, những trường hợp xấu nhất này liên quan đến nhiều giao dịch khởi tạo phức tạp chiếm một lượng lớn không gian khối trước khi các khối khó được tạo ra. Nếu kẻ tấn công không cẩn thận, ai đó đang theo dõi mạng Bitcoin có thể phát hiện ra các giao dịch khởi tạo này và cảnh báo người dùng về một soft fork khẩn cấp, điều này có thể ngăn chặn cuộc tấn công (hoặc không). Do đó, từ góc độ này, lỗ hổng này tương tự như một "cuộc tấn công bẻ cong thời gian".

Tuy nhiên, bất chấp sự phức tạp của cuộc tấn công, chúng tôi tin rằng đây là một vấn đề rất nghiêm trọng đối với Bitcoin cần được khắc phục. Có khả năng đây là vấn đề nghiêm trọng nhất trong bốn vấn đề mà BIP-54 dự định giải quyết. Chúng tôi đã xếp hạng bốn vấn đề này từ nghiêm trọng nhất đến ít nghiêm trọng nhất như sau:

1. Khối phức tạp
2. Cuộc tấn công bẻ cong thời gian
3. 64 giao dịch
4. Giao dịch chồng chéo

(qua)