Dưới bài đăng PR về việc "lọc" các chỉ dẫn Bitcoin, các nhà phát triển có những quan điểm trái chiều nào?
Tuyển chọn TechFlowTuyển chọn TechFlow
Dưới bài đăng PR về việc "lọc" các chỉ dẫn Bitcoin, các nhà phát triển có những quan điểm trái chiều nào?
Về chủ đề liệu có nên "cấm" inscriptions hay không, bài viết này tổng hợp các quan điểm trái chiều từ cộng đồng nhà phát triển.
Chuyên sâu báo cáo Web3Thực hiện: gloria
Biên dịch: GaryMa, Wu Shuo Blockchain
Bối cảnh
Tháng 9 năm 2023, nhà phát triển Bitcoin Luke Dashjr đã gửi một yêu cầu kéo (PR) vào kho lưu trữ Bitcoin Core trên GitHub nhằm cập nhật tùy chọn «datacarriersize» để lọc các giao dịch mang dữ liệu dạng script mới như «inscriptions», phản ánh quan điểm cho rằng các giao dịch loại này là hành vi lợi dụng lỗ hổng và cần bị cấm sửa chữa.
Theo mặc định, Bitcoin Core giới hạn số lượng đầu ra OP_RETURN và lượng dữ liệu nhúng trong các giao dịch chưa xác nhận, với giá trị mặc định là 80 byte. Bằng cách cấu hình tùy chọn -datacarriersize, người dùng có thể thay đổi giới hạn này. Tuy nhiên, hiện tại tùy chọn này chỉ áp dụng cho các đầu ra OP_RETURN.
Thay đổi từ PR này cho phép người dùng đã cấu hình -datacarriersize không chỉ giới hạn lượng dữ liệu trong đầu ra OP_RETURN mà còn giới hạn cả lượng dữ liệu được nhúng trong phần chứng cứ (witness).
Cần lưu ý rằng PR này không thực hiện một phương pháp toàn diện để nhận diện mọi dữ liệu nhúng «bất kỳ» trong chứng cứ (vì hiện tại chưa có phương pháp chắc chắn nào để làm điều đó). Nó chủ yếu kiểm tra cấu trúc OP_FALSE OP_IF ... OP_ENDIF thường được dùng để xử lý dữ liệu inscriptions.
Mặc dù PR này đã thu hút nhiều cuộc thảo luận sôi nổi giữa các nhà phát triển, nhưng vào ngày 5 tháng 1 năm 2024, người duy trì mã nguồn Bitcoin Core achow101 đã chính thức đóng PR này. Trong tuyên bố cuối cùng của mình, achow101 cho biết PR do Luke đề xuất rõ ràng là gây tranh cãi, và ở trạng thái hiện tại, không có hy vọng đạt được một kết luận chấp nhận được đối với tất cả; vì vậy, ông không thấy lý do gì để tiếp tục giữ nó mở và gửi thông báo duy trì những cuộc tranh luận bế tắc liên tục.
Một nhà duy trì mã nguồn Bitcoin Core khác là gloria đã tổng hợp các quan điểm ủng hộ và phản đối từ cộng đồng phát triển về chủ đề này, Wu Shuo biên dịch như sau.
Quan điểm ủng hộ việc cấm «inscriptions»
1. «Cấm inscriptions – đây là các giao dịch rác»
Các loại giao dịch này được dùng cho ordinals, NFT, mang dữ liệu hoặc một số trường hợp sử dụng phi tài chính. Lưu lượng giao dịch này là «giao dịch rác», làm ảnh hưởng đến chức năng thanh toán của Bitcoin do khối lượng giao dịch cao và phí cao.
● Những giao dịch rác này khiến việc sử dụng đúng mục đích thật sự của Bitcoin ngày càng khó khăn hơn.
● Việc chèn dữ liệu là hành vi lừa dối và lạm dụng kịch bản taproot.
● Khả năng nhúng các byte ngẫu nhiên là một «lỗ hổng».
● Nếu Bitcoin là tiền tệ (và nó chính là như vậy!), thì các giao dịch phi tiền tệ nên được giảm thiểu tối đa.
● Những người cổ vũ ordinals là những cực đoan chống Bitcoin đến từ Ethereum, và những người hô hào «chúng ta cần thay đổi văn hóa Bitcoin» chỉ là những kẻ phá hoại tốn thời gian.
● Đây là sự lạm dụng mạng lưới – vốn được thiết kế dành cho các giao dịch tài chính (sách trắng, tên gọi và mã nguồn đều chỉ điều này), lưu trữ dữ liệu không phải là trường hợp sử dụng dự kiến.
● Điều này dẫn đến «tắc nghẽn mạng» và «phí cao hơn hoặc xử lý chậm hơn», chính là một dạng «tấn công DDoS».
● Vấn đề không nằm ở inscriptions, mà là ở mức phí cao.
● Mạng Bitcoin cần được bảo vệ ngay lập tức khỏi các cuộc tấn công bằng giao dịch rác.
2. «Inscriptions và dữ liệu nhúng gây hại cho mạng»
Loại giao dịch này làm tăng chi phí vận hành cho các nút, theo một cách nào đó gây tổn hại đến mạng.
● Các giao dịch mà PR này hướng tới chính là một trong những nguồn chi phí lớn mà các nút vận hành bình thường không thể chịu đựng nổi.
● Những giao dịch này ảnh hưởng đến tính phi tập trung của mạng bằng cách gia tăng chi phí vận hành nút.
● Điều này dẫn đến việc lưu trữ quá nhiều dữ liệu lớn không tương xứng trực tiếp trên chuỗi khối.
3. «Việc cấm là nhu cầu của người dùng»
Rõ ràng người dùng có nhu cầu và các trường hợp sử dụng cụ thể, do đó Bitcoin Core nên cung cấp tuỳ chọn này. Nếu không, mọi người sẽ tự viết và chạy các bản vá, điều này có thể không an toàn.
● Người vận hành nút cần một tùy chọn tích hợp để bỏ qua mọi hình thức mang dữ liệu hiện đại, để họ không phải vá thủ công nút của mình.
● Nếu các nhà phát triển không giúp người vận hành nút tự bảo vệ khỏi cuộc tấn công này, họ có thể phải resort đến các biện pháp không phù hợp để tăng cường phòng thủ.
● Tôi muốn kiểm soát chính sách mempool của tôi, tôi muốn tự quyết định đâu là giao dịch rác và đâu không phải.
● Nếu các thợ đào coi Bitcoin là tiền tệ chứ không chỉ là một chuỗi khối bất biến không cần giấy phép, họ thực sự sẽ lọc giao dịch rác để giữ mạng tiền tệ hoạt động, do đó họ mong muốn có chức năng này.
4. «Đây chỉ đơn thuần là sửa lỗi để datacarriersize hoạt động như dự kiến»
Chúng ta đã giới hạn dữ liệu mang trong OP_RETURN. Điều này cũng nên áp dụng cho mọi phương pháp nhúng dữ liệu tùy ý vào giao dịch. Đây luôn là «mục đích» của -datacarriersize, do đó đây là một «sửa lỗi».
● luke-jr cho rằng -datacarriersize không được cập nhật để bao gồm các loại mang dữ liệu khác khi segwit và taproot ra đời là một sai sót, và định nghĩa điều này là lỗi/hư hỏng.
● Bitcoin Core đã chuẩn hóa việc chèn dữ liệu tùy ý dài hơn 83 byte và việc chèn inscriptions là một cách né tránh giới hạn này, do đó đây là một bản sửa lỗi.
● Giao dịch rác đã được lọc ở nhiều tầng mã code khác nhau và điều này đã diễn ra hơn mười năm. Tất cả những gì PR này làm là áp dụng giới hạn datacarriersize hiện có lên một hình thức mang dữ liệu khác, rõ ràng đây là một lỗ hổng ngoài dự kiến.
● Nếu không phải để hạn chế dữ liệu tùy ý được lưu trữ trong giao dịch, thì mục đích của giới hạn trình mang dữ liệu là gì?
● Mục đích của quy tắc chuẩn hóa này không chỉ nhằm dữ liệu chứa trong scriptPubKey gốc, mà là tất cả các hình thức dữ liệu tùy ý.
Quan điểm phản đối việc cấm «inscriptions»
1. «Điều này sẽ không ngăn được inscriptions»
Việc này sẽ không ngăn được inscriptions. Vì thiếu tính tương thích động lực, các thợ đào (và tất nhiên cả người dùng inscriptions) rất khó có thể áp dụng chính sách này, nghĩa là hiệu quả của nó trong việc ngăn chặn các giao dịch này là rất nhỏ.
● Nếu chỉ riêng Ocean Pool sử dụng và nó vẫn là một nhóm khai thác tương đối nhỏ, thì sẽ không có tác dụng gì. Ngay cả khi được triển khai rộng rãi, việc né tránh cũng rất dễ dàng.
● Về lâu dài, điều này không tương thích động lực đối với các thợ đào.
● Các thợ đào khó có thể từ bỏ nguồn thu nhập đó. Việc kiểm duyệt các giao dịch này chỉ khuyến khích sự phát triển của các mempool riêng tư.
● Giao dịch ordinals cuối cùng sẽ đi vào chuỗi khối bằng cách bỏ qua mempool, do đó PR này không có tác dụng gì trong việc giải quyết hay giảm nhẹ vấn đề.
● Về cơ bản, đây là một nỗ lực không chỉ không giám sát các giao dịch này, mà còn cố gắng ngăn chặn việc sử dụng chúng, điều này ít nhất sẽ khiến các giao dịch né tránh các nút thực hiện việc này, hoặc tệ hơn là dẫn đến thực tiễn gửi trực tiếp giao dịch cho thợ đào, tạo ra rủi ro nghiêm trọng đối với sự tập trung hóa khai thác.
● Những người yêu thích inscriptions có thể duy trì sự lan truyền của inscriptions trên mạng bằng cách đảm bảo rằng một số ít nút trên mạng không lọc chúng.
● Rõ ràng, điều này tất yếu dẫn đến việc các mẫu khối được xây dựng từ mempool đã lọc sẽ có tổng phần thưởng khối thấp hơn so với mẫu khối được xây dựng từ tất cả các giao dịch chưa xác nhận. Nghĩa là bất kỳ thợ đào nào lọc inscriptions đều đang tự giảm thu nhập của mình, từ đó mang lại lợi ích cho các thợ đào không lọc.
2. «Chúng ta không thể viết mã để phát hiện mọi dữ liệu nhúng»
Nói chung, chúng ta không thể ngăn chặn các giao dịch nhúng dữ liệu tùy ý. Incriptions tồn tại dưới vô số hình thức nhúng dữ liệu (chúng ta sẽ không bao giờ có thể bao phủ hoàn toàn). Tốt hơn hết là nên duy trì những phương pháp hiệu quả nhất, tức là những phương pháp ảnh hưởng ít nhất đến chi phí tài nguyên mạng.
● Không có phương pháp phổ quát nào để lọc mọi cách mang dữ liệu hiện tại và tương lai. Điều này sẽ khởi động một trò chơi mèo đuổi chuột không hồi kết trong các đoạn mã cực kỳ quan trọng.
● Cố gắng ngăn chặn mọi kiểu nhúng dữ liệu sẽ khiến đoạn mã này ngày càng phức tạp. Mỗi lần như vậy, sẽ gây áp lực rất lớn lên đội ngũ duy trì buộc họ phải nhanh chóng thúc đẩy «ngừng giao dịch rác».
● Theo tôi biết, không có phương pháp hợp lý nào để ngăn người dùng lưu trữ dữ liệu tùy ý trong phần chứng cứ (witnesses) mà không khuyến khích hành vi tồi tệ hơn và/hoặc phá hủy các trường hợp sử dụng hợp lệ.
3. «Thay đổi này có thể gây hại»
PR này, bằng cách thay đổi chính sách mempool mặc định, có thể gây hại cho người vận hành nút độc lập và cho mạng.
● Loại trừ các giao dịch sẽ được khai thác là có hại đối với nút. Ý nghĩa của việc tham gia chuyển tiếp giao dịch và sở hữu mempool là khả năng dự đoán hình dạng của khối tiếp theo. Việc cố ý loại trừ những giao dịch tồn tại nhu cầu kinh tế rất rõ ràng (dù ngu ngốc) phá vỡ khả năng này.
● Cuối cùng, người dùng chạy bản vá này vẫn xử lý các khối chứa inscriptions. Họ chỉ làm hại ước tính phí của chính mình, làm chậm tốc độ xác thực khối và giảm tính hữu ích đối với các nút khác.
● Nói chung, thay đổi chính sách mặc định là nguy hiểm. Làm cho các giao dịch trước đây đạt tiêu chuẩn trở thành không đạt tiêu chuẩn có nghĩa là hiện tại một số người có thể thấy việc truy cập quỹ của họ trở nên khó khăn hơn. Bằng cách thay đổi giá trị mặc định thay vì để người dùng tự lựa chọn, nó đại diện cho một sự thay đổi hành vi tiềm tàng gây gián đoạn và không được mong muốn đối với các thợ đào dựa vào Bitcoin Core để xây dựng mẫu khối... Điều này sẽ tượng trưng cho một hình thức tịch thu nhẹ, cần được tránh.
4. Các quan điểm phản đối PR khác
● Nói chung, việc sử dụng chính sách mempool để ngăn chặn việc sử dụng hiện nay đã mất hiệu lực, mặc dù trước đây từng được dùng theo cách này. Mặc dù trong lịch sử tính «không đạt tiêu chuẩn» từng được dùng để ngăn một số thao tác nặng nề, tôi tin rằng:
○ Điều này bây giờ ít liên quan hơn nhiều trong bối cảnh không gian khối đầy đã trở thành điều bình thường, vì nó dù sao cũng sẽ không làm giảm chi phí vận hành nút.
○ Không thể ngăn các giao dịch đã có thị trường tồn tại, những giao dịch hàng ngày trả hàng chục BTC phí.
● Việc cố gắng «kiểm duyệt» giao dịch dựa trên trường hợp sử dụng là không phù hợp. Thị trường tự do quyết định cách sử dụng Bitcoin. Chúng ta không có quyền nói với người khác nên dùng Bitcoin thế nào. Nếu bạn nghĩ thiết kế của bạn tinh tế hơn, hãy cứ làm, và để thị trường tự do quyết định cái nào tốt hơn.
● Bitcoin là một mạng lưới phi tập trung, không cần giấy phép... bất kỳ ai cũng có thể sử dụng Bitcoin theo cách họ muốn, dù lý do sử dụng đó có phản cảm đến đâu.
● Điều này thay đổi vai trò của -datacarriersize, ngoài việc thay đổi chính sách mặc định, nó gộp chung chính sách kích thước đầu ra OP_RETURN và giới hạn dữ liệu mới trong mã kịch bản dư thừa được nhúng, khiến người dùng không thể cấu hình nút của mình để khớp với chính sách mặc định của phiên bản 26.0 trở về trước.
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
@glozow
