Ngôn ngữ kịch bản Bitcoin là gì?

Bitcoin Script là ngôn ngữ lập trình điều khiển mọi giao dịch trên mạng Bitcoin. Đây là một ngôn ngữ đơn giản, dựa trên ngăn xếp, xác định các điều kiện chính xác để có thể chi tiêu Bitcoin, và mọi nút đầy đủ trên mạng đều thực thi ngôn ngữ này mỗi khi một giao dịch được xác thực. Nếu không có nó, Bitcoin sẽ chỉ là một sổ cái chứa các con số mà không có cơ chế nào để xác định ai sở hữu cái gì.

Hầu hết người dùng không bao giờ tiếp xúc trực tiếp với ngôn ngữ kịch bản Bitcoin. Các ví của họ xử lý điều này một cách ẩn. Tuy nhiên, mỗi khi bạn gửi hoặc nhận BTC, hai chương trình nhỏ sẽ được thực thi đồng thời trên hàng nghìn máy tính, nhằm kiểm tra xem các điều kiện chi tiêu đã được đáp ứng hay chưa. Hiểu được cơ chế hoạt động này sẽ giúp giải thích rất nhiều về lý do tại sao Bitcoin lại được cấu trúc như vậy, cũng như những gì nó có thể và không thể làm so với các nền tảng như Ethereum.

Bài viết này trình bày cách thức hoạt động của Bitcoin Script, giới thiệu chi tiết các loại giao dịch chính mà nó hỗ trợ, giải thích về bản nâng cấp Taproot đã hiện đại hóa lớp kịch bản vào năm 2021, đồng thời cập nhật tình hình tranh luận xung quanh mã lệnh covenant tính đến tháng 6 năm 2026.

Quản lý Bitcoin của bạn một cách an toàn với hình thức tự quản lý Ứng dụng Ví Bitcoin.com.

Những điểm chính cần lưu ý

• Bitcoin Script là một ngôn ngữ lập trình dựa trên ngăn xếp được tích hợp sẵn trong giao thức Bitcoin, dùng để xác định các điều kiện mà theo đó bất kỳ đầu ra Bitcoin nào cũng có thể được chi tiêu.
• Mỗi giao dịch Bitcoin đều bao gồm hai đoạn mã: đoạn mã khóa (ScriptPubKey) do người nhận thiết lập và đoạn mã mở khóa (ScriptSig) do người chi tiêu cung cấp. Cả hai đoạn mã này đều phải được thực thi thành công thì giao dịch mới được coi là hợp lệ.
• Bitcoin Script được thiết kế có chủ đích để không phải là ngôn ngữ Turing hoàn chỉnh. Ngôn ngữ này không có vòng lặp, không có trạng thái tồn tại giữa các lần thực thi và có giới hạn cứng về kích thước kịch bản. Điều này đảm bảo rằng mọi kịch bản đều sẽ kết thúc, đây là một tính năng bảo mật chứ không phải là một hạn chế.
• Ngôn ngữ kịch bản đã phát triển qua năm định dạng chính: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) và Taproot (P2TR), mỗi định dạng đều mở rộng khả năng ứng dụng đồng thời vẫn đảm bảo khả năng tương thích ngược.
• Taproot (tháng 11 năm 2021) đã giới thiệu chữ ký Schnorr, các lộ trình chi tiêu dựa trên MAST nhằm bảo vệ quyền riêng tư, và Tapscript – một ngôn ngữ kịch bản được cập nhật với cơ chế tích hợp sẵn giúp các bản nâng cấp trong tương lai diễn ra suôn sẻ hơn.
• Các trường hợp sử dụng thực tế được xây dựng trên Bitcoin Script bao gồm ví đa chữ ký, giao dịch khóa thời gian, Hợp đồng khóa thời gian bằng hàm băm (nền tảng của Lightning), dịch vụ ký quỹ và Hợp đồng nhật ký kín.
• Khác với các hợp đồng thông minh trên Ethereum, Bitcoin Script là hệ thống không lưu trạng thái: mỗi kịch bản chạy hoàn toàn độc lập và không có thông tin về bất kỳ giao dịch nào khác. Đây là một lựa chọn kiến trúc có chủ đích.
• Lĩnh vực phát triển Bitcoin Script sôi động nhất vào năm 2026 là các mã lệnh (opcode) liên quan đến điều khoản ràng buộc, đặc biệt là OP_CTV (BIP-119) và OP_CAT (BIP-347), cho phép các script đặt ra các điều kiện cụ thể về cấu trúc của một giao dịch chi tiêu. Cả hai mã lệnh này đều chưa được kích hoạt trên mạng chính.

Bitcoin Script là gì?

Bitcoin Script là một ngôn ngữ kịch bản dựa trên ngăn xếp, không lưu trạng thái, được tích hợp sẵn trong giao thức Bitcoin. Mỗi đầu ra giao dịch trên mạng Bitcoin đều chứa một kịch bản khóa (gọi là ScriptPubKey) quy định các điều kiện để chi tiêu số tiền đó. Bất kỳ ai muốn chi tiêu số tiền đó đều phải cung cấp một kịch bản mở khóa (gọi là ScriptSig, hoặc trong các giao dịch SegWit và Taproot, là dữ liệu chứng thực) đáp ứng các điều kiện đó.

Ngôn ngữ này lấy cấu trúc từ Forth, một ngôn ngữ lập trình tối giản dựa trên ngăn xếp được phát triển vào những năm 1960. Giống như Forth, Bitcoin Script được đọc từ trái sang phải, hoạt động trên một cấu trúc dữ liệu gọi là ngăn xếp và sử dụng ký hiệu RPN (Reverse-Polish Notation), trong đó các toán tử đứng sau các toán hạng thay vì đứng trước chúng. Ngôn ngữ này thực thi từng lệnh một, không có vòng lặp và không lưu giữ bộ nhớ giữa các lần thực thi.

Điểm cuối cùng này là điều mà hầu hết mọi người gặp phải đầu tiên khi tìm hiểu về Bitcoin Script ở cấp độ giao thức: ngôn ngữ này được thiết kế có chủ đích để không phải là ngôn ngữ Turing hoàn chỉnh. Một ngôn ngữ Turing hoàn chỉnh có thể thực hiện bất kỳ phép tính nào miễn là có đủ thời gian và tài nguyên. Bitcoin Script, theo thiết kế, không thể làm được điều đó, và những lý do đằng sau sự lựa chọn này có ý nghĩa rất lớn đối với cách thức hoạt động của mạng lưới.

Cách thức hoạt động của Bitcoin Script: Mô hình ngăn xếp

Để hiểu cách thức hoạt động của Bitcoin Script, bạn cần hiểu về ngăn xếp (stack). Ngăn xếp là một cấu trúc dữ liệu hoạt động theo nguyên tắc “Vào sau, ra trước” (LIFO). Hãy tưởng tượng một chồng đĩa: bạn chỉ có thể thêm hoặc lấy ra từ phía trên cùng. Trong Bitcoin Script, dữ liệu được đẩy vào stack và các mã lệnh (opcodes) sẽ thao tác với dữ liệu đang nằm ở phía trên cùng.

Khi một nút Bitcoin xác thực một giao dịch, nó sẽ lần lượt chạy hai tập lệnh:

1. Tập lệnh mở khóa (ScriptSig hoặc chứng thực) do người chi tiêu các đồng xu cung cấp. Thao tác này sẽ đẩy dữ liệu lên ngăn xếp, thường là một chữ ký số và một khóa công khai.
2. Tập lệnh khóa (ScriptPubKey) liên quan đến việc chi tiêu đầu ra. Phần này chứa các mã lệnh (opcode) thực hiện các thao tác trên dữ liệu trong ngăn xếp và kiểm tra xem các điều kiện chi tiêu có được đáp ứng hay không.

Nếu tập lệnh thực thi mà không gặp lỗi và để lại một giá trị khác 0 (TRUE) trên ngăn xếp khi kết thúc, thì giao dịch đó được coi là hợp lệ. Nếu tập lệnh gặp lỗi hoặc để lại giá trị FALSE, giao dịch sẽ bị nút từ chối và không bao giờ được đưa vào khối.

Quá trình thực thi này hoàn toàn không lưu trạng thái. Tập lệnh không có thông tin về bất kỳ giao dịch nào trước đó, không nắm được số dư hiện tại và không có bộ nhớ nào được giữ lại sau khi tập lệnh kết thúc chạy. Mỗi lần chạy, tập lệnh đều bắt đầu từ đầu và hoạt động độc lập.

Từng bước: Một giao dịch P2PKH tiêu chuẩn

Pay-to-Public-Key-Hash (P2PKH) là loại giao dịch Bitcoin ban đầu, được sử dụng từ năm 2009. Các địa chỉ P2PKH bắt đầu bằng số "1". Dưới đây là cách ScriptPubKey và ScriptSig trông như thế nào trong thực tế:

Tập lệnh mở khóa (ScriptSig):

<chữ ký> <khóa công khai>

Tập lệnh khóa (ScriptPubKey):

OP_DUP OP_HASH160 <băm khóa công khai> OP_EQUALVERIFY OP_CHECKSIG

Khi nút nối ghép và thực thi cả hai cùng lúc, các thao tác trên ngăn xếp diễn ra từng bước một:

• Chữ ký và khóa công khai từ ScriptSig được đẩy vào ngăn xếp
• OP_DUP sao chép khóa công khai ở đầu ngăn xếp
• OP_HASH160 tính băm cho các giá trị trùng lặp (SHA-256 tiếp theo là RIPEMD-160), tạo ra một giá trị băm dài 20 byte
• Hàm băm khóa công khai từ tập lệnh khóa được đẩy vào ngăn xếp
• OP_EQUALVERIFY kiểm tra xem hai giá trị băm có khớp nhau hay không. Nếu không khớp, quá trình thực thi sẽ dừng lại và giao dịch sẽ thất bại.
• OP_CHECKSIG xác minh rằng chữ ký đó hợp lệ đối với khóa công khai

Nếu tất cả các bước đều thành công, ngăn xếp sẽ kết thúc với giá trị TRUE và số tiền sẽ được giải phóng. Toàn bộ quá trình này chỉ mất vài mili giây và diễn ra giống hệt nhau trên mọi nút trong mạng.

Giải thích về các mã lệnh Bitcoin

Các mã lệnh (opcode) của Bitcoin là những lệnh riêng lẻ tạo nên một kịch bản. Mỗi mã lệnh có kích thước một byte, tạo ra 256 vị trí mã lệnh khả dụng. Trong số đó, hiện có khoảng 80 mã lệnh đang hoạt động trên mạng chính. Phần còn lại hoặc là được dành riêng, hoặc bị vô hiệu hóa, hoặc được gán cho cơ chế tương thích ngược OP_SUCCESS được giới thiệu cùng với Tapscript.

Các mã lệnh được chia thành một số loại:

• Mã lệnh đẩy dữ liệu đẩy các giá trị như khóa công khai, chữ ký và hàm băm vào ngăn xếp
• Mã lệnh toán học thực hiện các phép tính cộng, trừ và so sánh. Đáng chú ý là các phép nhân và chia đã bị vô hiệu hóa.
• Mã lệnh mã hóa bao gồm OP_SHA256, OP_HASH160, OP_SHA1 để tính băm, và OP_CHECKSIG để xác minh chữ ký
• Mã lệnh điều khiển luồng Kích hoạt logic điều kiện: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Mã lệnh thao tác ngăn xếp bao gồm OP_DUP (sao chép phần tử đầu tiên), OP_DROP (loại bỏ phần tử đầu tiên) và OP_SWAP (hoán đổi hai phần tử đầu tiên)

Năm 2010, Satoshi Nakamoto đã vô hiệu hóa một số mã lệnh (opcode) sau khi phát hiện ra các lỗ hổng bảo mật trong các bản triển khai ban đầu của chúng. Trong số đó có OP_CAT (ghép nối hai phần tử trên ngăn xếp), OP_MUL (nhân) và OP_DIV (chia). Sự vắng mặt của chúng đã gây ra những hậu quả lâu dài đối với khả năng biểu đạt của Bitcoin Script, và một số đề xuất nâng cấp Bitcoin được tranh luận sôi nổi nhất vào năm 2026 liên quan đến việc có nên kích hoạt lại một số trong số chúng hay không.

Để xem tài liệu tham khảo đầy đủ về mã lệnh (opcode), bao gồm các giá trị thập lục phân và mô tả, hãy truy cập Trang Bitcoin Wiki Script là nguồn thông tin đáng tin cậy.

Tại sao việc không hoàn chỉnh theo Turing lại là một ưu điểm

Lời giải thích thông thường là Bitcoin Script không có vòng lặp, do đó các tập lệnh chắc chắn sẽ kết thúc, nhờ đó mạng được bảo vệ khỏi tình trạng thực thi vô hạn. Điều đó là chính xác, nhưng lại chưa nêu hết vấn đề.

Vấn đề cốt lõi nằm ở “bề mặt tấn công”. Một ngôn ngữ Turing hoàn chỉnh có thể biểu diễn bất kỳ phép tính nào. Chính khả năng biểu đạt đó cũng là môi trường sinh sôi của các lỗ hổng. Ngôn ngữ Solidity của Ethereum đã gây ra một số lỗ hổng phần mềm tốn kém nhất trong lịch sử. Vụ tấn công DAO năm 2016 đã khai thác một lỗ hổng tái nhập (reentrancy) trong hợp đồng thông minh và gây ra thiệt hại khoảng 60 triệu USD theo giá thị trường lúc bấy giờ, cuối cùng dẫn đến một đợt hard fork gây tranh cãi trên mạng Ethereum. Hệ sinh thái DeFi rộng lớn hơn đã chứng kiến hàng trăm triệu USD bị thất thoát do các vụ khai thác lỗ hổng hợp đồng thông minh trong nhiều năm qua.

Bitcoin Script khiến loại tấn công này trở nên bất khả thi về mặt cấu trúc. Bạn không thể viết một đoạn mã Bitcoin Script gọi các đoạn mã khác, lặp lại cho đến khi một điều kiện thay đổi, hoặc lưu trữ trạng thái giữa các giao dịch. Mỗi script đều là một chương trình có giới hạn, kết thúc được và có thể kiểm tra được. Kích thước tối đa của một script là 10.000 byte. Số lượng tối đa các mã lệnh không phải push (non-push opcodes) trong mỗi script là 201. Người xác thực luôn có thể tính toán chi phí thực thi trong trường hợp xấu nhất trước khi chạy script.

Đối với một mạng lưới có giá trị lên tới hàng trăm tỷ đô la, tính dự đoán được đó có giá trị hơn cả sự linh hoạt mà bạn phải từ bỏ. Ethereum giải quyết vấn đề tính toán không giới hạn bằng cách áp dụng giới hạn gas, tính phí người dùng cho mỗi mã lệnh (opcode) được thực thi và dừng các skript khi hết ngân sách. Cách này hoạt động, nhưng lại mang đến những phức tạp và nguy cơ thất bại riêng. Bitcoin thì hoàn toàn tránh được vấn đề này ngay từ thiết kế.

Dù vậy, “không hoàn chỉnh theo Turing” không có nghĩa là “không có khả năng xử lý logic phức tạp”. Bitcoin Script hỗ trợ các yêu cầu chi tiêu đa bên, điều kiện dựa trên thời gian, tiết lộ hình ảnh gốc của hàm băm, cũng như sự kết hợp của tất cả các yếu tố này. Mạng Lightning, nơi xử lý hàng triệu giao dịch mỗi ngày, được xây dựng hoàn toàn dựa trên các nguyên tố cơ bản của Bitcoin Script.

Các loại kịch bản: Quá trình phát triển từ P2PKH đến Taproot

Lớp kịch bản của Bitcoin đã có những bước phát triển đáng kể kể từ năm 2009, với mỗi lần nâng cấp đều giới thiệu một định dạng giao dịch mới nhưng vẫn đảm bảo khả năng tương thích ngược với tất cả các phiên bản trước đó.

P2PK (Pay-to-Public-Key, 2009)

Định dạng ban đầu, được sử dụng trong các giao dịch Bitcoin đầu tiên, bao gồm khoản thanh toán của Satoshi cho Hal Finney trong khối 170. Số tiền được khóa trực tiếp vào khóa công khai đầy đủ thay vì băm của khóa đó. Hiện nay, định dạng này hiếm khi được sử dụng trong các giao dịch mới vì nó làm lộ khóa công khai trên chuỗi trước khi chi tiêu, điều này được coi là một biện pháp bảo mật yếu hơn so với việc băm khóa trước khi sử dụng.

P2PKH (Pay-to-Public-Key-Hash, 2009)

Đây là định dạng tiêu chuẩn đã được sử dụng trong hơn một thập kỷ. P2PKH khóa số dư vào giá trị băm (hash) của khóa công khai thay vì chính khóa đó, giúp giữ bí mật khóa công khai cho đến thời điểm chi tiêu, tạo ra địa chỉ ngắn hơn chỉ 20 byte và là nền tảng cho tất cả các địa chỉ bắt đầu bằng số "1". Theo dữ liệu trên chuỗi từ Unchained (tháng 4 năm 2026), các địa chỉ P2PKH hiện đang nắm giữ khoảng 43% tổng nguồn cung Bitcoin đã được khai thác.

P2SH (Pay-to-Script-Hash, 2012, BIP 16)

Được giới thiệu thông qua soft fork vào ngày 1 tháng 4 năm 2012, P2SH đã chuyển gánh nặng của các kịch bản chi tiêu phức tạp từ người gửi sang người nhận. Thay vì nhúng toàn bộ kịch bản khóa vào đầu ra, P2SH chỉ xuất ra cam kết (commit) đối với hàm băm 20 byte của một “kịch bản đổi thưởng” (redeem script). Kịch bản đầy đủ chỉ được tiết lộ khi các đồng tiền được chi tiêu. Điều này đã giúp cơ chế đa chữ ký (multisig) trở nên thực tiễn đối với người dùng thông thường: một cấu hình đa chữ ký 2-trong-3 không còn yêu cầu cả ba khóa công khai phải hiển thị cho người gửi tại thời điểm thanh toán. Các địa chỉ P2SH bắt đầu bằng số "3."

Để biết phân tích chi tiết về cách thức hoạt động của quá trình xác thực P2SH ở cấp độ giao thức, Hướng dẫn giao dịch trên developer.bitcoin.org hướng dẫn từng bước về cơ chế của tập lệnh redeem.

P2WPKH và P2WSH (SegWit gốc, 2017, BIP 141)

Segregated Witness (SegWit), được kích hoạt vào tháng 8 năm 2017 tại khối số 481.824, đã chuyển dữ liệu chữ ký ra khỏi phần thân chính của giao dịch sang một cấu trúc chứng thực riêng biệt. Dữ liệu chứng thực được giảm 75% trọng số, giúp các giao dịch SegWit trở nên rẻ hơn đáng kể. Theo số liệu, một giao dịch P2WPKH tiêu chuẩn với một đầu vào và hai đầu ra có trọng lượng khoảng 141 byte ảo, so với 226 vbytes của giao dịch P2PKH tương đương, theo Phân tích các loại địa chỉ Bitcoin của Spark từ tháng 3 năm 2026. SegWit cũng đã khắc phục được vấn đề tính dễ biến đổi của giao dịch, vốn là điều kiện tiên quyết để Mạng Lightning ra đời. Các địa chỉ SegWit gốc bắt đầu bằng "bc1q."

P2TR (Pay-to-Taproot, 2021, BIP 340/341/342)

Taproot được kích hoạt vào tháng 11 năm 2021 tại khối số 709.632 và là bản nâng cấp quan trọng nhất đối với lớp kịch bản của Bitcoin kể từ SegWit. Bản nâng cấp này đã giới thiệu chữ ký Schnorr, một loại đầu ra mới hỗ trợ MAST, và Tapscript – ngôn ngữ kịch bản được cập nhật. Các địa chỉ Taproot bắt đầu bằng "bc1p."

Taproot và Tapscript: Ngôn ngữ kịch bản Bitcoin đã thay đổi như thế nào trong năm 2021

Taproot không phải là một thay đổi duy nhất. Đó là ba Đề xuất Cải tiến Bitcoin được thiết kế cùng nhau và được kích hoạt đồng thời.

BIP 340: Chữ ký Schnorr

Ban đầu, Bitcoin sử dụng thuật toán ECDSA (Thuật toán chữ ký số trên đường cong elip). Satoshi đã chọn thuật toán này một phần vì lúc đó chữ ký Schnorr đang được bảo hộ bằng bằng sáng chế. Bằng sáng chế đó đã hết hiệu lực vào năm 2008, và Taproot cuối cùng đã đưa chữ ký Schnorr vào giao thức.

Chữ ký Schnorr có kích thước nhỏ hơn, chỉ 64 byte so với 71–73 byte của ECDSA. Quan trọng hơn, chúng hỗ trợ tổng hợp khóa thông qua một cơ chế gọi là MuSig2. Tổng hợp khóa cho phép nhiều người ký kết hợp các khóa và chữ ký riêng lẻ của họ thành một khóa tổng hợp và chữ ký duy nhất, không thể phân biệt được trên chuỗi với một giao dịch thanh toán bằng chữ ký đơn thông thường. Một ví đa chữ ký 2-trong-3 thực hiện giao dịch thông qua đường dẫn khóa hợp tác của Taproot trông giống hệt như một giao dịch tiêu chuẩn trên blockchain. Đây là một lợi ích thực sự về quyền riêng tư cho bất kỳ ai đang nắm giữ bitcoin trong một thỏa thuận lưu ký phức tạp.

BIP 341: Pay-to-Taproot và MAST

P2TR giới thiệu một loại đầu ra mới với hai lộ trình chi tiêu:

• A đường dẫn chính thực hiện giao dịch bằng chữ ký Schnorr, được sử dụng khi tất cả các bên đều đồng ý và mong muốn lựa chọn phương án đơn giản nhất, tiết kiệm nhất
• A đường dẫn tập lệnh thực hiện giao dịch bằng cách sử dụng MAST (Cây cú pháp trừu tượng Merkelized, là cách triển khai khái niệm này trong Taproot)

MAST cho phép một đầu ra duy nhất được áp dụng cho một cây gồm nhiều kịch bản chi tiêu thông qua gốc Merkle. Khi thực hiện chi tiêu, chỉ điều kiện cụ thể thực sự được sử dụng mới được tiết lộ trên chuỗi. Tất cả các đường dẫn chi tiêu khả thi khác trong cây vẫn được ẩn vĩnh viễn. Đối với người dùng đã cấu hình một chính sách chi tiêu phức tạp, ví dụ như “Tôi có thể chi tiêu bình thường, hoặc hai trong số ba người được ủy thác có thể chi tiêu sau sáu tháng, hoặc khóa khôi phục có thể chi tiêu sau hai năm”, thì chỉ có đường dẫn thực sự được thực thi mới xuất hiện trên blockchain.

Theo dữ liệu của Glassnode được Spark trích dẫn vào tháng 3 năm 2026, tính đến năm 2024, tỷ lệ giao dịch Bitcoin sử dụng Taproot đã tăng lên khoảng 42%, chủ yếu nhờ vào hoạt động khắc dấu Ordinals và BRC-20. Tỷ lệ này đã biến động theo tình hình thị trường kể từ đó, nhưng hiện nay cơ sở hạ tầng này đã trở thành tiêu chuẩn trên các ví và sàn giao dịch lớn. Trang chủ đề Taproot của Bitcoin Optech theo dõi quá trình phát triển giao thức đang diễn ra liên quan đến Taproot.

BIP 342: Tapscript

Tapscript là ngôn ngữ kịch bản được cập nhật, được sử dụng cho các giao dịch theo đường dẫn kịch bản (script-path) trong Taproot. Ngôn ngữ này chia sẻ hầu hết các mã lệnh (opcode) với Bitcoin Script phiên bản cũ nhưng có một số thay đổi đáng kể:

• OP_CHECKMULTISIG và OP_CHECKMULTISIGVERIFY đã bị loại bỏ. Mã lệnh multisig cũ có một điểm bất thường, đòi hỏi phải đẩy một phần tử giả vào ngăn xếp như một giải pháp tạm thời. Tapscript đã loại bỏ điểm bất thường này và thay thế bằng OP_CHECKSIGADD, cho phép xác minh các chữ ký Schnorr từng cái một và tích lũy số lượng. Các phương án đa chữ ký ngưỡng trở nên đơn giản hơn và tiết kiệm chi phí hơn khi thực thi.
• Giới hạn kích thước tập lệnh trên mỗi lá MAST đã được gỡ bỏ. Các tập lệnh riêng lẻ trong một nhánh Taproot có thể có kích thước tùy ý.
• Mã lệnh OP_SUCCESS là sự thay đổi mang tính tiên phong nhất. Trong Script truyền thống, việc gặp phải một mã lệnh (opcode) chưa được định nghĩa sẽ khiến kịch bản thất bại. Trong Tapscript, các mã lệnh thuộc phạm vi OP_SUCCESS sẽ khiến kịch bản thành công vô điều kiện. Các soft fork trong tương lai có thể gán hành vi thực tế cho các opcode này bằng cách thêm các ràng buộc về thời điểm chúng thành công, mà không cần phải phát hành phiên bản kịch bản mới hoặc thực hiện chu kỳ triển khai lại toàn bộ trên toàn hệ sinh thái. Các tính năng mới có thể được bổ sung vào lớp kịch bản của Bitcoin một cách gọn gàng hơn so với bất kỳ thời điểm nào trước đây trong lịch sử của giao thức.

Miniscript

Bên cạnh Tapscript, một dự án liên quan có tên Miniscript đang ngày càng trở nên quan trọng đối với các nhà phát triển. Miniscript là một phương pháp có cấu trúc để viết một tập con của Bitcoin Script, cho phép phân tích, kết hợp và ký xác nhận một cách tổng quát. Trong khi Script thô đòi hỏi phải xây dựng thủ công và khó kiểm toán, các kịch bản Miniscript có thể được xác minh tính chính xác một cách tự động và kết hợp thành các chính sách lớn hơn. Miniscript không mở rộng khả năng của Script, nhưng giúp các tính năng hiện có của Script trở nên dễ tiếp cận hơn đáng kể đối với các nhà phát triển đang xây dựng ví và công cụ lưu ký.

Những gì Bitcoin Script mang lại: Các trường hợp ứng dụng trong thực tế

Hiện nay, các loại giao dịch sau đây đang hoạt động trên mạng chính Bitcoin, tất cả đều được xây dựng dựa trên các nguyên tố cơ bản của Bitcoin Script:

Ví đa chữ ký (multisig) Yêu cầu M trong số N khóa riêng để ủy quyền giao dịch chi tiêu. Bộ phận tài chính của một công ty có thể yêu cầu 3 trong số 5 sự chấp thuận cho bất kỳ giao dịch rút tiền nào. Một cặp vợ chồng có thể sử dụng 2 trong số 2 cho tài khoản tiết kiệm chung. Với Taproot và cơ chế tổng hợp khóa Schnorr, các giao dịch chi tiêu đa chữ ký hợp tác hiện nay trên chuỗi không thể phân biệt được với các giao dịch chữ ký đơn tiêu chuẩn.

Giao dịch có thời gian khóa Sử dụng OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify, hay CLTV) và OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify, hay CSV) để ngăn chặn việc chuyển tiền trước khi đạt đến độ cao khối nhất định hoặc thời gian trôi qua nhất định. Các ứng dụng bao gồm lập kế hoạch thừa kế, lịch trình phân bổ token cho nhân viên, cơ chế tiết kiệm bắt buộc và các giao dịch phạt được sử dụng trong các kênh Lightning Network.

Hợp đồng khóa thời gian băm (HTLC) kết hợp yêu cầu về hình ảnh gốc của hàm băm với cơ chế khóa thời gian. Điều kiện chi tiêu hoạt động như sau: phải tiết lộ hình ảnh gốc của hàm băm này trước khi đạt đến độ cao khối này, nếu không số tiền sẽ được trả lại cho người gửi. HTLC là thành phần cơ bản cốt lõi của Mạng Lightning, cho phép định tuyến thanh toán không cần sự tin cậy qua chuỗi các kênh giữa các bên không có mối quan hệ trực tiếp với nhau.

Tài khoản ký quỹ Các cơ chế này khóa số tiền trong một kịch bản P2SH hoặc Taproot, yêu cầu sự đồng thuận của nhiều bên trước khi giải phóng số tiền đó, thường do một bên thứ ba đóng vai trò trọng tài nắm giữ khóa quyết định trong trường hợp hòa.

Hợp đồng nhật ký kín đáo (DLC) sử dụng chữ ký bộ điều hợp Schnorr dựa trên oracle để cho phép các hợp đồng tài chính được thanh toán dựa trên dữ liệu thực tế như nguồn cấp dữ liệu giá hoặc kết quả sự kiện, mà không yêu cầu oracle phải giữ bất kỳ khoản tiền nào. Các DLC hiện đã hoạt động trên mạng chính Bitcoin và được sử dụng cho các sản phẩm quyền chọn và hợp đồng tương lai được thanh toán bằng Bitcoin.

Kịch bản Bitcoin so với Hợp đồng thông minh Ethereum

Cả Bitcoin Script và Solidity của Ethereum đều xác định các điều kiện để tiền có thể được chuyển đi, nhưng chúng đại diện cho những lựa chọn kiến trúc hoàn toàn khác nhau. Việc so sánh trực tiếp này rất đáng thực hiện vì những điểm khác biệt này giải thích rất nhiều về những sự đánh đổi mà mỗi mạng lưới đã chấp nhận.

Điểm khác biệt cơ bản nằm ở tính trạng thái. Các hợp đồng trên Ethereum lưu trữ và sửa đổi dữ liệu tồn tại xuyên suốt các giao dịch, nhờ đó tạo điều kiện cho sự ra đời của các giao thức cho vay, sàn giao dịch phi tập trung, quản trị trên chuỗi và các tiêu chuẩn token. Bitcoin Script không có tính năng tương đương. Mỗi script chạy trong một môi trường cô lập, không có thông tin về bất kỳ giao dịch nào khác.

Đây là một lựa chọn kiến trúc có chủ đích, chứ không phải là một lỗ hổng đang chờ được lấp đầy. Lớp kịch bản của Bitcoin được thiết kế cho một nhiệm vụ cụ thể: đảm bảo các điều kiện để chi tiêu Bitcoin một cách có thể dự đoán được và an toàn, trên quy mô lớn. Đối với nhiệm vụ đó, tính không lưu trạng thái là một thế mạnh. Diện tích tấn công nhỏ hơn, quá trình thực thi mang tính xác định trên hàng triệu trình xác thực độc lập, và không có loại lỗ hổng khai thác hợp đồng thông minh nào ở cấp độ giao thức vì không có hợp đồng lưu trạng thái ở cấp độ giao thức.

Các dự án mong muốn có khả năng lập trình cao hơn trên nền tảng Bitcoin thường triển khai theo mô hình nhiều lớp. Mạng Lightning xử lý các giao dịch thanh toán. Các giao thức DLC xử lý các hợp đồng tài chính liên kết với dữ liệu bên ngoài. Các hệ thống Lớp 2 như Ark và Mạng Liquid đáp ứng các nhu cầu mở rộng quy mô khác nhau. Không có giải pháp nào trong số này yêu cầu phải sửa đổi mô hình kịch bản của lớp cơ sở.

Cuộc tranh luận về Hiệp ước: Những gì có thể thay đổi trong Bitcoin Script

Sự phát triển của Bitcoin Script luôn diễn ra chậm rãi và thận trọng. Lĩnh vực phát triển sôi động nhất hiện nay là các mã lệnh covenant (covenant opcodes) — đây là những đề xuất cho phép một đoạn script không chỉ giới hạn đối tượng có thể chi tiêu một đầu ra, mà còn quy định giao dịch kết quả phải có hình thức như thế nào. Đây là một bước mở rộng đáng kể về khả năng biểu đạt của Script.

Các đề xuất hàng đầu tính đến tháng 6 năm 2026 là:

• OP_CTV (BIP-119, CheckTemplateVerify), do Jeremy Rubin soạn thảo, bổ sung một mã lệnh duy nhất để cam kết một UTXO vào một mẫu chi tiêu cụ thể, đã được xác định trước, bao gồm phiên bản giao dịch, thời gian khóa, số lượng đầu vào, chuỗi đầu vào, số lượng đầu ra và các đầu ra. Đề xuất này được thiết kế theo hướng không đệ quy, được coi là đề xuất lớn có tính thận trọng nhất, và chủ yếu nhắm đến các kho lưu trữ (vaults), kiểm soát tắc nghẽn và một số cải tiến của Lightning. Tính đến tháng 4 năm 2026, OP_CTV đã có các thông số triển khai cụ thể được đưa ra bàn thảo, trong đó quy định khoảng thời gian tín hiệu “Speedy Trial”, nhưng vẫn chưa đạt được sự đồng thuận rộng rãi của cộng đồng cần thiết để kích hoạt, theo Phân tích điều khoản cam kết của BlockEden tháng 4 năm 2026.
• OP_CAT (BIP-347), do Ethan Heilman và Armin Sabouri đề xuất, sẽ kích hoạt lại một mã lệnh (opcode) mà Satoshi đã vô hiệu hóa vào năm 2010. OP_CAT ghép nối hai phần tử trên ngăn xếp, một cơ chế nghe có vẻ đơn giản nhưng lại mang ý nghĩa sâu rộng. Khi kết hợp với chữ ký Schnorr, nó cho phép thực hiện việc kiểm tra nội dung giao dịch theo kiểu “covenant”. Trên mạng thử nghiệm Bitcoin Signet, theo phân tích trên chuỗi của sCrypt vào cuối năm 2024, OP_CAT đã tạo ra số lượng giao dịch của nhà phát triển nhiều hơn đáng kể so với cả APO và CTV. OP_CAT hiện đã được kích hoạt trên Mạng Liquid và Fractal Bitcoin mà chưa ghi nhận bất kỳ lỗ hổng bảo mật nào liên quan đến nó. BIP-347 đã có số đề xuất chính thức và được hỗ trợ bởi các nghiên cứu đang diễn ra, nhưng việc kích hoạt trên mạng chính (mainnet) đòi hỏi sự đồng thuận của cộng đồng – điều mà hiện tại vẫn chưa có.
• LNHANCE kết hợp OP_CTV với OP_CHECKSIGFROMSTACK (CSFS) và OP_INTERNALKEY, nhằm mang lại những cải tiến cụ thể cho việc xây dựng kênh trên Mạng Lightning, bao gồm việc mở kênh không tương tác và quản lý kênh đa bên hiệu quả hơn.

Tính đến tháng 6 năm 2026, chưa có đề xuất nào trong số này được kích hoạt trên mạng chính Bitcoin. Những bất đồng về mặt kỹ thuật giữa các bên phần lớn đều có thể giải quyết được. Vấn đề khó khăn hơn nằm ở cơ chế kích hoạt. Quy trình soft fork của Bitcoin đòi hỏi sự đồng thuận rộng rãi, và cuộc tranh luận về thỏa thuận vẫn còn tồn tại những căng thẳng dư âm từ các bản nâng cấp gây tranh cãi trước đây. Điều rõ ràng từ cuộc tranh luận này là lớp kịch bản của Bitcoin vẫn có không gian phát triển đáng kể trong khuôn khổ bảo thủ của nó. Vấn đề đang được thảo luận là thứ tự thực hiện và sự đồng thuận của cộng đồng, chứ không phải liệu ngôn ngữ kịch bản có tương lai hay không.

Kết luận

Bitcoin Script là cơ sở hạ tầng vô hình nằm đằng sau mọi giao dịch trên mạng lưới. Hầu hết người dùng không bao giờ tiếp xúc trực tiếp với nó. Các ví tạo ra các kịch bản hợp lệ, ký tên vào chúng và phát sóng chúng mà không bao giờ tiết lộ cơ chế hoạt động bên trong. Tuy nhiên, mọi khoản thanh toán, mọi kênh Lightning, mọi kế hoạch khóa thời gian và mọi kho lưu trữ đa chữ ký đều chạy trên cùng một ngôn ngữ kịch bản Bitcoin dựa trên ngăn xếp, vốn đã được tích hợp sẵn trong giao thức từ năm 2009.

Lớp kịch bản đã phát triển đáng kể kể từ đó, với P2SH giúp việc chi tiêu phức tạp trở nên khả thi, SegWit giảm phí giao dịch và mở đường cho Lightning, cùng với Taproot mang đến chữ ký Schnorr, tính riêng tư dựa trên MAST và thiết kế mã lệnh tương thích về phía trước của Tapscript. Các đề xuất về "covenant" hiện đang được thảo luận sôi nổi đại diện cho chương tiếp theo tiềm năng. Việc liệu có đề xuất nào được kích hoạt hay không, và vào thời điểm nào, vẫn còn là một ẩn số tính đến giữa năm 2026.

Để hiểu về Script, bạn không cần phải là một nhà phát triển. Tuy nhiên, bạn cần nhận ra rằng tính bảo thủ của Bitcoin, những hạn chế có chủ đích, nhịp độ nâng cấp chậm chạp, cũng như việc không đạt tính đầy đủ Turing, không phải là những thiếu sót. Chính những đặc tính giúp Bitcoin Script trở nên dễ dự đoán cũng chính là những đặc tính đã giúp lớp đồng thuận duy trì sự trong sạch trong suốt mười sáu năm qua.