Tiếp cận BTC: Kiến thức nền cần thiết để hiểu BitVM (1)
Tuyển chọn TechFlowTuyển chọn TechFlow
Tiếp cận BTC: Kiến thức nền cần thiết để hiểu BitVM (1)
Bài viết này sẽ giới thiệu về ý tưởng cơ bản của BitVM, script Bitcoin và Segregated Witness.
Chuyên sâu báo cáo Web3Tác giả: Nickqiao, Faust, Shew Wang, Geek web3
Cố vấn: Nhóm nghiên cứu Bitlayer
Tóm tắt: Gần đây Delphi Digital đã công bố báo cáo kỹ thuật liên quan đến lớp thứ hai của Bitcoin với tựa đề "The Dawn of Bitcoin Programmability: Paving the Way for Rollups", trình bày hệ thống các khái niệm cốt lõi liên quan đến Bitcoin Rollup như bộ công cụ BitVM, OP_CAT và điều khoản ràng buộc Covenant, lớp DA hệ sinh thái Bitcoin, cầu nối (bridge), cũng như bốn dự án lớp hai Bitcoin sử dụng BitVM là Bitlayer, Citrea, Yona, Bob.
Báo cáo này tuy phần nào phác họa bức tranh tổng thể về công nghệ lớp hai Bitcoin nhưng lại khá chung chung, thiếu chi tiết cụ thể, khiến người đọc khó hiểu rõ. Geek web3 mở rộng và đào sâu hơn trên cơ sở báo cáo của Delphi, cố gắng giúp nhiều người hiểu rõ hơn về các công nghệ như BitVM.
Chúng tôi sẽ cùng nhóm nghiên cứu Bitlayer và cộng đồng tiếng Trung về BitVM triển khai một chuyên mục chuỗi bài có tên “Tiến gần hơn tới BTC”, tập trung dài hạn vào phổ biến kiến thức về các chủ đề trọng điểm như BitVM, OP_CAT và cầu nối chéo chuỗi Bitcoin, nhằm gỡ bỏ sự thần bí xung quanh các công nghệ lớp hai Bitcoin, mở đường cho nhiều người đam mê tiếp cận dễ dàng hơn.
Vài tháng trước, người đứng đầu ZeroSync Robin Linus đã công bố bài viết mang tên "BitVM: Compute Anything on Bitcoin", chính thức giới thiệu khái niệm BitVM, thúc đẩy tiến trình phát triển công nghệ lớp hai Bitcoin. Có thể nói đây là một trong những đổi mới cách mạng nhất trong hệ sinh thái Bitcoin, làm bùng nổ toàn bộ hệ sinh thái lớp hai Bitcoin, thu hút sự tham gia của các dự án nổi bật như Bitlayer, Citrea, BOB, mang lại sức sống mới cho thị trường.
Sau đó, nhiều nhà nghiên cứu hơn tham gia cải tiến BitVM, lần lượt ra mắt các phiên bản kế thừa khác nhau như BitVM1, BitVM2, BitVMX, BitSNARK. Tình hình cụ thể như sau:
-
Bản whitepaper triển khai BitVM do Robin Linus đưa ra ban đầu năm ngoái là dựa trên phương án mạch logic cổng ảo hóa, được gọi là BitVM0;
-
Trong một vài buổi thuyết trình và phỏng vấn sau đó, Robin Linus không chính thức giới thiệu thêm phương án BitVM dựa trên CPU ảo (gọi là BitVM1), tương tự hệ thống bằng chứng gian lận Cannon của Optimism, có thể mô phỏng hiệu ứng của một CPU phổ thông bằng script Bitcoin bên ngoài chuỗi.
-
Robin Linus còn đề xuất BitVM2, một giao thức bằng chứng gian lận từng bước đơn, không cần cấp phép (Permissionless).
-
Các thành viên Rootstock Labs và Fairgate Labs đã công bố whitepaper BitVMX, tương tự BitVM1, họ mong muốn dùng script Bitcoin để mô phỏng hiệu quả của một CPU phổ thông (bên ngoài chuỗi).
Hiện tại, việc xây dựng hệ sinh thái nhà phát triển liên quan BitVM ngày càng rõ ràng, việc cập nhật và hoàn thiện các công cụ phụ trợ cũng đã trở nên rõ rệt. So với năm ngoái, hệ sinh thái BitVM hiện nay đã chuyển từ "ảo ảnh trên không" sang "có thể nhìn thấy mờ mờ", điều này thu hút ngày càng nhiều nhà phát triển và các quỹ VC đổ xô vào hệ sinh thái Bitcoin.
Tuy nhiên, đối với đa số người dùng, việc hiểu các thuật ngữ kỹ thuật liên quan đến BitVM và lớp hai Bitcoin không hề dễ dàng, bởi bạn cần trước tiên nắm vững kiến thức nền tảng liên quan, đặc biệt là script Bitcoin và Taproot. Hiện tại, tài liệu tham khảo sẵn có trên mạng hoặc quá dài dòng lan man, hoặc giải thích chưa thấu đáo khiến người đọc nửa hiểu nửa không. Chúng tôi cam kết giải quyết các vấn đề trên, cố gắng dùng ngôn ngữ rõ ràng nhất có thể để giúp nhiều người hiểu biết về các kiến thức nền tảng của lớp hai Bitcoin, xây dựng nhận thức hệ thống về hệ thống BitVM.
MATT và Cam kết: Tư tưởng nền tảng của BitVM
Đầu tiên, chúng ta cần nhấn mạnh rằng tư tưởng nền tảng của BitVM là MATT - Merkleize All The Things, nghĩa là sử dụng cấu trúc dữ liệu dạng cây Merkle để biểu diễn quá trình thực thi chương trình phức tạp, cố gắng cho phép xác minh gian lận một cách tự nhiên trên Bitcoin.
MATT dù có thể biểu đạt chương trình phức tạp và dấu vết xử lý dữ liệu, nhưng sẽ không trực tiếp đăng tải những dữ liệu này lên chuỗi BTC vì dung lượng dữ liệu rất lớn. Giải pháp dùng MATT chỉ lưu trữ dữ liệu trong cây Merkle bên ngoài chuỗi, chỉ đăng tải phần tóm tắt ở đỉnh cây Merkle (Merkle Root) lên chuỗi. Cây Merkle này chủ yếu chứa ba nội dung cốt lõi:
-
Mã script hợp đồng thông minh
-
Dữ liệu cần thiết cho hợp đồng
-
Dấu vết để lại khi thực thi hợp đồng (ghi lại những thay đổi bộ nhớ, thanh ghi CPU khi hợp đồng thông minh thực thi trên máy ảo EVM...)
(Minh họa sơ đồ cây Merkle đơn giản, Merkle Root được tính toán qua nhiều tầng hash từ 8 đoạn dữ liệu ở đáy hình)
Theo giải pháp MATT, chỉ có Merkle Root kích thước cực nhỏ được lưu trên chuỗi, toàn bộ tập dữ liệu đầy đủ của cây Merkle được lưu bên ngoài chuỗi, điều này sử dụng một tư duy gọi là "cam kết" (commitment). Chúng ta hãy giải thích "cam kết" là gì. Cam kết giống như một tuyên bố cô đọng, có thể coi là "dấu vân tay" nén từ một lượng lớn dữ liệu. Nói chung, người đăng "cam kết" trên chuỗi tuyên bố rằng dữ liệu lưu bên ngoài chuỗi là chính xác, và dữ liệu bên ngoài chuỗi này phải tương ứng với một tuyên bố cô đọng - tức là "cam kết".
Cam kết thường giống như một tuyên bố ngắn gọn, có thể hiểu là "dấu vân tay" nén từ một lượng lớn dữ liệu. Thông thường, người đăng "cam kết" trên chuỗi tuyên bố rằng dữ liệu lưu bên ngoài chuỗi là chính xác, và dữ liệu bên ngoài chuỗi này phải tương ứng với một tuyên bố ngắn gọn - tức là "cam kết".
Trong một số trường hợp, hash dữ liệu có thể đóng vai trò là "cam kết" cho dữ liệu đó, các phương án cam kết khác gồm KZG Commitment hoặc cây Merkle. Trong giao thức bằng chứng gian lận quen thuộc ở Layer2, người đăng dữ liệu sẽ công bố toàn bộ tập dữ liệu bên ngoài chuỗi, và đăng "cam kết" của tập dữ liệu đó lên chuỗi. Nếu ai đó phát hiện dữ liệu bên ngoài chuỗi không hợp lệ, họ sẽ thách thức "cam kết" dữ liệu trên chuỗi.
Thông qua "cam kết" (Commitment), lớp hai có thể nén một lượng lớn dữ liệu, chỉ đăng "cam kết" của nó lên chuỗi Bitcoin. Tất nhiên, cần đảm bảo tập dữ liệu đầy đủ bên ngoài chuỗi có thể bị quan sát từ bên ngoài.
Hiện tại, các giải pháp BitVM lớn 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 phân tích chương trình phức tạp thành nhiều mã vận hành cơ bản (biên dịch), sau đó ghi lại dấu vết khi thực thi các mã vận hành này (nói trắng ra là bản ghi thay đổi trạng thái toàn bộ khi một chương trình chạy trên CPU và bộ nhớ, gọi là Trace). Sau đó, tổ chức tất cả dữ liệu bao gồm Trace và mã vận hành thành một tập dữ liệu, rồi tạo "cam kết" cho tập dữ liệu này.
Cụ thể, phương án cam kết có thể có nhiều hình thức: cây Merkle, PIOPs (các thuật toán ZK khác nhau), hàm băm
2. Đặt cược tài sản và ký trước: Người đăng dữ liệu và người xác minh cần khóa một lượng tài sản nhất định trên chuỗi dưới dạng chữ ký trước, kèm theo các điều kiện ràng buộc. Các điều kiện này sẽ được kích hoạt tùy theo tình huống xảy ra trong tương lai; nếu người đăng dữ liệu gian lận, người xác minh có thể nộp bằng chứng để lấy đi tài sản của họ.
3. Đăng dữ liệu và cam kết: Người đăng dữ liệu đăng cam kết lên chuỗi, đăng tập dữ liệu đầy đủ bên ngoài chuỗi, người xác minh kiểm tra dữ liệu để tìm lỗi. Mỗi phần dữ liệu bên ngoài chuỗi đều có liên kết với cam kết trên chuỗi.
4. Thách thức và xử phạt: Ngay khi người xác minh phát hiện dữ liệu do người đăng cung cấp có sai sót, họ sẽ lấy 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 cực nhỏ), đâ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 đăng thực sự cung cấp dữ liệu không hợp lệ bên ngoài chuỗi, tài sản của họ sẽ bị người thách thức lấy đi.
Tóm lại, người đăng dữ liệu Alice công khai tất cả dấu vết sinh ra trong quá trình thực thi giao dịch lớp hai bên ngoài chuỗi, đăng 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 sai, trước tiên phải chứng minh phần dữ liệu đó liên kết với cam kết trên chuỗi, tức là chứng minh dữ liệu này do chính Alice công bố, sau đó yêu cầu nút Bitcoin xác định phần dữ liệu đó có lỗi.
Giờ đây chúng ta đã hiểu đại khái tư tưởng tổng thể của BitVM, mọi biến thể BitVM cơ bản đều không thoát khỏi khuôn mẫu trên. Tiếp theo, hãy bắt đầu học và hiểu các công nghệ quan trọng được dùng trong quy trình trên, khởi đầu từ script Bitcoin cơ bản, Taproot và chữ ký trước.
Script Bitcoin là gì?
Kiến thức liên quan Bitcoin khó hiểu hơn Ethereum, ngay cả hành vi chuyển tiền cơ bản cũng liên quan đến một loạt khái niệm như UTXO (đầu ra giao dịch chưa tiêu dùng), script khóa (còn gọi là ScriptPubKey) và script mở khóa (còn gọi là ScriptSig). Trước tiên, chúng ta sẽ giải thích các khái niệm chính này.
(Một ví dụ mã script Bitcoin, gồm các mã vận hành thấp cấp hơn ngôn ngữ lập trình cao cấp)
Phương thức biểu đạt tài sản Ethereum giống Alipay hay WeChat, mỗi lần chuyển tiền chỉ cần cộng trừ số dư tài khoản, phương pháp này lấy tài khoản làm trung tâm, số dư tài sản chỉ là con số gắn với tên tài khoản; phương thức biểu đạt tài sản Bitcoin giống vàng, mỗi miếng vàng (UTXO) đều đánh dấu chủ nhân, chuyển tiền thực chất là hủy UTXO cũ, tạo UTXO mới (chủ nhân thay đổi).
UTXO Bitcoin chứa hai trường dữ liệu then chốt:
-
Số lượng, đơn vị là "satoshi" (100 triệu satoshi = 1 BTC);
-
Script khóa, còn gọi là "script khóa công khai (ScriptPubKey)", định nghĩa điều kiện mở khóa UTXO.
Lưu ý rằng, sở hữu UTXO Bitcoin được biểu đạt qua script khóa, nếu bạn muốn chuyển UTXO của mình cho Sam, bạn có thể khởi tạo giao dịch hủy UTXO cụ thể của mình, đặt điều kiện mở khóa UTXO mới tạo là "chỉ Sam mới mở khóa được".
Sau đó, nếu Sam muốn sử dụng Bitcoin này, cần nộp một script mở khóa (ScriptSig), trong đó Sam phải trình chữ ký số của mình, chứng minh mình là Sam. Nếu script mở khóa phù hợp với script khóa nói trên, Sam có thể mở khóa và chuyển Bitcoin cho người khác.
(Script mở khóa phải khớp với script khóa mới được)
Xét về hình thức biểu đạt, mỗi giao dịch trên chuỗi Bitcoin tương ứng với nhiều Input và Output, mỗi Input cần khai báo UTXO muốn mở khóa, nộp script mở khóa, mở khóa và hủy UTXO đó; Output sẽ hiển thị thông tin UTXO mới tạo, công bố nội dung script khóa.
Ví dụ, trong một giao dịch Input, bạn chứng minh mình là Sam, mở khóa nhiều UTXO người khác gửi cho bạn, hủy thống nhất, sau đó tạo nhiều UTXO mới và tuyên bố để xxx mở khóa trong tương lai.
Cụ thể, trong dữ liệu Input giao dịch, bạn cần khai báo muốn mở khóa UTXO nào, chỉ ra "vị trí lưu trữ" dữ liệu UTXO này. Lưu ý, Bitcoin và Ethereum hoàn toàn khác nhau: Ethereum cung cấp hai loại tài khoản là tài khoản hợp đồng và EOA để lưu dữ liệu, số dư tài sản được ghi dưới dạng con số gắn với tên tài khoản hợp đồng hoặc EOA, tập trung trong cơ sở dữ liệu gọi là "trạng thái thế giới", khi chuyển tiền trực tiếp sửa đổi tài khoản cụ thể trong "trạng thái thế giới", thuận tiện định vị vị trí lưu trữ dữ liệu;
Bitcoin không có thiết kế trạng thái thế giới, dữ liệu tài sản được lưu rải rác trong các khối trước đó (là dữ liệu UTXO chưa mở khóa, được lưu riêng trong OutPut mỗi giao dịch).
Nếu bạn muốn mở khóa một UTXO, cần nói rõ thông tin UTXO đó tồn tại trong Output giao dịch nào trước đây, xuất ID giao dịch đó (chính là hash), để nút Bitcoin tìm trong lịch sử. Nếu muốn tra số dư Bitcoin địa chỉ nào đó, cần duyệt từ đầu tất cả khối, tìm UTXO chưa mở khóa liên quan đến địa chỉ xx.
Khi dùng ví Bitcoin hàng ngày, có thể nhanh chóng kiểm tra số dư Bitcoin địa chỉ nào đó, phần lớn là vì dịch vụ ví tự quét khối, xây dựng chỉ mục cho tất cả địa chỉ, giúp chúng ta truy vấn nhanh chóng.
(Khi bạn tạo giao dịch tuyên bố tặng UTXO cho người khác, cần đánh dấu vị trí lịch sử Bitcoin của UTXO đó dựa trên hash/ID giao dịch mà UTXO thuộc về)
Thú vị là, kết quả giao dịch Bitcoin được tính toán hoàn tất bên ngoài chuỗi, khi người dùng tạo giao dịch trên thiết bị cá nhân, cần trực tiếp tạo toàn bộ Input và Output, tương đương tính toán xong kết quả giao dịch. Giao dịch được phát sóng mạng Bitcoin, sau khi nút xác minh mới lên chuỗi. Mô hình "tính toán bên ngoài chuỗi – xác minh trên chuỗi" này hoàn toàn khác Ethereum, nơi bạn chỉ cần cung cấp tham số đầu vào giao dịch, kết quả do nút Ethereum tính toán và xuất ra.
Ngoài ra, script khóa UTXO (Locking Script) có thể tùy chỉnh, bạn có thể đặt UTXO là "chủ nhân địa chỉ Bitcoin cụ thể mới mở khóa được", chủ nhân đị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-Script-Hash (P2SH), bạn có thể thêm Script Hash vào script khóa UTXO, ai nộp đúng script gốc tương ứng hash này và thỏa mãn điều kiện cài đặt sẵn trong script gốc đó thì có thể mở khóa UTXO. Taproot script mà BitVM dựa vào sử dụng đặc tính tương tự P2SH.
Script Bitcoin được kích hoạt như thế nào?
Ở đây chúng ta 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 mới có thể hiểu Taproot và BitVM phức tạp hơn. P2PKH viết đầy là "Pay to Public Key Hash", trong giải pháp này, script khóa UTXO đặt một hash khóa công khai, khi mở khóa cần nộp khóa công khai tương ứng hash này, tư duy này cơ bản giống chuyển tiền Bitcoin thông thường.
Lúc này, nút Bitcoin cần xác định khóa công khai trong script mở khóa khớp với hash khóa công khai chỉ định trong script khóa, nói cách khác, cần xác định "chìa khóa" do người mở khóa nộp khớp với "khóa" cài đặt sẵn trong UTXO.
Nói sâu hơn, trong giải pháp P2PKH, sau khi nút Bitcoin nhận giao dịch, sẽ ghép script mở khóa ScriptSig do người dùng cung cấp với script khóa ScriptPubkey của UTXO cần mở khóa, đặt vào môi trường thực thi script BTC để thực thi. Hình dưới minh họa kết quả ghép trước khi thực thi:
Người đọc có thể chưa hiểu môi trường thực thi script BTC, ở đây chúng tôi giới thiệu sơ lược. Trước tiên, script BTC gồm hai yếu tố:
Dữ liệu và mã vận hành. Dữ liệu và mã vận hành này theo thứ tự trái sang phải lần lượt được đẩy vào ngăn xếp (stack) để thực thi theo logic chỉ định, thu được kết quả cuối cùng (không mở rộng về stack, bạn đọc tự hỏi Chatgpt).
Lấy hình trên làm ví dụ, bên trái là script mở khóa ScriptSig do một người tải lên, chứa chữ ký số và khóa công khai của anh ta, còn bên phải script khóa ScriptPubkey chứa một đoạn mã vận hành và dữ liệu do người tạo UTXO thiết lập khi tạo UTXO (ở đây không cần hiểu ý nghĩa từng mã vận hành, hiểu đại khái là được).
Các mã vận hành như DUP, HASH160, EQUALVERIFY trong script khóa bên phải hình trên chịu trách nhiệm lấy hash khóa công khai trong script mở khóa bên trái, so sánh với hash khóa công khai cài đặt sẵn trong script khóa, nếu bằng nhau thì chứng tỏ khóa công khai tải lên trong script mở khóa khớp với hash khóa công khai trong script khóa, như vậy vượt qua kiểm tra đầu tiên.
Tuy nhiên, có vấn đề: nội dung script khóa UTXO thực tế được công khai trên chuỗi, ai cũng có thể quan sát hash khóa công khai chứa trong đó, ai cũng có thể tải khóa công khai tương ứng lên, giả danh là người được "chọn". Vì vậy, sau khi xác minh khóa công khai và hash khóa công khai, cần xác minh người khởi tạo giao dịch có thực sự là người kiểm soát khóa công khai đó hay không, cần xác minh chữ ký số. Mã vận hành CHECKSIG trong script khóa chịu trách nhiệm xác minh chữ ký số.
Tóm lại, trong giải pháp P2PKH, người khởi tạo giao dịch nộp trong script mở khóa chứa khóa công khai và chữ ký số, khóa công khai phải khớp với hash khóa công khai chỉ định trong script khóa, và chữ ký số giao dịch phải đúng, thỏa mãn các điều kiện này mới có thể mở khóa UTXO thành công.
(Hình này động: sơ đồ script mở khóa Bitcoin theo giải pháp P2PKH
Nguồn: https://learnmeabitcoin.com/technical/script )
Tất nhiên, mạng Bitcoin hỗ trợ nhiều loại giao dịch, không chỉ Pay to public key/public key hash, còn có P2SH (Pay to Script hash)... tùy thuộc hoàn toàn vào script khóa được tùy chỉnh khi tạo UTXO.
Ở đây cần lưu ý rằng, theo giải pháp P2SH, script khóa có thể cài đặt sẵn một Script Hash, còn script mở khóa cần nộp đầy đủ nội dung script tương ứng Script Hash. Nút Bitcoin có thể thực thi đoạn script này, nếu script này định nghĩa logic xác minh đa chữ ký, có thể tạo ví đa chữ ký trên chuỗi Bitcoin.
Tất nhiên, theo giải pháp P2SH, người tạo UTXO cần cho người mở khóa UTXO trong tương lai biết trước nội dung script tương ứng Script Hash, chỉ cần hai bên đều biết nội dung script này, chúng ta có thể thực hiện logic nghiệp vụ phức tạp hơn đa chữ ký.
Cần nói rõ một điểm: chuỗi Bitcoin (khối) không ghi trực tiếp UTXO nào liên kết với địa chỉ nào, nó chỉ ghi UTXO có thể được mở khóa bởi hash khóa công khai/hash script nào, nhưng chúng ta có thể nhanh chóng tính ra địa chỉ tương ứng từ hash khóa công khai/hash script (thứ giống mã loạn hiện trên giao diện ví).
Lý do chúng ta có thể thấy trên trình khám phá khối và giao diện ví rằng địa chỉ xx có số Bitcoin xx là vì các dự án trình khám phá khối và ví đã giúp bạn phân tích dữ liệu này, quét tất cả khối và dựa trên hash khóa công khai/hash script tuyên bố trong script khóa để tính ra "địa chỉ" tương ứng, sau đó hiển thị số Bitcoin địa chỉ xx có.
Witness tách biệt (SegWit) và Witness
Khi hiểu rõ tư duy P2SH, chúng ta sẽ tiến gần hơn đến Taproot mà BitVM dựa vào. Nhưng trước đó, cần hiểu một khái niệm quan trọng: Witness và SegWit.
Nhìn lại script mở khóa, script khóa và quy trình mở khóa UTXO vừa trình bày, sẽ phát hiện một vấn đề: chữ ký số giao dịch nằm trong script mở khóa, khi tạo chữ ký không thể bao gồm script mở khóa (tham số tạo chữ ký không thể chứa chữ ký bản thân), do đó chữ ký số chỉ có thể bao phủ phần ngoài script mở khóa, tức là chỉ liên kết với phần xương sống dữ liệu giao dịch, không thể bao phủ toàn bộ dữ liệu giao dịch.
Như vậy, dù script mở khóa bị kẻ trung gian can thiệp nhẹ cũng không ảnh hưởng kết quả xác minh chữ ký. Ví dụ, nút Bitcoin hay mỏ đào có thể nhét dữ liệu khác vào script mở khóa giao dịch, miễn không ảnh hưởng xác minh chữ ký và kết quả giao dịch, khiến dữ liệu giao dịch thay đổi nhẹ, cuối cùng hash giao dịch/ID giao dịch cũng thay đổi. Đây gọi là vấn đề thay đổi giao dịch (transaction malleability).
Tác hại là, nếu bạn định liên tục khởi tạo nhiều giao dịch, có quan hệ phụ thuộc thứ tự (ví dụ, giao dịch 3 trích dẫn đầu ra giao dịch 2, giao dịch 2 trích dẫn đầu ra giao dịch 1), thì giao dịch sau chắc chắn phải trích dẫn ID (hash) giao dịch trước, mỏ đào hay nút Bitcoin bất kỳ có thể điều chỉnh nhẹ nội dung script mở khóa, khiến hash giao dịch sau khi lên chuỗi khác với dự kiến của bạn, dẫn đến nhiều giao dịch có liên hệ thứ tự bạn tạo trước đó bị vô hiệu.
Thực tế, trong giải pháp cầu DLC và BitVM2, sẽ xây dựng hàng loạt giao dịch có liên hệ thứ tự, nên cảnh huống nói trên không hiếm.
Tóm lại, vấn đề thay đổi giao dịch là do ID/hash giao dịch khi tính toán bao gồm dữ liệu script mở khóa, trong khi nút Bitcoin hay trung gian có thể điều chỉnh nhẹ nội dung script mở khóa, dẫn đến ID giao dịch khác với dự kiến của người dùng. Thực ra đây là gánh nặng lịch sử do thiết kế Bitcoin thời kỳ đầu chưa cân nhắc kỹ.
Sau này nâng cấp SegWit (Witness tách biệt) thực chất là tách biệt hoàn toàn ID giao dịch và script mở khóa, khi tính toán hash giao dịch không cần bao gồm dữ liệu script mở khóa. UTXO tuân thủ nâng cấp SegWit, script khóa mặc định đặt một mã vận hành gọi là "OP_0" ở vị trí đầu tiên làm dấu hiệu; còn script mở khóa tương ứng đổi tên từ SigScript thành Witness (chứng cứ).
Sau khi tuân thủ quy tắc SegWit, vấn đề thay đổi giao dịch được giải quyết thỏa đáng, bạn không cần lo dữ liệu giao dịch gửi đến nút Bitcoin bị điều chỉnh nhẹ. Tất nhiên, không cần nghĩ quá phức tạp, chức năng P2WSH không khác bản chất P2SH đã nói, bạn có thể cài đặt sẵn một script hash trong script khóa UTXO, đợi người nộp script mở khóa nộp nội dung script tương ứng hash lên chuỗi và thực thi.
Nhưng nếu nội dung script bạn muốn thực hiện quá lớn, chứa quá nhiều mã, không thể nộp script đầy đủ lên chuỗi Bitcoin bằng phương pháp thông thường (mỗi khối có giới hạn kích thước). Vậy phải làm sao? Lúc này cần tận dụng Taproot để tinh giản nội dung script lên chuỗi, và BitVM chính là giải pháp phức tạp xây dựng dựa trên Taproot.
Trong bài viết tiếp theo của chuỗi "Tiến gần hơn tới BTC", chúng tôi sẽ phổ biến chi tiết các công nghệ phức tạp hơn liên quan BitVM như Taproot, chữ ký trước... kính mời quý vị đón chờ!
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@godrealmx
