Tác giả: Antoine Poinsot
Nguồn: https://bitcoinmagazine.com/print/the-core-issue-consensus-cleanup
Về tương lai của Bitcoin, các nhà phát triển giao thức Bitcoin nhìn chung bi quan hơn hầu hết Bitcoin. Việc tiếp xúc hàng ngày với những khiếm khuyết của Bitcoin chắc chắn mang lại cho họ một cái nhìn tỉnh táo hơn, nhưng điều này cũng phản ánh những thành tựu của Bitcoin. Bất kỳ ai trên thế giới, bất kể chủng tộc, tuổi tác, giới tính, quốc tịch hay bất kỳ tiêu chuẩn nào khác, đều có thể lưu trữ và chuyển giao giá trị trên một mạng lưới tiền tệ trung lập, và mạng lưới này tiếp tục lớn mạnh từng ngày. Tuy nhiên, Bitcoin vẫn còn một số vấn đề mà nhiều Bitcoin chưa nhận thấy, nếu không được giải quyết đúng cách, có thể đe dọa tương lai Bitcoin. Các lỗ hổng được khắc phục bởi "Consensus Cleanup" là một ví dụ như vậy.
"Consensus Rule Cleanup" (BIP 54 1 ) là một đề xuất soft fork nhằm khắc phục một số lỗ hổng bảo mật lâu năm Bitcoin. Không giống như hầu hết các công việc phát triển Bitcoin Core được thảo luận trong tạp chí này ("The Core Issue" của Bitcoin Magazine), đây là một đề xuất soft fork. Mặc dù đề xuất này lịch sử được dẫn dắt bởi một số nhà phát triển tham gia vào dự án Bitcoin Core , nhưng thực tế nó thuộc về phạm trù rộng hơn của "phát triển giao thức Bitcoin".
Bài viết này sẽ giới thiệu cả bốn biện pháp trong đề xuất này, nêu rõ các vấn đề mà chúng nhằm giải quyết, tác động của chúng và kết quả của các biện pháp khắc phục. Chúng tôi sẽ giải thích cách các biện pháp giảm thiểu này được tinh chỉnh bằng cách kết hợp phản hồi và giải quyết các lỗ hổng mới được phát hiện. Cuối cùng, chúng tôi sẽ cung cấp tổng quan về trạng thái hiện tại của đề xuất soft fork này.
Một lỗ hổng trong cơ chế Bằng chứng công việc Bitcoin.
Mạng lưới Bitcoin duy trì tốc độ khai thác trung bình một khối mới mỗi 10 phút bằng cách điều chỉnh độ khó khai thác . Tuy nhiên, có một "lỗi nhất thời" (một lỗi lập trình phổ biến) trong việc triển khai cơ chế điều chỉnh độ khó này cho phép xảy ra một cuộc tấn công gọi là "time warping": thợ đào kiểm soát phần lớn tỷ lệ băm khai thác (hash power) có thể tùy ý tăng tốc độ tạo khối bằng cách giảm độ khó.
May mắn thay, cuộc tấn công này yêu cầu kiểm soát hơn 51% tỷ lệ băm khai thác ; tuy nhiên, việc tăng tốc sản xuất khối một cách tùy tiện là một điểm yếu chí mạng. Điều này có nghĩa là nút đầy đủ sẽ không còn kiểm soát việc sử dụng tài nguyên nữa, và kẻ tấn công có thể tăng tốc đáng kể việc phân phối các phần thưởng khối Bitcoin(đơn vị tiền tệ mới).
Mặc dù cuộc tấn công này yêu cầu "51% số thợ đào", nhưng nó khác biệt đáng kể so với mô hình đe dọa tiêu chuẩn mà Bitcoin phải đối mặt. Một cuộc tấn công "51%" truyền thống cho phép một thợ đào duy nhất ngăn chặn việc xác nhận giao dịch (miễn là họ duy trì được lợi thế tỷ lệ băm). Tuy nhiên, lỗ hổng này cho phép kẻ tấn công làm tê liệt toàn bộ mạng lưới trong vòng 38 ngày bằng cách nhanh chóng giảm độ khó khai thác.
Tuy nhiên, những kẻ tấn công có thể không làm tê liệt toàn bộ mạng lưới, mà chỉ khai thác lỗi này trên quy mô nhỏ hơn. Thợ đào hiện tại có thể thông đồng để tăng gấp bốn lần tốc độ sản xuất khối (khai thác một khối cứ sau 2,5 phút) trong khi vẫn giữ cho mạng Bitcoin hoạt động bình thường. Về cơ bản, điều này sẽ tăng gấp bốn lần dung lượng khối khả dụng và đánh cắp phần thưởng khối từ thợ đào tương lai. Người dùng ngắn hạn có thể được khích lệ hỗ trợ cuộc tấn công như vậy vì dung lượng khối khả dụng lớn hơn đồng nghĩa với phí giao dịch thấp hơn trong blockchain(giả sử các điều kiện khác không thay đổi). Tất nhiên, điều này sẽ phải trả giá bằng việc vận hành nút đầy đủ và làm giảm tính ổn định lâu dài của mạng lưới.
Tấn công bẻ cong thời gian khai thác thực tế là các chu kỳ điều chỉnh độ khó không chồng chéo nhau. Do đó, dấu thời gian của một khối trong một chu kỳ mới có thể được đặt sớm hơn khối cuối cùng của chu kỳ trước đó. Vì các chu kỳ điều chỉnh độ khó chồng chéo sẽ dẫn đến hard fork, nên giải pháp thỏa hiệp tốt nhất là tương quan dấu thời gian của các khối nằm trên ranh giới của các chu kỳ điều chỉnh độ khó. BIP 54 quy định rằng dấu thời gian của khối đầu tiên của một chu kỳ điều chỉnh độ khó không được sớm hơn hai giờ so với khối cuối cùng của chu kỳ trước đó.
Hơn nữa, BIP 54 quy định rằng một chu kỳ điều chỉnh độ khó phải mất một số phút dương. Tức là, trong một chu kỳ điều chỉnh độ khó, dấu thời gian của khối cuối cùng không thể sớm hơn dấu thời gian của khối đầu tiên. Bạn có ngạc nhiên khi Bitcoin chưa bao giờ có quy tắc này không? Chúng tôi cũng ngạc nhiên khi thấy nó lại cần thiết. Thực tế cho thấy đây chỉ là một giải pháp đơn giản cho một cuộc tấn công tinh vi liên quan đến việc bẻ cong thời gian, được phát hiện bởi nhà phát triển, sử dụng biệt danh "Zawy," và Mark "Murch" Erhardt trong khi xem xét các đề xuất làm sạch quy tắc đồng thuận.
Các khối cần vài giờ để xác minh
Bất kỳ thợ đào nào cũng có thể khai thác một số thao tác xác minh tốn nhiều thời gian để tạo ra các khối cần rất nhiều thời gian để xác minh. Trong khi một khối Bitcoin thông thường có thể được xác minh trong khoảng 100 mili giây, thì những "khối tấn công" này có thể mất hơn 10 phút trên các máy tính cấu hình cao và hơn 10 giờ trên Raspberry Pi (phần cứng thường được sử dụng để chạy nút đầy đủ).
Kẻ tấn công độc hại có thể sử dụng cuộc tấn công này để phá hủy toàn bộ mạng lưới; trong khi đó, ở một biến thể có lợi hơn về mặt kinh tế, thợ đào có thể sử dụng nó để trì hoãn đối thủ cạnh tranh, tăng lợi nhuận của chính họ và ngăn chặn sự sụp đổ lan rộng khắp mạng lưới.
Lịch sử, các nỗ lực giải quyết vấn đề này đều gặp nhiều khó khăn vì các giải pháp đòi hỏi phải áp đặt những hạn chế lên khả năng lập trình của Bitcoin. Những hạn chế như vậy có thể dẫn đến "mất quyền sở hữu" và cần phải tuyệt đối tránh trong bất kỳ thiết kế soft fork nghiêm túc nào.
(Ghi chú của người dịch: "Việc tịch thu" được đề cập ở đây ám chỉ việc do vô hiệu hóa một số chức năng của hệ thống chữ viết, số tiền xu chứa trong hệ thống chữ viết đó không thể được sử dụng nữa.)
Đề xuất "Great Consensus Cleanup" của Matt Corallo, lần đầu tiên được đề xuất vào năm 2019, gợi ý việc vô hiệu hóa một số thao tác hiếm gặp trong các tập lệnh không phải là Segregated Witness (thường được gọi là "tập lệnh cũ") để giải quyết vấn đề thời gian xác minh kéo dài. Một số người lo ngại rằng mặc dù các giao dịch sử dụng các thao tác này đã không được chuyển tiếp hoặc khai thác bởi cấu hình Bitcoin Core mặc định trong nhiều năm, nhưng một số cá nhân vẫn có thể đang sử dụng chúng ở một số nơi mà không bị phát hiện. Tất nhiên, rủi ro này phải được cân nhắc so với rủi ro mà một thợ đào duy nhất khai thác lỗ hổng này có thể gây ra cho tất cả người dùng Bitcoin .
Mặc dù mối lo ngại về việc bị tịch thu này gần như hoàn toàn mang tính lý thuyết, nhưng nó cũng là một câu hỏi triết học: làm thế nào để thiết kế các biện pháp giảm thiểu thích hợp trong quá trình phát triển giao thức Bitcoin nhằm giải quyết các lỗ hổng đồng thời giảm thiểu khả năng bị tịch thu. Cải tiến sau này của tôi đối với đề xuất dọn dẹp quy tắc đồng thuận đã giải quyết mối lo ngại này bằng cách thêm một hạn chế xác định chính xác hành vi gây hại mà không vô hiệu hóa bất kỳ hoạt động cụ thể nào của tập lệnh Bitcoin.
Chứng từ thanh toán ngụy tạo
Block Header Bitcoin chứa một gốc Merkle cam kết tất cả các giao dịch trong khối. Điều này cho phép chúng ta tạo ra một dạng bằng chứng cô đọng rằng một giao dịch đã được xác nhận bởi blockchain với một Bằng chứng công việc nhất định. Đây là điều mà chúng ta thường gọi là "bằng chứng SPV".
Tuy nhiên, do một lỗi thiết kế trong Merkle trees, kẻ tấn công có thể ngụy tạo bằng chứng SPV cho một giao dịch giả mạo (không tồn tại) nếu một khối chứa một giao dịch 64 byte được tạo ra một cách cẩn thận. Điều này có thể được sử dụng để đánh lừa các trình xác thực SPV (thường được sử dụng để xác minh các khoản thanh toán hoặc tiền gửi đến một hệ thống con). Các biện pháp giảm thiểu tồn tại để cho phép các trình xác thực từ chối bằng chứng không hợp lệ như vậy; tuy nhiên, chúng thường bị bỏ qua—ngay cả bởi các nhà mật mã học—và có thể gây ra vấn đề trong một số trường hợp nhất định.
Đề xuất dọn dẹp quy tắc đồng thuận giải quyết vấn đề này bằng cách vô hiệu hóa các giao dịch có kích thước tuần tự hóa chính xác là 64 byte (trong phạm vi các quy tắc đồng thuận). Các giao dịch như vậy vốn dĩ không an toàn (chúng chỉ có thể được sử dụng để đốt tiền hoặc bị bất kỳ ai sử dụng), và kể từ năm 2019, cấu hình mặc định Bitcoin Core đã ngừng chuyển tiếp và khai thác các giao dịch như vậy. Phương pháp khác đã được thảo luận, chẳng hạn như một giải pháp tạm thời để cải thiện các biện pháp giảm thiểu hiện có, nhưng các tác giả của đề xuất đã chọn giải quyết nguyên nhân gốc rễ của vấn đề, loại bỏ cả việc các nhà phát triển phần mềm phải phô trương các biện pháp giảm thiểu của họ và việc họ phải nhận thức được lỗ hổng này.
Lưu ý a: Độ sâu của Merkle trees được ghi lại trong trường số phiên bản của Block Header .
Bản sao UTXO: Giao dịch chồng chéo
"Lạm phát nhỏ...trung bình...lớn - Nền kinh tế quá nóng" là tiêu đề một bài đăng trên blog mà Russell O'Connor đã xuất bản vào tháng 2 năm 2012. Trong bài đăng này, ông đã thảo luận về khả năng các giao dịch Bitcoin chồng chéo nhau. Đây từng là một lỗ hổng nghiêm trọng trong Bitcoin, phá vỡ giả định cơ bản rằng mã định danh giao dịch (giá trị băm) là duy nhất. Vấn đề bắt nguồn từ thực tế là giao dịch coinbase của thợ đào chỉ có một đầu vào trống, có nghĩa là bất kỳ giao dịch coinbase nào có cùng đầu ra sẽ có cùng mã định danh giao dịch.
(Ghi chú của người dịch: Giao dịch Coinbase là giao dịch đầu tiên trong một khối, được sử dụng để cho phép thợ đào tạo ra khối đó nhận phí giao dịch và phần thưởng khối; nó có thể được thực hiện mà không cần tiêu tốn bất kỳ UTXO nào.)
Vào thời điểm đó, các nhà phát triển của Bitcoin Core (lúc đó được gọi là "Bitcoin") đã khắc phục lỗ hổng này bằng BIP 30 2 , yêu cầu nút đầy đủ thực hiện xác minh bổ sung khi nhận được khối. Việc xác minh bổ sung này không hoàn toàn cần thiết và đã bị bỏ qua trong BIP 34 3 , được triển khai cùng năm. Thật không may, bản vá trong BIP 34 không hoàn hảo, và 20 năm sau, chúng ta sẽ cần phải giới thiệu lại xác minh BIP 30. Bên cạnh việc không hoàn toàn cần thiết, biện pháp xác minh này không thể được thực hiện bởi máy trạm Bitcoin thay thế (như Utreexo) và thực tế sẽ ngăn cản chúng xác minh đầy đủ blockchain.
Đề xuất sửa đổi quy tắc đồng thuận kết hợp một giải pháp đáng tin cậy và đã được kiểm chứng qua thời gian. Tất cả các giao dịch Bitcoin, bao gồm cả giao dịch Coinbase, đều có một trường xác định "ngày hiệu lực" của giao dịch. Giá trị của trường này thể hiện Block Height của khối cuối cùng trước khi giao dịch được coi là không hợp lệ. BIP 54 quy định rằng tất cả các giao dịch Coinbase phải đặt trường này thành Block Height trừ đi một.
Kết hợp điều này với một đề xuất khôn ngoan từ Anthony Towns—đảm bảo rằng quá trình xác minh khóa thời gian luôn hoạt động—nó đảm bảo rằng các giao dịch Coinbase trong các khối trước đó không thể sử dụng cùng một giá trị khóa thời gian. Đến lượt mình, điều này đảm bảo rằng sẽ không có hai giao dịch Coinbase nào có cùng mã định danh giao dịch (giá trị băm), và loại bỏ nhu cầu xác minh BIP 30.
Phòng bệnh hơn chữa bệnh.
Các lỗ hổng được khắc phục bằng việc dọn dẹp quy tắc đồng thuận (BIP 54) không phải là mối đe dọa hiện hữu ngay lập tức Bitcoin. Mặc dù một số trong đó có khả năng làm tê liệt toàn bộ mạng lưới, nhưng hiện tại chúng khó có thể bị khai thác. Tuy nhiên, tình hình có thể thay đổi, và việc chủ động giảm thiểu rủi ro dài hạn đối với mạng lưới Bitcoin là hoàn toàn cần thiết, ngay cả khi điều đó đòi hỏi gánh nặng ngắn hạn là phối hợp soft fork .
Đề xuất cải tiến quy tắc đồng thuận bắt nguồn từ một đề xuất ban đầu của Matt Corallo vào năm 2019. Sáu năm sau, với sự ra mắt của BIP 54 và việc triển khai soft fork tương ứng của Bitcoin Inquisition (một mạng thử nghiệm cho các thay đổi về đồng thuận Bitcoin ), đề xuất này cuối cùng đã được hiện thực hóa. Trong thời gian này, đề xuất đã nhận được lượng lớn phản hồi, và chúng tôi đã thảo luận về nhiều phương án thay thế và bổ sung các biện pháp giảm thiểu cho các điểm yếu khác. Tôi cho rằng giờ đây nó đã sẵn sàng để được chia sẻ với người dùng Bitcoin.
Việc tinh chỉnh quy tắc đồng thuận là một dạng soft fork. Các nhà phát triển giao thức Bitcoin sẽ lựa chọn những cải tiến nào cần triển khai trước tiên và công bố chúng. Tuy nhiên, quyết định cuối cùng về việc có chấp nhận thay đổi đối với các quy tắc đồng thuận của Bitcoin hay không thuộc về người dùng. Sự lựa chọn là của bạn.
(qua)
Tham khảo
1. https://github.com/bitcoin/bips/blob/master/bip-0054.md
2. https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
3. https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
