Quá trình phát triển token , NFT và DeFi trên Bitcoin thực sự phức tạp hơn nhìn lên. Ví dụ, trên Ethereum Virtual Machine (EVM) và các nền tảng hợp đồng thông minh khác, hợp đồng thông minh là Turing hoàn chỉnh, nghĩa là các tính năng hoặc tùy chọn mới có thể được thêm vào chỉ bằng cách triển khai một hợp đồng tùy chỉnh. Nhưng trên Bitcoin, các nhà phát triển phải cẩn thận trong việc đổi mới mà không gây ra hard fork và chỉ có thể hoạt động trong giới hạn của chức năng giao thức hiện có. Như đã đề cập trước đó, một trong đó những yếu tố chính khiến Bitcoin trở nên đặc biệt quan trọng và có giá trị là tính "độc đáo" của nó, với Chuỗi chính ít thay đổi theo thời gian.
Tuy nhiên, Bitcoin là blockchain đầu tiên được áp dụng rộng rãi và nhiều công nghệ sau đó được triển khai trên blockchain linh hoạt hơn thực sự đã có hạt giống đầu tiên trên Bitcoin. Trên thực tế, NFT lần đầu tiên xuất hiện trên Bitcoin dưới dạng “Tiền xu màu”; khái niệm về Kênh trạng thái có thiết kế khá giống với kiến trúc L1-L2 ngày nay; và Hoán đổi nguyên tử Nguyên tử đã đặt nền tảng cho cầu nối xuyên chuỗi hiện đại. Chúng tôi đã giới thiệu một phần những phát triển này trong bài viết trước "Bắt đầu từ Bitcoin: Nguồn gốc thực sự của DeFi". Nhưng để thực sự hiểu được giá trị vô song của Bitcoin như một cơ sở hạ tầng cho Botanix và Chuỗi Bitcoin khác, chúng ta cần hiểu sâu hơn về cách những đổi mới ban đầu này mở đường cho hệ sinh thái ngày nay. Mặc dù Bitcoin có bản chất tương đối đơn giản, nhưng thực tế đây là một trong những hệ sinh thái phức tạp và hấp dẫn nhất trong không gian Web3, với lịch sử phong phú nhất.
Khám phá lý thuyết chức năng của Bitcoin: Bitcoin có đủ mạnh để hỗ trợ một hệ sinh thái phức tạp không?
Khi Bitcoin ra mắt năm 2009, nó có ngôn ngữ lập trình tích hợp không chỉ cho phép thanh toán đơn giản mà còn hỗ trợ các hoạt động phức tạp hơn như đa chữ ký và khóa thời gian ngay từ đầu. Satoshi Nakamoto thậm chí còn mô tả rằng các giao dịch chưa được xác nhận sử dụng nLockTime và số thứ tự có thể được cập nhật lần giữa hai bên để giao dịch tần suất cao và chỉ có trạng thái cuối cùng mới được ghi vào Chuỗi.
Bitcoin Script là một cơ chế rất thú vị: một mặt, nó không đầy đủ về Turing, điều này hạn chế chức năng của nó; Mặt khác, nó vẫn đơn giản và an toàn. Do đó, khi xây dựng bất kỳ chức năng phức tạp nào trên Bitcoin, các nhà phát triển phải thiết kế nó trong khuôn khổ do Script cung cấp. Nó chứa lượng lớn các lệnh (Opcode) được sử dụng để lập trình các hành động khác nhau, cuối cùng sẽ được ghi vào dữ liệu giao dịch.
Bitcoin Script là ngôn ngữ lập trình được Bitcoin sử dụng để xác định các điều kiện chi tiêu của đồng tiền. Bạn có thể nghĩ về một Script như một công thức nấu ăn -- một tập hợp các bước để nướng bánh. Mã lệnh là những mô-đun xây dựng của ngôn ngữ này - chúng là những lệnh cơ bản mà các lập trình viên sử dụng khi viết tập lệnh, chẳng hạn như "khuấy", "làm nóng", v.v. Để hiểu rõ hơn về chức năng của Script, chúng ta hãy cùng xem qua các loại tập lệnh phổ biến nhất:
P2PK (Thanh toán bằng Key công khai) - Đây là phương thức chuyển BTC ban đầu, sau đó được thay thế bằng P2PKH. Nó bao gồm một số Opcode, ví dụ: OP_DATA_65 OP_CHECKSIG OP_DATA_33 OP_CHECKSIG.
P2PKH (Thanh toán theo mã Key công khai) - Định dạng tập lệnh là: OP_DUP OP_HASH160 OP_DATA_20 OP_EQUALVERIFY OP_CHECKSIG. Vì sử dụng hàm băm khóa công khai 32 byte để tối ưu hóa kích thước giao dịch nên tập lệnh này tiết kiệm không gian hơn so với P2PK 64 byte và do đó nhanh chóng trở nên phổ biến. Dữ liệu giao dịch càng nhỏ thì phí càng thấp - điều này đặc biệt quan trọng bối cảnh mức độ sử dụng và phí Bitcoin tăng lên.
Lưu trữ dữ liệu tùy ý - Các tập lệnh này thường khóa một lượng rất nhỏ Satoshi và chủ yếu được sử dụng để lưu trữ văn bản ASCII, liên kết hoặc tập lệnh. Ví dụ: OP_0 OP_DATA_20 # 20 byte dữ liệu tùy chỉnh. Ngoài ra còn có một cách chuẩn hóa để lưu trữ dữ liệu bằng cách sử dụng OP_RETURN. Ví dụ, giao thức Bitcoin Colored Coins (tiền thân của NFT) nhúng dữ liệu token thông báo thông qua OP_RETURN.
Một nghiên cứu của NCC Group đã tóm tắt 156 mẫu chữ viết khác nhau và tiến hành phân tích chi tiết các cấu trúc chữ viết này.
Vậy, chúng ta có thể thử sử dụng Script để tổ chức cơ chế giống DeFi trên Bitcoin không? Chúng ta hãy tiếp tục khám phá bước tiếp theo.
Cơ chế vay mượn:
Như đã đề cập trước đó, các mã lệnh có thể được kết hợp để xây dựng sê-ri Chuỗi lệnh nhỏ nhằm đạt được các hành vi phức tạp hơn. Ví dụ, các nhà phát triển có thể xây dựng các tập lệnh phức tạp với các chức năng hợp đồng vay mượn bằng cách kết hợp các mã lệnh. Điều này có thể đạt được thông qua sự kết hợp giữa khóa thời gian và chữ ký đa dạng:
OP_CHECKSEQUENCEVERIFY (CSV): dành cho khóa thời gian tương đối (ví dụ: khóa tiền X khối sau một giao dịch nhất định);
OP_CHECKLOCKTIMEVERIFY (CLTV): dành cho khóa thời gian tuyệt đối (ví dụ: khoản vay hết hạn ở Block Height hoặc dấu thời gian cụ thể);
OP_CHECKMULTISIG (hoặc nhiều OP_CHECKSIG với OP_ADD): yêu cầu bên long bên cùng ký;
Mã lệnh logic có điều kiện OP_IF / OP_ELSE: xác định các đường chi tiêu khác nhau (ví dụ: trả nợ so với mặc định).
Những công cụ này có thể cho phép “các hợp đồng ký quỹ song phương có thời hạn”. Ví dụ: giả sử Alice cung cấp BTC làm tài sản thế chấp và Bob cho cô ấy vay stablecoin ngoại tuyến. Họ hy vọng có thể đặt ra các quy tắc sau thông qua hợp đồng: nếu Alice không trả được khoản vay đúng hạn, Bob sẽ nhận được BTC của cô ấy; nếu cô ấy trả nợ đúng hạn, BTC sẽ được mở khóa và trả lại cho Alice. Để thực hiện điều này, họ có thể sử dụng đầu ra đa chữ ký 2 trong 2 (cả Alice và Bob đều cần phải ký để chi tiêu tiền). Sau đó, họ có thể thiết lập logic của tập lệnh: nếu khoản vay không được trả lại sau khi đạt đến một Block Height nhất định, thì chỉ có Bob mới có thể sử dụng số tiền đó một mình.
Tuy nhiên, vẫn còn một khó khăn lớn ở đây: Bản thân Bitcoin không thể tự động tính lãi suất, theo dõi tỷ lệ thế chấp hoặc thực hiện thanh lý. Mọi khoản thanh toán lãi suất phải được thực hiện Chuỗi hoặc thông qua các giao dịch được ký trước (trên thực tế khá phức tạp). Nếu giá giảm trong thời gian vay, bản thân tập lệnh Bitcoin không thể biết điều này và không thể tự động kích hoạt thanh lý. Để đạt được chức năng này, cần phải sử dụng oracle hoặc giao thức ngoài Chuỗi. Trong trường hợp không có oracle , hợp đồng chỉ có thể đưa ra quyết định dựa trên ngày hết hạn cuối cùng.
Do đó, rất khó để triển khai trực tiếp vay mượn stablecoin thế chấp bằng BTC không cần tin cậy trên nền tảng Bitcoin . Các hoạt động hiện tại thường dựa vào bên thứ ba đáng tin cậy hoặc được triển khai gián tiếp thông qua cơ chế hoán đổi nguyên tử trên Chuỗi khác.
Tính năng của AMM:
Như đã đề cập ở trên, về mặt lý thuyết, cơ chế vay mượn và đặt cược có thể được triển khai thông qua Bitcoin Script, nhưng lại kém hiệu quả hơn trên thực tế. Tuy nhiên, chúng ta vẫn có thể khám phá liệu có thể xây dựng các cơ chế phức tạp hơn như nhà tạo lập thị trường tự động (AMM) trên Bitcoin hay không. Bitcoin Script bao gồm các mã lệnh toán học như OP_ADD, OP_SUB và OP_MUL (mặc dù một số trong đó đã bị vô hiệu hóa), cũng như các mã lệnh so sánh như OP_LESSTHAN. Về mặt lý thuyết, các hàm này có thể được sử dụng để triển khai logic tính giá.
Về mặt lý thuyết, nhà phát triển có thể xây dựng một tập lệnh có giá cố định hoặc một tập hợp các mức giá có thể chấp nhận được được xác định trước, nhưng không thể điều chỉnh giá một cách linh hoạt sau lần giao dịch. Lý do là Bitcoin sử dụng mô hình UTXO và mỗi giao dịch sẽ tạo ra một UTXO và tập lệnh mới, do đó, mỗi trạng thái có thể xảy ra phải được tính toán trước hoặc phải triển khai lại hợp đồng sau lần giao dịch.
Một yếu tố quan trọng khác trong việc triển khai AMM là khả năng trao đổi tài sản. Về mặt lý thuyết, Bitcoin hỗ trợ Hoán đổi nguyên tử nguyên tử, có thể được xây dựng dưới dạng sổ lệnh thay vì nhóm thanh khoản. Hành vi giống AMM cũng có thể được mô phỏng bằng cách xây dựng sê-ri HTLC (Hợp đồng khóa thời gian băm) hoặc phát hành lệnh ở các mức giá khác nhau để tạo thành hệ thống tạo lập thị trường tự động tĩnh (tương tự như đường cong lợi nhuận). Tuy nhiên, việc duy trì một hệ thống như vậy rất phức tạp. Tập lệnh cần được cập nhật thủ công và phát hành lại UTXO sau lần giao dịch và chi phí Chuỗi cực kỳ cao.
Do đó, mặc dù về mặt lý thuyết có thể xây dựng được AMM, nhưng thực tế lại có một vấn đề lớn hơn: chỉ có một tài sản BTC trên mạng chính Bitcoin . Mặc dù các giao thức như Omni cung cấp cơ chế token, nhưng tài sản này tồn tại trong dữ liệu của giao dịch và không thể được xác định và xử lý bằng các tập lệnh. Do đó, việc trao đổi tài sản sang tài sản thực sự hoặc duy trì nhóm thanh khoản không thể đạt được thông qua Bitcoin Script. Ngoài ra, mô hình UTXO của Bitcoin không hỗ trợ một hợp đồng duy nhất nắm giữ tiền từ bên long bên cùng lúc và cập nhật số dư một phần - lần thay đổi trạng thái đều yêu cầu một giao dịch mới và bên long chữ ký.
Chức năng mở rộng của Script:
Những điểm trên giải thích lý do tại sao Bitcoin định kì trải qua các bản cập nhật lớn để cải thiện chức năng của nó. Một trong đó những bản cập nhật quan trọng là Taproot, được giới thiệu thông qua soft fork nhưng đã thay đổi đáng kể cách thiết kế Scripts.
Cơ chế OP_SUCCESS của Taproot:
Với việc giới thiệu nâng cấp Taproot (BIP 342), nhiều mã lệnh trước đây bị vô hiệu hóa hoặc được dành riêng đã được chuyển đổi thành mã lệnh OP_SUCCESS trong Tapscript (tức là các tập lệnh SegWit v1). OP_SUCCESS có nghĩa là tập lệnh sẽ kết thúc thành công ngay khi mã lệnh được thực thi. Thiết kế này giúp việc thêm mã lệnh mới thông qua soft fork trở nên dễ dàng và an toàn hơn. Cụ thể, trong Tapscript, nếu giá trị của opcode nằm trong một phạm vi nhất định (ví dụ: 0x50, 0x62, 0x7E–0x81, 0x83–0x86, 0x89–0x8a, 0x8d–0x8e, 0x95–0x99, 0xbb–0xfe), thì giá trị đó sẽ được coi là OP_SUCCESSx. Khi gặp phải những mã lệnh này, tập lệnh sẽ xác định vô điều kiện rằng lệnh thành công và bỏ qua các logic khác.
Cơ chế này thay thế phương pháp nâng cấp OP_NOP (không có mã hoạt động) cũ, mang lại tính bảo mật và linh hoạt cao hơn. Soft fork trong tương lai có thể xác định lại hành vi của một mã lệnh OP_SUCCESS nhất định và nút phiên bản cũ vẫn sẽ coi đó là "thành công của tập lệnh", do đó tránh được các giao dịch không hợp lệ do sự không nhất quán của phiên bản. Tóm lại, tất cả các mã lệnh không được liệt kê là "có sẵn" đều được dành riêng để sử dụng hoặc đã được chuyển đổi trong Taproot để luôn trả về OP_SUCCESS.
Một khía cạnh quan trọng khác là các mã lệnh có thể được đề xuất thông qua quy trình BIP ( Đề án cải tiến Bitcoin ) và hiện đã có một số Đề án mạnh mẽ đang được xem xét hoặc đã bị từ chối. Một số Đề án trong đó , nếu được thông qua, sẽ mở rộng đáng kể chức năng của Bitcoin , cho phép nó thực hiện các hoạt động phức tạp hơn:
OP_CAT (toán tử nối): Được sử dụng để tăng cường khả năng kết hợp và xử lý dữ liệu trong các tập lệnh Bitcoin , cải thiện đáng kể sức mạnh biểu đạt. OP_CAT ban đầu tồn tại trong Bitcoin thời kỳ đầu (bị vô hiệu hóa vào năm 2010). Chức năng của nó là lấy hai chuỗi byte từ ngăn xếp, kết nối chúng lại và sau đó đẩy chúng trở lại ngăn xếp. Hoạt động đơn giản nhưng mạnh mẽ này có thể được sử dụng để xây dựng thông điệp một cách động, tính toán hàm băm cây Merkle trong tập lệnh và các logic phức tạp khác. Đề án này gợi ý giới hạn kết quả được nối không quá 520 byte (giới hạn phần tử ngăn xếp tối đa).
OP_CHECKSIGFROMSTACK / OP_CHECKSIGFROMSTACKVERIFY (gọi tắt là OP_CSFS): Mã lệnh này cho phép xác minh tập lệnh dựa trên oracle. Ví dụ, một tập lệnh có thể xác minh rằng một thông báo đã ký về một điều kiện bên ngoài (như giá cả hoặc kết quả sự kiện) đến từ một oracle cụ thể. Mặc dù có logic thực thi đơn giản, OP_CSFS có thể mở ra những khả năng hoàn toàn mới cho Bitcoin. Ví dụ: oracle ký một thông báo "BTC giảm xuống dưới 20.000 đô la tại thời điểm X"vay mượn xác minh chữ ký này thông qua OP_CSFS, cho phép người cho vay thanh lý tài sản thế chấp - quá trình này không yêu cầu bên thứ ba giữ private key. Ngoài ra, sau khi người vay trả hết nợ, oracle hoặc bên cung cấp dịch vụ có thể ký "đã nhận được khoản thanh toán" và tài sản thế chấp sẽ được trả lại sau khi xác minh tập lệnh. Nếu không có OP_CSFS, các hợp đồng tự động dựa trên các điều kiện bên ngoài như vậy sẽ không thể triển khai được hoặc chỉ có thể được hoàn thành thông qua oracle với tư cách là người đồng ký, điều này sẽ liên quan đến rủi ro tin cậy cao hơn.
OP_CHECKTEMPLATEVERIFY (gọi tắt là OP_CTV): Mã lệnh này cho phép người dùng xác định trước cách sử dụng Bitcoin của họ trong tương lai, ví dụ: Bitcoin chỉ có thể được chuyển đến một nhóm địa chỉ nhất định hoặc chỉ có thể được chi tiêu nếu đáp ứng một số điều kiện phí nhất định. OP_CTV có thể được sử dụng để xây dựng các giao dịch hàng loạt, nhà máy kênh và các trường hợp sử dụng nâng cao khác dựa trên cơ chế “giao ước” để đảm bảo rằng một số quy tắc được xác định trước được thực thi.
Nhưng tại sao các mã lệnh này vẫn chưa được chấp thuận?
Lý do chính có thể là cộng đồng nhà phát triển Bitcoin cực kỳ thận trọng trong việc duy trì hình thức ban đầu của Bitcoin .
Một mặt, việc giới thiệu các tính năng mới thực sự có thể nâng cao khả năng sử dụng và mở rộng của Bitcoin ; nhưng mặt khác, bản thân Bitcoin là một mạng lưới được thiết kế để "chậm", và "sự chậm chạp" này, ở một mức độ nào đó, cũng được coi là tính năng "ban đầu" của nó. Ví dụ, khi áp dụng OP_CSFS vào cơ chế thanh lý, tốc độ là trong đó tố quan trọng. Nếu thị trường sụp đổ và giá BTC giảm mạnh, một nghịch lý có thể xảy ra:
Đầu tiên, tải blockchain tăng vọt và tốc độ mạng giảm hơn nữa;
Thứ hai, tốc độ xử lý giao dịch trong mạng Bitcoin sẽ chậm lại đáng kể và giá đã vượt xa mức thị trường hiện tại từ lâu, trong khi sàn giao dịch phi tập trung(CEX và DEX) đã phản ứng nhanh chóng.
Rất có khả năng giá sẽ phục hồi trước khi giao dịch thanh toán trên Chuỗi hoàn tất.
Do đó, bản thân Bitcoin chạy chậm và có phí giao dịch cực kỳ cao khi tải nặng, khiến cho các nỗ lực triển khai cơ chế liên quan đến DeFi trên mạng chính về cơ bản là vô nghĩa.
Vì lý do này, các nhà phát triển đã dần đi đến kết luận hợp lý hơn: nên xây dựng mở rộng trên Bitcoin . Trên thực tế, đây là tiền thân của ý tưởng Rollup - khái niệm "kênh thanh toán nguyên mẫu": bằng cách hỗ trợ nhiều giao dịch nhỏ ngoài Chuỗi , cuối cùng nó được nén thành một giao dịch quyết toán trên Chuỗi .
Ngay từ tháng 4 năm 2011, nhánh mã đầu tiên của Bitcoin, Namecoin, đã được ra mắt, hiện thực hóa việc đăng ký tên miền phi tập trung (DNS ".bit") thông qua công nghệ Bitcoin .
Ví dụ về Namecoin — lưu trữ các cặp tên-giá trị trên Chuỗi— là minh chứng đầu tiên cho thấy thiết kế Bitcoin không chỉ có thể được sử dụng cho các giao dịch tiền tệ mà còn cho tài sản khác, mặc dù có thể phải sử dụng cấu trúc blockchain riêng biệt. Những khái niệm này đã đặt nền tảng cho token hóa tài sản , giao dịch phi tập trung và những cải tiến mở rộng ngoài Chuỗi của Bitcoin sau này.
Stablecoin: Chúng có hiệu quả như thế nào trong hệ sinh thái Bitcoin?
Stablecoin đã trở thành một thành phần quan trọng trong bất kỳ hệ sinh thái Web3 nào, ngay cả những hệ sinh thái không liên quan trực tiếp đến DeFi. Chúng cho phép người dùng phòng ngừa rủi ro biến động và chuyển tiền mà không phải lo lắng về sự thay đổi giá tài sản. Như đã đề cập trước đó, mạng Bitcoin luôn cố gắng tìm sự cân bằng giữa tính đơn giản của chức năng và lượng dữ liệu có thể ghi lại. Điều thú vị là nỗ lực đầu tiên trong việc phát hành tài sản trên Bitcoin đã được thực hiện thông qua sự phát triển của "Colored Coin", có một số điểm tương đồng với NFT.
Ngay từ năm 2012, JR Willett đã đề xuất ý tưởng phát hành tài sản mới trên Bitcoin và đưa ra khái niệm "tiền màu". Sau đó, ông đã giúp tạo ra giao thức Mastercoin (sau này đổi tên thành Omni ), đặt nền tảng cho token hóa tài sản trên Bitcoin (bao gồm cả token được gắn với tiền tệ fiat).
Vì không có mã lệnh "mã thông báo" trực tiếp trong tập lệnh Bitcoin Script chuẩn nên các nhà phát triển chỉ có thể nhúng dữ liệu token vào đầu ra giao dịch với sự trợ giúp của OP_RETURN (OP_RETURN sẽ khiến đầu ra không thể chi tiêu và đi kèm với dữ liệu). Trước khi OP_RETURN được chuẩn hóa, thậm chí các tập lệnh đa chữ ký cũng được sử dụng như một giải pháp tạm thời để mã hóa dữ liệu.
Bản thân Bitcoin Script không thể thực thi bất kỳ quy tắc token— các quy tắc được duy trì bởi phần mềm Chuỗi chuỗi có trách nhiệm phân tích các giao dịch Bitcoin.
Các giao thức như Colored Coins, Omni Layer (trước đây là Mastercoin), Counterparty và Open Assets đều biểu thị token bằng cách “tô màu cho một số satoshi hoặc UTXO nhất định”. Ví dụ, giao thức Open Assets sử dụng đầu ra OP_RETURN trong đó dữ liệu cho biết số lượng token và ID tài sản .
Về cơ bản, bản thân blockchain Bitcoin không biết đến sự tồn tại của “ token” — nó chỉ xử lý dữ liệu. Tính hợp lệ của token(ví dụ: lượng cung ứng, quyền sở hữu) được theo dõi bởi ví bên ngoài sau khi phân tích dữ liệu OP_RETURN.
Điều đáng chú ý là OP_RETURN có giới hạn kích thước dữ liệu. Chính sách tiêu chuẩn của máy khách Bitcoin Core quy định rằng mỗi đầu ra OP_RETURN không được chứa quá 80 byte dữ liệu tùy ý. Dữ liệu vượt quá 80 byte sẽ được coi là "giao dịch không chuẩn" và theo mặc định sẽ không được chuyển tiếp. Về mặt lý thuyết, một giao dịch có thể chứa nhiều đầu ra OP_RETURN để tăng lượng dữ liệu đi kèm (tối đa 80 byte cho mỗi giao dịch), nhưng để ngăn chặn các giao dịch thư rác, chiến lược chuyển tiếp tiêu chuẩn hiện tại Bitcoin thường chỉ cho phép mỗi giao dịch chứa một đầu ra OP_RETURN.
Khả năng nhúng dữ liệu vào các giao dịch Bitcoin đã dẫn đến việc tạo ra giao thức Mastercoin vào năm 2012, sau đó đổi tên thành Omni. Omni Layer đóng vai trò quan trọng trong hoạt động ban đầu của Tether và trở thành giao thức truyền tải cơ bản cho đợt chuyển USDT đầu tiên.
Trong một khoảng thời gian vào giữa những năm 2010, USDT, dựa trên Bitcoin(Omni), là stablecoin thống trị nhất trên thị trường và được sử dụng rộng rãi trên sàn giao dịch như Bitfinex . Giao dịch Omni về cơ bản là giao dịch Bitcoin tiêu chuẩn với dữ liệu bổ sung. Sau đó, Omni đã phát triển một số danh mục triển khai khác nhau và hình thành lộ trình phát triển công nghệ riêng.
