Lần đầu tiên sau bốn năm, Bitcoin có thể trải qua một “phân nhánh mềm do người dùng dẫn đầu” không?

Tiêu đề gốc: "Lần đầu tiên sau bốn năm, liệu Bitcoin có thể mở ra một 'phân nhánh mềm do người dùng dẫn đầu' không?" 》

Tác giả gốc: GaryMa, Wu Says Blockchain

Theo Blockspace, cộng đồng Bitcoin cơ sở đang bắt đầu thúc đẩy những thay đổi đối với phần mềm cơ bản của Bitcoin, đây là một sự kiện hiếm hoi trong hơn bốn năm (trước đây, bất kỳ thay đổi cơ bản lớn nào đều do nhóm nhà phát triển cốt lõi thúc đẩy).

Lần này, sự ủng hộ từ cơ sở đang nổi lên đối với hai Đề xuất cải tiến Bitcoin (BIP), cụ thể là BIP-119 (CTV) và BIP-348 (CSFS). Hai đề xuất này đề xuất những cách mới để viết các tập lệnh Bitcoin cho phép Bitcoin thực hiện chức năng "Giao ước". Cả hai đề xuất đều có thể được triển khai trong đợt soft fork tiếp theo của Bitcoin.

Để tránh một số độc giả tạm thời không hiểu được mối quan hệ giữa Giao ước của Bitcoin và các giải pháp BIP cụ thể này, chúng tôi xin làm rõ ở đây:

Nói một cách đơn giản, Giao ước là một khái niệm chức năng trong mạng Bitcoin và hai BIP được đề cập trong bài viết là các giải pháp triển khai khác nhau để hiện thực hóa khái niệm chức năng này.

Giao ước Bitcoin là gì?

Định nghĩa:

Giao ước là một cơ chế được đề xuất trong giao thức Bitcoin cho phép đặt ra các điều kiện hoặc hạn chế trong giao dịch, chỉ định cách thức Bitcoin có thể được chi tiêu hoặc chuyển nhượng. Những điều kiện này có thể áp dụng cho nhiều giao dịch, hạn chế cách thức chi tiêu trong tương lai, do đó tăng cường khả năng lập trình của Bitcoin.

Chức năng:

· Cải thiện khả năng hợp đồng thông minh của Bitcoin và hỗ trợ các ứng dụng phức tạp hơn (như cho vay, nền tảng giao dịch phi tập trung và kho tiền).

· Tăng cường bảo mật để ngăn chặn tiền bị đánh cắp hoặc sử dụng sai mục đích.

· Tối ưu hóa hiệu suất mạng, chẳng hạn như giảm phí giao dịch hoặc cải thiện quyền riêng tư.

Ở đây chúng ta có thể hiểu sơ bộ rằng Covenants là một khái niệm và BIP-119 (CTV) và BIP-348 (CSFS) được đề cập trong bài viết này là các triển khai cụ thể của khái niệm chức năng Covenants.

Trạng thái hiện tại:

Mạng chính Bitcoin hiện chưa chính thức tích hợp bất kỳ tính năng nào liên quan đến Covenants, mặc dù các cuộc thảo luận và đề xuất liên quan (như BIP-119) đã được tiến hành trong nhiều năm.

BIP 119: OP_CHECKTEMPLATEVERIFY (CTV)

Một mã lệnh Bitcoin được đề xuất cho phép đầu ra giao dịch chỉ định một "mẫu" yêu cầu đầu ra của các giao dịch chi tiêu tiếp theo phải khớp với mẫu.

Được đề xuất bởi Jeremy Rubin, cựu cộng tác viên của Bitcoin Core, dự án này đã tồn tại được hơn năm năm. Nó thực hiện chức năng "mang theo nhà nước" bằng cách hạn chế tiền chỉ được chi tiêu theo những cách được xác định trước.

Các tình huống ứng dụng bao gồm:

· Tạo các khoản thanh toán theo đợt để giảm phí giao dịch. Xây dựng một sàn giao dịch phi tập trung (DEX) hoặc giao thức cho vay.

· Triển khai Vault để bảo vệ tiền khỏi bị trộm cắp.

· CTV là một triển khai nhẹ của Covenants tập trung vào các hạn chế về định dạng đầu ra mà không liên quan đến logic phức tạp.

BIP 348: OP_CHECKSIGFROMSTACK (CSFS)

Một mã lệnh Bitcoin được đề xuất cho phép xác minh chữ ký có hợp lệ đối với bất kỳ thông điệp nào hay không, không chỉ hàm băm của giao dịch hiện tại. Nó lấy chữ ký, khóa công khai và thông điệp từ ngăn xếp dữ liệu và kiểm tra xem chữ ký có khớp không.

Được Jeremy Rubin và Brandon Black chính thức đề xuất vào tháng 11 năm 2024.

OP_CSFS là một công cụ mạnh mẽ để triển khai các Giao ước linh hoạt hơn vì nó cho phép "tự kiểm tra" các dữ liệu đầu vào của giao dịch, tức là kiểm tra toàn bộ nội dung hoặc trạng thái của giao dịch đã ký.

Ứng dụng cụ thể:

· Triển khai giao ước: OP_CSFS có thể được sử dụng để tạo logic có điều kiện phức tạp nhằm đảm bảo rằng tiền chỉ có thể được chi tiêu theo các quy tắc cụ thể. Ví dụ, trình xác thực có thể kiểm tra xem dữ liệu đầu vào của giao dịch có tuân thủ theo các mẫu hoặc ràng buộc được thiết lập sẵn hay không.

· Cải tiến bảo mật: Hỗ trợ Vault và các giao thức phi tập trung để ngăn chặn hành vi trộm cắp hoặc chi tiêu trái phép thông qua xác minh chữ ký.

· Khả năng mở rộng: Kết hợp với các mã lệnh khác (như OP_CAT), có thể xây dựng các hợp đồng thông minh phức tạp hơn.

Khi đề cập đến các Giao ước của Bitcoin và các đề xuất BIP-119 (CTV) BIP-348 (CSFS), OP_CAT chắc chắn là không thể thiếu.

BIP 347: OP_CAT

Lịch sử:

Sự tồn tại ban đầu: OP_CAT là một phần của ngôn ngữ kịch bản gốc của Bitcoin, được Satoshi Nakamoto đưa vào khi Bitcoin ra mắt vào năm 2009. Ban đầu nó được thiết kế để tăng cường tính linh hoạt của tập lệnh và hỗ trợ logic phức tạp hơn.

Lý do xóa (2010):

· OP_CAT đã bị xóa (vô hiệu hóa) vào năm 2010 để ngăn chặn các lỗ hổng bảo mật tiềm ẩn và tình trạng lạm dụng tài nguyên.

· Vấn đề cụ thể: Nếu không có giới hạn, OP_CAT có thể bị người dùng có mục đích xấu sử dụng để tạo ra dữ liệu dài vô hạn (thông qua các lệnh gọi đệ quy), gây ra "cuộc tấn công từ chối dịch vụ" (Tấn công DoS), vì các nút Bitcoin cần xử lý dữ liệu này, làm tăng chi phí tính toán và lưu trữ.

· Vào thời điểm đó, ngôn ngữ lập trình Bitcoin đã được đơn giản hóa, vẫn giữ lại những chức năng cơ bản nhất để đảm bảo tính nhẹ, bảo mật và phi tập trung của giao thức.

Định nghĩa và chức năng:

OP_CAT là mã lệnh của Bitcoin Script. Đây không phải là triển khai Covenant trực tiếp, nhưng là công cụ tiềm năng để xây dựng logic Covenant phức tạp. So với hai opcode trên, OP_CAT mang tính tổng quát hơn và phù hợp hơn với các hoạt động dữ liệu, nhưng cần phải kết hợp với các opcode khác để đạt được các chức năng phức tạp.

Tình hình hiện tại:

Cộng đồng Bitcoin đã thảo luận lại về sự trở lại của OP_CAT trong những năm gần đây. Trước đây, nó xuất hiện dưới dạng đề xuất BIP-420 với biểu tượng thân thiện hơn với cộng đồng, nhưng hiện tại nó đã chính thức được hợp nhất vào kho lưu trữ bitcoin/bips với số BIP-347.

Tiến triển thế nào?

Theo Coindesk, trong vài tuần qua, nhiều nhà phát triển Bitcoin phương Tây đã bày tỏ sự ủng hộ của họ đối với CTV và CSFS trên Twitter — điều này chắc chắn là một tín hiệu mạnh mẽ cho thấy, ít nhất là trong giới truyền thông xã hội, một bộ phận cộng đồng Bitcoin đang tiến tới chấp nhận những thay đổi này.

Ngoài ra, các nhà phát triển thường tin rằng định nghĩa của hai đề xuất này tương đối "hẹp". Nói một cách dễ hiểu, điều này có nghĩa là một khi đã được kích hoạt, khả năng người dùng vô tình sử dụng sai mục đích sẽ thấp hơn. Cộng đồng nhà phát triển bitcoin từ trước đến nay luôn thận trọng với những thay đổi liên quan đến bitcoin. Ví dụ, mặc dù BIP 119 đã không hoạt động trong gần năm năm, nhưng cách đây không lâu, CTV vẫn được coi là quá cấp tiến để kích hoạt.

Các chiến dịch trước đó của Jeremy Rubin, người đồng tài trợ cho cả hai đề xuất, nhằm quảng bá CTV đã vấp phải sự phản đối mạnh mẽ - đặc biệt là từ một số người có ảnh hưởng trong cộng đồng Bitcoin có lượng người theo dõi lớn, chẳng hạn như Adam Back và Jimmy Song. Những lời chỉ trích cuối cùng đã biến thành sự bất mãn lan rộng trong cộng đồng Bitcoin, buộc Rubin phải rời khỏi lĩnh vực Bitcoin.

Vậy, chính xác thì điều gì đã gây ra sự thay đổi này? Việc ủng hộ gần đây cho mã lệnh OP_CAT dường như đã mở rộng phạm vi các đề xuất Bitcoin được coi là "có thể chấp nhận được", coi CTV và CSFS là các lựa chọn tương đối "thận trọng". Điều đáng chú ý là hầu hết những người ủng hộ OP_CAT cũng ủng hộ BIP 119 và BIP 348 (cũng như hầu hết các đề xuất khác).

Chúng ta có thể mong đợi điều gì tiếp theo? Đầu tiên, cuộc thảo luận sẽ tiếp tục. Các nhà phát triển dự kiến sẽ khám phá thêm các đề xuất tại một số hội nghị kỹ thuật, chẳng hạn như OPNEXT dự kiến diễn ra vào tháng 4, BTC++ vào tháng 7 và TABConf vào tháng 10. Khi các nhà phát triển đạt được sự đồng thuận sơ bộ, việc kích hoạt thực tế của soft fork sẽ được chuyển cho thợ đào, cộng đồng và nhà đầu tư để xác nhận cuối cùng.

Làm thế nào để theo dõi tiến trình thảo luận của BIP trong quá trình cộng đồng/soft fork?

Câu trả lời rất khó!

Cộng đồng kỹ thuật Bitcoin thường có những cuộc thảo luận chuyên sâu về những đề xuất này. Nhưng đây có vẻ là một quá trình thảo luận mơ hồ và vòng vo.

Tóm lại, quá trình phân tách mềm Bitcoin đòi hỏi phải ước tính sơ bộ mức độ hỗ trợ của nhiều bên liên quan đến Bitcoin, bao gồm nhà phát triển, người giám hộ, nhà đầu tư và thợ đào. Các chỉ báo hỗ trợ trực tiếp nhất thường đến từ thợ đào, vì họ có thể báo hiệu sự chấp thuận của mình đối với các thay đổi trong cơ sở mã bằng cách gửi tín hiệu trong các khối họ khai thác. Thông thường, Bitcoin Core yêu cầu 95% khối phải báo hiệu hỗ trợ trong một khoảng thời gian trước khi khóa bản cập nhật để kích hoạt.

Tuy nhiên, vẫn chưa có sự thống nhất về cách định nghĩa "hỗ trợ rộng rãi" và sự đồng thuận của Bitcoin luôn thay đổi. Thợ đào là những nhà cung cấp tín hiệu quan trọng đơn giản vì họ là một thực thể “có thể đếm được” trong mạng Bitcoin. Nói cách khác, do cấu trúc phi tập trung của Bitcoin nên rất khó để đo lường sự đồng thuận chung từ góc độ “có thể nhìn thấy”.

Tuy nhiên, Taproot Wizards, một công ty phát triển nổi tiếng với Bitcoin NFT, sử dụng OP_CAT làm ví dụ để tiết lộ quá trình dài và phức tạp của Bitcoin soft fork dưới dạng sơ đồ luồng. Độc giả quan tâm có thể tự mình kiểm tra tại https://www.quantumcats.xyz/bip-land. Sau đây chúng tôi cố gắng tóm tắt lại:

Vòng đời đề xuất BIP | Quá trình dài và phức tạp của nhánh mềm Bitcoin

1. Đề xuất ban đầu được đề xuất và thảo luận trên danh sách gửi thư của nhà phát triển Bitcoin.

2. Tham gia vào một cuộc thảo luận rộng hơn của toàn cộng đồng, tham gia vào một cuộc thảo luận dài hạn về những ưu và nhược điểm của chức năng được đề xuất. Nếu không thể đạt được tiến triển nào nữa, nó sẽ dừng lại ở đây.

3. Cộng đồng cơ sở viết bản thảo BIP cho đề xuất trên Github.

4. Các nhà phát triển bắt đầu triển khai các mã có liên quan và chỉ có thể tiếp tục nếu không có lỗi kiểm toán dài hạn.

5. Sau khi biên tập viên BIP của Bitcoin Repository xem xét và cộng đồng chấp thuận ban đầu, một số BIP chính thức sẽ được chỉ định.

6. Vào mạng thử nghiệm Signet. Signet là mạng thử nghiệm Bitcoin cho phép các nhà phát triển thử nghiệm các tính năng mới hoặc thay đổi mã mà không ảnh hưởng đến mạng chính. (Có thể hầu hết các tính năng mới sẽ bị gác lại vĩnh viễn ở bước này)

7. Có thể vào chuỗi phụ Liquid để thử nghiệm.

8. Gửi PR tới Bitcoin Core.

9. Tiến hành quá trình đánh giá mã cốt lõi của Bitcoin và hợp nhất đề xuất, quá trình này rất không chắc chắn. Chỉ khi một đề xuất tránh được hầu hết các phản đối và đáp ứng các yêu cầu kỹ thuật (không có lỗi nghiêm trọng) thì nó mới có cơ hội bước vào giai đoạn hợp nhất; ý kiến của các nhà phát triển chính (như Pieter Wuille) thường rất quan trọng và việc chấp thuận hay bác bỏ của họ sẽ ảnh hưởng rất lớn đến số phận của đề xuất.

10. Nếu quá trình đánh giá mã diễn ra tốt đẹp, hãy đợi người duy trì kho lưu trữ Bitcoin hợp nhất PR vào dự án chính. Hiện tại có năm người bảo trì: Michael Ford (fanquake), Hennadii Stepanov (hebasto), Andrew Chow (achow 101), Gloria Zhao (glozow), Ryan Ofsky (ryanofsky).

11. Vẫn tiếp tục có những tranh cãi và thảo luận tiềm tàng giữa các nhóm khác nhau như nhà phát triển Bitcoin và thợ đào.

12. Chọn một cơ chế kích hoạt:

a. Soft Fork do thợ đào dẫn đầu (MASF): Các quy tắc mới được thợ đào kích hoạt thông qua các tín hiệu (thường là ngưỡng 95%), chẳng hạn như chế độ mặc định của BIP-9 hoặc BIP-8. Tương đối ổn định, nhưng đòi hỏi sự phối hợp của sự đồng thuận rộng rãi và thử nghiệm, do đó sẽ mất nhiều thời gian hơn;

b. Soft fork do người dùng khởi tạo (UASF): Người vận hành nút (người dùng) kích hoạt cưỡng bức các quy tắc mới (chẳng hạn như "Lockinontimeout: True" của BIP-8) để vượt qua sự phản kháng của thợ đào, với rủi ro phân nhánh chuỗi tiềm ẩn và bất đồng quan điểm trong cộng đồng.

Kết luận

Wu cho biết trước đây có thông tin cho rằng Cobra, đơn vị duy trì tên miền Bitcoin.org, đã cảnh báo rằng mạng lưới Bitcoin có thể sẽ chứng kiến một soft fork do người dùng dẫn đầu (UASF) do các nhà phát triển ẩn danh bên ngoài lõi Bitcoin khởi xướng vào năm 2025, trên thực tế chính là những thay đổi tiềm ẩn đối với BIP 119 được đề cập trong bài viết này. Cobra tin rằng những cải tiến này có thể gây ra sự chia rẽ giữa những người “cứng rắn” và những người “cải tiến”, do cộng đồng cơ sở dẫn đầu và được thúc đẩy bởi các nhà phát triển cốt lõi không phải Bitcoin.

Người ta hiểu rằng UASF (User-Actuated Soft Fork) là phương pháp nâng cấp giao thức do người dùng Bitcoin khởi tạo, thực thi các bản cập nhật giao thức bằng cách nâng cấp phần mềm nút, ngay cả khi thợ đào hoặc các bên khác không hỗ trợ và do đó cũng có nghĩa là có nguy cơ phân nhánh chuỗi. Tất nhiên, hiện tại không cần phải lo lắng quá nhiều, dù sao thì vẫn còn nhiều chuyện chưa được giải quyết. Ví dụ, liệu soft fork trong tương lai chỉ bao gồm CTV và CSFS không? Liệu OP_CAT, thường được thảo luận với bộ mã lệnh này, có được tính đến không? Quá trình kích hoạt thực tế của soft fork sẽ diễn ra như thế nào? Liệu các bên liên quan khác (như thợ đào Bitcoin) có coi trọng vấn đề này không?

Xét cho cùng, miễn là sự đồng thuận của BIP đủ lớn thì các đề xuất do cộng đồng cơ sở thúc đẩy cũng có thể được thực hiện dưới hình thức soft fork do thợ đào dẫn đầu (MASF). Và ngay cả UASF cũng có những câu chuyện thành công trong lịch sử. UASF đóng vai trò quan trọng trong quá trình nâng cấp SegWit năm 2017, khi người dùng thành công trong việc thúc đẩy soft fork, tránh hard fork và thúc đẩy mở rộng Bitcoin.

Liên kết tham khảo:

https://www.coindesk.com/tech/2025/03/17/developer-consensus-may-be-converging-on-a-bitcoin-soft-fork-proposal-blockspace

https://www.quantumcats.xyz/bip-land

https://github.com/bitcoin/bips

Liên kết gốc