Lời tựa

Phát hành tài sản dựa trên BTC luôn là một chủ đề nóng. Từ Đồng xu màu đầu tiên vào năm 2011 cho đến giao thức Thứ tự phổ biến gần đây, cộng đồng BTC đã liên tục có thể đưa ra những người chơi mới và sự đồng thuận, nhưng rất ít người còn chần chừ. Tuy nhiên, Lightning Labs đã tiết lộ các kế hoạch đầy tham vọng để phát triển stablecoin dựa trên Taproot Assets. Tether cũng thông báo rằng họ sẽ sử dụng giao thức RGB để đúc USDT trên lớp 1 của Bitcoin.

Điều này có nghĩa là OmniLayer (trước đây là Mastercoin) nổi tiếng một thời không còn là người chơi lớn nhất trong hệ sinh thái BTC. Và các giao thức tài sản xác thực phía máy khách (CSV) đang bắt đầu đi vào tầm nhìn của mọi người. Các giao thức này không chỉ duy trì tính toàn vẹn của các giao thức tài sản Bitcoin truyền thống mà còn tăng cường khả năng mở rộng. Tuy nhiên, một loạt các giao thức tài sản trong hệ sinh thái Bitcoin đặt ra những câu hỏi thích hợp: Chúng khác nhau như thế nào và người ta nên điều hướng và nắm bắt các cơ hội trong bối cảnh này như thế nào?

Bài viết này nhằm mục đích hướng dẫn người đọc đánh giá toàn diện về các giao thức tài sản khác nhau đã xuất hiện trong lịch sử của Bitcoin. Hơn nữa, nó tìm cách đi sâu vào quỹ đạo tiềm năng cho sự phát triển của các giao thức tài sản dựa trên Bitcoin trong tương lai gần.

Đồng xu màu

Khái niệm Đồng tiền màu lần đầu tiên được trình bày rõ ràng bởi Yoni Assia, hiện là Giám đốc điều hành của eToro, trong bài viết chuyên đề “bitcoin 2.X (còn gọi là Bitcoin màu)“ vào ngày 27 tháng 3 năm 2012. Bài báo khẳng định rằng công nghệ cơ bản của Bitcoin cũng nền tảng và hoàn hảo như HTTP dành cho internet. Do đó, giao thức mã thông báo Colored Coins được thiết kế dựa trên BTC.

Yoni Assia đã hình dung ra việc tạo ra nền kinh tế BTC 2.0 thông qua sự đổi mới này, cho phép bất kỳ cộng đồng nào tạo ra nhiều loại tiền tệ theo cách này. Vào thời điểm đó, việc sử dụng công nghệ cơ bản của Bitcoin để giải quyết giao dịch và ngăn chặn chi tiêu gấp đôi là một ý tưởng tiên phong.

Tiền xu màu là một giao thức được thiết kế để phát hành tài sản trên chuỗi khối Bitcoin. Nó hoạt động bằng cách “tô màu” một phần bitcoin cụ thể để biểu thị các tài sản khác. Những Bitcoin được đánh dấu này vẫn giữ được chức năng ban đầu nhưng chúng cũng đại diện cho một tài sản hoặc giá trị khác. Tuy nhiên, câu hỏi cấp bách là làm thế nào ý tưởng này có thể thành hiện thực trên mạng Bitcoin.

Vào ngày 3 tháng 7 năm 2014, ChromaWay đã có một bước tiến đáng kể bằng cách phát triển Giao thức dựa trên đơn hàng tiền xu màu nâng cao (EPOBC), giúp đơn giản hóa đáng kể quy trình tạo tiền màu cho các nhà phát triển. Đây là giao thức đầu tiên sử dụng chức năng OP_RETURN của Bitcoin Script.

Kết quả trông như thế này:

Việc triển khai như vậy rất ngắn gọn nhưng cũng mang lại nhiều vấn đề:

1. Tính linh hoạt và vấn đề giá trị ràng buộc tối thiểu Bằng cách ràng buộc 1000 sats trong giao dịch ban đầu đối với một đồng xu màu, đơn vị tối thiểu của đồng xu màu đó sẽ trở thành 1 sats. Điều này có nghĩa là về mặt lý thuyết, tài sản hoặc mã thông báo có thể được chia thành tối đa 1000 đơn vị (nhưng trên thực tế, con số này thấp hơn để ngăn chặn các cuộc tấn công bụi. Ví dụ: giá trị satoshi tối thiểu từng được đặt ở mức 546 SAT và đối với Ordinals, nó thậm chí còn cao hơn).
2. Thử thách xác thực Để xác định tính xác thực và quyền sở hữu của một đồng xu có màu, lịch sử giao dịch của nó cần được truy nguyên và xác thực từ giao dịch ban đầu đến UTXO hiện tại. Do đó, cần phải phát triển ví chuyên dụng, nút đầy đủ và thậm chí cả máy quét.
3. Rủi ro kiểm duyệt thợ mỏ tiềm năng ColoredTransaction có những đặc điểm riêng biệt, chẳng hạn như ghi siêu dữ liệu vào đầu ra, điều này mang đến khả năng kiểm duyệt thợ mỏ.

Đồng xu màu về cơ bản 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 việc chuyển giao tài sản. Tuy nhiên, để chứng minh bất kỳ đầu ra cụ thể nào (txout) đại diện cho một nội dung cụ thể, bạn cần cung cấp toàn bộ chuỗi chuyển khoản từ nguồn gốc của nội dung đó. Điều này có nghĩa là việc xác thực tính hợp lệ của giao dịch có thể yêu cầu một chuỗi bằng chứng dài. Để giải quyết vấn đề này, các đề xuất như OP_CHECKCOLORVERIFY đã được đưa ra để giúp xác thực các giao dịch Colored Coin trực tiếp trên BTC, nhưng đề xuất này đã không được thông qua.

ICO đầu tiên trong tiền điện tử: Mastercoin

Khái niệm Mastercoin ban đầu được đề xuất bởi JR Willett. Vào năm 2012, ông đã xuất bản một sách trắng có tựa đề “Sách trắng Bitcoin thứ hai”, trong đó nêu ra ý tưởng tạo ra tài sản hoặc mã thông báo mới trên nền tảng chuỗi khối Bitcoin hiện có. Khái niệm này cuối cùng được biết đến với cái tên “MasterCoin”, sau này được đổi tên thành Omni Layer.

Vào năm 2013, dự án Mastercoin đã tiến hành phiên bản đầu tiên của cái mà ngày nay chúng ta gọi là ICO (Cung cấp tiền xu ban đầu), huy động thành công hàng triệu đô la. Đây được coi là ICO đầu tiên trong lịch sử. Một trong những ứng dụng đáng chú ý nhất của Mastercoin là Tether (USDT), một loại tiền ổn định được thế chấp bằng tiền pháp định nổi tiếng, ban đầu được phát hành trên Lớp Omni.

Trên thực tế, ý tưởng về Mastercoin đã có trước Đồng xu màu. Lý do chúng ta thảo luận về vấn đề này lần thứ hai là vì so với Đồng tiền màu, MasterCoin là một giải pháp tương đối toàn diện hơn. MasterCoin đã thiết lập một lớp nút đầy đủ, cung cấp các chức năng phức tạp hơn như hợp đồng thông minh. Ngược lại, Colored Coins đơn giản và trực tiếp hơn, chủ yếu tập trung vào việc “tô màu” hoặc đánh dấu UTXO Bitcoin để đại diện cho các tài sản khác.

Sự khác biệt chính giữa hai loại này là trên blockchain, Mastercoin chỉ ghi lại nhiều loại hành vi giao dịch khác nhau và không lưu trữ thông tin tài sản liên quan. Trong các nút của Mastercoin, cơ sở dữ liệu của mô hình trạng thái được duy trì bằng cách quét các khối Bitcoin và cơ sở dữ liệu này nằm trong các nút ngoài chuỗi khối.

So với Đồng tiền màu, Mastercoin có thể thực hiện logic phức tạp hơn. Ngoài ra, vì nó không ghi lại hoặc xác minh trạng thái trên blockchain nên các giao dịch của nó không cần phải liên tục (được tô màu liên tục).

Tuy nhiên, để triển khai logic phức tạp của Mastercoin, người dùng cần tin tưởng trạng thái được duy trì trong cơ sở dữ liệu ngoài chuỗi trong các nút hoặc chạy các nút Lớp Omni của riêng họ để thực hiện xác minh.

Tóm tắt:

Sự khác biệt chính giữa Mastercoin và Colored Coins là Mastercoin không duy trì tất cả dữ liệu cần thiết cho giao thức trên blockchain. Thay vào đó, nó dựa trên hệ thống đồng thuận của Bitcoin để quản lý việc xuất bản và đặt hàng giao dịch của riêng mình, sau đó nó duy trì trạng thái trong cơ sở dữ liệu ngoài chuỗi.

Theo thông tin do OmniBolt cung cấp: Omni Layer đang đề xuất giao thức tài sản UBA (UTXO Based Asset) mới cho Tether, giao thức này sẽ sử dụng bản nâng cấp Taproot. Giao thức này sẽ nhúng thông tin tài sản vào tapleaf, kích hoạt các chức năng như thanh toán có điều kiện. Đồng thời, OmniBolt đang nỗ lực tích hợp Stark vào cơ sở hạ tầng Lightning Network của Lớp Omni.

Khái niệm xác thực phía khách hàng

Nếu chúng ta muốn hiểu khái niệm Xác thực phía khách hàng (CSV), chúng ta cần quay trở lại năm sau khi Xu màu và Mastercoin xuất hiện, đó là năm 2013. Vào năm đó, Peter Todd, một nhà nghiên cứu mật mã và Bitcoin thời kỳ đầu, đã xuất bản một bài báo có tiêu đề “Giải quyết vấn đề khai thác tiền điện tử: Đánh dấu thời gian, Bằng chứng xuất bản và Xác thực.“ Mặc dù tiêu đề không đề cập rõ ràng đến Xác thực phía khách hàng, nhưng khi đọc kỹ sẽ thấy rằng đây là một trong những bài viết sớm nhất giới thiệu khái niệm này.

Peter Todd đã tìm cách làm cho hoạt động của Bitcoin hiệu quả hơn. Ông đã phát triển một khái niệm phức tạp hơn về xác thực phía khách hàng dựa trên ý tưởng về dấu thời gian. Ngoài ra, ông còn đưa ra khái niệm “con dấu sử dụng một lần”, khái niệm này sẽ được đề cập sau.

Để theo dõi suy nghĩ của Peter Todd, trước tiên chúng ta cần hiểu Bitcoin thực sự giải quyết được vấn đề gì. Theo Peter Todd, Bitcoin giải quyết ba vấn đề:

1. Bằng chứng xuất bản: Bản chất của bằng chứng xuất bản là giải quyết vấn đề chi tiêu gấp đôi. Ví dụ: nếu Alice muốn chuyển một số bitcoin cho Bob, mặc dù cô ấy đã ký một giao dịch để chuyển cho Bob, nhưng trên thực tế, Bob có thể không biết rằng giao dịch đó tồn tại. Vì vậy, chúng ta cần một nơi công cộng để công bố các giao dịch và mọi người đều có thể truy vấn các giao dịch từ đó.
2. Sự đồng thuận về thứ tự: Trong hệ thống máy tính, thời gian vật lý mà chúng ta thường trải qua không tồn tại. Trong các hệ thống phân tán, thời gian thường là dấu thời gian của Lamport, không cung cấp thước đo cho thời gian vật lý mà chỉ ra thứ tự cho các giao dịch của chúng ta.
3. Xác thực (Tùy chọn): Xác thực trên Bitcoin bao gồm việc xác minh chữ ký và số tiền được chuyển trong giao dịch BTC. Tuy nhiên, Peter Todd tin rằng việc xác thực này là không cần thiết để xây dựng hệ thống mã thông báo dựa trên Bitcoin; nó chỉ là một lựa chọn tối ưu hóa.

Tại thời điểm này, bạn có thể nhớ lại OmniLayer mà chúng ta đã thảo luận trước đó. Bản thân OmniLayer không ủy quyền tính toán và xác thực trạng thái cho Bitcoin, nhưng nó sử dụng lại tính bảo mật của Bitcoin. Mặt khác, Colored Coins giao phó việc theo dõi trạng thái cho Bitcoin. Sự tồn tại của hai hệ thống này đã chứng minh rằng việc xác thực không nhất thiết phải diễn ra trên blockchain.

Vậy làm cách nào để xác thực phía khách hàng xác minh giao dịch một cách hiệu quả?

Trước tiên, hãy xem những gì cần được xác minh:

1. Trạng thái (xác minh logic giao dịch)
2. Xác minh rằng đầu vào (TxIn) hợp lệ để ngăn chặn chi tiêu gấp đôi.

Dễ dàng nhận thấy rằng đối với các tài sản được phát hành trên Bitcoin, mọi giao dịch đều yêu cầu xác minh toàn bộ lịch sử giao dịch có liên quan để đảm bảo các đầu vào được tham chiếu chưa được chi tiêu và trạng thái là chính xác. Điều này rất không thực tế. Vì vậy, làm thế nào chúng ta có thể cải thiện điều này?

Peter Todd gợi ý rằng chúng ta có thể đơn giản hóa quy trình này bằng cách thay đổi trọng tâm của việc xác minh. Thay vì xác nhận rằng đầu ra chưa được chi tiêu gấp đôi, phương pháp này tập trung vào việc đảm bảo rằng đầu vào của giao dịch đã được công bố và không xung đột với các đầu vào khác. Bằng cách sắp xếp thứ tự đầu vào trong mỗi khối và sử dụng cây Merkle, loại xác minh này có thể được thực hiện hiệu quả hơn vì mỗi lần chỉ yêu cầu một phần nhỏ dữ liệu chứ không phải toàn bộ lịch sử chuỗi của đầu vào.

Cấu trúc cây cam kết do Peter Todd đề xuất như sau:

CTxIn -> CTxOut -> <đường<merkle path> dẫn merkle> -> CTransaction -> <đường dẫn merkle> <merkle path> -> CTxIn

Nhưng làm cách nào chúng ta có thể lưu trữ cây cam kết như vậy trên blockchain? Đây là nơi chúng tôi có thể giới thiệu khái niệm “con dấu sử dụng một lần”.

Con dấu sử dụng một lần

Con dấu sử dụng một lần là một trong những khái niệm cốt lõi để hiểu CSV. Nó tương tự như con dấu vật lý sử dụng một lần được sử dụng để bảo vệ các container hàng hóa. Con dấu sử dụng một lần là vật thể duy nhất có thể được đóng lại chính xác một lần trên một tin nhắn. Nói một cách đơn giản, con dấu sử dụng một lần là một cơ chế trừu tượng được sử dụng để ngăn chặn việc chi tiêu gấp đôi.

Đối với SealProtocol, có ba phần tử và hai hành động.

Các yếu tố cơ bản:

1. l: con dấu
2. m: tin nhắn, là thông tin hoặc giao dịch
3. w: nhân chứng, ai đó hoặc cái gì đó có thể xác minh con dấu

Các thao tác cơ bản: Có hai thao tác cơ bản:

1. Close(l, m) → w: Đóng dấu l trên tin nhắn m, đưa ra người làm chứng w.
2. Verify(l, w, m) → bool: Xác minh xem seal l đã được đóng trên tin nhắn m chưa.

Tính bảo mật của việc triển khai con dấu sử dụng một lần có nghĩa là kẻ tấn công không thể tìm thấy hai thông báo khác nhau m1 và m2 sao cho hàm Xác minh trả về true cho cùng một con dấu.

Nói một cách đơn giản, Con dấu sử dụng một lần đảm bảo rằng một tài sản hoặc phần dữ liệu nhất định chỉ được sử dụng hoặc khóa một lần. Trong bối cảnh của Bitcoin, điều này thường có nghĩa là UTXO chỉ có thể được sử dụng một lần. Vì vậy, đầu ra của giao dịch Bitcoin có thể được coi là con dấu sử dụng một lần và khi đầu ra được sử dụng làm đầu vào trong một giao dịch khác, con dấu đó sẽ “bị hỏng” hoặc “đã được sử dụng”.

Đối với tài sản trên Bitcoin, chính Bitcoin đóng vai trò là “nhân chứng” (w) cho con dấu sử dụng một lần. Điều này là do để xác minh 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 UTXO hợp lệ và chưa chi tiêu hay không. Nếu một giao dịch cố gắng chi tiêu gấp đôi một UTXO đã được sử dụng, các quy tắc đồng thuận của Bitcoin và mạng lưới các nút trung thực sẽ từ chối giao dịch đó.

Nói một cách đơn giản hơn:

Con dấu sử dụng một lần xử lý bất kỳ chuỗi khối nào giống như một cơ sở dữ liệu, nơi chúng tôi lưu trữ cam kết đối với một thông báo nhất định và duy trì trạng thái của nó là đã chi tiêu hoặc chưa chi tiêu.

Tóm tắt những điều trên, nội dung sử dụng xác thực phía máy khách có các đặc điểm sau:

1. Lưu trữ dữ liệu ngoài chuỗi: Lịch sử giao dịch, quyền sở hữu và dữ liệu liên quan khác của tài sản sử dụng xác thực phía khách hàng hầu hết được lưu trữ ngoài chuỗi. Điều này làm giảm đáng kể nhu cầu lưu trữ dữ liệu trên chuỗi và giúp nâng cao quyền riêng tư.
2. Cơ chế cam kết: Mặc dù dữ liệu tài sản được lưu trữ ngoài chuỗi, nhưng những thay đổi hoặc chuyển giao dữ liệu này sẽ được ghi lại trên chuỗi thông qua các cam kết. Những cam kết này cho phép các giao dịch trên chuỗi tham chiếu các trạng thái ngoài chuỗi, đảm bảo tính toàn vẹn và bất biến của dữ liệu ngoài chuỗi.
3. Nhân chứng trên chuỗi (Không nhất thiết phải là BTC): Mặc dù hầu hết dữ liệu và xác thực xảy ra ngoài chuỗi, các tài sản sử dụng xác thực phía khách hàng vẫn có thể tận dụng tính bảo mật của chuỗi khối cơ bản (bằng chứng xuất bản, đặt hàng giao dịch) thông qua các cam kết được nhúng trên -xích.
4. Công việc xác thực được thực hiện ở phía máy khách: Hầu hết công việc xác thực được thực hiện trên thiết bị của người dùng. Điều này có nghĩa là không phải mọi nút trong mạng đều cần tham gia xác thực từng giao dịch; chỉ các bên liên quan mới cần xác minh tính hợp lệ của giao dịch.

Đối với những người sử dụng nội dung có xác thực phía khách hàng, có một điểm bổ sung cần lưu ý:

Khi giao dịch và xác thực tài sản bằng xác thực ngoài chuỗi phía khách hàng, không chỉ cần xuất trình khóa riêng giữ tài sản mà còn phải cung cấp bằng chứng đường dẫn Merkle hoàn chỉnh cho tài sản tương ứng.

RGB, người tiên phong của CSV

Khái niệm RGB được đề xuất bởi Giacomo Zucco, một nhân vật nổi tiếng trong cộng đồng, sau năm 2015. Đây là thời kỳ Ethereum đang trên đà phát triển, ICO (Cung cấp tiền xu ban đầu) đang sinh sôi nảy nở và nhiều nỗ lực đã được thực hiện để tạo ra các dự án ngoài Bitcoin, chẳng hạn như Mastercoin và Colored Coins.

Giacomo Zucco thất vọng với những diễn biến này. Ông tin rằng không có dự án nào trong số này phù hợp với tiềm năng của Bitcoin và những nỗ lực trước đây nhằm triển khai token trên Bitcoin là chưa thỏa đáng. Trong thời gian này, anh gặp Peter Todd và bị cuốn hút bởi những ý tưởng của Todd về Xác thực phía khách hàng (CSV). Điều này khiến ông đề xuất ý tưởng về RGB.

Ngoài các đặc điểm được đề cập trước đó của nội dung sử dụng xác thực phía máy khách, điểm khác biệt chính giữa RGB và các giao thức nội dung trước đó là việc bổ sung VM thực thi (Máy ảo) để thực thi hợp đồng hoàn chỉnh Turing. Để đảm bảo tính bảo mật của dữ liệu hợp đồng, Lược đồ và Giao diện đã được thiết kế. Lược đồ, tương tự như của Ethereum, khai báo nội dung và chức năng của hợp đồng, trong khi Giao diện chịu trách nhiệm thực hiện các chức năng cụ thể, giống như giao diện trong ngôn ngữ lập trình.

Lược đồ của các hợp đồng này chịu trách nhiệm hạn chế các hành vi vượt quá mong đợi trong quá trình thực thi VM. Ví dụ: RGB20 và RGB21 lần lượt chịu trách nhiệm áp đặt một số hạn chế nhất định đối với các mã thông báo có thể thay thế và không thể thay thế trong quá trình giao dịch.

Cơ chế cam kết được sử dụng trong RGB, Pedersen Hash

Ưu điểm của nó nằm ở khả năng cam kết một giá trị mà không tiết lộ nó. Sử dụng Pedersen Hash để xây dựng cây Merkle có nghĩa là bạn có thể tạo cây Merkle bảo vệ quyền riêng tư có thể ẩn các giá trị của nó. Cấu trúc này hữu ích trong một số giao thức bảo vệ quyền riêng tư nhất định, chẳng hạn như một số dự án tiền điện tử ẩn danh. Tuy nhiên, nó có thể không phù hợp với nội dung CSV, điều này sẽ được đề cập sau khi so sánh với Nội dung Taproot.

Thiết kế máy ảo để đơn giản hóa RGB → AluVM

RGB không chỉ nhằm mục đích triển khai giao thức tài sản được xác thực phía máy khách mà còn mở rộng sang việc thực thi hợp đồng và thực thi máy ảo hoàn chỉnh Turing. Ban đầu, RGB tuyên bố sử dụng ngôn ngữ lập trình có tên Simplicity, ngôn ngữ này tạo ra bằng chứng thực thi và cho phép xác minh chính thức (để tránh lỗi) các hợp đồng được viết trong đó. Tuy nhiên, sự phát triển của ngôn ngữ này đã không diễn ra như kế hoạch, dẫn đến sự phức tạp và cuối cùng cản trở toàn bộ giao thức RGB. Cuối cùng, RGB bắt đầu sử dụng VM có tên AluVM, 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à sẽ được thay thế trong tương lai bằng ngôn ngữ lập trình có tên Contractum, loại bỏ việc sử dụng Rust hiện tại.

Hướng mở rộng quy mô lớp 2 của RGB: Lightning Network hay Sidechain?

Các tài sản được xác thực phía khách hàng không thể liên tục giao dịch an toàn ngoài chuỗi vì chúng vẫn dựa vào L1 để xuất bản và đặt hàng giao dịch. Điều này có nghĩa là nếu không có giải pháp mở rộng quy mô lớp 2, tốc độ giao dịch của họ vẫn bị giới hạn bởi tốc độ sản xuất khối của nhân chứng L1. Điều này ngụ ý rằng nếu các giao dịch RGB được thực hiện trực tiếp trên Bitcoin, theo các yêu cầu bảo mật nghiêm ngặt, thời gian giữa hai giao dịch liên quan sẽ cần cách nhau ít nhất mười phút (thời gian chặn của BTC), thường chậm đến mức không thể chấp nhận được.

RGB và mạng Lightning

Nói một cách đơn giản, Lightning Network hoạt động bằng cách yêu cầu các bên tham gia giao dịch ký một loạt hợp đồng (giao dịch cam kết) ngoài chuỗi. Các hợp đồng này đảm bảo rằng nếu bất kỳ bên nào vi phạm thỏa thuận, bên bị vi phạm có thể gửi hợp đồng (giao dịch cam kết) cho BTC để giải quyết, lấy lại tiền của họ và phạt người vi phạm. Nói cách khác, Lightning Network đảm bảo tính bảo mật của các giao dịch ngoài chuỗi thông qua giao thức và thiết kế lý thuyết trò chơi.

RGB có thể xây dựng cơ sở hạ tầng Lightning Network của riêng mình bằng cách thiết kế chi tiết hợp đồng kênh thanh toán phù hợp với chính RGB. Tuy nhiên, việc xây dựng cơ sở hạ tầng như vậy không hề dễ dàng do tính phức tạp cao của Lightning Network, đặc biệt khi xét đến số năm hoạt động của Lightning Labs trong lĩnh vực này và thị phần của LND là hơn 90%.

Sidechain Prime của RGB

LNP-BP, đơn vị duy trì giao thức RGB hiện tại, đã đưa ra đề xuất của Maxim vào tháng 6 năm 2023 về một giải pháp mở rộng quy mô tài sản được xác thực phía khách hàng có tên là Prime. Trong đó, Maxim chỉ trích các giải pháp mở rộng sidechain và Lightning Network hiện có vì quá phức tạp trong quá trình phát triển. Ông bày tỏ niềm tin rằng, ngoài Prime, các phương pháp mở rộng khác, bao gồm các kênh Lightning đa nút NUCLEUS và các nhà máy kênh Ark/Enigma, sẽ cần hơn hai năm phát triển. Tuy nhiên, Prime có thể được hoàn thành chỉ sau một năm.

Prime không được thiết kế như một blockchain truyền thống. Thay vào đó, đó là lớp xuất bản bằng chứng mô-đun được tạo riêng để xác thực phía máy khách. Nó bao gồm bốn thành phần chính:

1. Dịch vụ đánh dấu thời gian: Dịch vụ này có thể hoàn tất một chuỗi giao dịch chỉ trong 10 giây.
2. Bằng chứng: Chúng được lưu trữ dưới dạng Cây Merkle một phần (PMT) và được tạo và xuất bản cùng với các tiêu đề khối.
3. Con dấu sử dụng một lần: Đây là một giao thức con dấu sử dụng một lần trừu tượng được thiết kế để ngăn chặn việc chi tiêu gấp đôi. Khi được triển khai trên Bitcoin, nó có thể bị ràng buộc với UTXO, tương tự như thiết kế RGB hiện tại.
4. Giao thức hợp đồng thông minh: Hợp đồng được phân chia cho RGB (có thể thay thế)

Từ đó, chúng ta có thể thấy rằng để giải quyết vấn đề về thời gian xác nhận giao dịch trong RGB, Prime sử dụng dịch vụ đánh dấu thời gian để nhanh chóng xác nhận các giao dịch ngoài chuỗi và đóng gói chúng cùng với ID thành các khối. Đồng thời, bằng chứng giao dịch trên Prime có thể được củng cố hơn nữa thông qua PMT và sau đó được neo vào BTC theo cách giống như điểm kiểm tra.

Giao thức tài sản CSV dựa trên Taproot: Tài sản Taproot

Taproot Assets là giao thức tài sản CSV dựa trên Taproot, được thiết kế để phát hành tài sản trên chuỗi khối Bitcoin. Những tài sản này có thể được giao dịch ngay lập tức, với khối lượng lớn và với chi phí thấp thông qua Lightning Network. Cốt lõi của Taproot Assets là việc sử dụng tính bảo mật và ổn định của Bitcoin cùng với tốc độ, khả năng mở rộng và chi phí thấp của Lightning Network. Giao thức được thiết kế và phát triển bởi roasbeef, CTO của Lightning Labs. Roasbeef có thể là người duy nhất trên hành tinh đã đích thân lãnh đạo sự phát triển của cả ứng dụng khách Bitcoin (BTCD) và ứng dụng khách Lightning Network (LND), thể hiện sự hiểu biết sâu sắc về BTC.

Các giao dịch Taproot chỉ mang hàm băm gốc của tập lệnh nội dung, khiến người quan sát bên ngoài khó xác định liệu chúng có liên quan đến Tài sản Taproot hay không vì bản thân hàm băm này là chung và có thể đại diện cho bất kỳ dữ liệu nào. Với bản nâng cấp Taproot, Bitcoin đã có được khả năng thực hiện các hợp đồng thông minh (TapScript). Dựa trên điều này, mã hóa tài sản của Taproot Assets về cơ bản tạo ra định nghĩa mã thông báo tương tự như ERC20 hoặc ERC721. Do đó, Bitcoin không chỉ có được khả năng xác định tài sản mà còn có khả năng viết hợp đồng thông minh, đặt nền móng cho cơ sở hạ tầng hợp đồng thông minh mã thông báo cho Bitcoin.

Cấu trúc mã hóa của Taproot Assets như sau:

bởi roasbeef, CTO của Lighting Labs

Cũng như một giao thức nội dung CSV, Taproot Assets có thiết kế ngắn gọn hơn so với RGB. Sự khác biệt lớn nhất giữa Taproot Assets và RGB về khả năng mở rộng ứng dụng nằm ở VM thực thi, Taproot Assets sử dụng cùng một máy ảo TaprootScript làm mặc định gốc của BTC. Trong những năm gần đây, nhiều nghiên cứu về BTC Trong những năm gần đây, rất nhiều nghiên cứu về cơ sở hạ tầng cho BTC đều dựa trên TapScript, nhưng do BTC nâng cấp chậm nên không thể áp dụng trong thời gian ngắn nên không thể áp dụng được. có thể dự đoán rằng Taproot Assets sẽ là nơi thử nghiệm những ý tưởng mới mẻ này trong tương lai.

Sự khác biệt giữa Tài sản Taproot và RGB

1. Xác thực giao dịch và tính thân thiện với Light Node

Taproot Assets do triển khai cây tổng nên có hiệu quả xác minh và bảo mật cao. Nó cho phép xác minh trạng thái và các giao dịch được thực hiện đơn giản bằng cách sở hữu bằng chứng mà không cần phải xem lại toàn bộ lịch sử giao dịch. Ngược lại, việc RGB sử dụng các cam kết Pedersen gây khó khăn cho việc xác minh tính hợp lệ của các đầu vào một cách hiệu quả. Do đó, RGB yêu cầu truy tìm lại lịch sử giao dịch của đầu vào, điều này có thể trở thành gánh nặng đáng kể khi các giao dịch tích lũy theo thời gian. Thiết kế của cây tổng Merkel cũng cho phép Taproot Assets dễ dàng tạo điều kiện xác minh nút nhẹ, một tính năng trước đây không có trong các giao thức tài sản được xây dựng dựa trên Bitcoin.

2. Máy ảo thực thi

Tài sản Taproot được phát triển để đáp ứng việc nâng cấp Taproot của mạng Bitcoin. Nó sử dụng TaprootScriptVM, công cụ thực thi tập lệnh đi kèm với Bitcoin sau khi nâng cấp Taproot. Hơn nữa, nó sử dụng vPSBT, một biến thể của PSBT của Bitcoin, cho thấy rằng khi cơ chế kênh Lightning Taproot Assets được phát triển, nó có thể tái sử dụng ngay lập tức tất cả cơ sở hạ tầng hiện tại của LND (Lightning Network Daemon), cũng như các sản phẩm trước đó từ Lightning Labs (LND). hiện chiếm hơn 90% thị phần trong mạng Lightning). Ngoài ra, đề xuất BitVM phổ biến gần đây dựa trên TaprootScript, về mặt lý thuyết có nghĩa là tất cả những cải tiến này cuối cùng có thể mang lại lợi ích cho Tài sản Taproot.

Tuy nhiên, RGB hoạt động hơi khác một chút. Máy ảo và các quy tắc xác thực (SCHEMA) của nó là một phần của hệ thống khép kín, tạo thành một hệ sinh thái có phần khép kín. RGB hoạt động trong hệ sinh thái của riêng nó và mối quan hệ của nó với hệ sinh thái Bitcoin rộng lớn hơn không chặt chẽ như một số người nghĩ. Ví dụ: đối với bản nâng cấp Taproot, tương tác thực sự duy nhất của RGB là mã hóa dữ liệu cam kết lên chuỗi khối trong Witness TapLeaf. Điều này minh họa rằng RGB và bản nâng cấp Taproot chỉ được kết nối ở mức tối thiểu.

3. Hợp đồng thông minh

Trong quá trình triển khai RGB hiện tại, các hợp đồng và VM được nhấn mạnh rất nhiều. Tuy nhiên, trong Taproot Assets, dường như không có sự tập trung vào hợp đồng thông minh, ít nhất là chưa. Việc triển khai RGB hiện tại vẫn chưa giải thích cách sửa đổi Trạng thái toàn cầu đồng bộ hóa với các phân đoạn hợp đồng riêng lẻ (UTXO). Hơn nữa, trong khi các cam kết của Pedersen có thể đảm bảo tổng số tài sản, vẫn chưa rõ các bang khác sẽ được bảo vệ như thế nào khỏi sự giả mạo vì chưa có nhiều lời giải thích về điều này.

Mặt khác, Taproot Assets có thiết kế đơn giản hơn nhưng hiện chỉ lưu trữ số dư tài sản và không xử lý các trạng thái phức tạp hơn, khiến các cuộc thảo luận về hợp đồng thông minh trở nên sớm. Tuy nhiên, theo Lightning Labs, có kế hoạch tập trung vào thiết kế hợp đồng thông minh cho Taproot Assets vào năm tới.

4. Trung tâm đồng bộ

Nguyên tắc cơ bản được đề cập trước đó liên quan đến tài sản được xác minh ở phía khách hàng chỉ ra rằng việc giữ Bằng chứng cũng quan trọng như việc giữ khóa riêng. Tuy nhiên, có nguy cơ mất Bằng chứng vì nó được giữ ở phía khách hàng. Làm thế nào điều này có thể được giải quyết? Trong Taproot Assets, vấn đề này có thể tránh được bằng cách sử dụng “vũ trụ”. Vũ trụ là một cây Merkle thưa thớt có thể kiểm tra công khai bao gồm một hoặc nhiều nội dung. Không giống như cây tài sản Taproot tiêu chuẩn, vũ trụ không được sử dụng để lưu giữ tài sản Taproot. Thay vào đó, nó cam kết một tập hợp con của một hoặc nhiều lịch sử nội dung.

Trong hệ thống RGB, vai trò này được đảm nhận bởi Storm, hệ thống này đồng bộ hóa dữ liệu bằng chứng ngoài chuỗi thông qua mạng ngang hàng (p2p). Tuy nhiên, vì lý do lịch sử liên quan đến nhóm phát triển RGB, các nhóm này hiện đang sử dụng các định dạng chứng minh không tương thích. Nhóm hệ sinh thái RGB, DIBA, đã chỉ ra rằng họ sẽ phát triển “carbonado“ để giải quyết vấn đề này, nhưng tiến độ của nó vẫn chưa rõ ràng.

5. Triển khai kỹ thuật

Tất cả các thư viện mà Taproot Assets sử dụng đều đã được kiểm tra kỹ lưỡng, vì Lightning Labs có ứng dụng khách Bitcoin (BTCD), ứng dụng khách Lightning Network (LND) riêng và một loạt triển khai thư viện ví. Ngược lại, hầu hết các thư viện được sử dụng để triển khai RGB đều tự xác định. Từ góc độ tiêu chuẩn ngành, việc triển khai RGB vẫn đang trong giai đoạn thử nghiệm.

Một cái nhìn ngắn gọn về tương lai của việc mở rộng quy mô BTC

Tiếp tục cuộc thảo luận, rõ ràng là các giao thức tài sản được khách hàng xác thực đã vượt ra ngoài phạm vi của các giao thức truyền thống và hiện đang hướng tới mở rộng quy mô tính toán.

Nhiều người cho rằng trong tương lai, Bitcoin sẽ tồn tại dưới dạng “vàng kỹ thuật số”, trong khi các blockchain khác sẽ tạo ra hệ sinh thái ứng dụng. Tuy nhiên, tôi có quan điểm khác. Như đã thấy trong nhiều cuộc thảo luận trên các diễn đàn Bitcoin, có rất nhiều cuộc thảo luận về các loại tiền thay thế khác nhau và tuổi thọ ngắn ngủi của chúng. Sự sụp đổ nhanh chóng của những đồng tiền thay thế này đã biến vốn và nỗ lực xung quanh chúng thành bong bóng. Chúng tôi đã có Bitcoin như một nền tảng đồng thuận vững chắc; không cần phải xây dựng các giải pháp Lớp 1 (L1) mới chỉ dành cho các giao thức ứng dụng. Những gì chúng ta nên làm là tận dụng Bitcoin, cơ sở hạ tầng mạnh mẽ này, để xây dựng một thế giới phi tập trung lâu dài hơn.

Tính toán trên chuỗi ít hơn, xác minh trên chuỗi nhiều hơn

Từ góc độ thiết kế ứng dụng, Bitcoin ngay từ đầu đã chọn một triết lý không tập trung vào tính toán trên chuỗi mà tập trung vào xác minh (Tính hoàn thiện và trạng thái của Turing cho các hợp đồng thông minh). Bản chất của blockchain là một máy trạng thái được sao chép. Nếu sự đồng thuận của blockchain tập trung vào tính toán trên chuỗi, thật khó để tranh luận rằng việc mọi nút trong mạng lặp lại các tính toán này là một cách tiếp cận hợp lý hoặc có thể mở rộng. Nếu trọng tâm là xác minh thì việc xác thực các giao dịch ngoài chuỗi có thể là cách tiếp cận phù hợp nhất cho khả năng mở rộng của Bitcoin.

Việc xác minh diễn ra ở đâu? Điều này rất quan trọng.

Đối với các nhà phát triển tạo giao thức dựa trên Bitcoin, cách sử dụng Bitcoin để xác minh quan trọng hoặc thậm chí đặt xác minh ngoài chuỗi và cách thiết kế các sơ đồ an toàn là những vấn đề đối với chính các nhà thiết kế giao thức. Chúng không nên và không cần phải liên kết với chính chuỗi đó. Cách triển khai xác minh sẽ dẫn đến các giải pháp mở rộng quy mô khác nhau cho BTC.

Từ góc độ triển khai dựa trên xác minh, chúng tôi có ba hướng để mở rộng quy mô:

1.Xác minh trên chuỗi (OP-ZKP)

Việc triển khai OP-ZKP trực tiếp trong TaprootScriptVM sẽ mang lại cho Bitcoin khả năng thực hiện xác minh ZKP. Điều này, cùng với một số giao thức giải quyết thiết kế của Covenant, có thể tạo ra giải pháp mở rộng quy mô Zk-Rollup kế thừa tính bảo mật của Bitcoin. Tuy nhiên, không giống như việc triển khai hợp đồng xác minh trên Ethereum, việc nâng cấp Bitcoin vốn đã chậm và việc thêm một mã op-code chuyên biệt, có khả năng cần nâng cấp như vậy chắc chắn sẽ là một thách thức.

2.Xác minh trên bán trên chuỗi (BitVM)

Thiết kế của BitVM đảm bảo rằng nó không dành cho logic giao dịch thông thường. Robin Linus cũng đã chỉ ra rằng tương lai của BitVM nằm ở việc tạo ra một thị trường chuỗi chéo miễn phí cho nhiều SideChain khác nhau. Cách tiếp cận của BitVM được coi là bán trên chuỗi vì hầu hết các tính toán xác minh sẽ không xảy ra trên chuỗi mà xảy ra ngoài chuỗi. Lý do quan trọng để thiết kế xung quanh Taproot của Bitcoin là sử dụng TapScriptVM để xác minh tính toán khi cần thiết, về mặt lý thuyết kế thừa tính bảo mật của Bitcoin. Quá trình này cũng tạo ra một chuỗi xác minh tin cậy, chẳng hạn như chỉ cần một người xác minh trung thực trong số 'n' người xác minh, được gọi là Tổng hợp lạc quan.

BitVM phát sinh chi phí đáng kể trên chuỗi, nhưng liệu nó có thể sử dụng bằng chứng gian lận ZK để tăng hiệu quả không? Câu trả lời là không, vì việc triển khai bằng chứng gian lận ZK phụ thuộc vào khả năng thực hiện xác minh ZKP trên chuỗi, khiến chúng tôi quay trở lại những khó khăn của phương pháp OP-ZKP.

3.Xác minh ngoài chuỗi (Xác thực phía khách hàng, Lightning Network)

Xác minh ngoài chuỗi hoàn chỉnh đề cập đến các giao thức tài sản CSV đã thảo luận trước đó và Lightning Network. Như đã thấy trong các cuộc thảo luận trước, chúng ta không thể ngăn chặn hoàn toàn hành vi thông đồng trong thiết kế CSV. Những gì chúng tôi có thể làm là sử dụng mật mã và thiết kế giao thức để giữ thiệt hại do thông đồng độc hại trong giới hạn có thể kiểm soát được, khiến những hành động đó không mang lại lợi nhuận.

Ưu điểm và nhược điểm của xác minh ngoài chuỗi đều rõ ràng như nhau. Ưu điểm là nó sử dụng tài nguyên trên chuỗi tối thiểu và có tiềm năng mở rộng rất lớn. Điểm bất lợi là hầu như không thể kế thừa hoàn toàn tính bảo mật của Bitcoin, điều này hạn chế đáng kể các loại và phương thức giao dịch ngoài chuỗi có thể được thực hiện. Ngoài ra, xác minh ngoài chuỗi cũng ngụ ý rằng dữ liệu được lưu giữ ngoài chuỗi, do chính người dùng quản lý, điều này đặt ra yêu cầu cao hơn về tính bảo mật của môi trường thực thi phần mềm và tính ổn định của phần mềm.

Xu hướng phát triển quy mô

Hiện tại, các giải pháp Lớp 2 phổ biến trên Ethereum, theo thuật ngữ mô hình, xác thực tính toán Lớp 2 thông qua Lớp 1, nghĩa là tính toán trạng thái được đẩy xuống Lớp 2, nhưng việc xác minh vẫn được giữ lại ở Lớp 1. Trong tương lai, chúng ta có thể đẩy tính toán xác minh ra ngoài chuỗi một cách tương tự, tiếp tục giải phóng hiệu suất của cơ sở hạ tầng blockchain hiện tại.

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [mirror]. Mọi bản quyền đều thuộc về tác giả gốc [Ben77]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.