Tác giả: Antoine Poinsot
Nguồn: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710
Gần đây tôi đang xem xét đề xuất " đồng thuận dọn dẹp " của Matt Corallo. Tôi quan tâm đến việc tìm hiểu:
- Mức độ nghiêm trọng của các lỗi mà đề xuất tìm cách giải quyết;
- Cách khắc phục được đề xuất sẽ cải thiện tình huống xấu nhất đến mức nào;
- Sau năm năm kinh nghiệm nữa, liệu chúng ta có thể làm tốt hơn không? (Ghi chú của người dịch: Đề xuất của Matt được đưa ra vào năm 2019.)
- Còn có việc gì đáng giải quyết nữa không.
Tóm lại : Tôi cho rằng những lỗi đó thật tệ. Thời gian xác minh khối trong trường hợp xấu nhất có liên quan. Tôi cũng cho rằng rằng việc khắc phục lỗ hổng thời gian quan trọng hơn nhiều so với những gì mọi người thường cho rằng. Cuối cùng, tôi cho rằng chúng ta có thể đưa ra bản sửa lỗi để tránh xác thực BIP30 sau Block Height 198 3702 và giới hạn bổ sung về quy mô của các Giới hạn giao dịch cũ có thể mang lại giới hạn an toàn hữu ích cho thời gian xác minh khối.
Tôi hy vọng có thể sử dụng bài viết này để kích thích thảo luận về các lỗi giao thức mà đề xuất dọn dẹp đồng thuận hy vọng sẽ giải quyết được. Tôi sẽ đánh giá cao các nhận xét và ý kiến qua điện thoại về từng biện pháp giảm thiểu được đề xuất cũng như các đề xuất tiềm năng để có thêm cách khắc phục. Phần về thời gian xác minh khối đã giảm đáng kể: Tôi sẽ chia sẻ công khai một số con số, nhưng chi tiết về chiến lược tạo ra khối phá vỡ sẽ chỉ được chia sẻ với những người đóng góp thường xuyên cho Bitcoin Core và một số ít nhà phát triển giao thức Bitcoin.
lỗ hổng thời gian
Lỗ hổng chênh lệch thời gian giải thích cho thực tế là các chu kỳ điều chỉnh độ khó không trùng nhau. Thợ đào có thể tận dụng lợi thế này bằng cách di chuyển dấu thời gian của khối cuối cùng của khoảng thời gian điều chỉnh mục tiêu về phía trước càng xa càng tốt (nghĩa là 2 giờ kể từ bây giờ), đồng thời di chuyển dấu thời gian của tất cả các khối khác càng xa càng tốt. là để giảm bớt độ khó một cách giả tạo. Câu trả lời stackexchange này có lời giải thích kỹ lưỡng hơn.
Nó tệ đến mức nào?
Thật thú vị khi nghĩ xem chính xác nó làm tình hình trở nên tồi tệ hơn như thế nào và chính xác thì nó có tác dụng gì. Trong mọi trường hợp, thợ đào luôn có thể giữ dấu thời gian và ngăn nó tiến lên, ngay cả khi không khai thác lỗ hổng thời gian. Tuy nhiên, nếu dấu thời gian của khối đầu tiên của chu kỳ điều chỉnh độ khó không được đặt sớm hơn khối cuối cùng của chu kỳ trước, việc sử dụng cơ chế điều chỉnh độ khó chắc chắn sẽ dẫn đến việc tăng độ khó khai thác . Ngược lại, bằng cách đặt dấu thời gian của khối đầu tiên của chu kỳ sớm hơn khối cuối cùng của chu kỳ trước, kẻ tấn công có thể giảm độ khó hơn nữa đồng thời tận dụng độ khó thấp (kết quả của vòng này).
Trên thực tế, kẻ tấn công có thể gây ra thiệt hại nghiêm trọng trên mạng chỉ sau hơn một tháng sau khi bắt đầu một cuộc tấn công như vậy. Bắt đầu từ thời điểm t và khoảng thời gian N , kẻ tấn công bắt đầu cuộc tấn công. Đến cuối khoảng thời gian N+1 , kẻ tấn công đã có thể giảm độ khó xuống một nửa. Điều này cho phép họ khai thác tất cả các khối trong khoảng thời gian N+2 trong vòng một tuần, giảm độ khó thêm 2,5 lần, v.v. Trong vòng chưa đầy 40 ngày, kẻ tấn công có thể hạ độ khó xuống 1 và khai thác hàng triệu khối cùng một lúc. Ngoài việc loại bỏ tất cả các khoản trợ cấp khối còn lại, điều này sẽ phá hủy tính bảo mật của bất kỳ giao thức L2 nào dựa vào khóa thời gian và làm xấu đi bề mặt tấn công DoS (ví dụ: nó có thể được kết hợp với việc mở rộng bộ UTxO).
MTP (thời gian quá khứ trung bình) bị bỏ qua ở đây vì nó tốt nhất chỉ gây khó chịu nhỏ cho những kẻ tấn công. Tuy nhiên, điều này cũng đặt ra một câu hỏi: Mặc dù một cuộc tấn công như vậy nhằm mục đích kiểm soát phần lớn tỷ lệ băm khai thác , liệu một tỷ lệ băm nhỏ có thể cố gắng tận dụng các chiến lược có lợi của nó không? Ví dụ: di chuyển dấu thời gian của khối cuối cùng của khoảng thời gian điều chỉnh về phía trước càng xa càng tốt và di chuyển dấu thời gian của tất cả các khối khác (trong phạm vi được quy tắc MTP cho phép) càng xa càng tốt. Về mặt kỹ thuật, điều này không gây ra chi phí (đáng kể) cho thợ đào, nhưng có thể mang lại cho họ (và thợ đào khác) phần thưởng khối lớn hơn một chút (với chi phí của thợ đào trong tương lai). Hóa ra, khi sử dụng chiến lược như vậy, lợi nhuận cận biên đối với bất kỳ lượng nhỏ tỷ lệ băm khai thác nào là không đáng kể, vì vậy chúng ta có thể kỳ vọng một cách hợp lý rằng thợ đào sẽ không cố gắng khai thác các lỗ hổng làm cong vênh thời gian một cách nhanh chóng.
Chúng ta có nên sửa nó không?
Một số người cho rằng thợ đào không cố ý tự bắn vào chân mình. Trên thực tế, việc mong đợi họ tiêu diệt Chuỗi mà họ muốn khai thác không được hiển thị. Thay vào đó, họ có thể đạt đến trạng thái cân bằng chỉ đơn giản là tăng tốc độ tạo khối lên X%. Tôi để người đọc đánh giá ý nghĩa chính trị của thợ đào có thể tăng không gian khối có sẵn mà không thay đổi quy tắc đồng thuận giữa nút. Nhưng chúng tôi muốn chỉ ra rằng nếu một tập đoàn thợ đào(liên minh) có thể hạ thấp độ khó, dù chỉ một chút, bằng cách khai thác lỗ hổng lệch thời gian, thì nó có thể khiến mạng đứng trước bờ vực sụp đổ trong vài tuần.
Một khẳng định phổ biến khác là nó không khẩn cấp vì cuộc tấn công rất rõ ràng và mất nhiều thời gian. Tôi rất nghi ngờ những lập luận yêu cầu người dùng phối hợp và quyết định tính hợp lệ của một khối ở một độ cao nhất định nằm ngoài các quy tắc đồng thuận mà họ tuân theo. Hơn nữa, một tháng không phải là thời gian dài để phối hợp và thay đổi các quy tắc đồng thuận của Bitcoin. Và, như đã lưu ý trước đó, không chắc chắn liệu có thể đạt được sự đồng thuận rộng rãi để làm như vậy hay không. Người dùng thích mức phí thấp hơn và thợ đào thích nhiều trợ cấp hơn. Với sự phân bổ quyền kiểm soát hiện tại đối với tỷ lệ băm khai thác và trợ cấp khối giảm theo cấp số nhân, không phải vô lý cho rằng rằng một cartel có thể hình thành đang cố gắng khai thác lỗ hổng thời gian.
Cuối cùng, một số người tranh luận, và những người khác cho rằng điều đó không khẩn cấp, vì cuộc tấn công đòi hỏi sự tham gia của một phần lớn tỷ lệ băm khai thác . Tôi cho rằng điều này đã bị đánh giá quá thấp. Lý do Lỗ hổng Time Warp làm tăng đáng kể sát thương mà một cuộc tấn công có thể gây ra lên 51%. Ban đầu, cuộc tấn công 51% "chỉ có thể" kiểm duyệt tạm thời các giao dịch. Nhưng với một cuộc tấn công bẻ cong thời gian, toàn bộ mạng lưới có thể bị phá hủy.
Chúng ta có thể đưa ra cách khắc phục tốt hơn không?
Có lẽ không. Cách khắc phục được đề xuất rất đơn giản: làm cho các chu kỳ điều chỉnh độ khó chồng chéo lên nhau. Thay đổi do Matt đề xuất là đơn giản và quan trọng nhất: sử dụng dấu thời gian của khối cuối cùng của chu kỳ trước để hạn chế dấu thời gian của khối đầu tiên của chu kỳ này.
Thời gian xác minh khối trường hợp xấu nhất
Ai cũng biết rằng các giao dịch không phải Segwit tạo ra một cách độc hại có thể cực kỳ khó xác minh. Thời gian xác minh khối dài hơn có thể mang lại cho những kẻ tấn thợ đào khai thác lợi thế không công bằng, cản trở việc truyền bá các khối trong mạng (và tính nhất quán của chúng) và thậm chí gây ra hậu quả có hại cho phần mềm dựa vào tính khả dụng của khối. Để đạt được mục đích này, đề xuất dọn dẹp đồng thuận kết hợp một số hạn chế bổ sung đối với việc sử dụng tập lệnh truyền thống.
Nó tệ đến mức nào?
Rất tệ. Trong trường hợp xấu nhất, tôi có thể lấy được một khối mất 3 phút để xác minh trên CPU 16 lõi của máy tính xách tay mới nhất của tôi với CPU đầy đủ; trên Raspberry Pi 4, sẽ mất 1,5 giờ. Vì những lý do rõ ràng, tôi đã bỏ qua các chi tiết về khối như vậy ở đây, cũng như phương pháp khác nhau để tạo các khối khó xác minh tương tự. Tôi sẽ chia sẻ nó với các nhà phát triển giao thức khác trong một bài đăng đính kèm nửa riêng tư, sử dụng tính năng hội thảo riêng tư của Delving. Nếu bạn cho rằng bạn nên biết nhưng tôi quên đưa bạn vào, vui lòng liên hệ với tôi.
Đề xuất cải thiện được bao nhiêu trong trường hợp xấu nhất? Chúng ta có thể rút ra các biện pháp giảm thiểu hiệu quả hơn không?
Biện pháp giảm thiểu được đề xuất bởi đề xuất dọn dẹp đồng thuận sẽ vô hiệu hóa khối mà tôi tạo ra. Theo các hạn chế mới, khối tồi tệ nhất chỉ mất 5 giây để xác minh trên máy tính xách tay của tôi. Tôi cho rằng chúng ta có thể đưa ra thêm các giới hạn về khối lượng giao dịch truyền thống để đảm bảo an toàn.
Về các biện pháp giảm nhẹ được đề xuất, cũng có những lo ngại về việc "tịch thu" (khi các tập lệnh hợp lệ trở nên không thể sử dụng được). Tôi cho rằng những lo ngại này là hợp lý và có thể được giải quyết bằng cách chỉ áp dụng các quy tắc mới cho các tập lệnh được tạo sau một Block Height nhất định.
Tấn công Merkle trees sử dụng giao dịch 64 byte
Tùy thuộc vào cách tính toán gốc Merkle trong các khối Bitcoin, có hai cuộc tấn công còn lại (đã biết). Cả hai đều liên quan đến việc ghép hai giá trị băm 32 byte, yêu cầu chuỗi được ghép có thể được deserialized thành công thành giao dịch Bitcoin. Cách (có lẽ nổi tiếng nhất) là lừa một light node chấp nhận một giao dịch không được xác nhận bởi khối: có giao dịch 64 byte được khối xác nhận (và do đó được cam kết bởi Merkle trees), nhưng 32 byte theo sau nó tương ứng với txid của giao dịch đã được trả cho nạn nhân nhưng không được khối xác nhận. Một cách khác là lừa một nút cấm một khối hợp lệ mãi mãi: tìm một hàng nút cây có thể được giải tuần tự hóa thành các giao dịch 64 byte (không hợp lệ). Xem bài viết này của Suhas Daftuar để biết thêm chi tiết.
Đề xuất dọn dẹp đồng thuận phân loại các giao dịch có khối lượng nhỏ hơn hoặc bằng 64 byte là giao dịch không hợp lệ, có thể khắc phục cả hai vấn đề cùng một lúc.
Nó tệ đến mức nào?
Một cuộc tấn công chống lại light node(hoặc bất kỳ thứ gì chấp nhận bằng chứng Merkle, như sidechain) yêu cầu tìm kiếm mạnh mẽ trong phạm vi từ 61 đến (khoảng) 75 bit, tùy thuộc vào số lượng Bitcoin dành riêng cho cuộc tấn công. Điều này là tốn kém và có giảm nhẹ đơn giản. Ví dụ: kiểm tra độ sâu của Merkle trees bằng cách yêu cầu bằng chứng Merkle cho các giao dịch coinbase sẽ cho bạn biết khối đó chứa bao nhiêu giao dịch.
Nói cách khác, cuộc tấn công này ước tính trị giá 1 triệu USD , khi “ tỷ lệ băm ASIC khai thác Bitcoin mới nhất đạt 14TH/s”. Bây giờ, có vẻ như tỷ lệ băm của ASIC đã tăng lên 400TH/s. Ngoài ra, cuộc tấn công này có thể ngụy tạo bất kỳ số lượng xác nhận nào cho một giao dịch. Chi phí chỉ là khai thác một khối giả để đánh lừa máy trạm SPV, hiện cao hơn một chút (80 bit).
Các cuộc tấn công đánh lừa nút Bitcoin đã được giảm thiểu trong Bitcoin Core bằng cách không lưu vào bộ nhớ đệm kiểm tra khối mà không có ngữ cảnh ( CheckBlock() ). Việc tạo giao dịch hợp lệ không được hiển thị: giao dịch đầu tiên phải là giao dịch coinbase, yêu cầu tìm kiếm mạnh mẽ 224 bit.
Do cách tính toán gốc Merkle theo khối, các giao dịch 64 byte là lỗ hổng cốt lõi trong Bitcoin. Mặc dù cả hai cuộc tấn công (đã biết) do nó gây ra đều có thể được giảm thiểu, nhưng sẽ rất tốt nếu tránh được rủi ro sai sót này trong khi lưu vào bộ nhớ đệm kiểm tra khối không ngữ cảnh trong Bitcoin Core.
Chúng ta có thể đưa ra cách khắc phục tốt hơn không?
Phương thức 64 byte không "an toàn" vì 64 byte không đủ để chứa đầu ra có tập lệnh khóa (bất kỳ ai không thể sử dụng tập lệnh này và không bị khóa vĩnh viễn) trong một giao dịch. Chúng không có mục đích rõ ràng và được coi là giao dịch phi tiêu chuẩn trên mạng trong 5 năm. Với những lỗ hổng mà chúng gây ra và sự vô dụng của chúng, việc vô hiệu hóa chúng là hoàn toàn hợp lý.
Tuy nhiên, BIP đề xuất vô hiệu hóa các giao dịch nhỏ hơn 64 byte. Mặc dù chúng vô dụng (hoặc không hữu ích lắm) nhưng những giao dịch như vậy là vô hại. Tôi luôn cho rằng rằng một loại giao dịch không đủ hữu ích để chúng ta vô hiệu hóa chúng thông qua soft fork.
danh sách mong muốn
Xác minh BIP30
BIP34 tạm thời tránh chạy các bước kiểm tra BIP30 tương đối tốn kém trên mỗi kết nối khối. Bắt đầu từ Block Height 198 3702, bạn không còn có thể chỉ dựa vào BIP34 nữa. Nếu một soft fork được đề xuất để giải quyết một lỗi giao thức lâu đời, thì tốt nhất kể từ bây giờ hãy làm cho mọi giao dịch coinbase trở nên hoàn toàn độc nhất.
Một giải pháp đơn giản là đặt nLockTime của giao dịch coinbase theo Block Height mà nó được tạo. Tuy nhiên, có một cách tiếp cận vòng vo hơn có thể dễ dàng hơn cho thợ đào triển khai: buộc các nhân chứng phải cam kết trong tất cả các giao dịch coinbase (thông qua Greg Sanders). Tôi chưa xác định liệu có trường hợp ngoại lệ nào đối với quy tắc này hay không, nhưng tôi sẽ rất ngạc nhiên nếu đầu ra của giao dịch coinbase trước SegWit tình cờ đẩy tiêu đề Cam kết Nhân chứng được mở với 32 0x00 byte.
Lỗi "yêu thích" của bạn!
Ở giai đoạn này, tôi muốn thu thập càng nhiều đề xuất dọn dẹp càng tốt và đảm bảo rằng nếu soft fork như thế này được đưa vào bảng, chúng tôi đã phân tích tất cả các bản sửa lỗi mà chúng tôi có thể thêm chi tiết nhất có thể.
Tất nhiên, những lời đề nghị phải hợp lý. Ví dụ: "Ordinals thứ tự" là một đề xuất không thú vị và tôi nghi ngờ nhiều người sẽ tham gia. Hơn nữa, hãy tập trung vào các lỗi lâu dài, không gây tranh cãi. Ví dụ: "một khối mất hơn 30 phút để xác minh có nghĩa là một tình huống xấu", "tính toán Merkle trees bị hỏng gây ra rủi ro sai sót" và "làm cho các giao dịch coinbase thực sự độc đáo" dường như hoàn toàn không gây tranh cãi. Mặt khác, mặc dù có thể có những lý do chính đáng cho việc "hãy hạ thấp giới hạn kích thước khối", nhưng đối với tôi, điều đó gây tranh cãi hơn nhiều.
Ví dụ: đây là hai điều bạn không thể thuyết phục tôi đáng để đề xuất:
- Các giao dịch Segregated Witness v0 cũng được yêu cầu phải có byte loại SIGHASH tiêu chuẩn.
- Giới hạn kích thước của khóa chung của tập lệnh để giảm tăng trưởng của bộ UTXO trong trường hợp xấu nhất.
