Tiếp cận BTC: Giải thích chi tiết về kiến thức nền tảng cần thiết cho BitVM

Tác giả: Nickqiao & Faust & Shew Wang, Geek web3

Nhóm nghiên cứu Bitlayer: Tư vấn

Tóm tắt:

Gần đây, Delphi Digital đã phát hành một báo cáo nghiên cứu về công nghệ liên quan đến Bitcoin L2 có tiêu đề “The Dawn of Bitcoin Programmability: Paving the Way for Rollups”, hệ thống đã phân loại một cách cụ thể các khái niệm cốt lõi liên quan đến Rollup của Bitcoin, như BitVM full stack, OP_CAT và điều khoản hạn chế Covenant, DA lớp sinh thái Bitcoin, cũng như bốn lớp liên quan đến Bitcoin sử dụng BitVM gồm Bitlayer, Citrea, Yona, và Bob.

Bản báo cáo này mặc dù tổng quan cho thấy bức tranh tổng thể về công nghệ lớp hai của Bitcoin, nhưng tổng thể khá rộng rãi và thiếu mô tả chi tiết, khiến người đọc mơ hồ. Trên cơ sở báo cáo Delphi, Geekweb3 đã tiến hành một khám phá sâu hơn, cố gắng giúp nhiều người hiểu hệ thống hơn về các công nghệ như BitVM.

Chúng tôi sẽ phối hợp với nhóm nghiên cứu Bitlayer và cộng đồng tiếng Trung BitVM để tổ chức một loạt bài viết chuyên đề có tên là “Tiến gần với BTC”, tập trung lâu dài vào các chủ đề chính như BitVM, OP_CAT và cầu nối Cross-chain Bitcoin để giúp mọi người hiểu rõ hơn về các công nghệ liên quan đến Bitcoin lớp hai và mở đường cho nhiều người hâm mộ hơn.

Chính văn:

Cách đây vài tháng, Robin Linus, người đứng đầu ZeroSync, đã phát hành bài viết mang tên “BitVM: Compute Anything on Bitcoin”, chính thức đưa ra khái niệm BitVM, thúc đẩy sự tiến triển của công nghệ lớp hai của Bitcoin. Có thể nói rằng đây là một trong những đổi mới mang tính cách mạng nhất trong sinh thái Bitcoin, đã làm bùng nổ toàn bộ sinh thái lớp hai của Bitcoin, thu hút sự tham gia của các dự án nổi bật như Bitlayer, Citrea, BOB, mang đến sự sôi động cho toàn bộ thị trường.

Sau đó, nhiều nhà nghiên cứu đã tham gia cải tiến BitVM và liên tục phát hành các phiên bản BitVM1, BitVM2, BitVMX, BitSNARK và các phiên bản tiếp theo khác. Tình hình chung của nó như sau:

1. BitVM được đề xuất lần đầu tiên bởi Robin Linus vào năm ngoái trong bản sách trắng, đó là giải pháp thực hiện BitVM dựa trên mạch cửa logic ảo, được gọi là BitVM0;
2. Trong những lần diễn thuyết và phỏng vấn sau này, Robin Linus đã giới thiệu một cách không chính thức về giải pháp BitVM dựa trên CPU giả tưởng (được gọi là BitVM1), tương tự hệ thống chứng minh gian lận của Optimism, có thể mô phỏng hiệu quả của một CPU thông thường dưới dạng off-chain bằng script Bitcoin.
3. Robin Linus cũng đưa ra BitVM2, một giao thức chứng minh gian lận bước đơn cho phép mà không cần đến sự tương tác.
4. Các thành viên của Rootstock Labs và Fairgate Labs đã phát hành White Paper của BitVMX, tương tự như BitVM1, họ hy vọng mô phỏng hiệu quả của CPU thông qua script của Bitcoin (ngoại lệ)

So với năm ngoái, hệ sinh thái BitVM ngày nay đã trở nên “mờ nhạt” từ “short trong tòa nhà” ban đầu, điều này cũng đã thu hút ngày càng nhiều nhà phát triển và VC long lao vào hệ sinh thái Bitcoin.

Nhưng đối với đa số mọi người, việc hiểu rõ về các thuật ngữ công nghệ liên quan đến BitVM và lớp hai của Bitcoin không phải là điều dễ dàng, bởi bạn phải trước tiên hiểu rõ kiến thức cơ bản xung quanh nó một cách hệ thống, đặc biệt là kiến thức nền về tập lệnh Bitcoin và Taproot. Hiện tại, tài liệu tham khảo trực tuyến hiện có hoặc quá dài dòng, hoặc không giải thích đủ sâu sắc khiến người đọc cảm thấy mơ hồ. Chúng tôi cam kết giải quyết vấn đề trên, cố gắng sử dụng ngôn ngữ càng rõ ràng càng tốt, giúp người khác hiểu rõ hơn về kiến thức xung quanh lớp hai của Bitcoin và xây dựng nhận thức hệ thống về hệ thống BitVM.

MATT và Cam kết: Ý tưởng cơ bản của BitVM

Đầu tiên, chúng tôi muốn nhấn mạnh rằng ý tưởng cơ bản của BitVM là MATT, có ý nghĩa là Merkleize All The Things, chủ yếu là sử dụng cấu trúc lưu trữ dữ liệu dạng cây Merkle Tree để thể hiện quá trình thực hiện phức tạp của chương trình, cố gắng làm cho việc xác minh gian lận của Bitcoin Native.

MATT, mặc dù có thể biểu diễn một đoạn chương trình phức tạp cùng với dấu vết xử lý dữ liệu, nhưng không trực tiếp công bố những dữ liệu này trên chuỗi BTC, vì tổng quy mô của những dữ liệu này rất lớn. Phương án sử dụng MATT chỉ lưu trữ dữ liệu trong cây Merkle ở chuỗi ngoại (off-chain), chỉ công bố tóm tắt (Merkle Root) ở đỉnh cây Merkle lên chuỗi trên (on-chain). Cây Merkle chủ yếu chứa ba nội dung cốt lõi:

• Mã kịch bản hợp đồng thông minh
• Dữ liệu cần thiết cho hợp đồng
• Dấu vết để lại trong quá trình thực thi hợp đồng thông minh (biến đổi trong bộ nhớ, thanh ghi CPU được ghi nhận khi hợp đồng thông minh được thực thi trong máy ảo như EVM).

Trong kế hoạch MATT, chỉ có Merkle Root có kích thước rất nhỏ được lưu trữ trên chuỗi, tập dữ liệu đầy đủ được lưu trữ ngoài chuỗi trong Merkle Tree, điều này sử dụng một cách tiếp cận được gọi là “cam kết”. Hãy giải thích ý nghĩa của “cam kết” (Commitment) ở đây.

Cam kết giống như một tuyên bố ngắn gọn, có thể hiểu là “dấu vân tay” của một lượng lớn dữ liệu nén. Nói chung, những người xuất bản “lời hứa” trên on-chain sẽ tuyên bố rằng một số dữ liệu được lưu trữ off-chain là chính xác và dữ liệu off-chain này tương ứng với một tuyên bố ngắn gọn, được gọi là “cam kết”.

Tại một số điểm thời gian, hash của dữ liệu có thể được coi là “lời hứa” về dữ liệu chính nó, các lời hứa khác bao gồm lời hứa KZG hoặc Merkle Tree. Trong giao thức chứng minh gian lận thông thường trên Layer2, người phát hành dữ liệu sẽ công bố toàn bộ bộ dữ liệu trên chuỗi dưới, và công bố lời hứa về bộ dữ liệu trên chuỗi. Nếu có ai đó phát hiện ra rằng có dữ liệu không hợp lệ trong bộ dữ liệu chuỗi dưới, họ sẽ thách thức lời hứa chuỗi trên.

Với cam kết (Commitment), Layer 2 có thể nén và xử lý một lượng lớn dữ liệu, chỉ công bố ‘cam kết’ trên chuỗi Bitcoin. Tất nhiên, cần đảm bảo tập dữ liệu đầy đủ được công bố trên chuỗi ngoại vi.

Hiện tại, một số giải pháp BitVM như BitVM0, BitVM1, BitVM2 và BitVMX đều sử dụng cấu trúc trừu tượng tương tự.

1. Phân tích chương trình và cam kết: Đầu tiên, chúng ta phân tích chương trình phức tạp thành nhiều mã hoạt động cơ bản hơn (biên dịch), sau đó ghi lại dấu vết các mã hoạt động này khi thực hiện cụ thể (nói một cách đơn giản, đây là toàn bộ sự thay đổi trạng thái khi một chương trình chạy trong CPU và bộ nhớ, gọi là Trace). Sau đó, chúng ta tổ chức tất cả các dữ liệu bao gồm Trace và mã hoạt động để tạo ra một tập dữ liệu và tạo cam kết cho tập dữ liệu đó.

Các hình thức cam kết cụ thể có thể bao gồm nhiều loại, chẳng hạn như cây Merkle, PIOPs (các thuật toán ZK đa dạng), hàm băm

2. Thế chấp tài sản và chữ ký trước: Nhà cung cấp dữ liệu và người xác thực cần khóa một số tiền tài sản trên chuỗi dữ liệu bằng hình thức chữ ký trước và có các điều kiện hạn chế. Những điều kiện này sẽ được kích hoạt một cách đáng chú ý cho các trường hợp có thể xảy ra trong tương lai, nếu nhà cung cấp dữ liệu gian lận, người xác thực có thể gửi chứng cứ để lấy tài sản của nhà cung cấp dữ liệu.

3. Việc công bố dữ liệu và cam kết: Người phát hành dữ liệu công bố cam kết trên chuỗi, và công bố toàn bộ bộ dữ liệu trên chuỗi ngoại. Người xác thực truy xuất bộ dữ liệu và kiểm tra xem có bất kỳ lỗi nào hay không. Mỗi phần trong bộ dữ liệu ngoại đều có liên quan đến cam kết trên chuỗi.

4. Thách thức và Phạt: Nếu như người xác thực phát hiện ra dữ liệu mà người cung cấp cung cấp có sai sót, họ sẽ đưa phần dữ liệu đó lên chuỗi để xác minh trực tiếp (phải cắt phần dữ liệu này ra rất nhỏ trước). Đây là logic của bằng chứng gian lận. Nếu kết quả xác minh cho thấy người cung cấp dữ liệu đã cung cấp dữ liệu không hợp lệ ở chuỗi dưới, tài sản của họ sẽ bị người xác thực thách thức và lấy đi.

Tóm lại, nhà phát hành dữ liệu Alice công khai tất cả các dấu vết phát sinh trong quá trình thực hiện giao dịch tầng hai trên chuỗi và đưa cam kết tương ứng lên chuỗi. Nếu bạn muốn chứng minh một phần dữ liệu nào đó có lỗi, trước hết bạn phải chứng minh rằng phần dữ liệu đó liên quan đến cam kết trên chuỗi bằng cách chứng minh rằng dữ liệu đó đã được Alice công khai, sau đó bạn phải đảm bảo rằng phần dữ liệu đó có lỗi.

Bây giờ chúng ta đã hiểu được khái niệm chung của BitVM, tất cả các biến thể của BitVM đều không thể tránh khỏi mô hình trên. Vì vậy, tiếp theo, hãy bắt đầu học và hiểu một số kỹ thuật quan trọng được sử dụng trong quy trình trên, bắt đầu từ kịch bản Bitcoin và Taproot cơ bản nhất cùng với chữ ký trước.

Bitcoin Script là gì

Kiến thức liên quan đến Bitcoin khó hiểu hơn Ethereum, ngay cả hành vi chuyển tiền cơ bản nhất cũng liên quan đến một loạt các khái niệm, bao gồm UTXO (Đầu ra giao dịch chưa chi tiêu), kịch bản khóa (còn được gọi là PubKey) và kịch bản mở khóa (còn được gọi là Sig). Chúng ta sẽ trước tiên giải thích những khái niệm chính này.

（Một ví dụ về mã kịch bản Bitcoin bao gồm các mã hoạt động ở tầng thấp hơn so với ngôn ngữ lập trình cao cấp ）

Cách biểu diễn tài sản trên Ethereum, giống như Alipay hoặc WeChat hơn, mỗi lần chuyển khoản chỉ là thực hiện phép cộng trừ đối với số dư của các tài khoản khác nhau, phương pháp này xoay quanh tài khoản, số dư tài sản chỉ là một con số dưới tên tài khoản; cách biểu diễn tài sản trên Bitcoin giống như vàng hơn, mỗi đồng vàng (UTXO) đều sẽ gắn ký hiệu của chủ sở hữu, chuyển khoản thực tế là tiêu hủy UTXO cũ và tạo ra UTXO mới (chủ sở hữu sẽ thay đổi).

Gói UTXO Bitcoin bao gồm hai trường khóa chính:

Số tiền được tính bằng đơn vị ‘Satoshi’ (một BTC bằng mười triệu Satoshi);

Kịch bản khóa, còn được gọi là “Khóa công khai kịch bản (PubKey)”, định nghĩa điều kiện mở khóa UTXO.

Cần lưu ý rằng quyền sở hữu của UTXO Bitcoin được biểu thị thông qua script khóa, nếu bạn muốn chuyển nhượng UTXO của mình cho Sam, bạn có thể khởi tạo giao dịch hủy bỏ UTXO của mình, đặt điều kiện mở khóa cho UTXO mới được tạo ra là “chỉ có Sam mới có thể mở khóa”.

Sau đó, nếu Sam muốn sử dụng các đồng Bitcoin này, anh ấy cần gửi một tập lệnh mở khóa (Sig), trong đó Sam phải trình diễn chữ ký số của mình để chứng minh anh ấy là Sam. Nếu tập lệnh mở khóa này khớp với tập lệnh khóa đã nêu trên, Sam có thể mở khóa và chuyển đồng Bitcoin này cho người khác.

（Kịch bản mở khóa phải khớp với kịch bản khóa）

Từ góc độ hiển thị, mỗi giao dịch trên chuỗi Bitcoin đều tương ứng với nhiều Input và Output, mỗi Input phải khai báo UTXO mà họ muốn mở khóa và gửi mã mở khóa, mở khóa và phá hủy UTXO đó; Output sẽ hiển thị thông tin UTXO mới được tạo ra và công khai nội dung mã khóa.

Ví dụ, trong Input của một giao dịch, bạn chứng minh bạn là Sam, mở khóa nhiều UTXO mà người khác đã gửi cho bạn, đồng thời tiêu hủy chúng, sau đó tạo ra nhiều UTXO mới và khai báo cho xxx để mở khóa trong tương lai.

Cụ thể, trong dữ liệu Input của giao dịch, bạn cần khai báo rằng bạn muốn mở khóa những UTXO nào và chỉ ra “vị trí lưu trữ” của dữ liệu UTXO đó. Điều cần lưu ý ở đây là Bitcoin và Ethereum hoàn toàn khác biệt, Ethereum cung cấp hai loại tài khoản là tài khoản hợp đồng và tài khoản EOA để lưu trữ dữ liệu, số dư tài sản được ghi lại dưới tên tài khoản hợp đồng hoặc tài khoản EOA, được tổ chức tại cơ sở dữ liệu được gọi là “trạng thái thế giới”, khi chuyển tiền sẽ được chỉnh sửa trực tiếp từ “trạng thái thế giới” đối với tài khoản cụ thể, dễ dàng xác định vị trí lưu trữ dữ liệu;

Bitcoin không có thiết kế trạng thái toàn cầu, dữ liệu tài sản được lưu trữ phân tán trong các khối trước đó (đó là dữ liệu UTXO chưa được mở khóa, được lưu trữ riêng lẻ trong mỗi đầu ra giao dịch).

Nếu bạn muốn mở khóa một UTXO nào đó, bạn cần chỉ ra rằng thông tin UTXO đó tồn tại trong đầu ra của giao dịch nào đó trong quá khứ, hiển thị ID của giao dịch đó (tức là mã băm của nó), để nút Bitcoin đi tìm kiếm trong lịch sử. Nếu bạn muốn truy vấn số dư Bitcoin của một địa chỉ nào đó, bạn cần duyệt qua tất cả các khối từ đầu để tìm các UTXO chưa được mở khóa liên quan đến địa chỉ xx.

Khi sử dụng Ví tiền Bitcoin thường xuyên, bạn có thể nhanh chóng kiểm tra số dư Bitcoin của một địa chỉ cụ thể. Điều này thường xảy ra vì dịch vụ Ví tiền đã quét và tạo chỉ mục cho tất cả các địa chỉ trên khối, giúp chúng ta tra cứu nhanh chóng.

(Khi tạo một khai báo giao dịch để chuyển UTXO của mình cho người khác, bạn cần đánh dấu vị trí của UTXO đó trong lịch sử giao dịch Bitcoin dựa trên hash/ID của giao dịch mà UTXO đó thuộc về)

Thú vị là kết quả giao dịch Bitcoin được tính toán ngoại chuỗi, khi người dùng tạo giao dịch trên thiết bị cục bộ, họ phải tạo ra Tất cả các đầu vào và đầu ra trực tiếp, tương đương với việc tính toán kết quả đầu ra của giao dịch. Giao dịch được phát sóng đến mạng Bitcoin, sau khi được nút xác minh mới được đưa lên chuỗi. Mô hình “tính toán ngoại chuỗi - xác minh trên chuỗi” này hoàn toàn khác biệt so với Ethereum, trên Ethereum, bạn chỉ cần cung cấp tham số đầu vào của giao dịch, kết quả giao dịch được tính toán và đầu ra bởi nút Ethereum.

Ngoài ra, kịch bản khóa UTXO (Khóa) có thể được tùy chỉnh, bạn có thể đặt UTXO như là ‘chủ sở hữu của một địa chỉ Bitcoin cụ thể có thể mở khóa’, chủ sở hữu của địa chỉ cần cung cấp chữ ký số và khóa công khai (P2PKH). Trong loại giao dịch Pay-to-Hash (P2SH), bạn có thể thêm một Hash vào kịch bản khóa UTXO, ai có thể trình bày nguyên tố kịch bản tương ứng với Hash này và đáp ứng điều kiện được thiết lập trước trong nguyên tố kịch bản đó, thì có thể mở khóa UTXO. Kịch bản Taproot mà BitVM phụ thuộc vào sử dụng tính năng tương tự như P2SH.

Cách tập lệnh Bitcoin được kích hoạt

Ở đây, chúng ta sẽ sử dụng P2PKH làm ví dụ để giới thiệu cách kích hoạt script Bitcoin, chỉ khi hiểu cách kích hoạt này thì mới có thể hiểu được các phức tạp hơn như Taproot và BitVM. P2PKH là viết tắt của ‘Pay to Public Key Hash’, trong phương pháp này, một public key hash sẽ được đặt trong script khóa của UTXO, khi mở khóa cần phải gửi public key tương ứng với hash đó, điều này tương tự như quy trình chuyển Bitcoin thông thường.

Lúc này, nút Bitcoin phải xác định được khóa công khai trong mã mở khóa và khóa hash công khai được chỉ định trong mã khóa có khớp nhau, nghĩa là phải xác định rằng “chìa khóa” mà người mở khóa gửi và “khóa” được đặt trước của UTXO phù hợp với nhau.

Nói thêm, trong kế hoạch P2PKH, sau khi nhận giao dịch, nút Bitcoin sẽ ghép mã chữ ký mở khóa mà người dùng cung cấp với mã khóa khóa UTXO cần mở khóa và thực thi trong môi trường thực thi của BTC script. Hình dưới đây cho thấy kết quả ghép trước khi thực thi:

Có thể độc giả không hiểu môi trường thực thi script BTC, chúng tôi sẽ giới thiệu một cách đơn giản ở đây. Đầu tiên, script BTC bao gồm hai yếu tố:

Dữ liệu và mã hoạt động. Các dữ liệu và mã hoạt động này sẽ được đẩy vào ngăn xếp theo thứ tự từ trái sang phải và thực thi theo logic được chỉ định để đạt được kết quả cuối cùng (về ngăn xếp, không mở rộng chi tiết ở đây, đọc giả có thể tự tìm hiểu).

Ví dụ trên, phía bên trái là Đoạn mã mở khóa Sig được tải lên bởi một người nào đó, bao gồm chữ ký số và khóa công khai của anh ta, còn phía bên phải là Đoạn mã khóa Pubkey, bao gồm một đoạn mã và dữ liệu được thiết lập bởi người tạo UTXO khi tạo UTXO đó (Ở đây chúng ta không cần hiểu rõ ý nghĩa của mỗi đoạn mã, hiểu đại khái là đủ).

Trong mã lệnh khóa bên phải trong hình trên, các hoạt động DUP, HASH160, EQUALVERIFY vv. làm nhiệm vụ lấy băm của khóa công khai được mang trong mã mở khóa bên trái, và so sánh với băm của khóa công khai đã được thiết lập trong mã khóa, nếu cả hai bằng nhau, điều này có nghĩa là khóa công khai được đưa lên trong mã mở khóa tương ứng với băm của khóa công khai đã được thiết lập trong mã khóa, điều này đã vượt qua bước xác minh đầu tiên.

Tuy nhiên, có một vấn đề, nội dung của kịch bản khóa UTXO thực tế là công khai trên chuỗi, bất kỳ ai cũng có thể quan sát được hàm băm của khóa công khai được bao gồm trong đó, bất kỳ ai cũng có thể tải lên khóa công khai tương ứng và giả mạo rằng họ là người được “chỉ định”. Vì vậy, sau khi xác minh khóa công khai và băm khóa công khai, cần phải xác minh xem người gửi giao dịch có thực sự là người kiểm soát thực tế của khóa công khai đó hay không, điều này đòi hỏi phải xác minh chữ ký số. Mã hoạt động CHECKSIG trong kịch bản khóa, chính là để xác minh chữ ký số.

Tóm lại, trong kịch bản P2PKH, trong mã mở khóa mà người gửi giao dịch gửi đi, bao gồm khóa công khai và chữ ký số, khóa công khai này phải khớp với băm khóa công khai được chỉ định trong mã khóa, và chữ ký số của giao dịch phải đúng, chỉ khi đáp ứng các điều kiện này thì mới có thể mở khóa UTXO một cách thuận lợi.

（Hình này là động: Sơ đồ minh họa mã mở khóa Bitcoin dưới giao thức P2PKH

Nguồn: ** ）

Tất nhiên, trong mạng Bitcoin, có nhiều loại giao dịch được hỗ trợ, không chỉ có Pay to public key/public key hash, mà còn có P2SH (Pay to hash) và nhiều hơn nữa, tất cả phụ thuộc vào việc tạo ra UTXO và cách thiết lập kịch bản khóa được tùy chỉnh.

Ở đây, điều cần chú ý là, trong kế hoạch P2SH, có thể đặt trước một Hash trong script khoá, trong khi script mở khoá cần phải trình bày đầy đủ nội dung script tương ứng với Hash. Nút Bitcoin có thể thực hiện đoạn script này, nếu trong đoạn script này xác định logic xác minh đa chữ ký, có thể thực hiện hiệu quả ví đa chữ ký trên chuỗi Bitcoin.

Tất nhiên, dưới kế hoạch P2SH, người tạo UTXO phải cho người giải mã UTXO trong tương lai biết nội dung script tương ứng với Hash trước, chỉ cần cả hai bên đều biết nội dung này, chúng ta có thể thực hiện logic kinh doanh phức tạp hơn cả giao dịch đa chữ ký.

Ở đây cần phải giải thích một điều, Bitcoin on-chain (Khối) không ghi trực tiếp các UTXO và địa chỉ nào liên kết với nhau, nó chỉ ghi nhận rằng UTXO có thể được giải mã bởi địa chỉ hash công khai/những đoạn mã hash script nào, nhưng chúng ta có thể nhanh chóng tính toán ra địa chỉ tương ứng dựa trên hash công khai/những đoạn mã hash script (phần hiển thị trên giao diện Ví tiền giống như một đoạn mã hỗn hợp).

Lý do chúng ta có thể nhìn thấy số lượng Bitcoin của địa chỉ xx trên giao diện trình duyệt khối và ví tiền là do trình duyệt khối và dự án ví tiền đã giúp bạn phân tích dữ liệu này. Nó sẽ quét tất cả các khối và tính toán ‘địa chỉ’ tương ứng dựa trên khóa công khai hash / hash kịch bản khóa, sau đó hiển thị số lượng Bitcoin của địa chỉ xx.

SegWit và Witness

Khi chúng ta hiểu được cách thức hoạt động của P2SH, chúng ta sẽ tiến thêm một bước gần hơn với Taproot, một phần không thể thiếu của BitVM. Tuy nhiên, trước khi đi vào chi tiết, chúng ta phải hiểu một khái niệm quan trọng: Witness và SegWit.

Khi phân tích lại các script mở khóa và script khóa, cũng như quy trình mở UTXO, ta sẽ nhận thấy một vấn đề: chữ ký số của giao dịch được chứa trong script mở khóa và không thể ghi đè lên (các tham số được sử dụng để tạo chữ ký không thể bao gồm chính chữ ký), do đó chữ ký số chỉ có thể ghi đè lên phần ngoại trừ của script mở khóa, tức là chỉ có thể liên kết với phần trung tâm của dữ liệu giao dịch, không thể ghi đè lên toàn bộ dữ liệu giao dịch.

Như vậy, ngay cả khi mã kịch bản mở khóa giao dịch bị can thiệp bởi một bên thứ ba, nó cũng sẽ không ảnh hưởng đến kết quả xác minh. Ví dụ, một nút Bitcoin hoặc một pool khai thác có thể chèn dữ liệu khác vào mã kịch bản mở khóa giao dịch, làm thay đổi nhỏ trong dữ liệu giao dịch mà không ảnh hưởng đến việc xác minh và kết quả giao dịch, dẫn đến thay đổi trong hash giao dịch/ID giao dịch được tính toán cuối cùng. Điều này được gọi là vấn đề mở rộng giao dịch.

Nhược điểm của điều này là nếu bạn dự định thực hiện nhiều giao dịch liên tiếp và có sự phụ thuộc theo thứ tự (ví dụ, giao dịch 3 tham chiếu đến đầu ra của giao dịch 2, giao dịch 2 tham chiếu đến đầu ra của giao dịch 1), thì giao dịch sau cùng nhất định phải tham chiếu đến ID (hash) của các giao dịch trước đó. Bất kỳ bên thứ ba nào như pool khai thác hoặc nút Bitcoin có thể điều chỉnh nội dung trong tập lệnh mở khóa để tạo ra hash của giao dịch trên chuỗi không khớp với mong đợi của bạn, khiến cho các giao dịch liên quan theo thứ tự mà bạn đã tạo trước đó không còn hiệu lực.

Trong thực tế, trong các giải pháp cầu DLC và BitVM2, các giao dịch có liên quan theo thứ tự sẽ được xây dựng theo lô, vì vậy cảnh tượng được đề cập ở trên không phải là hiếm gặp.

Nói một cách đơn giản, vấn đề về tính mở rộng giao dịch là do khi tính toán ID/hash của giao dịch, nó sẽ bao gồm dữ liệu trong kịch bản mở khóa và các bên thứ ba như các nút Bitcoin có thể điều chỉnh nội dung trong kịch bản mở khóa, dẫn đến ID giao dịch không khớp với kỳ vọng của người dùng. Thực ra, đây là một gánh nặng lịch sử mà Bitcoin để lại khi thiết kế trong giai đoạn đầu.

Bản nâng cấp SegWit được ra mắt sau này thực sự là việc hoàn toàn tách rời ID giao dịch và script mở khóa, không cần bao gồm dữ liệu script mở khóa khi tính toán hash giao dịch. Script khóa UTXO tuân theo bản nâng cấp SegWit sẽ mặc định đặt một mã hoạt động gọi là ‘OP_0’ ở vị trí đầu tiên, đóng vai trò như một đánh dấu; và script mở khóa tương ứng đã được đổi tên từ Sig thành Witness.

Sau khi tuân thủ quy tắc SegWit, vấn đề mở rộng giao dịch sẽ được giải quyết một cách kỹ lưỡng, bạn không cần phải lo lắng về việc dữ liệu giao dịch gửi đến nút Bitcoin bị điều chỉnh. Tất nhiên, chúng ta không cần phải suy nghĩ quá phức tạp, tính năng P2WSH và P2SH đã được nói đến trước đó không có sự khác biệt cốt lõi, bạn có thể thiết lập một mã băm kịch bản trong mã khóa UTXO và chờ đợi người gửi mã giải khóa đưa nội dung kịch bản tương ứng của mã băm vào chuỗi và thực thi.

Nhưng nếu nội dung script mà bạn muốn triển khai cực kỳ lớn, bao gồm rất nhiều mã, không thể gửi toàn bộ script hoàn chỉnh lên chuỗi Bitcoin bằng phương pháp thông thường (mỗi khối có giới hạn về kích thước). Vậy làm thế nào? Điều này đòi hỏi sự trợ giúp từ Taproot, để tối ưu hóa nội dung script trên chuỗi, và BitVM chính là giải pháp phức tạp được xây dựng dựa trên Taproot.