OP_RETURN và cuộc tranh luận gần đây

Tác giả: Jeffrey Hu

Liên quan đến cuộc tranh luận gần đây về việc dỡ bỏ các hạn chế đối với việc chuyển tiếp đầu ra OP_RETURN, các nhân viên liên quan đã có rất nhiều cuộc thảo luận sôi nổi trên nhiều kênh khác nhau (nhóm gửi thư, Github, diễn đàn, phương tiện truyền thông xã hội, v.v.) và đã có nhiều bản tóm tắt và diễn giải từ các tổ chức, phương tiện truyền thông và KOL, tất yếu có một số lập trường ủng hộ hoặc phản đối. Mặc dù bản sửa đổi để nới lỏng các hạn chế đã được hoàn thiện, nhưng thật không may, trong đó nội dung không hiểu chính xác tình hình khách quan theo quan điểm của tôi.

Tác giả hy vọng rằng bài viết này có thể cung cấp cho độc giả phần phổ cập chính xác nhất có thể về các nguyên tắc của OP_RETURN và tình hình liên quan của mạng Bitcoin , tóm tắt quan điểm của cả hai phía lần và nêu ra một số vấn đề quan trọng nhưng chưa được giải quyết.

OP_RETURN là gì?

Nhiều người, bao gồm cả tôi, có thể biết đến OP_RETURN đầu tiên vì nó cho phép người dùng ghi lại dữ liệu tùy ý trên Chuỗi Bitcoin . Vậy, hàm giống như biên bản ghi nhớ giao dịch này liên quan như thế nào đến tên của nó?

Không khó để thấy từ tiền tố "OP" rằng OP_RETURN là mã hoạt động trong tập lệnh Bitcoin. Nhưng nó mang dữ liệu như thế nào? Điều này cần được xem xét từ cấp độ tập lệnh Bitcoin.

 OP_RETURN <data>

OP_RETURN là opcode kết thúc luồng điều khiển. Giống như từ khóa return trong các ngôn ngữ lập trình khác sẽ trả về từ một hàm, một khi tập lệnh Bitcoin thực hiện thao tác này, nó sẽ ngay lập tức dừng thực thi và đánh dấu kết quả là false, điều này có nghĩa là thất bại (về lý do tại sao nó được thiết kế là false, tác giả sẽ giải thích bên dưới).

Vì các quy tắc đồng thuận của Bitcoin quy định rằng tất cả các tập lệnh đầu ra được tham chiếu bởi đầu vào phải trả về giá trị true sau khi thực thi, nên bất kỳ đầu ra nào chứa OP_RETURN sẽ không thành công khi cố gắng chi tiêu nó và trở thành "đầu ra không thể chi tiêu".

Điều quan trọng là, xác thực này chỉ được kích hoạt khi có nỗ lực chi tiêu đầu ra . Khi tạo giao dịch, việc tạo đầu ra bằng tập lệnh OP_RETURN không ảnh hưởng đến tính hợp lệ của giao dịch. Hơn nữa, các giao dịch như vậy sẽ được nút chuyển tiếp miễn là chúng đáp ứng các chính sách tiêu chuẩn của nút (chẳng hạn như giới hạn kích thước). Vì các đầu ra này không bao giờ có thể được chi tiêu, nên chúng không cần được lưu trữ trong bộ UTXO và do đó không làm tăng gánh nặng lưu trữ nóng của nút đầy đủ.

Điều này tương đương với việc cung cấp cho Bitcoin một chức năng để ghi dữ liệu(hoặc vẽ bậy).

Liệu Satoshi Nakamoto có đủ tư cách để từ chức không?

Có lẽ độc giả sẽ nói rằng việc viết nội dung cho Chuỗi Bitcoin là điều tự nhiên và đã được thực hiện từ thời xa xưa. Chẳng phải Satoshi Satoshi Nakamoto sao?

Thật không may, Satoshi Nakamoto vẫn chưa sử dụng một hàm tiên tiến như OP_RETURN. Toàn bộ hàm OP_RETURN đã đề cập ở trên đã được định nghĩa lại trong Bitcoin Core v0.9.0.

Mặc dù OP_RETURN đã tồn tại trong các phiên bản đầu Satoshi Nakamoto, trước v0.3.5, hành động của nó là bỏ qua phần tập lệnh chưa được thực thi và trả về phần tử trên cùng của ngăn xếp. Nó có giống một câu lệnh return theo nghĩa thông thường không? Nhưng điều này sẽ mang lại rủi ro bảo mật lớn. Ví dụ, kẻ tấn công có thể xây dựng nội dung sau trong tập lệnh mở khóa:

 OP_TRUE OP_RETURN

Khi OP_RETURN được thực thi, tập lệnh sẽ trả về OP_TRUE ở đầu ngăn xếp, bỏ qua mọi điều kiện kiểm tra trong tập lệnh khóa, do đó Bitcoin của bất kỳ ai cũng có thể bị đánh cắp! Vì vậy, Satoshi Nakamoto đã nhanh chóng sửa lỗi và thay đổi kết quả của OP_RETURN thành luôn thất bại (sai), đây là cơ sở của "dữ liệu mang, không thể chi tiêu" mà chúng ta thấy hiện nay.

Định nghĩa chi tiết hơn về OP_RETURN <data> như một tập lệnh chuẩn hóa, để các đầu ra OP_RETURN trong giới hạn kích thước dữ liệu có thể được chuyển tiếp trong mạng, đã có trong phiên bản Bitcoin Core v0.9.0 năm 2014 sau khi Satoshi Nakamoto nghỉ hưu.

Ở đây, tác giả tóm tắt ngắn gọn lịch sử sửa đổi của OP_RETURN như sau:

Nhiều phương pháp graffiti

Vậy Satoshi Nakamoto đã viết câu đó như thế nào? Có phương pháp nào khác để đưa dữ liệu vào Chuỗi ?

kịch bảnSig

Satoshi Nakamoto đã sử dụng trường scriptSig. Mặc dù scriptSig cần phải tương ứng với tập lệnh đầu ra (khóa công khai) trong quá trình mở khóa để chi tiêu thành công, miễn là tập lệnh được xây dựng cẩn thận (chẳng hạn như sử dụng OP_DROP để loại bỏ dữ liệu graffiti trước khi xác minh mở khóa, v.v.), vẫn có thể đạt được hiệu ứng mang dữ liệu tùy ý trong khi chi tiêu bình thường.

Hiện tại, việc ghi dữ liệu trực tiếp vào scriptSig không phổ biến lắm, nhưng vẫn được sử dụng, chủ yếu trong các giao dịch coinbase. Lý do có thể là các giao dịch coinbase không cần mở khóa các đầu ra trước đó và có thể được điền một số nội dung tự do hơn để ghi lại Block Height, nonce mở rộng, nhận dạng thợ đào, tín hiệu, v.v.

Vậy thì scriptSig có vấn đề gì khiến nó không được ưa chuộng? Một phần lý do có thể là chi phí : vì scriptSig nằm trong đầu vào của giao dịch, nên đầu ra phải được tạo trước, sau đó dữ liệu được chuyển khi đầu ra được chi tiêu, do đó ngoài kích thước của dữ liệu, phải trả phí cho đầu ra bổ sung và kích thước của giao dịch (phí của giao dịch Bitcoin có mối tương quan tích cực với kích thước của giao dịch). Một phần khác là sự phức tạp của lập trình, điều này cũng xuất phát từ việc phải tạo đầu ra có cấu trúc đặc biệt trước.

P2FK

Vì vậy, sau này mọi người đã nghĩ ra một cách để đơn giản hóa nó: vì bản thân đầu ra không được tạo ra để tiết kiệm tiền/chi tiêu (nó chỉ là một cầu nối để tiết lộ dữ liệu), nội dung được viết có thể được sử dụng trực tiếp làm khóa công khai nhận, tức là Pay-to-Fake- Key . Không cần phải khởi tạo một giao dịch chi tiêu mới và khối lượng thanh toán bổ sung tự nhiên nhỏ hơn và chi phí xử lý phí cũng giảm.

 OP_PUSHBYTES_65 <fake-pubkey-data> OP_CHECKSIG

Vì địa chỉ này không có private key hợp lệ để chi tiêu nên UTXO này không bao giờ có thể được chi tiêu và Bitcoin trong đó tương đương với việc bị đốt cháy; nhưng giao dịch có vẻ bình thường nút vẫn cần lưu trữ nó, sau cùng, nếu có private key tương ứng thì sao? Do đó, chi phí tự nhiên là việc mở rộng bộ UTXO và tăng chi phí lưu trữ nút.

Tương tự như vậy, có P2FKH (tương tự như P2PKH, dữ liệu bạn muốn ghi sẽ được sử dụng làm giá trị băm trong tập lệnh), P2FMS (Pay-to-Fake-Multisig, được ngụy trang thành khóa công khai trong tập lệnh đa chữ ký trần), v.v.

Trên thực tế, một trong những mục đích chính của việc định nghĩa lại OP_RETURN dưới dạng một tập lệnh chuẩn hóa là để cung cấp một giải pháp thay thế, hy vọng rằng mọi người sẽ không còn sử dụng các đầu ra giả mạo này khiến bộ UTXO mở rộng nữa.

Ordinals/Chữ khắc

Những người đã tìm hiểu về Bitcoin trong những năm gần đây có thể quen thuộc hơn với Ordinals và phương pháp ghi dữ liệu ("inscriptions"). Inscriptions đưa dữ liệu tệp tùy ý vào dữ liệu chứng kiến ​​của đầu vào Taproot.

Hiệu ứng cuối cùng của việc triển khai này khá khác so với OP_RETURN: dữ liệu trong đầu ra OP_RETURN đã được tiết lộ trong giao dịch tạo ra nó; các bản ghi yêu cầu một giao dịch bổ sung khác để tiết lộ dữ liệu chứng kiến ​​(tương tự như phương pháp scriptSig, nhưng tiết kiệm hơn). Ngoài ra, các bản ghi phải tuân theo ít chiến lược chuyển tiếp nhóm giao dịch trên toàn mạng hơn và hầu hết nút không chuyển tiếp đầu ra OP_RETURN có kích thước dữ liệu lớn hơn 80 byte.

Mặc dù có nhiều kỹ thuật khác để ghi dữ liệu, tác giả vẫn tóm tắt các phương pháp phổ biến hoặc đã từng phổ biến ở trên.

Chiến lược chuyển tiếp so với các quy tắc đồng thuận

Trong các bảng trên và trước đó, tác giả đã đề cập đến từ khóa "chiến lược chuyển tiếp giao dịch". Phần lớn trọng tâm thảo luận của cơn bão OP_RETURN gần đây là về chiến lược chuyển tiếp nhóm giao dịch.

Chính sách chuyển tiếp giao dịch đề cập đến sê-ri các quy tắc không đồng thuận mà một nút Bitcoin (như Bitcoin Core) thực hiện khi chuyển tiếp và chấp nhận các giao dịch chưa được xác nhận . Các chính sách này thường được sử dụng để ngăn chặn các cuộc tấn công DoS, dành chỗ cho nâng cấp trong tương lai hoặc hướng dẫn và khuyến khích hành vi tốt hơn. Nếu một giao dịch đáp ứng các quy định về chính sách chuyển tiếp cục bộ của nút(bao gồm các loại đầu vào và đầu ra, kích thước, phí, hành vi tập lệnh, v.v.), nút sẽ chấp nhận và chuyển tiếp giao dịch đó theo mặc định.

Ngoài ra còn có một khái niệm gọi là "giao dịch chuẩn", bản thân khái niệm này là một định nghĩa trong phần mềm Bitcoin Core: khi một giao dịch không phải là giao dịch chuẩn được định nghĩa trong phiên bản phần mềm này, nút sẽ không lưu hoặc chuyển tiếp giao dịch đó.

Ngược lại, có các quy tắc đồng thuận. Các quy tắc đồng thuận đề cập đến các tiêu chí cứng nhắc cho tất cả nút để xác định tính hợp lệ của các khối và giao dịch. Chỉ những giao dịch vi phạm sự đồng thuận mới bị toàn bộ mạng từ chối.

Sự khác biệt quan trọng giữa chiến lược chuyển tiếp và các quy tắc đồng thuận là một giao dịch có thể "không chuẩn" nhưng vẫn "hợp pháp" . Nói cách khác, nếu một giao dịch không đáp ứng chính sách chuẩn mặc định, nút sẽ chọn không chuyển tiếp giao dịch đó, không đưa giao dịch đó vào nhóm giao dịch hoặc thậm chí không đóng gói giao dịch đó, nhưng một khi giao dịch đó xuất hiện trong khối (do thợ đào đóng gói), nút khác vẫn sẽ xác định rằng khối đó hợp lệ theo các quy tắc đồng thuận.

Lấy đầu ra OP_RETURN làm ví dụ, mã lệnh này tồn tại từ đầu đến cuối và bất kể khối lượng dữ liệu được mang trong tập lệnh của nó lớn đến mức nào, nó cũng không vi phạm các quy tắc đồng thuận . Tuy nhiên, trước tranh chấp lần , hầu hết nút Bitcoin đều áp dụng giới hạn khối lượng dữ liệu 80 byte làm chiến lược chuyển tiếp giao dịch: Các đầu ra OP_RETURN có khối lượng dữ liệu nhỏ hơn 80 byte sẽ được chuyển tiếp tự do và các đầu ra vượt quá 80 byte sẽ không được chuyển tiếp.

Vì vậy, độc giả nên biết từ đây rằng rõ ràng là không phù hợp khi một số phương tiện truyền thông gọi sửa đổi lần là " nâng cấp Bitcoin OP_RETURN". Tác giả cũng hoài nghi về một số dự án mong đợi phát triển các dự án mới dựa trên sửa đổi OP_RETURN lần, vì có nhiều phương pháp khác nhau để gửi giao dịch OP_RETURN với khối lượng dữ liệu lớn hơn đến Chuỗi, về cơ bản không khác nhau.

Tuy nhiên, trước khi những thay đổi có hiệu lực, Bitcoin Core hiện có những điều khoản sau đây đối với các giao dịch tiêu chuẩn:

• Các loại tập lệnh chuẩn : chẳng hạn như P2PKH / P2SH / P2WPKH / P2WSH / P2TR (Taproot), v.v. ^1. Không sử dụng mã lệnh chưa xác định, v.v.
• Kích thước tập lệnh chữ ký : Độ dài của scriptSig cho mỗi đầu vào không được vượt quá 1.650 byte.
• Tổng kích thước giao dịch : không quá 100.000 vByte.
• Số lượng đầu ra : Có giới hạn thấp hơn về mệnh giá đầu ra, ví dụ, đầu ra P2PKH phải lớn hơn ít nhất 546 sat ² (giới hạn bụi) và đầu ra OP_RETURN là 0 sat.
• Ràng buộc của tập lệnh chữ ký
• Ràng buộc tỷ lệ phí : Đáp ứng mức phí tối thiểu do nút đặt ra
• Số phiên bản và các quy tắc tương ứng : chẳng hạn như v2, v3. Ngoài ra, còn có RBF, chuyển tiếp gói tin và các quy tắc khác.

Lưu ý 1: Thông qua điều kiện chi tiêu, người dùng có thể xây dựng nhiều loại giao dịch khác nhau, và P2FK ở trên là một ví dụ điển hình. Do đó, chuẩn hóa rất hữu ích cho các ứng dụng để hiểu ý nghĩa của đầu ra của chúng.

Lưu ý 2: Giáo sư Lang có thể tự tin nói: Bạn đưa cho tôi 1 bitcoin (theo BIP-177 ), nhưng tôi không muốn nó vì giới hạn bụi là 546 bitcoin.

Tại sao những hạn chế này lại quan trọng và thậm chí là trọng tâm của cuộc tranh luận lần? Các chức năng chính của giao dịch chuẩn bao gồm:

• Ngăn chặn lạm dụng: Hạn chế việc lan truyền thêm dữ liệu không hợp lệ, giao dịch quá lớn hoặc đầu ra rác. Điều này có thể giúp kiểm soát định dạng giao dịch trong mempool, giảm áp lực xác minh và lưu trữ, đồng thời giúp nút ngăn chặn hiệu quả các cuộc tấn công DDoS.
• Kiểm soát mở rộng trên Chuỗi: Chủ yếu kiểm soát kích thước của bộ UTXO. Về lý thuyết, nút cần giữ tất cả các UTXO, nghĩa là các khoản tiền có thể được chi tiêu bất cứ lúc nào trong tương lai. Việc lạm dụng hoặc mở rộng không cần thiết bộ UTXO (chẳng hạn như các cuộc tấn công bụi) sẽ ảnh hưởng nghiêm trọng đến hiệu suất của nút và do đó ảnh hưởng đến tính bảo mật và phi tập trung của toàn bộ mạng.
• Cải thiện hiệu quả và khả năng dự đoán: Chiến lược chuyển tiếp không chỉ hạn chế các giao dịch không tuân thủ các quy tắc mà còn tạo điều kiện thuận lợi cho các giao dịch tuân thủ các quy tắc. Khi thợ đào nhận được các giao dịch đáp ứng các tiêu chuẩn (như tuân thủ tỷ lệ phí, cấu trúc đầu ra rõ ràng và chữ ký hợp lý), họ có xu hướng đóng gói chúng vào khối nhiều hơn. Điều này cung cấp cơ sở ổn định để ví triển khai ước tính phí và RBF, đồng thời cho phép người dùng có kỳ vọng tốt hơn về thời gian xác nhận giao dịch.
• Cải thiện tính tương tác: Thông qua các biểu mẫu chữ ký và tập lệnh của Bitcoin, người dùng có thể xây dựng nhiều loại giao dịch khác nhau. Tuy nhiên, nếu chỉ định một số loại giao dịch tiêu chuẩn, ví và các ứng dụng khác sẽ dễ dàng phát triển hơn cho các định dạng giao dịch này, do đó cải thiện tính di động và tính tương tác của người dùng khi sử dụng các ứng dụng khác nhau.

Dòng thời gian của những tranh cãi gần đây

Với phần giới thiệu hơi dài ở trên, giờ chúng ta có thể giải quyết được tranh cãi gần đây về OP_RETURN.

Ưu quan điểm

Mặc dù PR 32406 đã được sáp nhập và mọi thứ dường như đã được giải quyết, tác giả vẫn hy vọng có thể sắp xếp lại quan điểm của cả hai bên. Một mặt, tôi hy vọng rằng độc giả sẽ xem xét lại các cuộc thảo luận và quan điểm này thông qua phần giới thiệu phổ cập trong nửa đầu của bài viết, và mặt khác, thông qua quan điểm này, chúng ta có thể kích thích thêm nhiều suy nghĩ và hiểu biết sâu sắc hơn. Ý kiến ​​cá nhân của tác giả sẽ được để lại trong chương tiếp theo.

Hỗ trợ nới lỏng quan điểm OP_RETURN

• Tôn trọng nhu cầu của người dùng và thừa nhận thực tế: Những người ủng hộ chỉ ra rằng các hạn chế liên quan đến OP_RETURN trong chính sách chuyển tiếp không thể ngăn cản lưu trữ trên Chuỗi, vì có nhu cầu thực tế của thị trường đối với điều này và người dùng sẵn sàng trả tiền cho nó. Lấy cơn sốt Ordinals làm ví dụ, lượng lớn dữ liệu phi tài chính như hình ảnh được ghi vào khối thông qua trường chứng kiến ​​và không phải tuân theo bất kỳ hạn chế chính sách tiêu chuẩn nào. Theo thống kê , Ordinals đã tạo ra hơn 88 lần inscription kể từ khi ra mắt và đã trả hơn 7.000 BTC phí xử lý, cho thấy nhiều người dùng sẵn sàng trả tiền cho lưu trữ Chuỗi. Thay vì tiếp tục khăng khăng áp dụng một hạn chế chỉ trên danh nghĩa, tốt hơn là nên dỡ bỏ nó theo thực tế - vì " con ngựa đã chạy ra khỏi hàng rào ", ngay cả khi không có OP_RETURN, những dữ liệu này vẫn sẽ nằm trên Chuỗi theo những cách khác.

• Nguyên tắc trung lập và chống kiểm duyệt: Các nhà phát triển Bitcoin Core nhấn mạnh rằng bản chất chống kiểm duyệt của mạng Bitcoin là thuộc tính chính và phần mềm nút phải giữ thái độ trung lập và không phân biệt đối xử dựa trên nội dung hoặc mục đích giao dịch. Họ cũng không thích dữ liệu rác hoặc việc sử dụng sai không gian Chuỗi, nhưng tin rằng cơ chế phí giao dịch là phương tiện cuối cùng để lọc giao dịch : miễn là ai đó sẵn sàng trả giá phí cao hơn những người khác cho một giao dịch, thợ đào có động cơ kinh tế để đóng gói giao dịch đó. Như Eric Voskuil, một nhà phát triển Bitcoin thời kỳ đầu, đã nói: " Khả năng chống lại kiểm duyệt cuối cùng đến từ phí giao dịch ". Do đó, thay vì cố gắng kiểm soát nó ở cấp độ chuyển tiếp, tốt hơn là để thị trường phí đóng vai trò - miễn là các giao dịch rác không thể tiếp tục trợ cấp cho các khoản phí cao, chúng sẽ dần biến mất vì chúng không có lợi nhuận. Quan điểm này cho rằng mặc dù việc lọc thủ công nútkhác về mặt đạo đức so với kiểm duyệt nội dung, nhưng về mặt hiệu ứng kỹ thuật thì tương tự nhau và cũng khó có thể chống lại nó bằng động lực kinh tế.

• Cái ít tệ hơn trong hai cái tệ: Quan điểm này cho rằng hiện tại, các đầu ra OP_RETURN mang khối lượng dữ liệu lớn không được phép chuyển tiếp tự do, khiến các nhà phát triển và người dùng sử dụng các phương pháp mạng "có hại" hơn để lưu trữ dữ liệu, chẳng hạn như P2FK và scriptSig đã đề cập ở trên, gây ra sự mở rộng vĩnh viễn của UTXO. Vì dữ liệu sẽ nằm trên Chuỗi dù sao đi nữa , nên việc để chúng tồn tại theo cách ít gây hại hơn cho nút là hợp lý. Các đầu ra OP_RETURN không nhập vào bộ UTXO và không cần phải thực thi các tập lệnh phức tạp trong quá trình xác minh, điều này thân thiện hơn nhiều so với các đầu ra giả chiếm dụng tài nguyên. Khi không gian khối được lấp đầy, lượng lớn OP_RETURN có thể giảm bớt gánh nặng nút: do sự tồn tại của chiết khấu chứng kiến, nếu một khối chứa đầy dữ liệu chứng kiến, kích thước thực tế gần bằng 4MB; nhưng nếu tất cả là OP_RETURN, thì không có chiết khấu và giới hạn byte khối là khoảng 1MB. Đồng thời, dữ liệu OP_RETURN có thể được cắt tỉa (không nhập vào bộ UTXO), điều này có lợi cho việc giảm chi phí vận hành của nút đầy đủ. Do đó, việc dỡ bỏ các hạn chế chuyển tiếp OP_RETURN có thể tránh việc sử dụng dữ liệu Chuỗi hơn và tối ưu hóa việc sử dụng tài nguyên của toàn bộ mạng.

• Tuân thủ hành vi thợ đào và cải thiện hiệu quả mạng: Nghiên cứu của BitMEX chỉ ra rằng nếu nút không chuyển tiếp các giao dịch thực sự được thợ đào chấp nhận theo mặc định, người dùng sẽ buộc phải dùng đến các kênh sở hữu tư nhân của nhóm khai thác để gửi giao dịch. Ví dụ, các nhóm khai thác như MARA cung cấp dịch vụ chấp nhận các giao dịch không chuẩn. Hậu quả là nội dung khối và nhóm giao dịch công khai ngày càng xa nhau và nút khó có thể biết được tất cả các giao dịch có trong khối một cách kịp thời, điều này sẽ phá hủy các cơ chế như khối nhỏ gọn giúp tăng tốc độ lan truyền khối, dẫn đến độ trễ lan truyền khối tăng lên . Việc lan truyền chậm hơn sẽ làm tăng khả năng thợ đào nhỏ bị cô lập sau khi tạo ra các khối, do đó làm trầm trọng thêm tình trạng tập trung hóa của ngành khai thác . Ngược lại, nếu chính sách nút phù hợp với hành vi thực tế thợ đào, thì mạng P2P công khai có thể chứa mọi loại giao dịch, thợ đào không cần thiết lập các kênh sở hữu tư nhân và các giao dịch có thể được phát và đóng gói hiệu quả hơn. Đồng thời, nhóm giao dịch của mỗi nút phản ánh chính xác hơn các giao dịch cần xác nhận và kỳ vọng của toàn bộ mạng đối với khối tiếp theo nhất quán hơn, giúp cải thiện ước tính phí xử lý và trải nghiệm của người dùng. Nhìn chung, việc xóa bỏ hạn chế OP_RETURN sẽ cho phép mạng Bitcoin vượt trội về tính minh bạch và hiệu quả, thay vì buộc các giao dịch lớn phải được đẩy ra phía sau hậu trường.

• Lựa chọn của người dùng và quy trình phát triển minh bạch: Những người ủng hộ cũng phản hồi cáo buộc "ép buộc mọi người phải chấp nhận", nhấn mạnh rằng người dùng vẫn có toàn quyền lựa chọn . Bản thân phần mềm Bitcoin Core là mã nguồn mở và bất kỳ ai cũng có thể sao chép và sửa đổi. "Bitcoin Core chỉ là một trong nhiều triển khai giao thức. Nó chỉ đặc biệt vì cách những người đóng góp đưa ra quyết định". Nếu phản đối mạnh mẽ, người dùng có thể bỏ phiếu bằng chân và tiếp tục chạy phiên bản cũ hoặc chuyển sang máy trạm khác , chẳng hạn như Bitcoin Knots, nơi duy trì chính sách nghiêm ngặt hơn. Mặt khác, các nhà phát triển Core cho rằng Đề án này đã được thảo luận và truyền đạt một cách cởi mở và minh bạch trong suốt quá trình ra quyết định: từ danh sách gửi thư đến GitHub, rồi đến tuyên bố chung vào tháng 6, thông tin có thể được công khai xem xét. Dựa trên điều này, những người ủng hộ cho rằng sửa đổi lần tuân theo tinh thần hợp tác mã mã nguồn mở nhất quán của quá trình phát triển Bitcoin và không bị nghi ngờ là "bị ép buộc mà không thảo luận".

Quan điểm phản đối việc nới lỏng các hạn chế OP_RETURN

• Lạm dụng không gian trên Chuỗi, đi chệch khỏi mục đích ban đầu của Bitcoin: Nhiều người phản đối cho rằng rằng không gian quý giá của blockchain Bitcoin chủ yếu nên phục vụ cho các giao dịch tiền tệ. Việc cấp phép quá mức cho dữ liệu phi tài chính được nhúng sẽ biến Bitcoin thành một " mạng lưu trữ dữ liệu ", làm mờ đi vị thế của nó như một hệ thống tiền điện tử ngang hàng. Như một người dùng đã nói một cách mỉa mai : "Cái này được gọi là Bitcoin (Bit'Coin'), không phải Bit'Store '". Lượng lớn hình ảnh, âm thanh và dữ liệu khác chiếm các khối sẽ làm chật không gian cho các giao dịch tài chính thông thường và làm hỏng giá trị hỗ trợ của Bitcoin như một mạng lưới tiền tệ . Khi OP_RETURN được sửa đổi để mang dữ liệu trong v0.9.0, người ta cũng đề cập cụ thể rằng việc ghi dữ liệu phi tài chính vào blockchain không được khuyến khích.

• Kích hoạt các giao dịch thư rác và rủi ro DoS tiềm ẩn: Sau khi các hạn chế được dỡ bỏ, những kẻ tấn công hoặc đầu cơ có thể gửi nhiều giao dịch thư rác hơn vì ngưỡng thực tế đã được hạ xuống. Điều này không chỉ làm tăng phí xử lý của người dùng thông thường (vì họ cần cạnh tranh với dữ liệu thư rác để giành không gian) mà còn có thể làm chậm tốc độ xử lý của nút và gây ra rủi ro tấn công từ chối dịch vụ (DoS) trên mạng. Những người có quan điểm này cho rằng thái độ của các nhà phát triển rằng "dữ liệu thư rác cuối cùng sẽ được thợ đào đóng gói" là một sự thỏa hiệp và chủ nghĩa thất bại , cho rằng họ không nên "đầu hàng" trước hành vi độc hại. Theo quan điểm của họ, một cách tiếp cận chủ động hơn là tăng cường lọc nút và văn hóa cộng đồng để ngăn dữ liệu thư rác được tải lên Chuỗi .

• Phá hủy tính tự chủ của chiến lược chuyển tiếp nhóm giao dịch: Những người phản đối nhấn mạnh rằng phi tập trung của Bitcoin không chỉ được phản ánh trong lớp đồng thuận mà còn trong quyền kiểm soát tự chủ của nút đối với nhóm giao dịch của riêng nó (mempool) và chiến lược chuyển tiếp cũng rất quan trọng. Việc hủy bỏ hạn chế OP_RETURN sẽ tước đi quyền lựa chọn tự chủ của người dùng : trước nút, các nút có thể từ chối các giao dịch vượt quá một kích thước nhất định thông qua các thiết lập tham số như -datacarrier , nhưng tùy chọn này sẽ bị xóa hoặc không hợp lệ trong phiên bản mới. Điều này có nghĩa là tất cả nút chạy phiên bản Core mới đều buộc phải chấp nhận và chuyển tiếp các giao dịch có tải dữ liệu lớn và cá nhân không còn được phép lọc dựa trên sở thích của họ nữa. Thay đổi này đã làm dấy lên mối quan ngại và nghi ngờ về "chiến lược nút đơn": Liệu đội ngũ phát triển Core có đang thay đổi mục đích của mạng lưới nhân danh các bản cập nhật phần mềm không? Các nhà phát triển có tiếng như Luke Dashjr đã công khai kêu gọi người dùng từ chối nâng cấp hoặc chuyển sang các triển khai nút có thể tuân thủ chiến lược lọc ban đầu (chẳng hạn như phần mềm Bitcoin Knots mà anh ấy duy trì).

• Quy trình ra quyết định và tranh chấp giá trị: Ngoài những lo ngại về mặt kỹ thuật, nhiều người phản đối đã bày tỏ sự phản đối đối với quy trình ra quyết định của thay đổi này. Theo PR tương ứng trên GitHub, một lượng lớn người dùng đã đưa ra lượng lớn biểu tượng cảm xúc 👎. Mặc dù đội ngũ Core tuyên bố rằng quy trình này là công khai và minh bạch, nhiều người vẫn cho rằng các nhà phát triển đã vội vàng hợp nhất mã khi chưa đạt được sự đồng thuận hoàn toàn và có những khác biệt rõ ràng trong cộng đồng, điều này vi phạm nguyên tắc "tránh tranh chấp một cách cẩn thận". Một số bình luận thẳng thắn nêu rõ: Thực tế này đã tạo ra tiền lệ rất xấu. Những người khác đặt câu hỏi về động cơ đằng sau sự thay đổi này, cho rằng rằng một số nhà phát triển đã bị ảnh hưởng bởi một số dự án "hệ sinh thái Bitcoin", chẳng hạn như Citrea.

Quan điểm ​​cá nhân

Từ cuộc thảo luận trên, nhiều phương tiện truyền thông có những diễn giải khác nhau hơn nữa, chẳng hạn như liệu Bitcoin có phi tập trung hay không, liệu nó có chống kiểm duyệt hay không, v.v. Tuy nhiên, tôi cho rằng rằng miễn là chúng ta hiểu rõ hơn về các nguyên tắc của Bitcoin, (ít nhất là từ trạng thái hiện tại), chúng ta sẽ không quá lo lắng, và sau đó chúng ta sẽ không bị vướng vào việc liệu nó phi tập trung như các loại tiền điện tử khác hay không. Cuộc tranh luận lần cũng đã làm sai lệch những lo ngại này ở một mức độ nào đó.

Nhìn lại toàn bộ sự việc, tôi đồng ý với Olaoluwa rằng đây là một lỗi không cố ý : không ai chủ động yêu cầu thay đổi; nếu có, thì đó là động thái phòng ngừa của nhà phát triển dựa trên một thứ gì đó vẫn chưa được triển khai và không có nhiều nhu cầu về các giao dịch không chuẩn trong tương lai gần. Nhưng bây giờ, các nhà phát triển đang ở trong tình thế tiến thoái lưỡng nan.

Chống kiểm duyệt so với thư rác

Một quan điểm rất quan trọng để ủng hộ việc nới lỏng các hạn chế là chúng ta không nên áp đặt các hạn chế đối với các giao dịch có thể được thực hiện trên Bitcoin và để thị trường quyết định, nếu không sẽ dẫn đến kiểm duyệt giao dịch trên thực tế.

Tôi đồng ý với một phần trong đó tuyên bố này. Một trong những đặc điểm kinh tế tuyệt vời Bitcoin không chỉ là tính ổn định vĩ mô (giới hạn phát hành 21 triệu) mà còn là tính đồng nhất của chính sách phí giao dịch ở cấp độ vi mô (luôn được tính theo khối lượng giao dịch). Ethereum, Ethereum không chỉ thay đổi tổng khối lượng kinh tế (PoS, EIP-1559 sửa đổi toàn bộ mô hình kinh tế) mà còn thay đổi chính sách phí thường xuyên ( nâng cấp Dencun làm giảm chi phí ghi dữ liệu). Vì vậy, nếu "bàn tay vô hình" có thể hoạt động, đừng để "bàn tay hữu hình" can thiệp, vì nó thường trở thành "bàn tay không thể kiểm soát".

Lần, OP_RETURN không thay đổi chính sách phí xử lý, nhưng quá trình sửa đổi được thúc đẩy nhiều hơn bởi "người viết mã" thay vì "người viết bài đăng".

Nhưng theo tôi, lập luận về việc kiểm duyệt giao dịch là không thể chấp nhận được. Sự khác biệt cốt lõi nằm ở chỗ nó liên quan đến nội dung hay hình thức, và liên quan đến người khác hay chính bản thân họ .

Một hành vi đánh giá giao dịch điển hình là nút tìm hiểu danh tính của người khởi tạo giao dịch (kẻ tấn công, đội ngũ rửa tiền, v.v.) hoặc nguồn tiền (không tuân thủ một số quy định pháp lý) và không cho phép công bố trên Chuỗi. Nói cách khác, sau khi tìm hiểu nội dung và "ngữ nghĩa" của giao dịch, nó sẽ chủ động ảnh hưởng đến những người khác .

Chính sách nút hạn chế OP_RETURN đối với các chuẩn mực chính thức và chỉ chuyển tiếp các giao dịch chuẩn được đề cập ở trên đáp ứng các chuẩn mực để ngăn chặn việc lạm dụng mạng. Một ví dụ phản biện điển hình là giai đoạn chiến tranh khối, khi mạng Bitcoin phải chịu một cuộc tấn công bụi nghiêm trọng. Nếu bạn cực kỳ tuân thủ khái niệm "miễn là ai đó sẵn sàng trả tiền", thì các cuộc tấn công bụi có thể không được coi là một cuộc tấn công mà là một cách sử dụng hợp lý không?

Mặt khác, chiến lược nút tập trung nhiều hơn vào việc xử lý nútcủa chính nó , chẳng hạn như lọc ra các giao dịch mà nó không quan tâm để giảm áp lực về mạng và lưu trữ.

Tính tự chủ của nút so với hiệu quả của mạng

Một trọng tâm khác của cuộc tranh luận là liệu có nên hỗ trợ nhiều hơn nút để tùy chỉnh các chiến lược chuyển tiếp và nhóm giao dịch hay liệu có nên duy trì tính nhất quán để cải thiện hiệu quả mạng (khả năng tương thích với khích lệ thợ đào , tốc độ lan truyền khối nhanh hơn và phí có thể dự đoán được hơn).

Về mặt hiệu quả, hiệu quả lan truyền khối nhanh hơn về mặt kỹ thuật là thuyết phục. Mặc dù không có nhóm giao dịch thống nhất , nhưng nếu nội dung nhóm giao dịch giữa nút nhất quán hơn, bản thân nút sẽ giữ lại nhiều giao dịch hơn sẽ có trên Chuỗi trong tương lai. Theo cơ chế khối nhỏ gọn, chi phí mạng sẽ giảm, giúp đồng bộ hóa khối nhanh hơn. Đồng thời, ước tính tỷ lệ sẽ chính xác hơn, điều này quan trọng hơn đối với một số giao dịch nhạy cảm với tỷ lệ (chẳng hạn như giao dịch được ký trước trên Lightning Network).

Nhưng câu hỏi đặt ra là, có quá nhiều giao dịch OP_RETURN đến mức chúng ảnh hưởng đáng kể đến việc truyền bá các khối dày đặc hay ước tính tốc độ không? Hay nó quá cấp bách đến mức chúng ta cần sử dụng "bàn tay hữu hình" của việc viết mã để quảng bá nó, thay vì đăng bài để kêu gọi mọi người sửa đổi cấu hình mặc định?

Tôi không muốn ra mắt sâu vào tầm quan trọng của mở rộng nút đối với mạng. Là một nhà điều hành nút, PR #32406 có thể chấp nhận được hơn đối với tôi, ít nhất là tạm thời giữ lại tùy chọn tự cấu hình nút.

Triển khai nút so với chính sách công khai của mạng

Như đã đề cập ở trên, chúng ta không thể gọi sửa đổi lần là " nâng cấp OP_RETURN của Bitcoin ". Đây chỉ là sửa đổi chính sách riêng của Bitcoin Core. Một số triển khai máy trạm khác không tuân theo cùng một thay đổi chính sách. Nhưng tại sao nó lại gây ra một cuộc tranh luận lớn như vậy? Tôi e rằng một lý do là Bitcoin Core là máy trạm được sử dụng rộng rãi nhất và là tiêu chuẩn thực tế.

Một ví dụ có lẽ không phù hợp là đồng đô la Mỹ, vừa là đồng tiền trong nước của Hoa Kỳ vừa là đồng tiền quốc tế trên thực tế. Hoa Kỳ có thể gây ảnh hưởng đến thế giới thông qua đồng đô la, nhưng khi xây dựng chính sách tiền tệ, tất nhiên cần phải xem xét đến các điều kiện kinh tế trong nước.

Bitcoin Core cũng có mâu thuẫn tương tự ở cấp độ “tiêu chuẩn thực tế”:

Một mặt, Bitcoin Core bị hạn chế bởi vị trí này và các chiến lược riêng của nó (quản lý nhóm giao dịch, chuyển tiếp giao dịch) không chỉ có thể xem xét bản thân nút mà còn cần phải tính đến tình hình của toàn bộ mạng. Các chiến lược mới có thể gây ra tác động đủ lớn, chẳng hạn như chuyển tiếp giao dịch v3 . Và các chiến lược này cũng sẽ ảnh hưởng rất lớn đến sự phát triển của các ứng dụng khác, chẳng hạn như Lightning Network.

Mặt khác, tiêu chuẩn de facto này cũng có khả năng ép buộc các giao thức mạng. Ví dụ, Bitcoin Core sẽ tiết lộ các lỗ hổng của các phiên bản trước theo các quy tắc . Do đó, mặc dù về mặt lý thuyết, người dùng có thể chạy máy trạm từ rất lâu trước đây , nhưng lỗ hổng bảo mật này sẽ buộc người dùng phải nâng cấp lên các phiên bản mới và chấp nhận các tính năng mới, đặc biệt là khi các tùy chọn cấu hình cũng bị xóa.

Xét theo sự cố lần, Bitcoin Core sẽ tiếp tục cân bằng giữa hai nhân vật này trong tương lai. Tuy nhiên, người dùng chạy nút không dễ bỏ phiếu bằng chân như một số nhà phát triển nghĩ: không thực tế khi mong đợi mọi người chạy nút đều sửa đổi mã và việc chuyển sang máy trạm khác cũng đòi hỏi phải cân nhắc rằng các máy khách khác có thể có ít tài nguyên phát triển và thử nghiệm hơn và có thể không đủ mạnh mẽ và an toàn. Sau đó, lựa chọn còn lại cho những người dùng bất đồng chính kiến ​​khá khó xử.

Vấn đề này hiện vẫn chưa được giải quyết.

(qua)