Bản nâng cấp lớn tiếp theo của Bitcoin là gì? Đánh giá OP_CAT và OP_CTV

Tác giả: Gabe Parker, nhà phân tích của Galaxy; Bản dịch: Golden Finance xiaozou

Tóm tắt

• Bitcoin có thái độ bảo thủ đối với các nâng cấp giao thức, khiến những thay đổi về sự đồng thuận trở nên tương đối hiếm. Nhưng như các bản nâng cấp SegWit và Taproot trước đây đã chỉ ra, các nhà phát triển vẫn sẵn sàng tối ưu hóa ngôn ngữ lập trình và các thông số mạng của Bitcoin.

• Ngôn ngữ lập trình của Bitcoin, Bitcoin Script, không cho phép các giao dịch mang trạng thái toàn cầu và có khả năng tự kiểm tra, điều này hạn chế khả năng biểu đạt của nó.

• Hiện tại có hai đề xuất chính là OP_CAT (BIP 347) và OP_CTV (BIP 119) nhằm mục đích nâng cao khả năng lập trình các giao dịch Bitcoin và cho phép đầu ra giao dịch có nhiều điều kiện chi tiêu hơn. Những đề xuất này có thể cải thiện đáng kể chức năng của Bitcoin Script, giúp nó linh hoạt hơn.

• Các kịch bản ứng dụng triển vọng nhất của OP_CAT và OP_CTV bao gồm:Thiết lập cầu nối chuỗi chéo không cần tin cậy giữa lớp đầu tiên (L1) và lớp thứ hai (L2) của Bitcoin,Cải thiện các giải pháp kho lưu trữ tự quản tiên tiến vàCải thiện Mạng Lightning.

• Quy trình quản lý nâng cấp soft fork liên quan đến nhiều bên liên quan của Bitcoin. Trong giai đoạn đầu của quá trình hình thành ý tưởng giao thức và đánh giá kỹ thuật, những người có sức ảnh hưởng trên phương tiện truyền thông và các nhà phát triển cốt lõi có ảnh hưởng lớn nhất.

• Galaxy Research dự đoán rằng các nhà phát triển cốt lõi của Bitcoin sẽ đạt được sự đồng thuận về OP_CAT hoặc OP_CTV vào năm 2025, nhưng do quá trình kích hoạt phức tạp nên việc triển khai thực tế có thể mất 1-2 năm.

1. Giới thiệu

Những thay đổi đối với giao thức Bitcoin đòi hỏi sự thảo luận và hợp tác giữa nhiều bên liên quan, bao gồm nhưng không giới hạn ở các nhà phát triển giao thức, nút đầy đủ, người dùng cuối và thợ đào. Quá trình đồng thuận để đạt được nâng cấp giao thức rất phức tạp và gây nhiều tranh cãi. Ví dụ, cuộc chiến về kích thước khối năm 2015-2017 đã chia rẽ cộng đồng Bitcoin thành những người muốn điều chỉnh kích thước khối và những người phản đối điều đó. Nhiều năm tranh luận đã dẫn đến sự chia tách vĩnh viễn trong blockchain và sự ra đời của một loại tiền điện tử mới, Bitcoin Cash, một phiên bản phân nhánh của Bitcoin.

Do khó đạt được sự đồng thuận về những thay đổi trong giao thức nên những nâng cấp lớn cho Bitcoin là rất hiếm. Các nhà phát triển giao thức Bitcoin có lịch sử lâu dài trong việc từ chối các nâng cấp gây tranh cãi và mất nhiều năm để triển khai những nâng cấp được cộng đồng Bitcoin rộng rãi ủng hộ. Điều này nhấn mạnh cam kết của các nhà phát triển trong việc áp dụng cách tiếp cận thận trọng đối với quá trình phát triển Bitcoin nhằm thúc đẩy khả năng dự đoán, độ trung thực của mạng và khả năng tương thích ngược.

Mặc dù những thay đổi về sự đồng thuận của Bitcoin tương đối hiếm, nhưng các nhà phát triển Bitcoin đã thể hiện thái độ cởi mở đối với việc tối ưu hóa các tập lệnh Bitcoin và các tham số mạng. Bản nâng cấp Segregated Witness (SegWit) xuất hiện sau cuộc tranh luận về kích thước khối thực chất đã tăng giới hạn kích thước khối, cho phép đưa nhiều giao dịch hơn vào một khối. SegWit cũng tối ưu hóa định dạng dữ liệu giao dịch bằng cách thay đổi đơn vị đo lường dữ liệu giao dịch từ byte sang byte ảo (vbyte). Sự thay đổi này, kết hợp với việc di chuyển dữ liệu chữ ký đến trường chứng kiến, cho phép một khối Bitcoin chứa tới 4 triệu đơn vị trọng lượng dữ liệu giao dịch (khoảng 4MB). Bản soft fork gần đây nhất của Bitcoin là bản nâng cấp Taproot năm 2021, giới thiệu ngôn ngữ lập trình được cập nhật có tên là Tapscript. Phiên bản mới này của Bitcoin Script bao gồm một lược đồ chữ ký mới (chữ ký Schnorr) và cải thiện khả năng tổng hợp khóa, kết hợp nhiều khóa công khai và chữ ký thành một khóa ký duy nhất. Việc tổng hợp khóa cho chữ ký Schnorr giúp giảm lượng dữ liệu giao dịch yêu cầu nhiều chữ ký đồng thời cải thiện tính riêng tư của các giao dịch trên Lightning Network (lớp thanh toán P2P lớn nhất của Bitcoin, được xây dựng trên lớp cơ sở của Bitcoin). Tổng quan ngắn gọn về SegWit và Taproot này cho thấy rằng, mặc dù các nhà phát triển Bitcoin thận trọng về những thay đổi trong sự đồng thuận của Bitcoin, nhưng điều này không có nghĩa là các tính năng kỹ thuật của Bitcoin sẽ không thay đổi.

Sau SegWit và Taproot, các nhà phát triển Bitcoin hiện đang tìm cách cải thiện khả năng lập trình giao dịch của Bitcoin để bổ sung thêm logic hợp đồng thông minh vào các giao dịch. Hợp đồng thông minh Bitcoin liên quan đến việc sử dụng các điều kiện chi tiêu, đó là khả năng giới hạn và kiểm soát cách các đầu ra giao dịch chưa chi (UTXO) có thể được chi tiêu trong tương lai. Các ràng buộc chi tiêu phức tạp và nghiêm ngặt hơn được gọi là "giao ước" ("hạn chế" hoặc "giao ước"). Bài viết này trước tiên sẽ xem xét Bitcoin Script và cách nó hoạt động với mô hình kế toán UTXO của Bitcoin. Sau đó, chúng tôi sẽ phân tích hai mã lệnh đang chờ xử lý, OP_CTV và OP_CAT, để làm nổi bật cách các mã lệnh này có tiềm năng cải thiện Bitcoin Script để bao gồm các tính năng mạnh mẽ cho phép lập trình giao dịch hiệu quả. Cuối cùng, bài báo nhấn mạnh tầm quan trọng của khả năng lập trình giao dịch đối với cơ sở hạ tầng Bitcoin như cầu nối và ký quỹ, đồng thời hướng đến khả năng đạt được sự đồng thuận về OP_CAT và OP_CTV, cũng như con đường triển khai các mã lệnh này vào bản nâng cấp soft fork tiếp theo.

2. Bitcoin Script và Mô hình UTXO

Bitcoin sử dụng ngôn ngữ kịch bản gốc để xây dựng các giao dịch, được gọi là "Bitcoin script". Một tập lệnh bao gồm một tập hợp các hướng dẫn xác định cách người nhận giao dịch có thể chi tiêu số bitcoin được gửi đi, còn được gọi là “điều kiện chi tiêu”. Bitcoin Script bao gồm 186 mã lệnh chạy như các hàm lệnh. Các mã lệnh này được sử dụng để tạo ra các quy tắc chính thức về cách chi tiêu và chuyển giao tài sản Bitcoin trên mạng. Ví dụ, giao dịch Pay-to-PubKey Hash chứa 4 mã lệnh thực thi các điều kiện chi tiêu cho các giao dịch Bitcoin, trong đó Bitcoin được chi cho một khóa công khai đã băm và chỉ có thể được chi tiêu bằng cách sử dụng đúng khóa công khai và khóa riêng được liên kết với người chi tiêu.

Script Bitcoin được thiết kế cho đầu ra giao dịch chưa sử dụng của Bitcoin (mô hình UTXO), sử dụng đầu vào và đầu ra. Mỗi giao dịch Bitcoin bao gồm ít nhất 1 đầu vào và 1 đầu ra, mặc dù hầu hết các giao dịch đơn giản đều bao gồm ít nhất 1 đầu vào và 2 đầu ra (một phần BTC ở phía đầu vào được sử dụng để tài trợ cho giao dịch, một phần được gửi cho người nhận và phần còn lại được trả lại cho người chi tiêu ở phía đầu ra). UTXO là một phần của Bitcoin chưa được chi tiêu và có thể được gửi trong các giao dịch trong tương lai. Khi UTXO được sử dụng làm đầu vào cho giao dịch, chúng không còn là đầu ra nữa. Do đó, khi người dùng chi tiêu Bitcoin, UTXO liên tục được tạo ra và hủy bỏ. Sau đây là ví dụ về mô hình UTXO đơn giản hóa:

*Nếu Alice có UTXO trị giá 1 BTC trong ví và cô ấy gửi 0,5 BTC cho Bob, thì đầu vào của Alice sẽ là 1 BTC. *Đầu ra của cô ấy sẽ là 0,49 BTC (trả lại cho Alice) và 0,5 BTC (gửi cho Bob). Sự chênh lệch 0,01 BTC thể hiện số BTC được trả dưới dạng phí giao dịch (phí giao dịch này sẽ thay đổi tùy thuộc vào tình trạng tắc nghẽn của mạng). *Khi kết thúc giao dịch này, Alice sẽ có một bộ UTXO mới đại diện cho 0,49 BTC còn lại của cô ấy. Ở bước 1, Alice sử dụng UTXO trị giá 1 BTC làm dữ liệu đầu vào đầu tiên của giao dịch, hủy UTXO. Ở bước 2, Alice tạo ra hai UTXO mới, trị giá 0,5 BTC và 0,49 BTC, một được trả lại cho cô ấy dưới dạng tiền thừa và một được trả cho Bob. Ở bước 3, Alice hiện có một UTXO mới trị giá 0,49 BTC. Lưu ý rằng nếu Alice cần trả cho Bob 0,5 BTC, Alice cũng có thể sử dụng nhiều UTXO ở bước 1, tổng cộng là 0,5 BTC; nếu không có UTXO đầu vào nào được cung cấp đầy đủ cho người nhận, thì Alice hiện có thể nhận được 2 UTXO mới thay vì 1. Mô hình UTXO là một tính năng chính của mạng Bitcoin và đóng vai trò quan trọng trong việc xử lý và xác minh giao dịch.

Ví dụ UTXO ở trên được xây dựng hoàn toàn bằng Bitcoin Script. Mỗi UTXO đều chứa một tập lệnh khóa, trong đó bao gồm một tập hợp các điều kiện mà theo đó UTXO có thể được sử dụng. Khi người dùng chứng minh quyền sở hữu đầu vào (UTXO đang được chi tiêu) bằng cách cung cấp chữ ký khóa riêng chính xác được liên kết với khóa công khai tương ứng, tập lệnh khóa của UTXO sẽ được mở khóa. Thông tin này được gọi là "chữ ký tập lệnh" và khi chữ ký tập lệnh chính xác được đưa vào dữ liệu đầu vào, các điều kiện chi tiêu sẽ được đáp ứng và bitcoin có thể được chi tiêu. Quay trở lại ví dụ UTXO của Alice và Bob, ở bước 1, Alice phải cung cấp chữ ký khóa riêng của mình trên dữ liệu đầu vào để sử dụng UTXO. Sau đó, Bob phải cung cấp thông tin tương tự trước khi chi tiêu 0,5 BTC mới nhận được.

Ngôn ngữ lệnh của Bitcoin có thể bao gồm các điều kiện chi tiêu phức tạp hơn, chẳng hạn như yêu cầu nhiều chữ ký hoặc mở khóa bitcoin ở độ cao khối cụ thể. Tuy nhiên, Bitcoin Script không phải là ngôn ngữ lập trình đa năng và thiếu sức mạnh biểu đạt như ngôn ngữ lập trình gốc của Ethereum là Solidity. Do đó, việc lập trình logic hợp đồng thông minh cho các giải pháp cầu nối và lưu ký bằng Bitcoin Script là vô cùng khó khăn.

3. Những trở ngại mà Bitcoin Script phải đối mặt tính đến năm 2025

Mặc dù Bitcoin Script đã chứng minh được tính thực tế đối với người dùng và khả năng chống lại các cuộc tấn công chi tiêu gấp đôi trong 16 năm qua, nhưng ngôn ngữ lập trình này vẫn thiếu các tính năng chung như khả năng biểu đạt và khả năng lưu trữ trạng thái toàn cục. Bitcoin Script không có tính biểu cảm vì nó là ngôn ngữ lập trình dựa trên ngăn xếp không thể thực hiện phép nhân và phép tính số học trên các số lớn. Bitcoin Script chỉ có thể thực hiện các phép tính không tầm thường trên các giá trị có kích thước 32 bit. Do đó, Bitcoin Script tách biệt các phần tử ngăn xếp lớn hơn 32 bit với nhau. Giới hạn 32 bit này cô lập các lệnh tốn nhiều tính toán bằng cách sử dụng các hàm mã hóa, phép nhân và phép chia đòi hỏi kích thước tập lệnh lớn hơn mức mà bộ mã lệnh hiện tại có thể xử lý. Mặc dù có thể mô phỏng phép tính số học và phép nhân bằng nhiều mã lệnh, nhưng điều này đòi hỏi nhiều phần tử ngăn xếp và Bitcoin Script có giới hạn kích thước ngăn xếp là 1000 phần tử. Do đó, việc tạo ra các điều kiện chi tiêu phức tạp cho các giao dịch đầu ra vượt ra ngoài các hoạt động hiện tại là một thách thức.

Hạn chế lớn nhất của Bitcoin Script là ngôn ngữ này không thể đọc/ghi và lưu trữ dữ liệu giao dịch vì nó chỉ có thể đọc dữ liệu đầu vào do người chi tiêu cung cấp. Nếu ngôn ngữ lập trình không thể lưu trữ trạng thái toàn cục, các tập lệnh không thể tự mình xác minh số dư tài khoản trong các ứng dụng hoặc cầu nối. Logic tập lệnh Bitcoin không thể truy cập trạng thái toàn cầu vì bất kỳ dữ liệu trạng thái nào cũng phải phù hợp với một giao dịch duy nhất. Do đó, gần như không thể phát triển các chức năng chung hoặc xây dựng cầu nối không cần tin cậy giữa mạng L2 và lớp cơ sở Bitcoin.

Những nỗ lực nhằm khắc phục những hạn chế của Bitcoin Script đã được tiến hành kể từ năm 2020. Trong nhiều năm, có vẻ như các nhà phát triển đã nhất trí rằng cách duy nhất để tăng khả năng biểu đạt của Bitcoin Script là thực hiện nâng cấp soft fork, triển khai các mã lệnh mới để cho phép giao ước. Trong khi một bộ phận cộng đồng Bitcoin tin rằng những nâng cấp này gây rủi ro cho mạng Bitcoin thì một bộ phận khác lại tin rằng Bitcoin cần nhiều tính năng lập trình hơn để mở rộng các trường hợp sử dụng Bitcoin. Mặc dù chưa có tiến triển thực sự nào về việc mã lệnh nào phù hợp nhất để cải thiện khả năng lập trình giao dịch của Bitcoin, nhưng những người ủng hộ giao ước hiện nay phần lớn đều đồng ý rằng OP_CTV và OP_CAT là Đề xuất cải tiến Bitcoin (BIP) chính để cải thiện khả năng lập trình giao dịch của Bitcoin. Chúng tôi hiểu rằng có nhiều hơn hai giải pháp để thực hiện các giao ước trên Bitcoin, nhưng bài viết này sẽ chỉ mô tả hai đề xuất nổi bật nhất là OP_CTV và OP_CAT.

4. BIP 119 (OP_CTV)

Đề xuất cải tiến Bitcoin 119 (BIP 119), còn được gọi là CHECK-TEMPLATE-VERIFY (CTV), được nhà phát triển cốt lõi của Bitcoin Jeremy Rubin đề xuất vào tháng 1 năm 2020. Đề xuất này giới thiệu một mã lệnh mới, OP_CTV, có thể thực thi các điều kiện chi tiêu chung, được gọi là giao ước, đối với kết quả của các giao dịch Bitcoin. Sau đây là phần giới thiệu tóm tắt. Phần mẫu trong “CHECK_TEMPLATE_VERIFY” đề cập đến định dạng giao dịch phải tuân theo khi viết tập lệnh Bitcoin. CHECK-TEMPLATE-VERIFY là tính năng mới cho phép tập lệnh khóa của đầu ra giao dịch cam kết với các điều kiện chi tiêu được lưu trữ trong tập lệnh khóa dưới dạng băm, còn được gọi là băm cam kết. Do đó, đầu ra giao dịch chỉ có thể được mở khóa nếu các điều kiện được nêu chi tiết trong hàm băm cam kết được đáp ứng. Sau khi được phát trên chuỗi, hàm băm cam kết liên quan đến giao dịch là không thể thay đổi. Lợi ích của OP_CTV là người gửi giao dịch có thể áp đặt các điều kiện chi tiêu cho người nhận, đây là một thay đổi đáng kể so với các quy tắc hiện tại của Bitcoin Script, vốn chỉ có thể xây dựng các điều kiện chi tiêu cho người gửi.

Có hai loại Giao ước chính. Một hợp đồng chung có thể được sao chép và áp dụng cho nhiều UTXO. Giao ước không hết hạn sau khi UTXO được sử dụng. Mặt khác, các hợp đồng được tính toán trước cũng có thể được sao chép, nhưng chỉ trong một số lần giới hạn được xác định trước. Logic của hợp đồng được tính toán trước phải được người gửi chỉ định trước và khác với hợp đồng chung ở chỗ các điều kiện chi tiêu không thể được sao chép vô hạn. Hợp đồng chung, còn được gọi là hợp đồng đệ quy, có thể gây rủi ro cho khả năng thay thế UTXO, đó là lý do tại sao những người ủng hộ BIP 119 thường chỉ tập trung vào trường hợp sử dụng OP_CTV bằng cách sử dụng hợp đồng được tính toán trước và tại sao BIP 119 không hỗ trợ hợp đồng chung. Ví dụ, nếu các giao ước chung được kích hoạt, bên lưu ký hoặc sàn giao dịch bitcoin có thể xử lý việc rút tiền với các điều kiện chi tiêu cố định, trong đó những bitcoin đó không bao giờ thoát khỏi khả năng bị chính phủ hoặc cơ quan có thẩm quyền khác kiểm duyệt.

5. Triển khai Giao ước bằng BIP 119

Lấy giải pháp kho bạc làm ví dụ, sau đây là cách hàm OP_CTV triển khai giao ước:

Alice muốn chi 0,8 BTC trong số 1 BTC UTXO của mình cho Bob và Charlie (mỗi người 0,4 BTC) trong 10 năm tới. Alice cũng muốn gửi tiền thừa của mình, khoảng 0,2 BTC, vào một két tiền mới để khóa BTC trong 10 năm nữa.

Bước 1:Alice chi UTXO trị giá 1 BTC của mình cho Bob và Charlie, và thông báo chi tiết trong tập lệnh khóa rằng Bob và Charlie có thể chi BTC sau 525 nghìn khối, tức là khoảng 10 năm sau đó. Alice cũng bao gồm hướng dẫn chi tiết rằng số tiền thay đổi của cô ấy là khoảng 0,2 BTC sẽ được gửi đến địa chỉ kho tiền mà cô ấy sở hữu, nơi sẽ khóa 525 nghìn khối UTXO của cô ấy hoặc khoảng 10 năm kể từ bây giờ.

Bước 2: Bob và Charlie chi tiêu UTXO tương ứng của họ trị giá 0,4 BTC sau 525 nghìn khối. Tập lệnh khóa do Alice thiết lập sẽ kiểm tra hàm băm cam kết so với chiều cao khối hiện tại và nếu đáp ứng được các điều kiện, Bob và Charlie có thể sử dụng UTXO mới của họ.

Ở bước 2, sau khi Bob và Charlie chi tiêu UTXO của họ, một phần của tập lệnh Bitcoin, còn được gọi là "tập lệnh khóa", sẽ kiểm tra việc thực hiện các điều kiện chi tiêu để đảm bảo rằng tất cả các điều kiện đều được đáp ứng trước khi giải phóng BTC. Hoạt động này thường được gọi là "mở khóa" đầu ra Bitcoin bằng cách sử dụng chữ ký tập lệnh chính xác. Nếu không đáp ứng được các điều kiện, tập lệnh khóa sẽ không khởi tạo việc chuyển BTC.

Bước 3:Sau khi Charlie và Bob thỏa mãn hàm băm cam kết trong tập lệnh khóa, UTXO (khoảng 0,2 BTC) được trả về cho Alice dưới dạng tiền thừa được sử dụng làm đầu vào cho địa chỉ có khóa công khai của tập lệnh kho lưu trữ đã chỉ định. Khóa công khai của tập lệnh vault bao gồm hàm băm cho phép Alice mở khóa vault sau 525 nghìn khối để chi tiêu UTXO của cô ấy trị giá khoảng 0,2 BTC. Lợi ích của việc sử dụng lược đồ két an toàn là Alice có thể thêm các biện pháp bảo mật chi tiết vào hàm băm, chẳng hạn như địa chỉ khôi phục bí mật, trong trường hợp ai đó đánh cắp khóa riêng của cô ấy và cố gắng mở khóa UTXO trước thời điểm khóa khối 525k. Nếu không có giao ước, trong ví dụ trước, Alice sẽ cần tạo một giao dịch được ký trước để thực thi các điều kiện chi tiêu trong tương lai đối với BTC mà cô ấy chi cho Bob và Charlie. Giao dịch được ký trước có thể là một hoặc nhiều giao dịch được ký trước bằng khóa riêng của người gửi nhưng không thực sự được phát tới mạng để xác nhận và thực hiện. Các giao dịch được ký trước không thể mở rộng quy mô vì chúng yêu cầu người dùng lưu trữ dữ liệu cho nhiều giao dịch cho đến khi chúng được thực hiện trên chuỗi. Ngoài ra, các giao dịch được ký trước yêu cầu phải có sự tương tác giữa tất cả các bên ký trước khi có thể chi tiền. Tuy nhiên, việc triển khai các giao ước sử dụng hàm băm cam kết thông qua OP_CTV giúp người dùng không cần phải lưu trữ dữ liệu giao dịch đã ký trước và dựa vào tính tương tác giữa tất cả các bên liên quan đến giao dịch.

Nói chung, chức năng này có thể được sử dụng để tạo ra một loạt các thiết kế lưu trữ và bảo mật phức tạp, có độ bảo mật cao và linh hoạt, giúp cải thiện các thiết lập tự lưu trữ hoặc được quản lý, tạo ra các thiết lập tài khoản doanh nghiệp hoặc số lượng thành viên mới sáng tạo hoặc tạo ra các chương trình thực thi tự chủ hơn với tính minh bạch và độ tin cậy cao hơn.

6. BIP 347 (OP_CAT)

BIP 347 là một đề xuất cải tiến Bitcoin khác do Ethan Heilman và Armin Sabouri viết vào tháng 10 năm 2023, cũng có thể triển khai các điều kiện chi tiêu được tính toán trước trên đầu ra của các giao dịch Bitcoin. Đề xuất này đề xuất thêm mã lệnh OP_CAT vào ngôn ngữ lập trình của Bitcoin, một tính năng cho phép các nhà phát triển Bitcoin "nối" hai điểm dữ liệu với nhau trong ngăn xếp và đặt các giá trị đó lên đầu ngăn xếp. Chúng ta hãy cùng xem qua phần giới thiệu ngắn gọn. "Ghép nối" là quá trình kết hợp hai hoặc nhiều chuỗi mã thành một chuỗi byte hoặc dữ liệu lớn hơn. Bitcoin Script là ngôn ngữ lập trình dựa trên ngăn xếp, đánh giá từng chuỗi mã theo trình tự. Đối với ngăn xếp gồm 5 dòng mã, Bitcoin Script sẽ đánh giá dòng 1 trước và dòng 5 cuối cùng. Thật không may, ngôn ngữ lập trình của Bitcoin không chứa mã lệnh cho phép các nhà phát triển hợp nhất nhiều chuỗi mã trên toàn bộ ngăn xếp. Hiện tại, Bitcoin Script thiếu các hàm số học và nhân, hạn chế khả năng nén Bitcoin Script, điều này hạn chế sự tương tác giữa các tập lệnh lớn (lớn hơn 32 bit) và các tập lệnh nhỏ (nhỏ hơn 32 bit) trong một ngăn xếp duy nhất. Nếu không có khả năng nén các tập lệnh thông qua "nối ghép" và cho phép các tập lệnh lớn giao tiếp với các tập lệnh nhỏ, các điều kiện chi tiêu phức tạp cho đầu ra giao dịch sẽ không khả thi. Điều quan trọng là các thành phần được kết nối của Bitcoin Script ở đầu ngăn xếp có thể mô phỏng các hàm số học và phép nhân, cho phép tạo ra các tập lệnh phức tạp mà không cần phải viết các tập lệnh dài, tốn nhiều dữ liệu và dễ xảy ra lỗi hơn. Ngoài ra, khả năng kết nối của OP_CAT cho phép các nhà phát triển tạo ra các điều kiện chi tiêu bằng cách sử dụng cây Merkle và các cấu trúc dữ liệu băm khác trong Tapscript, ngôn ngữ lập trình gốc được sử dụng để kích hoạt các loại giao dịch mới như một phần của bản nâng cấp Taproot sẽ được kích hoạt vào tháng 11 năm 2021.

Điều đáng chú ý là Satoshi Nakamoto đã vô hiệu hóa OP_CAT và các mã lệnh khác cho phép các tập lệnh Bitcoin thực hiện các phép toán phức tạp trực tiếp trong tập lệnh. Bản thân Satoshi Nakamoto đã xóa OP_CAT vì mã lệnh này có thể được kết hợp với OP_DUP để xây dựng các tập lệnh sử dụng nhiều dữ liệu khi giới hạn tập lệnh Bitcoin là 2000 byte tại thời điểm đó. Các tập lệnh có kích thước này có thể gây áp lực và quá tải cho tài nguyên tính toán của các nút Bitcoin. Tuy nhiên, bản nâng cấp Taproot đã giới hạn kích thước là 520 byte cho các tập lệnh Taproot vào năm 2021, do đó OP_CAT không còn gây thêm chi phí tính toán quá mức cho người vận hành nút nữa.

7. Triển khai Covenants bằng BIP 347 (OP_CAT)

Bản nâng cấp Taproot năm 2021 sẽ giới thiệu chữ ký Schnorr vào ngôn ngữ lệnh Bitcoin. Chữ ký Schnorr hỗ trợ tổng hợp khóa công khai và riêng tư, cho phép nhiều bên cùng ký một giao dịch bằng một chữ ký duy nhất. Việc kết hợp các mã lệnh xác minh có trong chữ ký Schnorr với OP_CAT sẽ tạo ra một hợp đồng không đệ quy tạo ra các hàm băm giao dịch. Thông qua OP_CAT, người dùng có thể hạn chế một số phần nhất định của giao dịch, chẳng hạn như địa chỉ gửi hoặc số tiền gửi, làm yêu cầu cho tập lệnh mở khóa và hàm băm giao dịch đóng vai trò là chìa khóa để mở khóa.

Lấy giải pháp vault làm ví dụ, sau đây là tổng quan về cách hàm OP_CAT triển khai Covenants. Các chi tiết kỹ thuật của ví dụ này nằm ngoài phạm vi của bài viết này.

Alice muốn tạo một kho lưu trữ mở khóa UTXO của cô ấy sau 100 khối:

*Bước 1:Alice chi UTXO của mình vào một địa chỉ kho lưu trữ và bao gồm thông tin chi tiết về các điều kiện chi của tập lệnh mở khóa kho lưu trữ trong trường chứng kiến, bao gồm cả chiều cao khối.

*Bước 2: Trong giao dịch của Alice, OP_CAT nối các hướng dẫn mở khóa két trong trường chứng kiến ​​và băm chúng hai lần để có được sighash/txhash.

*Bước 3:Sau khi 100 khối được xác nhận, Alice bắt đầu quá trình chi tiêu bitcoin kho bạc của mình bằng cách phát sóng giao dịch chi tiêu cho kho bạc UTXO. Để xác minh rằng Alice đáp ứng mọi điều kiện chi tiêu, ví của cô ấy sẽ thực thi mã lệnh CheckSig ở chế độ nền. Hoạt động này thực hiện hai xác thực chính: xác minh mã băm giao dịch từ giao dịch thiết lập ban đầu (bước 1) và so sánh với giao dịch chi tiêu hiện tại (bước 3). Chức năng CheckSig tái cấu trúc các thành phần của giao dịch thiết lập và xác minh chữ ký khóa công khai của giao dịch hiện tại để đảm bảo rằng tất cả các điều kiện chi tiêu kho tiền đã được đáp ứng.

*Bước 4:Sau khi khóa công khai của giao dịch của Alice được CheckSig xác minh (CheckSig sẽ xây dựng lại các điều kiện chi tiêu được lưu trữ trong trường chứng kiến), Alice có thể tự do chi tiêu UTXO của mình.

Ví dụ trên cho thấy bản thân OP_CAT không thể triển khai các điều kiện chi tiêu cho các giao dịch, nhưng OP_CAT kết hợp với các mã lệnh khác trong tập lệnh Bitcoin có thể đơn giản hóa việc viết tập lệnh và do đó triển khai các giao ước. Chức năng duy nhất của OP_CAT là nối hai phần tử trên cùng của ngăn xếp.

Mặc dù OP_CAT có thể được sử dụng với CheckSig để tạo giao ước, nhưng việc chỉ thêm OP_CAT sẽ không mang lại chức năng giống như Solidity cho Bitcoin Script. Giới hạn này cũng áp dụng khi chỉ thêm OP_CTV. Ngay cả với OP_CAT, các giao dịch Bitcoin cũng chỉ có khả năng tự kiểm tra tối thiểu, nghĩa là các giao dịch không có quyền truy cập đầy đủ vào các thành phần hoặc trạng thái của các giao dịch trước đó. Do đó, OP_CAT chỉ có thể hỗ trợ các giao ước chi tiết cho đầu ra giao dịch Taproot. OP_CAT không thể sửa chữa các nút lá của đầu ra Taproot hoặc xác minh các khóa nội bộ được sử dụng. Một nhánh Taproot là một điều kiện chi tiêu hoặc tập lệnh duy nhất được gửi tới đầu ra Taproot. Hãy nghĩ về chúng như những “con đường” hoặc cách khác nhau để chi tiêu bitcoin của bạn — mỗi nút lá đại diện cho một cách có thể chi tiêu nó. Khóa bên trong trong giao dịch Bitcoin Taproot là khóa công khai chính được sử dụng cho đường dẫn chi tiêu hiệu quả nhất. Khi sử dụng UTXO bằng khóa nội bộ, bạn chỉ cần cung cấp chữ ký trên chuỗi mà không tiết lộ bất kỳ tập lệnh hoặc đường dẫn Merkle nào.

Cần lưu ý rằng những hạn chế này có thể được giải quyết thông qua các đề xuất mã lệnh khác như OP_TWEAK_VERIFY và OP_INTERNALKEY. Nhìn chung, OP_CAT có thể được xem là nền tảng chính để tạo ra các điều kiện chi tiêu phức tạp cho đầu ra giao dịch; tuy nhiên, các nền tảng khác bao gồm CheckSig cũng rất quan trọng để thúc đẩy sự phát triển của khả năng lập trình giao dịch Bitcoin.

8. Các tính năng chính mà Covenants có thể mang lại cho Bitcoin

（1） Cầu nối không cần tin cậy và thoát đơn phương

Starkware (người tạo ra Starknet zk-rollup trên Ethereum) đã phát hành một báo cáo nêu bật cách OP_CAT hỗ trợ việc tạo trình xác thực STARK và trình xác thực Merkle để đạt được cầu nối Bitcoin không cần tin cậy. Cầu nối không cần tin cậy được xây dựng thông qua hệ thống hợp đồng đệ quy duy trì trạng thái cầu nối thông qua chuỗi giao dịch được ghi lại trong cây Merkle. Cốt lõi của cơ chế này là trạng thái liên tục của cầu nối được lưu trữ trong đầu ra OP_RETURN không thể chi tiêu, chứa hàm băm gốc của cây Merkle biểu thị số dư tài khoản. Giao ước OP_CAT yêu cầu mọi giao dịch gửi hoặc rút tiền mới phải chứa trạng thái chuyển tiếp hợp lệ phản ánh trạng thái cầu nối hiện tại. Người dùng tương tác với cây cầu thông qua các giao ước gửi và rút tiền chuyên biệt, sử dụng cây Merkle để tổng hợp nhiều giao dịch thành nhiều đợt nhằm xác minh hiệu quả. Gốc của cây Merkle này sau đó được sáp nhập vào hợp đồng cầu nối chính, nơi xác thực và xử lý mỗi khoản tiền gửi hoặc rút tiền. Trong quá trình rút tiền, hợp đồng sẽ xác minh quyền sở hữu bằng cách đảm bảo rằng địa chỉ rút tiền khớp với địa chỉ đầu tiên trong giao dịch lá. Thiết kế tận dụng bằng chứng Merkle để cập nhật trạng thái hiệu quả trong Bitcoin Script, tạo ra một hệ thống không cần tin cậy, trong đó trạng thái và quy tắc của cầu nối được thực thi đầy đủ thông qua logic hợp đồng trên chuỗi do OP_CAT tạo ra, mà không cần bên thứ ba đáng tin cậy. Điều quan trọng là, đối với một cầu nối Bitcoin không cần tin cậy để xác minh quá trình chuyển đổi trạng thái của hệ thống cuối, Bitcoin Script yêu cầu bằng chứng xác minh. OP_CAT xây dựng khả năng của trình xác thực STARK vào các tập lệnh Bitcoin bằng cách nối dữ liệu băm lại với nhau, cho phép các tập lệnh khóa UTXO xác minh bằng chứng zk (bằng chứng không kiến ​​thức) về quá trình chuyển đổi trạng thái hệ thống cuối.

Nhóm Taproot Wizard đã cải tiến một khuôn khổ cầu nối không cần tin cậy mới kết hợp OP_CAT với BitVM. BitVM đạt được khả năng biểu đạt hoàn chỉnh của Turing bằng cách cho phép phân vùng và thực hiện các phép tính tùy ý trên Bitcoin. BitVM chia thời gian chạy của các phép tính tùy ý sử dụng Bitcoin Script thành nhiều giao dịch trên Bitcoin. Nếu không có giao ước, cầu nối BitVM khóa Bitcoin sẽ yêu cầu một giao dịch được ký trước để thiết lập cầu nối. Khả năng mang dữ liệu từ các giao dịch trước đó của OP_CAT cho phép cầu nối BitVM khóa và mở khóa bitcoin mà không cần giao dịch được ký trước. OP_CAT có thể mang dữ liệu từ các giao dịch trước đó thông qua một thủ thuật gọi là “CAT trên ngăn xếp”. Thủ thuật này bao gồm việc nối dữ liệu đã băm trên ngăn xếp để xây dựng gốc cây Merkle, mà OP_CAT có thể xác minh. Do đó, cầu nối CatVM đảm bảo rằng dữ liệu giao dịch cụ thể từ các giao dịch trước đó, tiền gửi và tiền rút phải được đưa vào giao dịch tiếp theo để đảm bảo gốc Merkle được tiếp tục sau khi rút tiền thành công. CAT trên thủ thuật xếp chồng cũng đảm bảo rằng sau khi một người dùng rút tiền, số bitcoin còn lại được bắc cầu có thể được bất kỳ người dùng đủ điều kiện nào rút ra.

(2) Advanced Vault Custody

Bitcoin Vault là giải pháp lưu ký mới bao gồm các tính năng bảo mật như đường dẫn phục hồi, cho phép người dùng rút Bitcoin của họ đến một địa chỉ bí mật trong trường hợp khóa riêng bị rò rỉ. BIP 345, tên gọi chính thức là OP_VAULT, là Đề xuất cải tiến Bitcoin đang chờ xử lý, tận dụng OP_CTV để tăng cường các thông số bảo mật của dịch vụ lưu ký Bitcoin. Điều quan trọng cần lưu ý là OP_CAT cũng có thể được sử dụng để tạo điều kiện chi tiêu cho két Bitcoin mà không cần giao dịch được ký trước. Nhà phát triển Bitcoin Core James O’Beirne đã đề xuất OP_VAULT vào tháng 1 năm 2023 để thu hẹp các trường hợp sử dụng cho OP_CTV. OP_VAULT dựa vào OP_CTV để tạo điều kiện chi tiêu cho Bitcoin được lưu trữ mà không yêu cầu người gửi tiền phải ký trước nhiều giao dịch. Các giao ước cho phép két có thời gian trễ được kích hoạt khi có ai đó cố gắng chi tiêu số bitcoin trong két trước thời gian khóa ban đầu, thường thì kẻ tấn công sẽ cố gắng đánh cắp tiền.

（3）Hợp đồng không mơ hồ

Hợp đồng không mơ hồ được đưa vào mạng lưới Bitcoin vào năm 2015. Đây là đầu ra giao dịch Bitcoin. Nếu người ký chi tiêu gấp đôi, khóa ký sẽ bị rò rỉ. Trên thực tế, người dùng khóa Bitcoin gốc như một khoản tiền ký quỹ có thể cắt giảm. Khoản tiền gửi này cho phép người dùng thực hiện các giao dịch không xác nhận trên lớp cơ sở, sau đó được khai thác trong một khối. Giao dịch xác nhận 0 là giao dịch Bitcoin tức thời được xác minh và bảo mật theo các quy tắc đồng thuận của Bitcoin. Nếu người gửi giao dịch xác nhận 0 chi tiêu dữ liệu đầu vào trước khi giao dịch được khai thác, bên đối tác có thể mất khoản tiền ký quỹ Bitcoin của họ từ khóa ký bị xâm phạm.

（4）Cải tiến đối với Mạng Lightning

OP_CAT có thể kích hoạt Channel Factory, cho phép người dùng mở các kênh Lightning mà không cần phát giao dịch mở kênh trước trên lớp cơ sở Bitcoin. Ví dụ, nếu Alice muốn tạo 2 kênh sét (một với Bob và một với Charlie), Alice sẽ phát sóng giao dịch mở kênh với cả Bob và Charlie (2 giao dịch). Giao dịch mở kênh yêu cầu cả hai bên gửi Bitcoin vào địa chỉ đa chữ ký 2/2. Với nhà máy kênh, Bob và Charlie có thể mở các kênh riêng biệt với nhau mà không cần phát sóng giao dịch mở kênh mới. Do đó, tất cả những người tham gia vào giao dịch mở kênh ban đầu có thể tạo ra các kênh độc lập với nhau.

OP_CTV có thể tạo UTXO dùng chung, trong đó một UTXO đại diện cho nhiều người dùng. Việc sử dụng UTXO được chia sẻ của CTV cho phép nhiều người dùng mở nhiều kênh Lightning bằng một giao dịch trên chuỗi duy nhất. Thông thường, mỗi kênh Lightning yêu cầu một giao dịch trên chuỗi. Do đó, nếu nhiều người dùng mở kênh Lightning, điều này có thể làm đầy mempool bằng các giao dịch đang chờ xử lý và làm tăng phí giao dịch. Mặc dù hiện tại đây không phải là vấn đề, nhưng việc mở kênh sẽ cần phải mở rộng quy mô để hỗ trợ Lightning Network nhằm thu hút hàng triệu người dùng tích cực.

9. Rủi ro liên quan đến OP_CAT và OP_CTV

Tất cả các đợt soft fork của Bitcoin đều liên quan đến rủi ro kỹ thuật, chẳng hạn như lỗi trong mã lệnh mới hoặc các trường hợp sử dụng không lường trước được. Trong khi trường hợp trước rất hiếm thì trường hợp sau lại được phát hiện trong quá trình tạo ra các dòng chữ khắc. Ghi chú liên quan đến việc nhập dữ liệu tùy ý vào trường chứng kiến ​​của giao dịch, được sử dụng để tạo mã thông báo mới và bộ sưu tập NFT trên Bitcoin. SegWit và bản nâng cấp Taproot cho phép người dùng nhập hình ảnh và dữ liệu văn bản dưới dạng dữ liệu chuỗi vào trường chứng kiến. Trong khi nghệ thuật kỹ thuật số và việc tạo ra các token có thể thay thế không phải là mục đích kích hoạt SegWit hoặc Taproot, nhiều năm sau, các nhà phát triển thông minh đã tìm ra cách sử dụng các bản nâng cấp này cho các mục đích khác. Galaxy Research đã củng cố quan điểm này trong báo cáo Ordinals của chúng tôi, lưu ý rằng các dòng chữ vô tình được tạo ra thông qua SegWit và Taproot có thể tác động tiêu cực đến các bản nâng cấp Bitcoin trong tương lai, vì sự ngạc nhiên của cộng đồng trước những trường hợp sử dụng mới này có thể khiến họ ngần ngại hơn trong việc hỗ trợ các soft fork mới.

Bất chấp tâm lý bi quan về khả năng nâng cấp của Bitcoin, OP_CAT và OP_CTV đã được thử nghiệm và nghiên cứu rộng rãi. Lời chỉ trích ban đầu về các giao ước là chính phủ có thể buộc các ứng dụng phải thực thi các điều kiện chi tiêu chỉ cho phép một số địa chỉ được chấp thuận mới được phép chi tiêu Bitcoin. Lời chỉ trích này là không hợp lệ vì các điều kiện để chi tiêu được thực hiện được quyết định bởi người dùng sở hữu quỹ. Người dùng có thể tạo các giao dịch hạn chế chi tiêu trong tương lai vào các địa chỉ cụ thể, nhưng những hạn chế này không thể được bên thứ ba áp đặt bên ngoài và không được gia hạn vĩnh viễn sau khi số tiền bị khóa đã được chi tiêu. Do đó, chính phủ không thể thực thi cách thức chi tiêu tiền của ứng dụng kho bạc hoặc cầu nối tự lưu trữ. Trong khi người lưu ký và sàn giao dịch bitcoin vẫn có thể hạn chế cách người dùng chi tiêu tiền, họ không thể thêm các điều kiện chi tiêu cố định vào việc rút tiền mà không có khả năng thực thi các hợp đồng chung, điều mà OP_CTV không cho phép.

Nhìn chung, OP_CAT và OP_CTV là các mã lệnh đơn giản, mỗi mã lệnh thực hiện một chức năng rất tốt. OP_CAT nối hai phần tử ở đầu ngăn xếp, trong khi OP_CTV có thể băm các điều kiện chi tiêu trong tập lệnh khóa. Một số trường hợp sử dụng các mã lệnh này, chẳng hạn như phát triển các cầu nối không cần tin cậy, vẫn cần được nghiên cứu và thử nghiệm thực tế thêm vì các cầu nối rất dễ bị lỗi và tấn công.

10. Lộ trình triển khai Covenants cho bản nâng cấp soft fork tiếp theo

Xác định sự đồng thuận của các bên liên quan đến Bitcoin về các bản nâng cấp giao thức trong tương lai là một quá trình phức tạp phát triển theo vòng đời của một đề xuất, còn được gọi là quá trình BIP (Đề xuất cải tiến Bitcoin). Báo cáo của BCAP về lịch sử nâng cấp Bitcoin nêu chi tiết vai trò của các bên liên quan như sau:

* Các nút kinh tế: Các sàn giao dịch, đơn vị lưu ký, đơn vị bán hàng, đơn vị cung cấp dịch vụ thanh toán

* Các nhà đầu tư: Các cá voi, MicroStrategy, đơn vị cung cấp ETF, Galaxy

* Những người nổi tiếng trên phương tiện truyền thông: CoinDesk, Tạp chí Bitcoin, X, những người nổi tiếng trên podcast

* Những người khai thác: Bitmain, MicroBT, Riot, Marathon, những người khai thác tư nhân lớn

* Các nhà phát triển giao thức: Các nhà phát triển cốt lõi của Bitcoin

* Các nhà phát triển ứng dụng: Các dự án L2

Trong suốt vòng đời của Đề xuất cải tiến Bitcoin (BIP), các bên liên quan khác nhau có mức độ ảnh hưởng khác nhau và mức độ ảnh hưởng tương đối của họ thay đổi trong quá trình xây dựng sự đồng thuận để triển khai soft fork. Dưới đây là bảng phân tích chi tiết về mức độ ảnh hưởng của từng bên liên quan, được xếp hạng từ 1-10. Tính đến tháng 3 năm 2024, OP_CAT và OP_CTV đang trong giai đoạn hình thành giao thức. Trong giai đoạn này, những người làm truyền thông có ảnh hưởng lớn nhất vì họ có thể tác động đến dư luận và tạo ra các câu chuyện. Ví dụ, Taproot Wizards là một nhóm gồm những người có ảnh hưởng nổi tiếng trong lĩnh vực Bitcoin, sử dụng lượng người theo dõi lớn trên mạng xã hội để giáo dục cộng đồng Bitcoin về những lợi ích của OP_CAT. Nhóm Taproot Wizards đã sản xuất nội dung giáo dục và nghiên cứu về OP_CAT để thúc đẩy quan điểm cho rằng Bitcoin Script cần mã lệnh mới để nâng cao khả năng lập trình giao dịch. Kết quả là, Taproot Wizards đã xây dựng được một nhóm lớn những người ủng hộ OP_CAT và họ đang thúc đẩy các nhà phát triển cốt lõi xem xét bản thảo BIP của OP_CAT.

Trong giai đoạn hình thành ý tưởng giao thức, các nhà phát triển Bitcoin Core xếp thứ hai về tầm ảnh hưởng vì biên tập viên BIP chịu trách nhiệm xem xét bản thảo của các BIP đang chờ xử lý và quan trọng nhất là họ là thực thể duy nhất có thể hợp nhất các BIP vào kho lưu trữ GitHub của Bitcoin Core. Nếu không có sự hỗ trợ từ các nhà phát triển Bitcoin Core, BIP chắc chắn sẽ bị gác lại và cuối cùng bị từ chối. Các nhà phát triển Bitcoin Core cũng chịu trách nhiệm duy trì cơ sở mã Bitcoin và đảm bảo rằng nó không chứa bất kỳ lỗi nào. Đạt được sự đồng thuận giữa các nhà phát triển cốt lõi của Bitcoin là một quá trình khó khăn vì quan điểm tư tưởng có thể khác nhau giữa các nhà phát triển cốt lõi và ảnh hưởng của mỗi nhà phát triển cốt lõi trong quá trình ra quyết định khác nhau tùy thuộc vào đóng góp và lý lịch của họ.

OP_CAT và OP_CTV BIP đang ở giai đoạn mà những người nổi tiếng trên phương tiện truyền thông, người dùng và nhà phát triển ứng dụng đang sử dụng ảnh hưởng của mình để thuyết phục các nhà phát triển Bitcoin Core rằng những thay đổi về sự đồng thuận này sẽ làm tăng khả năng lập trình của các giao dịch Bitcoin. Giai đoạn tiếp theo của hành trình đồng thuận sẽ yêu cầu các chuyên gia kỹ thuật, nhà phát triển ứng dụng và nhà phát triển cốt lõi thực hiện nghiên cứu cụ thể để nêu chi tiết tất cả các rủi ro tiềm ẩn của OP_CAT và OP_CTV. Nếu không có nghiên cứu cụ thể và đối thoại cởi mở với các nhà phát triển cốt lõi, sẽ không có ý kiến ​​chung về OP_CAT và OP_CTV từ cộng đồng nhà phát triển cốt lõi nói chung.

Khi các nhà phát triển cốt lõi đạt được sự đồng thuận, OP_CAT và OP_CTV sẽ cần chỉ định một người bảo trì chính để tạo điều kiện cho bước cuối cùng của việc triển khai BIP vào kho lưu trữ Bitcoin Core. Sau khi BIP cho OP_CAT và OP_CTV được hợp nhất vào kho lưu trữ Bitcoin Core, cần phải đưa ra quyết định về phương pháp kích hoạt. Khi phương pháp kích hoạt được chọn, giai đoạn phát tín hiệu sẽ bắt đầu, trong đó thợ đào, nhà đầu tư và các nút kinh tế có ảnh hưởng lớn nhất. Tính đến tháng 3 năm 2024, các thợ đào, nhà đầu tư lớn như Microstrategy và các nút kinh tế như Coinbase vẫn chưa bày tỏ quan điểm công khai về OP_CAT và OP_CTV. Các bên liên quan này cần hiểu rõ hơn về rủi ro và lợi ích của OP_CAT và OP_CTV trước khi có thể triển khai BIP.

11. Phương pháp kích hoạt BIP

Nếu các nhà phát triển cốt lõi của Bitcoin đồng ý đưa OP_CAT hoặc OP_CTV vào bản nâng cấp soft fork tiếp theo, cộng đồng cần đạt được sự đồng thuận về phương pháp kích hoạt BIP. Phương pháp kích hoạt cho phép thợ đào báo hiệu sự sẵn sàng nâng cấp của họ.

Nói chung, có hai cách để thực hiện thay đổi mã trên Bitcoin. Đầu tiên, việc thay đổi mã có thể được thực hiện thông qua soft fork. Soft fork là những bản nâng cấp tương thích ngược cho phép người vận hành nút Bitcoin vận hành an toàn trên mạng Bitcoin ngay cả khi không nâng cấp phần mềm máy khách. Một lợi ích khác của việc soft fork tương thích ngược là bất kỳ ai không đồng ý với định hướng của Bitcoin Core (phần mềm máy khách Bitcoin chính) đều có thể chọn chạy phiên bản cũ hơn của phần mềm máy khách loại trừ việc kích hoạt BIP mới nhưng vẫn có thể kết nối với chuỗi khối Bitcoin chuẩn. Soft fork bổ sung chức năng bằng cách tạo ra các điều kiện mới hạn chế hơn so với bộ quy tắc hiện có và do đó phù hợp với các quy tắc hiện có.

Khi một soft fork được kích hoạt bởi người dùng (thay vì thợ đào), thì nó được gọi là soft fork do người dùng kích hoạt (UASF). Ví dụ nổi tiếng nhất về UASF trên Bitcoin gần như đã xảy ra trong "cuộc chiến kích thước khối" vào ngày 1 tháng 8 năm 2017, nhằm giúp đẩy nhanh quá trình áp dụng nâng cấp SegWit. Trong quá trình tranh chấp về kích thước khối, người dùng Bitcoin đã nâng cấp các nút của họ để hỗ trợ nâng cấp SegWit và sau đó đe dọa sẽ từ chối các khối từ các nút không được nâng cấp. Bằng cách đó, những thợ đào chưa nâng cấp phần mềm Bitcoin của mình sẽ được khuyến khích áp dụng Segwit để khối của họ được lan truyền rộng rãi hơn và tăng cơ hội nhận được phần thưởng khối. Mặc dù UASF chưa bao giờ xảy ra trong cuộc chiến kích thước khối, nhưng mối đe dọa về UASF tiềm tàng đã ảnh hưởng đến các thợ đào áp dụng SegWit.

Cách thứ hai để triển khai thay đổi mã là thông qua hard fork, đây là bản nâng cấp không tương thích ngược, chia tách vĩnh viễn sự đồng thuận giữa các nút đã nâng cấp và chưa nâng cấp. Các nhà phát triển Bitcoin Core chưa bao giờ triển khai hard fork vì cộng đồng coi trọng sự ổn định và khả năng tương thích ngược của mã giao thức. Bitcoin có thể bị chia tách chuỗi nếu một nhóm nhỏ người dùng thực hiện nâng cấp hard fork, chẳng hạn như thay đổi kích thước khối. Đây là cách Bitcoin Cash được tạo ra vào năm 2017 khi một bộ phận cộng đồng Bitcoin không đồng tình với bản nâng cấp Segwit và thay vào đó muốn tách khỏi giao thức Bitcoin bằng cách kích hoạt thay đổi mã không tương thích ngược để chỉ tăng kích thước khối.

Ngoài sự khác biệt giữa kích hoạt hard fork và soft fork, còn có nhiều cách khác nhau để đánh giá cảm nhận của cộng đồng đối với bản nâng cấp trước khi quá trình fork diễn ra. Sau đây là tổng quan về các loại quy trình BIP khác nhau do cộng đồng Bitcoin đề xuất để hỗ trợ tốt hơn cho việc kích hoạt các nâng cấp soft fork:

*BIP 9: BIP 9 cung cấp một khuôn khổ để thợ đào thể hiện sự hỗ trợ của họ đối với các nâng cấp soft fork bằng cách sửa đổi trường bit phiên bản trong tiêu đề khối Bitcoin. Sau khi giai đoạn báo hiệu kết thúc, cộng đồng Bitcoin có thể đánh giá tỷ lệ thợ đào ủng hộ việc nâng cấp và bỏ phiếu dựa trên tỷ lệ băm của thợ đào. Nếu vượt quá ngưỡng hỗ trợ nhất định, quá trình nâng cấp có thể tiến hành kích hoạt vào “ngày cờ”, đơn giản là chiều cao khối được chỉ định để kích hoạt quá trình nâng cấp.

*BIP 8:Nhà phát triển Bitcoin Core lâu năm Luke Dashjr (người đã làm việc về phát triển Bitcoin từ năm 2011) đã đề xuất BIP 8 vào tháng 2 năm 2017 với tư cách là phiên bản kế nhiệm của BIP 9. BIP 8 đề xuất sử dụng chiều cao khối thay vì hashrate để xác định thời lượng của giai đoạn báo hiệu để phê duyệt đề xuất. BIP 8 cũng giới thiệu một tham số soft fork mới được kích hoạt trên chuỗi có tên là “LOT”. Nếu tham số này được đặt thành "TRUE", cần có tín hiệu trong thời gian hoàn tất để đảm bảo rằng soft fork bị khóa ở độ cao thời gian chờ. Từ đây trở đi, việc nâng cấp sẽ được các nút kích hoạt vào ngày cờ được xác định trước, bất kể thợ đào có phát tín hiệu hay không. BIP 8 tìm cách giảm sự can thiệp của thợ đào vào các hoạt động đề xuất mà cộng đồng mong muốn và buộc thợ đào phải cân nhắc hậu quả của việc mất doanh thu do không nhận được khối từ các nút được nâng cấp nếu tham số LOT của bản nâng cấp được đặt thành ĐÚNG.

*Bản dùng thử nhanh: Các nhà phát triển cốt lõi của Bitcoin là AJ Townes và Andrew Chow đã giới thiệu phiên bản BIP 8 có tên là “Bản dùng thử nhanh” vào tháng 4 năm 2021. Speedy Trial cố gắng đẩy nhanh mốc thời gian để thợ mỏ báo hiệu sẵn sàng kích hoạt. Cách tiếp cận này có nghĩa là một đề xuất sẽ được kích hoạt khi phần lớn các khối được khai thác trong một khoảng thời gian nhất định cho thấy tín hiệu sẵn sàng. Chức năng dùng thử Speedy Trial tương tự như triển khai kích hoạt BIP 9, nhưng có cửa sổ kích hoạt ngắn hơn. Gần đây, bản nâng cấp Taproot đã được kích hoạt trên Bitcoin thông qua bản dùng thử Speedy. Bản dùng thử yêu cầu 90% khối được khai thác phải báo hiệu sẵn sàng trong khoảng thời gian hai tuần trước khi Taproot có thể được kích hoạt trên mạng. Phiên tòa kết thúc vào ngày 12 tháng 6 năm 2021. Sau khi đạt ngưỡng hỗ trợ 90% thợ đào, mạng sẽ bước vào thời gian chờ năm tháng để thợ đào và nút có thời gian nâng cấp phần mềm của họ. Taproot sau đó được kích hoạt chính thức trên Bitcoin vào ngày 15 tháng 11 năm 2021.

*Kích hoạt Soft Fork hiện đại:Đây là phương pháp kích hoạt nâng cấp kết hợp các thuộc tính khác nhau của BIP 9 và BIP 8. Ý tưởng này được đề xuất vào tháng 1 năm 2020 bởi Matt Corallo, một trong những người đóng góp tích cực nhất cho Bitcoin Core. Phương pháp này bao gồm ba bước. Bước đầu tiên là một soft fork được kích hoạt bởi thợ đào như được nêu trong BIP 9. Nếu thợ đào không kích hoạt bản nâng cấp, quy trình kích hoạt soft fork hiện đại do Corallo vạch ra sẽ mặc định chuyển sang bước thứ hai, thời gian chờ sáu tháng để các nhà phát triển và cộng đồng bitcoin nói chung xem xét lại việc thay đổi mã. Sau sáu tháng, nếu nhà phát triển và người dùng muốn tiếp tục nâng cấp, họ có thể bắt đầu bước ba, về cơ bản tương đương với BIP 8 với tham số LOT được đặt thành TRUE.

12. Kết luận

Mặc dù OP_CAT (BIP 347) và OP_CTV (BIP 119) đã nhận được sự hỗ trợ từ nhiều nhà phát triển Bitcoin nổi tiếng, nhưng những đề xuất này vẫn cần phải trải qua quá trình thẩm định dài hạn trước khi có thể được triển khai. Điều này là do OP_CAT và OP_CTV yêu cầu phải thay đổi lớp đồng thuận của Bitcoin và quy trình quản trị BIP cho những thay đổi như vậy rất rộng rãi. Mặc dù mốc thời gian kích hoạt cho BIP 119 và BIP 347 không rõ ràng và không thể đoán trước, nhưng thời gian xem xét dài có thể mang lại lợi ích cho các đề xuất vì nó cung cấp cho cộng đồng đủ thời gian để hiểu được những lợi ích và tác động của OP_CTV và OP_CAT. Ngoài ra, những người đóng góp BIP sẽ có nhiều thời gian hơn để kiểm tra mức độ căng thẳng của OP_CTV và OP_CAT cũng như tác động tiềm ẩn của chúng đối với các lỗi trong tương lai của Bitcoin Script.

Mặc dù tiềm năng đầy đủ của OP_CAT và OP_CTV vẫn đang được khám phá, tác động tức thời nhất của chúng là tạo ra những cầu nối không cần tin cậy cho Bitcoin L2 và các kho lưu trữ Bitcoin an toàn tiên tiến. Không thể phủ nhận tầm quan trọng của việc bắc cầu không cần tin cậy đối với Bitcoin L2 tương thích với EVM, đặc biệt là trong bối cảnh Bitcoin DeFi tiếp tục phát triển. Các giải pháp không cần tin cậy này đại diện cho sự tiến bộ đáng kể so với các giải pháp thay thế hiện tại như WBTC và cbBTC, vốn dựa vào các trung gian đáng tin cậy và làm suy yếu bản chất không cần cấp phép của công nghệ blockchain. Trong khi kho lưu trữ Bitcoin tự lưu trữ có thể mang lại giá trị thiết thực nhất trong số các giải pháp lưu ký, thì tiềm năng của các cầu nối L2 không cần tin cậy cho thấy khả năng rộng lớn hơn mà khả năng lập trình giao dịch nâng cao mang lại cho Bitcoin.

Cộng đồng nhà phát triển đã đạt được tiến bộ đáng kể trong việc thúc đẩy các đề xuất này vào năm 2024 và đà phát triển tốt này có thể sẽ tiếp tục vào năm 2025. Với hoạt động giao dịch Bitcoin có xu hướng giảm và phí giao dịch thấp tới 1 sat/VB, trọng tâm hiện đang chuyển sang cách khôi phục hoạt động giao dịch trên mạng Bitcoin. Mặc dù báo cáo dự báo Galaxy Research 2025 của chúng tôi giả định rằng các nhà phát triển Bitcoin Core sẽ đạt được sự đồng thuận giữa OP_CAT hoặc OP_CTV, quá trình triển khai và kích hoạt cuối cùng có thể mất thêm 1-2 năm nữa. Tuy nhiên, việc áp dụng những đề xuất này cuối cùng sẽ là một cột mốc quan trọng trong quá trình phát triển Bitcoin Script, đặt nền tảng cho các ứng dụng Bitcoin tinh vi và an toàn hơn trong tương lai.

Bằng cách nâng cao khả năng lập trình giao dịch, Bitcoin sẽ có thể hỗ trợ nhiều trường hợp sử dụng sáng tạo hơn, chẳng hạn như cầu nối chuỗi chéo không cần tin cậy và các giải pháp lưu ký tiên tiến, thúc đẩy hơn nữa sự phát triển của hệ sinh thái Bitcoin. Việc giới thiệu các công nghệ này không chỉ cải thiện chức năng của Bitcoin mà còn cung cấp cho các nhà phát triển và người dùng nhiều công cụ hơn để xây dựng các ứng dụng phi tập trung an toàn và hiệu quả hơn. Mặc dù việc đạt được các mục tiêu này sẽ mất thời gian và cần có sự chung tay nỗ lực của cộng đồng, nhưng tác động tiềm tàng của chúng chắc chắn sẽ mang lại sức sống mới cho tương lai của Bitcoin.