Chuyển nhượng ngoài chuỗi: Hành trình phát triển của các giao thức tài sản Bitcoin
Tuyển chọn TechFlowTuyển chọn TechFlow
Chuyển nhượng ngoài chuỗi: Hành trình phát triển của các giao thức tài sản Bitcoin
Bài viết này hy vọng thông qua việc điểm lại các giao thức tài sản từng xuất hiện trong lịch sử BTC, tìm kiếm hướng phát triển tương lai của các giao thức tài sản trên BTC.
Chuyên sâu báo cáo Web3Lời nói đầu
Việc phát hành tài sản dựa trên BTC luôn là chủ đề nóng. Từ Colored Coins xuất hiện từ năm 2011 đến giao thức Ordinal gần đây thu hút sự chú ý, cộng đồng BTC liên tục đón nhận những người chơi và sự đồng thuận mới, nhưng số lượng dự án tồn tại lâu dài lại rất ít. Tuy nhiên, với việc Lightling Labs đầy tham vọng công bố kế hoạch xây dựng Stable Coin trên Taproot Assets, và Tether cũng tuyên bố sẽ chọn RGB để đúc USDT trực tiếp trên lớp một của Bitcoin.
Điều này cho thấy OmniLayer (Mastercoin), từng là dự án lớn nhất trong hệ sinh thái BTC, nay không còn giữ vị thế đó nữa. Giao thức tài sản xác minh khách hàng (CSV) bắt đầu bước vào tầm ngắm của cộng đồng. Khác biệt lớn so với các giao thức tài sản truyền thống trên BTC là chúng mang theo thuộc tính mở rộng quy mô cho BTC. Nhưng trước vô số giao thức tài sản như vậy trong hệ sinh thái BTC, người ta không khỏi đặt câu hỏi: điểm khác biệt giữa chúng nằm ở đâu? Làm sao để lựa chọn và tìm ra cơ hội cho bản thân giữa muôn vàn giao thức? Bài viết này mong muốn cùng bạn đọc nhìn lại các giao thức tài sản từng xuất hiện trong lịch sử BTC, đồng thời khám phá tương lai phát triển của giao thức tài sản BTC.
Tiền được "nhuộm màu": Colored Coins
Ý tưởng về Colored Coins lần đầu tiên được Yoni Assia – hiện là CEO của eToro – đề xuất vào ngày 27 tháng 3 năm 2012 qua bài viết có tên bitcoin 2.X (aka Colored bitcoin). Bài viết cho rằng Bitcoin như một công nghệ nền tảng là hoàn hảo, giống như HTTP là nền tảng của mạng internet. Vì vậy, Colored Coins được thiết kế nhằm tận dụng lại cơ sở hạ tầng của BTC.
Yoni Assia hy vọng thông qua cách thức này, có thể tạo ra nền kinh tế BTC 2.0 – bất kỳ cộng đồng nào cũng có thể dùng phương pháp này để phát hành nhiều loại tiền tệ khác nhau. Việc sử dụng Bitcoin như một công nghệ nền tảng để thanh toán và ngăn chặn chi tiêu kép là một ý tưởng cực kỳ táo bạo vào thời điểm đó.
Colored Coins là một giao thức phát hành tài sản dựa trên Bitcoin, hoạt động bằng cách “nhuộm màu” một lượng nhất định Bitcoin để biểu thị cho tài sản đó. Những Bitcoin đã được đánh dấu này vẫn giữ chức năng như Bitcoin thông thường, nhưng đồng thời đại diện cho một tài sản hoặc giá trị khác. Vậy làm thế nào để hiện thực hóa ý tưởng này trên Bitcoin?
Vào ngày 3 tháng 7 năm 2014, ChromaWay đã phát triển giao thức nhuộm màu dựa trên đơn đặt hàng tăng cường (EPOBC), giúp đơn giản hóa quá trình tạo ra Colored Coins cho các nhà phát triển – đây cũng là giao thức đầu tiên sử dụng chức năng OP_RETURN của Bitcoin Script.
Hiệu quả cuối cùng đạt được như hình dưới đây:
Cách hiện thực này rất đơn giản, nhưng cũng kéo theo nhiều vấn đề:
1. Token đồng nhất và giá trị ràng buộc tối thiểu
Nếu trong giao dịch khởi nguyên (genesis transaction), một Colored Coin được gắn 1000 satoshi, thì đơn vị chia nhỏ tối thiểu của nó là 1 satoshi. Điều này có nghĩa tài sản hoặc token này có thể được chia thành tối đa 1000 phần (tuy chỉ là lý thuyết; để tránh tấn công bụi bẩn (dust attack), ví dụ trước đây mỗi satoshi thường cố định ở mức 546 satoshi, sau này với Ordinal thì cao hơn).
2. Vấn đề xác minh
Để xác định tính xác thực và quyền sở hữu của Colored Coin, cần truy vết và xác minh toàn bộ chuỗi từ giao dịch khởi nguyên đến UTXO hiện tại. Do đó, cần phát triển riêng ví, nút toàn phần (full node), thậm chí cả trình duyệt.
3. Rủi ro tiềm ẩn bị thợ đào kiểm duyệt
Do đặc điểm dễ nhận biết của ColoredTransaction – cụ thể là ghi metadata vào output – điều này mở ra khả năng bị thợ đào kiểm duyệt.
Thực chất, Colored Coins là một hệ thống theo dõi tài sản, sử dụng các quy tắc xác thực của Bitcoin để theo dõi chuyển nhượng tài sản. Tuy nhiên, để chứng minh một output (txout) cụ thể đại diện cho một tài sản nhất định, cần cung cấp toàn bộ chuỗi chuyển nhượng từ nguồn gốc đến hiện tại. Điều này có nghĩa việc xác minh tính hợp lệ của một giao dịch có thể yêu cầu một chuỗi chứng minh rất dài. Để giải quyết vấn đề này, trước đây đã có người đề xuất OP_CHECKCOLORVERIFY nhằm hỗ trợ xác minh trực tiếp tính đúng đắn của giao dịch Colored Coins trên BTC, tuy nhiên đề xuất này chưa từng được thông qua.
ICO đầu tiên trong ngành mật mã: Mastercoin
Khái niệm ban đầu về Mastercoin do J.R. Willett đưa ra. Năm 2012, ông công bố một bản whitepaper có tên "The Second Bitcoin Whitepaper", mô tả khái niệm tạo ra tài sản hoặc token mới trên blockchain Bitcoin hiện tại – sau này được gọi là “MasterCoin”, và đổi tên thành Omni Layer về sau.
Dự án Mastercoin đã tổ chức một đợt bán token sơ khai (ngày nay gọi là ICO hoặc Initial Coin Offering) vào năm 2013, huy động thành công hàng triệu đô la Mỹ – được coi là ICO đầu tiên trong lịch sử. Ứng dụng nổi tiếng nhất của Mastercoin chính là Tether (USDT), stablecoin fiat nổi bật nhất, ban đầu được phát hành trên Omni Layer.
Thực ra, ý tưởng Mastercoin xuất hiện sớm hơn Colored Coins. Lý do trình bày ở vị trí thứ hai là vì so với Colored Coins, Mastercoin là một giải pháp nặng nề hơn. Mastercoin xây dựng một lớp nút hoàn chỉnh, cung cấp các chức năng phức tạp hơn (ví dụ như hợp đồng thông minh), trong khi Colored Coins đơn giản và trực tiếp hơn, tập trung chủ yếu vào việc “nhuộm màu” hay đánh dấu UTXO của Bitcoin để đại diện cho tài sản khác.
Khác biệt lớn nhất với Colored Coins là Mastercoin chỉ công bố các hành vi giao dịch khác nhau trên chuỗi, chứ không ghi lại thông tin tài sản liên quan. Trong các nút Mastercoin, một cơ sở dữ liệu trạng thái mô hình được duy trì bằng cách quét khối Bitcoin, lưu trữ ở nút bên ngoài chuỗi.
So với Colored Coins, Mastercoin có thể thực hiện logic phức tạp hơn. Đồng thời, vì không ghi trạng thái và xác minh trên chuỗi, nên các giao dịch không cần phải liên tục (không cần nhuộm màu liên tục).
Tuy nhiên, để hiện thực hóa logic phức tạp của Mastercoin, người dùng cần tin tưởng vào trạng thái trong cơ sở dữ liệu ngoài chuỗi của nút, hoặc tự vận hành nút Omni Layer để xác minh.
Tổng kết
Sự khác biệt lớn nhất giữa Mastercoin và Colored Coins là Mastercoin không chọn lưu trữ mọi dữ liệu giao thức cần thiết trên chuỗi, mà ký sinh vào hệ thống đồng thuận của BTC để thực hiện việc công bố và sắp xếp giao dịch, rồi duy trì trạng thái trong cơ sở dữ liệu ngoài chuỗi.
Theo thông tin từ OmniBolt: Omni Layer đang đề xuất giao thức tài sản mới UBA (UTXO Based Asset) cho Tether, sẽ tận dụng nâng cấp Taproot để mã hóa thông tin tài sản vào tapleaf, từ đó thực hiện các chức năng như thanh toán có điều kiện. Đồng thời, OmniBolt đang tích hợp Stark vào cơ sở hạ tầng mạng lưới Lightning của OmniLayer.
Tư tưởng Xác minh Khách hàng (Client Side Validation)
Nếu muốn hiểu khái niệm xác minh khách hàng, ta cần quay lại năm thứ hai sau khi Colored Coins và Mastercoin ra đời – tức là năm 2013. Peter Todd đã công bố bài viết: Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation. Dù tên bài viết dường như không liên quan đến xác minh khách hàng, nhưng nếu đọc kỹ sẽ thấy đây chính là tư tưởng khởi nguyên đầu tiên về Client Side Validation.
Peter Todd là một nhà nghiên cứu sớm về Bitcoin và mật mã học, luôn tìm kiếm phương pháp làm cho Bitcoin hoạt động hiệu quả hơn. Ông đã phát triển một khái niệm xác minh khách hàng phức tạp hơn dựa trên khái niệm dấu thời gian. Ngoài ra, ông cũng đề xuất khái niệm “single use seal” (niêm phong dùng một lần), sẽ được nhắc đến sau.
Bây giờ, hãy theo tư tưởng của Peter Todd, trước hết cần hiểu BTC thực sự giải quyết vấn đề gì. Theo Peter Todd, BTC giải quyết ba vấn đề:
-
Bằng chứng công bố (Proof-of-publication)
Bản chất của bằng chứng công bố là giải quyết vấn đề chi tiêu kép. Ví dụ Alice muốn chuyển một số Bitcoin cho Bob, dù đã ký giao dịch chuyển tiền cho Bob, nhưng về mặt vật lý Bob không nhất thiết biết giao dịch này tồn tại. Vì vậy, chúng ta cần một nơi công cộng để công bố giao dịch, và mọi người có thể tra cứu giao dịch từ đó.
-
Xếp thứ tự giao dịch (Order consensus)
Trong hệ thống máy tính, không tồn tại thời gian vật lý mà chúng ta cảm nhận. Trong hệ thống phân tán, thời gian này thường là đồng hồ phân tán lamport, đồng hồ này không đo lường thời gian vật lý, mà dùng để sắp xếp thứ tự giao dịch.
-
Xác minh giao dịch (Validation) (tùy chọn)
Xác minh trên BTC là về chữ ký và xác minh số tiền chuyển BTC. Tuy nhiên, Peter Todd cho rằng việc xác minh này đối với việc xây dựng hệ thống token trên BTC là không cần thiết, chỉ là một tùy chọn tối ưu.
Đến đây, bạn hẳn đã nghĩ đến OmniLayer vừa nhắc tới. Bản thân OmniLayer không giao việc tính toán trạng thái và xác minh cho BTC, nhưng vẫn tái sử dụng độ an toàn của BTC. Colored Coins thì giao việc theo dõi trạng thái cho BTC. Sự tồn tại của cả hai đã chứng minh rằng việc xác minh không nhất thiết phải xảy ra trên chuỗi.
Làm sao để xác minh giao dịch hiệu quả với Client Side Validation?
Trước hết, hãy xem những gì cần được xác minh:
-
Trạng thái (xác minh logic giao dịch)
-
TxIn đầu vào có hợp lệ không (ngăn chi tiêu kép)
Rõ ràng là tài sản được đăng trên BTC, mỗi giao dịch đều cần kiểm tra toàn bộ lịch sử giao dịch liên quan, để đảm bảo đầu vào tham chiếu chưa bị tiêu dùng và trạng thái là chính xác. Điều này rất phi lý, vậy làm sao cải thiện?
Peter Todd cho rằng, ta có thể đơn giản hóa quá trình này bằng cách thay đổi trọng tâm xác minh. Thay vì xác nhận một output chưa bị chi tiêu kép, phương pháp này tập trung vào việc xác nhận đầu vào giao dịch đã được công bố và không xung đột với đầu vào khác. Bằng cách sắp xếp đầu vào trong mỗi khối và sử dụng cây Merkle, có thể xác minh hiệu quả hơn, vì mỗi lần xác minh chỉ cần một phần nhỏ dữ liệu, thay vì toàn bộ lịch sử trên chuỗi của đầu vào đó.
Cấu trúc commitment tree do Peter Todd đề xuất như sau:
CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CT= xIn
Nhưng làm thế nào để lưu trữ commitment tree như vậy trên chuỗi? Đây là lúc ta giới thiệu khái niệm niêm phong dùng một lần (single use seal).
Niêm phong dùng một lần (Single Use Seal)
Single use seal là một trong những khái niệm cốt lõi để hiểu xác minh khách hàng, tương tự như niêm phong vật lý dùng một lần để bảo vệ container vận tải trong thế giới thực. Single use seal là một đối tượng độc đáo, có thể đóng kín chính xác một lần trên một thông điệp. Nói ngắn gọn, niêm phong dùng một lần là một cơ chế trừu tượng để ngăn chặn chi tiêu kép.
Với SealProtocol, có ba yếu tố và hai hành động.
Yếu tố cơ bản:
-
l: seal, tức là niêm phong
-
m: message, thông điệp
-
w: witness, nhân chứng
Hành động cơ bản: có hai thao tác cơ bản:
-
Close(l,m) → w: Đóng niêm phong l trên thông điệp m, tạo ra một nhân chứng w.
-
Verify(l,w,m) → bool: Xác minh niêm phong l đã được đóng trên thông điệp m hay chưa.
Về mặt an ninh, Seal dùng một lần phải đảm bảo kẻ tấn công không thể tìm ra hai thông điệp khác nhau m1 và m2 sao cho hàm Verify trả về true với cùng một niêm phong.
Trước hết, niêm phong dùng một lần (Single-Use Seal) là một khái niệm, đảm bảo một loại tài sản hoặc dữ liệu chỉ được sử dụng hoặc khóa một lần. Trong môi trường Bitcoin, điều này thường có nghĩa là một UTXO (đầu ra giao dịch chưa dùng) chỉ có thể được tiêu dùng một lần. Do đó, đầu ra giao dịch Bitcoin có thể được xem như một niêm phong dùng một lần, và khi đầu ra này được dùng làm đầu vào cho giao dịch khác, thì niêm phong đó bị “phá vỡ” hoặc “sử dụng”.
Đối với tài sản CSV trên BTC, chính Bitcoin đóng vai trò là "nhân chứng" (witness) cho niêm phong dùng một lần. Bởi vì, để xác minh một giao dịch Bitcoin, các nút phải kiểm tra xem mỗi đầu vào của giao dịch có tham chiếu đến một UTXO hợp lệ và chưa tiêu hay không. Nếu một giao dịch cố gắng chi tiêu kép một UTXO đã bị sử dụng, thì quy tắc đồng thuận Bitcoin và các nút trung thực trên toàn mạng sẽ từ chối giao dịch đó.
Có thể đơn giản hơn nữa không?
Single use seal là dùng bất kỳ blockchain nào như một cơ sở dữ liệu, lưu cam kết (commitment) của một thông điệp vào cơ sở dữ liệu đó theo một cách nào đó, đồng thời duy trì trạng thái đã tiêu dùng hoặc chờ tiêu dùng cho nó.
Đúng vậy, đơn giản như vậy đó.
Tóm lại, tài sản xác minh khách hàng có các đặc điểm sau:
-
Lưu trữ dữ liệu ngoài chuỗi: Lịch sử giao dịch, quyền sở hữu và các dữ liệu liên quan khác của tài sản xác minh khách hàng phần lớn được lưu trữ ngoài chuỗi. Điều này giảm đáng kể nhu cầu lưu trữ dữ liệu trên chuỗi và góp phần nâng cao tính riêng tư.
-
Cơ chế cam kết: Mặc dù dữ liệu tài sản được lưu ngoài chuỗi, nhưng các thay đổi hoặc chuyển nhượng dữ liệu đó sẽ được ghi lại trên chuỗi thông qua các cam kết (commitments). Những cam kết này cho phép giao dịch trên chuỗi tham chiếu đến trạng thái ngoài chuỗi, từ đó đảm bảo tính toàn vẹn và không thể sửa đổi của dữ liệu ngoài chuỗi.
-
Nhân chứng trên chuỗi (không nhất thiết là BTC): Mặc dù phần lớn dữ liệu và xác minh diễn ra ngoài chuỗi, nhưng thông qua các cam kết nhúng vào chuỗi, tài sản xác minh khách hàng vẫn có thể tận dụng độ an toàn của chuỗi nền tảng (bằng chứng công bố, sắp xếp giao dịch).
-
Xác minh được thực hiện ở phía khách hàng: Phần lớn công việc xác minh được hoàn tất trên thiết bị người dùng. Điều này có nghĩa là không cần tất cả các nút trong mạng đều tham gia xác minh mọi giao dịch; chỉ những bên liên quan cần xác minh tính hợp lệ của giao dịch.
Đối với người dùng tài sản xác minh khách hàng, cần lưu ý thêm một điểm:
Khi giao dịch và xác minh tài sản xác minh khách hàng ngoài chuỗi, người dùng không chỉ cần xuất trình khóa riêng nắm giữ tài sản, mà còn phải xuất trình bằng chứng đường dẫn merkel đầy đủ tương ứng với tài sản đó.
Người tiên phong Xác minh Khách hàng (CSV): RGB
Khái niệm RGB được Giacomo Zucco – một nhân vật nổi bật trong cộng đồng – đề xuất từ năm 2015. Khi Ethereum lên ngôi và các ICO bắt đầu tràn lan, trước thời điểm đó, nhiều người đã thử làm những điều khác ngoài Bitcoin, như các dự án Mastercoin và Colored Coins.
Giacomo Zucco tỏ ra thất vọng. Ông cho rằng các dự án này đều không sánh bằng Bitcoin, và cho rằng cách thực hiện token trên Bitcoin trước đây đều không phù hợp. Trong quá trình này, ông gặp Peter Todd và bắt đầu say mê ý tưởng về Xác minh Khách hàng (Client-Side-Validation) của Peter Todd, từ đó đưa ra ý tưởng RGB.
Ngoài những đặc điểm đã nêu về tài sản xác minh khách hàng, RGB còn khác biệt lớn so với các giao thức tài sản trước đó ở chỗ bổ sung thêm máy ảo (VM) để thực thi các hợp đồng Turing-complete. Ngoài ra, để đảm bảo tính an toàn của dữ liệu hợp đồng, RGB còn thiết kế Schema và Interface. Schema tương tự như trên Ethereum, khai báo nội dung và chức năng của hợp đồng, trong khi Interface chịu trách nhiệm hiện thực chức năng cụ thể, giống như interface trong ngôn ngữ lập trình.
Các schema hợp đồng này chịu trách nhiệm giới hạn hành vi không vượt quá dự kiến khi VM thực thi, ví dụ như RGB20 và RGB21, lần lượt quản lý các giới hạn nhất định trong giao dịch token đồng nhất và token không đồng nhất.
Cơ chế cam kết PerdersenHash của RGB
Xét về cơ chế cam kết, RGB sử dụng Perdersen Hash. Ưu điểm là có thể cam kết một giá trị mà không tiết lộ nó. Việc dùng hàm băm Pedersen để xây dựng cây Merkle nghĩa là bạn có thể tạo ra một cây Merkle bảo vệ quyền riêng tư, ẩn được các giá trị bên trong. Cấu trúc này có thể được dùng trong một số giao thức bảo vệ riêng tư nhất định, như các dự án tiền mật mã ẩn danh. Tuy nhiên, có lẽ không phù hợp với tài sản CSV, điều này sẽ được đề cập khi so sánh với Taproot Assets.
Thiết kế máy ảo RGB: Simplicity → AluVM
Mục tiêu của RGB không chỉ là hiện thực một giao thức tài sản xác minh khách hàng, mà còn hướng tới việc mở rộng sang máy ảo Turing-complete và lập trình hợp đồng. Trong thiết kế RGB ban đầu, nó tuyên bố dùng một ngôn ngữ lập trình tên là Simplicity, có đặc điểm là khi thực thi biểu thức sẽ tạo ra một bằng chứng thực thi, và dễ dàng hơn trong việc xác minh hình thức (tránh lỗi). Tuy nhiên, việc phát triển ngôn ngữ này không lý tưởng, cuối cùng rơi vào bế tắc. Điều này trực tiếp khiến toàn bộ giao thức RGB khó ra mắt. Cuối cùng, RGB chuyển sang dùng AluVM – một máy ảo do Maxim phát triển, với mục tiêu tránh mọi hành vi không xác định, tương tự như Simplicity ban đầu. AluVM mới được cho là trong tương lai sẽ dùng một ngôn ngữ lập trình tên là Contractum thay thế Rust hiện tại.
Hướng mở rộng lớp 2 cho RGB: Mạng lưới Lightning hay sidechain?
Tài sản xác minh khách hàng không thể đảm bảo an toàn giao dịch liên tục ngoài chuỗi. Bởi vì tài sản xác minh khách hàng vẫn phụ thuộc vào L1 để công bố và sắp xếp giao dịch, nên khi chưa có giải pháp mở rộng L2, tốc độ giao dịch vẫn bị giới hạn bởi tốc độ tạo khối của nút chứng kiến L1. Điều này có nghĩa nếu thực hiện giao dịch RGB trực tiếp trên Bitcoin, trong điều kiện an toàn nghiêm ngặt, khoảng cách thời gian giữa hai giao dịch liên quan có thể lên đến mười phút (thời gian tạo khối BTC). Không nghi ngờ gì, tốc độ giao dịch như vậy hầu như không thể chấp nhận được trong phần lớn trường hợp.
RGB và Mạng lưới Lightning
Nguyên lý mạng lưới Lightning nói đơn giản là hai bên giao dịch ký một loạt hợp đồng (giao dịch cam kết) ngoài chuỗi, nhằm đảm bảo rằng bên bị xâm phạm có thể nộp hợp đồng (giao dịch cam kết) lên BTC để thanh toán, lấy lại tiền và phạt bên kia nếu một bên vi phạm hợp đồng. Nghĩa là mạng lưới Lightning đảm bảo an toàn giao dịch ngoài chuỗi thông qua thiết kế giao thức và lý thuyết trò chơi.
RGB có thể xây dựng cơ sở hạ tầng mạng lưới Lightning riêng bằng cách thiết kế các quy tắc kênh thanh toán phù hợp với chính nó, nhưng mạng lưới Lightning có độ phức tạp cực cao, việc xây dựng cơ sở hạ tầng này không hề dễ dàng. Trong khi đó, Lightnling labs đã dày công nghiên cứu lĩnh vực này nhiều năm, và LND hiện chiếm hơn 90% thị phần trên thị trường.
Sidechain Prime của RGB
LNP-BP, đơn vị duy trì giao thức RGB hiện tại, Maxim đã công bố một đề xuất vào tháng 6 năm 2023 tên là **Prime**, một giải pháp mở rộng cho tài sản xác minh khách hàng, đồng thời phê bình các phương án sidechain và mạng lưới Lightning hiện tại quá phức tạp trong phát triển. Maxim cho biết, ngoài Prime, các phương án mở rộng khác như NUCLEUS (kênh lightning đa nút) và Ark/Enigma (nhà máy kênh) đều cần phát triển hơn hai năm. Nhưng Prime chỉ cần một năm để hoàn thành.
Prime không phải là thiết kế blockchain theo nghĩa truyền thống, mà là một lớp công bố bằng chứng mô-đun dành riêng cho xác minh khách hàng, gồm bốn phần:
-
Dịch vụ dấu thời gian
Xác định nhanh nhất một chuỗi giao dịch trong 10 giây. -
Bằng chứng
Lưu trữ dưới dạng PMT cùng với việc sản xuất và công bố tiêu đề khối. -
Niêm phong dùng một lần
Giao thức niêm phong dùng một lần trừu tượng, chỉ cần đảm bảo chống chi tiêu kép. Khi hiện thực trên Bitcoin, có thể liên kết với UTXO, tương tự thiết kế RGB hiện tại. -
Giao thức hợp đồng thông minh
Hợp đồng phân mảnh – RGB (có thể thay thế)
Từ đó có thể thấy, để giải quyết vấn đề thời gian xác nhận giao dịch RGB, Prime sử dụng dịch vụ dấu thời gian để nhanh chóng xác nhận giao dịch ngoài chuỗi, đồng thời đóng gói giao dịch và ID vào khối. Đồng thời, bằng chứng giao dịch trên prime có thể được hợp nhất thêm qua PMT, rồi neo lên BTC theo kiểu checkpoint.
Giao thức tài sản CSV dựa trên Taproot: Taproot Assets
Taproot Assets là giao thức tài sản CSV dựa trên Taproot, dùng để phát hành tài sản xác minh khách hàng trên blockchain Bitcoin, các tài sản này có thể giao dịch tức thì, dung lượng lớn, phí thấp thông qua mạng lưới Lightning. Cốt lõi của Taproot Assets là tận dụng độ an toàn và ổn định của mạng Bitcoin cùng với tốc độ, khả năng mở rộng và phí thấp của mạng lưới Lightning. Giao thức này do CTO roasbeef của Lightnling labs thiết kế và phát triển. roasbeef có lẽ là người duy nhất trên hành tinh từng trực tiếp đứng đầu việc phát triển cả client Bitcoin (BTCD) và client mạng lưới Lightning (LND), có hiểu biết sâu sắc về BTC.
Giao dịch Taproot chỉ mang theo hash gốc của script tài sản, khiến người quan sát bên ngoài khó nhận biết liệu có liên quan đến Taproot Assets hay không, vì bản thân hash là phổ quát, có thể đại diện cho bất kỳ dữ liệu nào. Với nâng cấp Taproot, Bitcoin đã có khả năng hợp đồng thông minh (TapScript). Trên cơ sở này, việc mã hóa tài sản Taproot Assets tương đương với việc tạo ra định nghĩa token tương tự ERC20 hoặc ERC721. Như vậy, Bitcoin không chỉ có chức năng định nghĩa tài sản, mà còn có khả năng viết hợp đồng thông minh, từ đó đặt nền móng cho cơ sở hạ tầng hợp đồng thông minh token trên Bitcoin.
Cấu trúc mã hóa Taproot Assets như sau:
Hình ảnh từ CTO roasbeef của Lightning Labs
Cũng là giao thức tài sản CSV, Taproot Assets có thiết kế đơn giản hơn nhiều so với RGB. Đồng thời, nó tận dụng tối đa các tiến triển hiện tại trong hệ sinh thái BTC, như nâng cấp Taproot, PSBT, v.v. Điểm khác biệt lớn nhất về khả năng mở rộng ứng dụng giữa Taproot Assets và RGB nằm ở máy ảo thực thi. Taproot Assets sử dụng TaprootScriptVM – giống hệt máy ảo mặc định gốc của BTC. Nhiều nghiên cứu cơ sở hạ tầng gần đây dành cho BTC đều dựa trên TapScript, nhưng do BTC nâng cấp chậm nên chưa thể ứng dụng trong ngắn hạn. Có thể dự đoán Taproot Assets sẽ là cánh đồng thử nghiệm cho những ý tưởng mới mẻ này trong tương lai.
Sự khác biệt giữa Taproot Assets và RGB nằm ở đâu?
1. Kiểm tra giao dịch và tính thân thiện với nút nhẹ
Do hiện thực sum tree, Taproot Assets có hiệu quả và độ an toàn xác minh cao (chỉ cần bằng chứng sở hữu là có thể xác minh trạng thái và thực hiện giao dịch, không cần duyệt toàn bộ lịch sử giao dịch đầu vào). Việc RGB dùng cam kết pedersen khiến nó không thể xác minh hiệu quả tính hợp lệ của đầu vào, dẫn đến việc RGB phải truy ngược lịch sử giao dịch đầu vào – giao dịch càng về sau sẽ càng trở thành gánh nặng nặng nề. Thiết kế Merkle sum cũng giúp Taproot Assets dễ dàng hiện thực xác minh nút nhẹ – điều này trước đây chưa từng tồn tại trong các giao thức tài sản trên BTC.
2. Máy ảo thực thi
Taproot Assets ra đời đúng thời điểm nâng cấp Taproot, sử dụng TaprootScriptVM – bộ máy thực thi script vốn có của Bitcoin sau nâng cấp Taproot, và dùng vPSBT – phiên bản sao chép PSBT của BTC. Điều này có nghĩa một khi cơ chế kênh Lightning của Taproot Assets hoàn thiện, có thể ngay lập tức tái sử dụng toàn bộ cơ sở hạ tầng LND hiện tại, cũng như các sản phẩm trước đây của Lightning labs (LND hiện chiếm hơn 90% thị phần mạng lưới Lightning). Hơn nữa, đề xuất BitVM đang rất hot gần đây cũng dựa trên TaprootScript, về lý thuyết tất cả các cải tiến này cuối cùng đều có thể hỗ trợ Taproot Assets.
Tuy nhiên, đối với RGB, máy ảo và quy tắc xác minh (SCHEMA) của nó tự thành một hệ thống, ở mức độ nào đó là một hệ sinh thái nhỏ khép kín. Việc xây dựng dựa trên RGB chỉ có thể vận hành trong hệ sinh thái riêng, mối liên hệ với hệ sinh thái Bitcoin không chặt chẽ như mọi người tưởng tượng. Lấy ví dụ việc theo kịp nâng cấp Taproot: mối liên hệ duy nhất giữa RGB và nâng cấp Taproot là mã hóa dữ liệu cam kết trên chuỗi vào TapLeaf trong Witness.
3. Hợp đồng thông minh
Trong thiết kế hiện tại của RGB, hợp đồng và máy ảo là phần được nhấn mạnh đậm nét. Tuy nhiên, trong Taproot Assets, hiện tại chưa thấy bóng dáng hợp đồng thông minh. Tuy nhiên, RGB hiện tại vẫn chưa giải thích rõ việc sửa đổi Global State sẽ đồng bộ như thế nào với các phân mảnh hợp đồng độc lập (UTXO). Hơn nữa, cam kết Pedersen chỉ đảm bảo tổng số tài sản, còn việc đảm bảo các trạng thái khác không bị sửa đổi thì hiện tại dường như chưa có lời giải thích rõ ràng. Đối với Taproot Assets, dù thiết kế đơn giản, nhưng hiện tại trạng thái lưu trữ mới chỉ là số dư tài sản, chưa có trạng thái nào khác, do đó chưa thể bàn đến hợp đồng thông minh. Tuy nhiên, theo tiết lộ từ Lightning Labs, sang năm Taproot Assets sẽ tập trung phát triển thiết kế hợp đồng thông minh.
4. Trung tâm đồng bộ
Từ nguyên tắc cơ bản của tài sản xác minh khách hàng đã đề cập trước đó, có thể thấy việc sở hữu Proof và sở hữu khóa riêng đều quan trọng như nhau. Nhưng Proof nếu luôn ở phía client người dùng thì có thể dễ bị mất, vậy phải làm sao? Trong Taproot Assets, chúng ta có thể dùng universe để tránh vấn đề này. Universe là một cấu trúc công khai có thể kiểm toán (MS-SMT), bao phủ một hoặc nhiều tài sản. Khác với cây tài sản Taproot thông thường, Universe không dùng để lưu trữ tài sản Taproot. Thay vào đó, Universe cam kết một tập con lịch sử của một hoặc nhiều tài sản.
Trong RGB, phần này do Storm đảm nhiệm, đồng bộ và lưu trữ dữ liệu bằng chứng ngoài chuỗi theo cách p2p. Tuy nhiên, do lý do lịch sử của đội phát triển RGB, hiện tại các định dạng bằng chứng của các đội này chưa tương thích lẫn nhau. DIBA, nhóm trong hệ sinh thái RGB, hiện cho biết sẽ phát triển carbonado để giải quyết vấn đề này, nhưng tiến độ hiện chưa rõ.
5. Hiện thực kỹ thuật
Tất cả các thư viện mà Taproot Assets sử dụng đều đã được kiểm chứng lâu năm, bởi vì Lightning labs sở hữu client Bitcoin (BTCD), client mạng lưới Lightning (LND), cùng hàng loạt hiện thực wallet lib. Ngược lại, phần lớn thư viện dùng trong hiện thực RGB đến từ định nghĩa riêng, xét theo tiêu chuẩn công nghiệp thì hiện thực RGB vẫn đang ở giai đoạn phòng thí nghiệm.
Nhìn thoáng qua tương lai mở rộng quy mô của BTC
Đến đây, bạn cũng nhận ra rằng các giao thức tài sản xác minh khách hàng đã vượt ra khỏi phạm vi giao thức, bắt đầu tiến về hướng mở rộng quy mô tính toán.
Nhiều người nói rằng tương lai Bitcoin sẽ tồn tại như vàng kỹ thuật số, còn việc xây dựng hệ sinh thái ứng dụng sẽ do các chuỗi khác đảm nhiệm. Nhưng tôi có quan điểm khác. Giống như trên diễn đàn BTC, nhiều cuộc thảo luận đều xoay quanh các alt-coin và vòng đời ngắn ngủi của chúng. Sự sụp đổ nhanh chóng của các alt-coin này khiến vốn và nỗ lực từng đổ vào chúng tan thành bọt nước. Chúng ta đã có Bitcoin – nền tảng đồng thuận mạnh mẽ như vậy, không cần thiết phải xây dựng L1 mới chỉ để phục vụ giao thức ứng dụng. Việc chúng ta cần làm là làm sao tận dụng tốt nhất cơ sở hạ tầng mạnh nhất này, để xây dựng một thế giới phi tập trung bền vững hơn.
Ít tính toán trên chuỗi, nhiều xác minh trên chuỗi
Xét về thiết kế ứng dụng, Bitcoin từ rất sớm đã chọn triết lý thiết kế lấy xác minh làm trọng tâm chứ không phải tính toán trên chuỗi (Turing completeness and state for smart contract). Bản chất blockchain là một máy trạng thái sao chép, nếu đồng thuận của một chuỗi đặt trọng tâm vào tính toán trên chuỗi, thì thật khó để nói rằng việc yêu cầu mọi nút trong mạng đều lặp lại các tính toán này là một cách mở rộng hợp lý. Nếu lấy xác minh làm trọng tâm, thì việc xác minh tính hợp lệ của giao dịch ngoài chuỗi có lẽ là phương án mở rộng phù hợp nhất với BTC.
Xác minh xảy ra ở đâu? Điều này rất quan trọng
Đối với các nhà phát triển giao thức trên Bitcoin, việc sử dụng Bitcoin để xác minh then chốt, thậm chí đặt việc xác minh ra ngoài chuỗi, và thiết kế phương án an toàn, thực ra đều là chuyện của người thiết kế giao thức, không cần và không nên liên quan đến bản thân chuỗi. Vậy làm sao để hiện thực xác minh, sẽ dẫn đến các phương án mở rộng quy mô khác nhau cho BTC.
Vì vậy, từ góc nhìn hiện thực xác minh, chúng ta có ba hướng mở rộng:
-
Xác minh xảy ra trên chuỗi (OP-ZKP)
Nếu trực tiếp hiện thực OP-ZKP trong TaprootScriptVM, tương đương việc trang bị khả năng xác minh ZKP cho chính BTC, kết hợp với một số thiết kế Covenant và giao thức thanh toán, có thể tạo ra phương án mở rộng Zk-Rollup kế thừa độ an toàn của BTC. Tuy nhiên, khác với việc triển khai một hợp đồng xác minh trên Ethereum, việc nâng cấp BTC vốn đã chậm, việc thêm op-code như vậy – không phổ biến và có thể cần nâng cấp sau này – chắc chắn sẽ rất khó khăn.
-
Xác minh xảy ra bán trên chuỗi (BitVM)
Thiết kế BitVM注定 nó sẽ không phục vụ logic giao dịch thông thường, Robin linus cũng khẳng định tương lai BitVM là làm thị trường liên chuỗi tự do cho các SideChain. Lý do gọi phương án BitVM là bán trên chuỗi là vì phần lớn thời gian các tính toán xác minh này sẽ không xảy ra trên chuỗi, mà xảy ra ngoài chuỗi. Tuy nhiên, lý do thiết kế quan trọng quanh Taproot của BTC là để trong thời điểm cần thiết cũng có thể sử dụng TapScriptVM để xác minh tính toán, nhằm kế thừa lý thuyết độ an toàn của BTC. Trong quá trình này cũng hình thành một chuỗi tin cậy xác minh, ví dụ chỉ cần một trong n người xác minh là trung thực là đủ, chính là Optimistic Rollups.
Chi phí trên chuỗi của BitVM rất lớn, nhưng có thể dùng bằng chứng gian lận ZK để nâng cao hiệu suất không? Câu trả lời là không, vì việc hiện thực bằng chứng gian lận ZK dựa trên nền tảng có thể xác minh ZKP trên chuỗi, điều này quay lại tình cảnh khó xử của phương án OP-ZKP.
-
Xác minh xảy ra ngoài chuỗi (Client-Side-Validation, Mạng lưới Lightning)
Xác minh hoàn toàn xảy ra ngoài chuỗi, đó là các giao thức tài sản CSV và mạng lưới Lightning đã thảo luận trước đây. Như đã thấy trong thảo luận trước, trong thiết kế CSV, chúng ta không thể hoàn toàn ngăn chặn việc thông đồng sửa đổi, điều chúng ta có thể làm là tận dụng mật mã học và thiết kế giao thức để giới hạn phạm vi gây hại của thông đồng ác ý trong tầm kiểm soát, khiến hành vi này trở nên vô lợi.
Ưu và nhược điểm của xác minh ngoài chuỗi đều rất rõ ràng. Ưu điểm là chiếm dụng tài nguyên trên chuỗi cực kỳ ít, tiềm năng mở rộng rất lớn. Nhược điểm là gần như không thể tái sử dụng hoàn toàn độ an toàn của BTC, điều này đặt ra giới hạn cực lớn đối với loại và hình thức giao dịch ngoài chuỗi có thể thực hiện. Đồng thời, xác minh ngoài chuỗi cũng đồng nghĩa dữ liệu đều ở ngoài chuỗi, do người dùng tự bảo quản, điều này đặt ra yêu cầu cao hơn về độ an toàn và ổn định của môi trường thực thi phần mềm.
Xu hướng tiến hóa mở rộng
Hiện tại, Layer2 phổ biến trên Ethereum về phạm trù, là thông qua Layer1 xác minh tính hiệu quả của tính toán Layer2, tức là đẩy việc tính toán trạng thái xuống Layer2, nhưng vẫn giữ xác minh trên Layer1. Trong tương lai, chúng ta có thể tiếp tục đẩy cả xác minh tính toán xuống ngoài chuỗi, từ đó giải phóng thêm hiệu suất của cơ sở hạ tầng blockchain hiện tại.
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
@wooooer
