
Lỗ hổng bảo mật Bitcoin: Tấn công bóp méo thời gian
Tuyển chọn TechFlowTuyển chọn TechFlow

Lỗ hổng bảo mật Bitcoin: Tấn công bóp méo thời gian
Trong bài viết này, chúng tôi phân tích một lỗ hổng bảo mật của Bitcoin, được gọi là tấn công xoắn thời gian.
Bài viết: BitMEX Research

Tổng quan
Ngày 26 tháng 3 năm 2025, nhà phát triển Bitcoin Antoine Poinsot đã công bố một đề xuất cải tiến Bitcoin mới. Đây là một đề xuất nâng cấp mềm có tên gọi là "Làm sạch đồng thuận lớn". Bản nâng cấp này sửa chữa một số lỗ hổng và điểm yếu tồn tại trong giao thức Bitcoin từ nhiều năm nay. Một trong các lỗ hổng đó là vấn đề giao dịch trùng lặp mà chúng tôi đã thảo luận gần đây. Một lỗ hổng nghiêm trọng hơn nữa sẽ được sửa bởi bản nâng cấp mềm này được gọi là "tấn công bóp méo thời gian", chính là chủ đề của bài viết này.
Quy tắc bảo vệ dấu thời gian khối Bitcoin
Trước khi thảo luận về tấn công bóp méo thời gian, hãy cùng xem lại các quy tắc hiện tại nhằm ngăn chặn việc thao túng thời gian:
Quy tắc Thời gian quá khứ trung vị (MPT) — Dấu thời gian phải sau thời gian trung vị của mười một khối trước đó.
Quy tắc Khối trong tương lai — Dựa trên hằng số MAX_FUTURE_BLOCK_TIME, dấu thời gian không được vượt quá quá 2 giờ so với thời gian trung vị của các nút peer. Khoảng chênh lệch tối đa cho phép giữa thời gian do nút cung cấp và đồng hồ hệ thống cục bộ là 90 phút, đây là một lớp bảo vệ an toàn khác.
Quy tắc MPT nhằm đảm bảo khối không thể lùi quá sâu vào quá khứ, còn quy tắc khối trong tương lai ngăn chúng tiến xa về phía tương lai. Lưu ý rằng không thể áp dụng quy tắc tương tự như quy tắc khối trong tương lai để ngăn chặn dấu thời gian ở quá khứ, vì điều này có thể ảnh hưởng đến quá trình đồng bộ hóa blockchain ban đầu. Tấn công bóp méo thời gian liên quan đến việc giả mạo dấu thời gian để đẩy nó lùi rất xa về quá khứ.
Lỗi "thiếu một" của Satoshi
Trong Bitcoin, một chu kỳ điều chỉnh độ khó bao gồm 2016 khối, với mục tiêu 10 phút mỗi khối thì khoảng thời gian này tương đương khoảng hai tuần. Để tính toán điều chỉnh độ khó khai thác, giao thức tính toán sự chênh lệch dấu thời gian giữa khối đầu tiên và khối cuối cùng trong cửa sổ 2016 khối liên quan. Cửa sổ 2016 khối này chứa 2015 khoảng cách giữa các khối (tức là 2016 trừ đi một). Do đó, thời gian mục tiêu liên quan cần dùng là 60 giây * 10 phút * 2015 khoảng cách, bằng 1.209.000 giây. Tuy nhiên, giao thức Bitcoin lại sử dụng con số 2016 để tính toán mục tiêu: 60 giây * 10 phút * 2016 = 1.209.600 giây. Đây là một lỗi thiếu một. Đây là một sai lầm dễ mắc phải, và dường như Satoshi đã nhầm lẫn giữa số lượng khối và số lượng khoảng cách giữa các khối.
Mã nguồn gốc của Satoshi

Nguồn: https://sourceforge.net/p/bitcoin/code/1/tree//trunk/main.cpp#l687
Lỗi này khiến thời gian mục tiêu dài hơn 0,05% so với mức lẽ ra phải có. Do đó, khoảng thời gian mục tiêu của Bitcoin thực tế không phải là 10 phút, mà là 10 phút cộng thêm 0,3 giây. Lỗ hổng này không nghiêm trọng; thực tế, kể từ khi Bitcoin khởi chạy, khoảng thời gian trung bình luôn là 9 phút 36 giây, rõ ràng ngắn hơn 10 phút. Điều này xảy ra vì kể từ năm 2009, công suất băm trung bình liên tục tăng lên. Đó là lý do tại sao lần giảm thưởng cuối cùng diễn ra vào tháng 4 năm 2024 chứ không phải tháng 1 năm 2025. Chúng ta đã đi trước lịch trình. Dù sao thì, lỗi 0,3 giây của Satoshi cũng không đáng kể về tổng thể. Có lẽ một ngày nào đó, trong tương lai xa, khi giá cả và công suất băm ngừng tăng trưởng, lỗ hổng này có thể giúp chúng ta quay trở lại đúng tiến độ.

Mặc dù lỗi 0,3 giây này bản thân nó không phải là vấn đề lớn, nhưng tồn tại một vấn đề liên quan, đây là một lỗ hổng nghiêm trọng hơn. Việc tính toán độ khó dựa trên khối đầu tiên và khối cuối cùng trong mỗi cửa sổ 2016 khối là không chính xác. Theo quan điểm của chúng tôi, chu kỳ liên quan nên là sự khác biệt giữa khối cuối cùng của cửa sổ 2016 khối trước và khối cuối cùng của cửa sổ hiện tại. Đây dường như là cách hợp lý nhất để tính độ dài cửa sổ điều chỉnh độ khó, trong đó phạm vi thời gian bao phủ các cửa sổ điều chỉnh khác nhau. Nếu làm theo cách này, thì 2016 cũng sẽ là số khoảng cách đúng đắn để tính toán mục tiêu. Có thể lý do Satoshi mắc lỗi này là vì ông phải tính đến chu kỳ điều chỉnh độ khó đầu tiên, mà tại đó chưa tồn tại khối cuối cùng của chu kỳ trước.
Tấn công bóp méo thời gian
Tấn công bóp méo thời gian đối với Bitcoin lần đầu tiên được phát hiện vào khoảng năm 2011, khai thác lỗi mà Satoshi mắc phải trong việc tính toán độ khó. Để thực hiện cuộc tấn công, giả sử khai thác tập trung hoàn toàn 100%, thợ đào có thể đặt bất kỳ dấu thời gian nào mà giao thức cho phép. Trong cuộc tấn công, với hầu hết các khối, thợ đào sẽ đặt dấu thời gian tiến lên một giây so với khối trước đó, do đó chuỗi khối di chuyển về phía trước theo thời gian và tuân thủ quy tắc MTP. Để làm chậm tối đa việc di chuyển thời gian, thợ đào có thể giữ nguyên dấu thời gian trong sáu khối liên tiếp, rồi tăng thời gian thêm một giây ở khối tiếp theo, cứ như vậy tiếp tục. Điều này có nghĩa là dấu thời gian khối tiến một giây sau mỗi sáu khối.
Cuộc tấn công này dẫn đến việc chuỗi khối ngày càng tụt lại so với thời gian thực, độ khó tăng lên, khiến việc khai thác trở nên ngày càng khó khăn hơn. Tuy nhiên, để tăng hiệu quả của cuộc tấn công, ở khối cuối cùng của mỗi chu kỳ điều chỉnh độ khó, thợ đào sẽ đặt dấu thời gian về thời gian thực tế. Khối tiếp theo, tức là khối đầu tiên của mỗi cửa sổ điều chỉnh, sau đó được đặt lại về quá khứ, sớm hơn một giây so với khối thứ hai từ cuối của cửa sổ điều chỉnh độ khó trước đó. Cách làm này vẫn phù hợp với quy tắc MTP, vì trong trường hợp này, một khối bất thường sẽ không ảnh hưởng đến trung vị của 11 khối.
Khi thực hiện cuộc tấn công này, độ khó sau chu kỳ đầu tiên sẽ không bị ảnh hưởng. Tuy nhiên, sau chu kỳ điều chỉnh thứ hai kể từ khi bắt đầu tấn công, độ khó sẽ được điều chỉnh giảm xuống. Sau đó, thợ đào có thể tạo ra các khối cực kỳ nhanh chóng, có thể tạo ra một lượng lớn Bitcoin, rồi bán số coin này để thu lợi nhuận.
Giải thích đơn giản hóa
Vì chu kỳ độ khó gồm 2016 khối nên việc minh họa cuộc tấn công này bằng đồ thị có thể rất khó khăn. Vì vậy, chúng tôi đã tạo ra tình huống sau để cố gắng giải thích cuộc tấn công này.
-
Mỗi cửa sổ điều chỉnh độ khó có năm khối
-
Khoảng thời gian mục tiêu là 10 phút
-
Quy tắc MTP dựa trên ba khối cuối cùng
-
Dấu thời gian mỗi khối tăng thêm một phút, ngoại trừ khối cuối cùng của mỗi chu kỳ, khối này sử dụng dấu thời gian thực tế
Minh họa tấn công bóp méo thời gian

Như hình trên, có hai đường cong:
-
Đường cong đại diện cho thời gian thực của khối cuối cùng trong mỗi cửa sổ điều chỉnh độ khó. Khi thợ đào tìm thấy khối ngày càng nhanh hơn, độ khó giảm xuống, đường cong này trở nên ít dốc hơn
-
Đường thẳng đại diện cho các dấu thời gian bị thao túng ở các khối còn lại
Tính toán tấn công bóp méo thời gian Bitcoin
Bảng dưới đây cho thấy cách thợ đào có thể sử dụng cuộc tấn công này một cách cực đoan nhất để thao túng độ khó giảm xuống.

Lưu ý: Mức điều chỉnh độ khó tối đa mà giao thức cho phép trong bất kỳ chu kỳ nào là 4 lần, nhưng trong bảng trên chưa đạt đến mức này
Việc giảm độ khó trong mỗi chu kỳ dần tiệm cận mức hơi cao hơn 2,8 lần. Điều này xảy ra vì khi mỗi chu kỳ ngắn lại theo thời gian, tốc độ giảm độ khó cũng chậm dần.
Ở chu kỳ thứ 11 trong bảng, vào ngày thứ 39 của cuộc tấn công, hơn 6 khối được tạo ra mỗi giây, cụ thể là 10,9 khối mỗi giây. Tại thời điểm này, giới hạn về dấu thời gian được phân bổ bắt đầu phát huy tác dụng theo cách khác. Theo quy tắc MTP, thời gian phải tiến lên sau mỗi 6 khối, với bước tăng nhỏ nhất là 1 giây. Do đó, tại thời điểm này, theo hiểu biết của chúng tôi, dấu thời gian bắt đầu tiến nhanh hơn so với thời gian thực, đồng hồ chuỗi khối bắt đầu di chuyển về phía trước, tiến gần hơn đến thời gian thực tế nhưng vẫn còn cách xa rất nhiều. Dù vậy, cuộc tấn công vẫn có thể tiếp tục, độ khó tiếp tục giảm cho đến khi đạt mức tối thiểu cho phép.
Khả thi của cuộc tấn công
Mặc dù về mặt lý thuyết cuộc tấn công này mang tính hủy diệt, nhưng việc thực hiện nó gặp một số thách thức. Thực hiện cuộc tấn công có thể đòi hỏi phần lớn công suất băm. Nếu có những thợ đào trung thực nhập vào dấu thời gian trung thực, thì cuộc tấn công sẽ trở nên khó khăn hơn. Quy tắc MTP và dấu thời gian từ các thợ đào trung thực có thể giới hạn mức độ mà thợ đào độc hại có thể lùi dấu thời gian. Ngoài ra, nếu các thợ đào trung thực tạo ra khối đầu tiên của bất kỳ cửa sổ điều chỉnh độ khó nào, thì chu kỳ tấn công đó sẽ không thành công. Một yếu tố giảm nhẹ khác có thể khiến cuộc tấn công khó thực hiện hơn là nó hoàn toàn có thể nhìn thấy. Bất kỳ ai cũng có thể quan sát dấu thời gian, và việc phải thao túng dấu thời gian trong suốt bốn tuần trước khi độ khó giảm xuống có thể cho chúng ta đủ thời gian để triển khai một bản sửa lỗi nâng cấp mềm khẩn cấp.
Giải pháp
Việc sửa lỗi này tương đối đơn giản, mặc dù có thể yêu cầu thay đổi giao thức thông qua nâng cấp mềm. Việc trực tiếp khắc phục vấn đề bằng cách thay đổi thuật toán điều chỉnh độ khó để tính toán khoảng thời gian giữa các khối trong các cửa sổ 2016 khác nhau và hoàn toàn sửa lỗi thiếu một là khá phức tạp. Điều này thậm chí có thể là một nâng cấp cứng. Một phương pháp sửa lỗi khác là loại bỏ quy tắc MTP, thay vào đó yêu cầu thời gian luôn tiến lên ở mỗi khối, tuy nhiên điều này có thể khiến thời gian bị kẹt ở quá xa trong tương lai, và cũng có nghĩa là các thợ đào có thể gặp rắc rối nếu sử dụng thời gian thực trên đồng hồ hệ thống, nếu một thợ đào khác có đồng hồ chạy nhanh hơn vài giây, điều này có thể dẫn đến dấu thời gian không hợp lệ.
May mắn thay, có một giải pháp đơn giản hơn. Để ngăn chặn tấn công bóp méo thời gian, chúng ta chỉ cần yêu cầu rằng dấu thời gian của khối đầu tiên trong chu kỳ độ khó mới không được sớm hơn một số phút nhất định so với khối cuối cùng của chu kỳ trước. Số phút cho quy tắc giới hạn mới này đã được thảo luận, với các đề xuất dao động từ 10 phút đến 2 giờ. Về mặt giảm thiểu tấn công bóp méo thời gian, cả hai lựa chọn đều có thể hiệu quả.
Trong đề xuất Làm sạch đồng thuận lớn của Poinsot, ông hiện xác định con số này là 2 giờ. 2 giờ chỉ chiếm khoảng 0,6% thời gian mục tiêu của chu kỳ điều chỉnh độ khó, do đó khả năng thao túng độ khó giảm xuống bị giới hạn nghiêm ngặt. Chúng tôi tóm tắt cuộc thảo luận về thời gian ân hạn nên sử dụng trong bảng dưới đây:

Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News














