Bản dịch gốc: GaryMa Wu nói về 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), 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 trường hợp một số độc giả tạm thời không hiểu được mối quan hệ giữa Bitcoin Covenants và các giải pháp BIP cụ thể này, chúng tôi sẽ làm rõ ở đây:
Nói một cách đơn giản, Covenants 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 cho khái niệm chức năng này.
Giao ước Bitcoin là gì?
sự đị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ế đối với các giao dịch, quyết định cách thức chi tiêu hoặc chuyển giao Bitcoin. 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.
tác dụng:
Cải thiện khả năng hợp đồng thông minh của Bitcoin để hỗ trợ các ứng dụng phức tạp hơn (như cho vay, trao đổi phi tập trung và kho tiền).
Tăng cường bảo mật để ngăn chặn trộm cắp hoặc sử dụng sai mục đích tiền.
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à những triển khai cụ thể của khái niệm chức năng Covenants.
Tình trạng hiện tại:
Mạng chính Bitcoin hiện không 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 triển 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 mà các giao dịch chi tiêu tiếp theo phải khớp.
Đượ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ó cho phép tính năng mang theo trạng thái 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 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 một thông điệp tùy ý hay không, không chỉ đối với 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, đảm bảo 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á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_MÈO
lịch sử:
Tồn tại ban đầu: OP_CAT là một phần của ngôn ngữ lập trình 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 bỏ (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 bị hạn chế, OP_CAT có thể bị người dùng có mục đích xấu lợi dụng để tạo ra dữ liệu có độ dài vô hạn (thông qua các lệnh gọi đệ quy), gây ra 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ữ.
Ngôn ngữ lập trình Bitcoin đã được đơn giản hóa vào thời điểm đó, vẫn giữ lại những chức năng cơ bản nhất để đảm bảo tính nhẹ, an toàn và phi tập trung của giao thức.
Định nghĩa và chức năng:
OP_CAT là một opcode trong ngôn ngữ Bitcoin Script. Nó không phải là một triển khai Covenant trực tiếp, nhưng nó là một công cụ tiềm năng để xây dựng logic Covenant phức tạp. So với hai mã lệnh 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 mã lệnh khác để đạt được các chức năng phức tạp.
tình trạng hiện tại:
Trong những năm gần đây, cộng đồng Bitcoin đã thảo luận lại về sự trở lại của OP_CAT. Trước đây nó xuất hiện dưới dạng đề xuất BIP-420 thân thiện với cộng đồng hơn, nhưng hiện đã được chính thức sáp nhập vào kho lưu trữ bitcoin/bips với số BIP-347.
Mọi việc thế nào rồi?
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 - đâ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 dần 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 khi thực hiện những thay đổi đối với 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 đượ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 lĩnh vực bitcoin với 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ì đã thúc đẩy 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 độ thảo luận về 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 tham gia vào các 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.
Nói một cách đơn giản, quá trình phân nhánh Bitcoin đòi hỏi phải ước tính sơ bộ mức độ hỗ trợ từ 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ể thể hiện 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 mà họ đào. 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. Chúng tôi xin tóm tắt lại như sau:
Vòng đời đề xuất BIP | Quá trình dài và phức tạp của Bitcoin Soft Fork
1. Đề xuất ban đầu được đề xuất và thảo luận trên danh sách gửi thư của các 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 tra 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 cấp.
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ể tham gia vào chuỗi phụ Liquid để thử nghiệm.
8. Gửi PR tới Bitcoin Core.
9. Đang tiến hành quá trình đánh giá mã Bitcoin Core 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ã không có vấn đề gì, 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 ẩn giữa các nhóm khác nhau như nhà phát triển Bitcoin và thợ đào.
12. Chọn 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 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, nên 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) buộc kích hoạt 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 trong cộng đồng.
Phần kết luận
Wu cho biết trước đây đã có báo cáo 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 khởi xướng (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.
Có thể hiểu rằng UASF (User-Initiated Soft Fork) là phương pháp nâng cấp giao thức do người dùng Bitcoin khởi tạo. Nó 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ợ, điều này 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 trường hợp 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:
