Chuyển giao ngoài chuỗi: Con đường phát triển của giao thức tài sản Bitcoin

Giới thiệu loại coin

Phát hành tài sản dựa trên BTC luôn là một chủ đề nóng. Từ sự xuất hiện sớm nhất của Đồng tiền màu vào năm 2011 cho đến Giao thức thứ tự phổ biến gần đây, cộng đồng BTC luôn có thể mang lại những người chơi mới và sự đồng thuận. Tuy nhiên, rất ít người đã đứng vững trước thử thách của thời gian. Với việc Lightling Labs đầy tham vọng công bố kế hoạch xây dựng Đồng tiền ổn định dựa trên Tài sản Taproot và Tether tuyên bố lựa chọn RGB để đúc USDT trên lớp đầu tiên của Bitcoin, rõ ràng là OmniLayer (Mastercoin) nổi tiếng một thời không còn là lớn nhất nữa. người chơi trong hệ sinh thái BTC. Các giao thức tài sản Xác thực phía máy khách (CSV) đang bắt đầu được chú ý, khác với các giao thức tài sản BTC truyền thống bằng cách kết hợp các tính năng cho khả năng mở rộng của Bitcoin. Nhưng đối mặt với vô số giao thức tài sản như vậy trong hệ sinh thái BTC, người ta phải đặt câu hỏi: sự khác biệt của chúng là gì? Và chúng ta nên chọn và tìm kiếm cơ hội cho riêng mình như thế nào trong vô số giao thức tài sản này?

Bài viết này nhằm mục đích hướng dẫn người đọc xem xét các giao thức tài sản khác nhau đã xuất hiện trong lịch sử của Bitcoin, đi sâu vào quỹ đạo tiềm năng 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

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

Yoni Assia nhằm mục đích tạo ra nền kinh tế BTC 2.0 thông qua phương pháp này - bất kỳ cộng đồng nào cũng có thể tạo ra nhiều loại tiền tệ theo cách này. Cách tiếp cận sử dụng Bitcoin làm công nghệ cơ bản để thanh toán bù trừ các giao dịch và tránh chi tiêu gấp đôi chắc chắn là một ý tưởng rất táo bạo vào thời điểm đó.

Là một giao thức phát hành tài sản dựa trên Bitcoin, phương pháp của Colored Coins là “tô màu” một lượng Bitcoin nhất định để đại diện cho những tài sản này. Những Bitcoin được đánh dấu này về mặt chức năng vẫn là Bitcoin, nhưng chúng cũng đại diện cho một tài sản hoặc giá trị khác. Nhưng làm thế nào ý tưởng này có thể được thực hiện trên Bitcoin?

Vào ngày 3 tháng 7 năm 2014, ChromaWay đã phát triển giao thức Tiền xu màu dựa trên Pay-to-Script-Hash (P2SH) nâng cao (EPOBC), giúp đơn giản hóa quy trình cho các nhà phát triển tạo ra các đồng tiền màu. Đây là giao thức sớm nhất áp dụng chức năng OP_RETURN của Bitcoin Script.

Việc thực hiện cuối cùng được hiển thị trong hình ảnh sau:

)

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

Mã thông báo đồng nhất và giá trị ràng buộc tối thiểu

Trong giao dịch Genesis, nếu một đồng xu màu được ràng buộc với 1000 sats thì đơn vị phân chia nhỏ nhất của đồng xu màu này là 1 sats. Điều này có nghĩa là tài sản hoặc mã thông báo có thể được chia hoặc phân bổ thành tối đa 1000 phần (nhưng đây chỉ là lý thuyết, để ngăn chặn các cuộc tấn công bụi, ví dụ: sat trước đây được đặt ở 546 SAT và sau đó là thứ tự cao hơn ).

Vấn đề xác minh

Để xác định tính xác thực và quyền sở hữu của một đồng tiền có màu, cần phải theo dõi và xác minh từ giao dịch ban đầu của tài sản đến UTXO hiện tại. Do đó, điều cần thiết là phải phát triển một ví chuyên dụng và nút đầy đủ đi kèm và thậm chí cả trình duyệt.

Rủi ro tiềm ẩn của việc kiểm duyệt thợ mỏ

Do các đặc điểm riêng biệt của ColoredTransaction, bao gồm việc ghi thông tin siêu dữ liệu vào đầu ra, nên có khả năng xảy ra kiểm duyệt của 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 minh của Bitcoin để theo dõi việc chuyển giao tài sản. Tuy nhiên, để chứng minh rằng bất kỳ đầu ra cụ thể nào (txout) đại diện cho một nội dung nhất định, cần phải có toàn bộ chuỗi chuyển giao từ nguồn gốc của nội dung đó đến hiện tại. Điều này có nghĩa là việc xác minh tính hợp pháp của một 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ó đề xuất cho OP_CHECKCOLORVERIFY hỗ trợ xác minh trực tiếp tính chính xác của các giao dịch Đồng xu màu trên BTC, nhưng đề xuất này đã không được thông qua.

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

Khái niệm ban đầu về Mastercoin đượ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”, mô tả khái niệm tạo tài sản hoặc mã thông báo mới trên chuỗi khối hiện có của Bitcoin, sau này được gọi là “MasterCoin”. Sau đó nó được đổi tên thành Omni Layer.

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

Trên thực tế, khái niệm Mastercoin có trước Đồng xu màu. Lý do nó được thảo luận thứ hai ở đây là vì so với Colored Coins, Mastercoin là một giải pháp tương đối phức tạp hơn. Mastercoin đã thiết lập một lớp nút hoàn chỉnh, từ đó cung cấp các chức năng phức tạp hơn (chẳng hạn 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 “tô màu” hoặc đánh dấu UTXO Bitcoin để đại diện cho các tài sản khác.

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

So với Đồng tiền màu, Mastercoin có thể thực hiện logic phức tạp hơn. Và vì nó không ghi lại trạng thái và thực hiện xác thực trên chuỗi nên các giao dịch của nó không yêu cầu tính liên tục (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 cậy trạng thái trong cơ sở dữ liệu ngoài chuỗi của các nút hoặc chạy các nút Lớp Omni của riêng họ để xác minh.

Tóm tắt:

Sự khác biệt chính giữa Mastercoin và Colored Coins là Mastercoin đã chọn không duy trì tất cả dữ liệu cần thiết cho giao thức trên chuỗi. Thay vào đó, nó sử dụng ký sinh hệ thống đồng thuận của BTC để thực hiện xuất bản và đặt hàng giao dịch của riêng mình, đồng thời 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 để mã hóa 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. Trong khi đó, OmniBolt đang giới thiệu Stark vào cơ sở hạ tầng Lightning Network của OmniLayer.

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

Để hiểu khái niệm xác thực phía khách hàng, chúng ta cần quay trở lại năm sau khi Xu màu và Mastercoin xuất hiện, tức là năm 2013. Vào năm đó, Peter Todd đã xuất bản một bài báo: “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 đề của bài viết dường như không liên quan trực tiếp đến việc xác thực phía khách hàng, nhưng khi đọc kỹ sẽ thấy rằng nó chứa đựng những suy nghĩ sáng suốt sớm nhất về xác thực phía khách hàng.

Peter Todd, một nhà nghiên cứu ban đầu về Bitcoin và mật mã, luôn tìm kiếm một phương pháp giúp 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 máy khách dựa trên khái niệm 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” sẽ được đề cập sau.

Theo suy nghĩ của Peter Todd, trước tiên chúng ta hãy cùng tìm hiểu những vấn đề mà BTC (Bitcoin) thực sự đã giải quyết được. Theo quan điểm của Peter Todd, BTC đã giải quyết được ba vấn đề:

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ụ: Alice có một số bitcoin mà cô ấy muốn chuyển cho Bob. Mặc dù cô ấy ký một giao dịch để chuyển cho Bob nhưng Bob có thể không biết về sự tồn tại của giao dịch đó. Vì vậy, cần phải có một nơi công cộng để công bố các giao dịch, nơi mọi người đều có thể truy vấn chúng.

Đồng thuận đặt hàng

Trong hệ thống máy tính, thời gian vật lý mà chúng ta thường cảm nhận được không tồn tại. Trong các hệ thống phân tán, thời gian thường được biểu thị bằng dấu thời gian Lamport, dấu thời gian này không đo thời gian vật lý mà ra lệnh cho các giao dịch của chúng ta.

Xác thực (Tùy chọn)

Xác thực trên BTC đề cập đến việc xác minh chữ ký và số tiền chuyển BTC. Tuy nhiên, ở đây, Peter Todd tin rằng việc xác thực này không cần thiết để xây dựng hệ thống mã thông báo dựa trên BTC mà là một tùy chọn tối ưu hóa.

Tại thời điểm này, bạn có thể nghĩ đến Ominilayer đã đề cập trước đó. Bản thân Ominilayer không ủy quyền tính toán và xác minh trạng thái cho BTC mà vẫn sử dụng lại tính bảo mật của BTC. Mặt khác, Colored Coins ủy quyền theo dõi trạng thái cho BTC. Sự tồn tại của cả hai chứng tỏ rằng việc xác nhận không nhất thiết phải diễn ra trên chuỗi.

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

Trước tiên chúng ta hãy xem những gì cần được xác nhận:

• Trạng thái (xác thực logic giao dịch)

• Nhập giá trị TxIn (để tránh chi tiêu gấp đôi)

Rõ ràng là đối với các tài sản được phát hành trên BTC, mỗi giao dịch đều yêu cầu xác minh toàn bộ lịch sử giao dịch liên quan để đảm bảo rằng đầ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 kém hiệu quả. Vì vậy, làm thế nào nó có thể được cải thiện?

Peter Todd tin 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 xác thực. 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 xác nhận 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 thực này có thể được thực hiện hiệu quả hơn vì mỗi xác thực 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 đó.

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

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

Nhưng làm thế nào để chúng ta lưu trữ cây cam kết như vậy trên chuỗi? Điều này dẫn chúng ta đến 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 xác thực phía khách hàng, 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 vận chuyển hàng hóa trong thế giới thực. Con dấu sử dụng một lần là một vật thể duy nhất có thể đóng chính xác tin nhắn một lần. Nói tóm lại, 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, nghĩa là con dấu
2. m: tin nhắn, tin nhắn
3. In:nhân chứng, nhân chứng

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

1. Close(l,m) → w: trong messagemupper đóng dấu, tạo ra một nhân chứngIn。
2. Verify(l,w,m) → bool: Verify seallBạn có biết tin tức không? Đã đóng nhầm.

Việc triển khai con dấu sử dụng một lần là về mặt bảo mật. Kẻ tấn côngm1andm2 không thể tìm thấy hai thông báo khác nhau và khiến hàm Xác minh trả về cùng một con dấu.

Trước hết, Con dấu sử dụng một lần là một khái niệm đảm bảo rằng một tài sản hoặc dữ liệu nhất định chỉ được sử dụng hoặc khóa một lần. Trong bối cảnh Bitcoin, điều này thường có nghĩa là UTXO (đầu ra giao dịch chưa chi tiêu) chỉ có thể được chi tiêu một lần. Do đó, đầu ra của giao dịch Bitcoin có thể được coi là con dấu một lần và khi đầu ra này được sử dụng làm đầu vào cho giao dịch khác, con dấu sẽ bị “hỏng” hoặc “đã được sử dụng”.

Đối với nội dung CSV trên BTC, bản thân Bitcoin đóng vai trò là “nhân chứng” được niêm phong một lần. Điều này là do, để xác thực giao dịch Bitcoin, 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 chi tiêu, các quy tắc đồng thuận của Bitcoin và các nút trung thực trên mạng sẽ từ chối giao dịch.

Nó có thể đơn giản hơn?

con dấu sử dụng một lần Nghĩa là, bất kỳ blockchain nào cũng được coi là cơ sở dữ liệu. Chúng tôi lưu trữ lời hứa về một tin nhắn nhất định trong cơ sở dữ liệu này theo một cách nào đó và duy trì trạng thái đã sử dụng hoặc sẽ được sử dụng cho thông báo đó.

Vâng, nó đơn giản như vậy.

Tóm lại, tài sản được khách hàng xác minh có các đặc điểm sau:

1. Lưu trữ dữ liệu ngoài chuỗi: Hầu hết 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 được khách hàng xác minh đều đượ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 cải thiện 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 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, từ đó đảm bảo tính toàn vẹn và không bị giả mạo của dữ liệu ngoài chuỗi.
3. Nhân chứng trực tuyến (không nhất thiết là BTC): Mặc dù hầu hết dữ liệu và xác minh đều nằm ngoài chuỗi, nhưng tài sản được khách hàng xác minh vẫn có thể tận dụng tính bảo mật của chuỗi cơ bản (phát hành bằng chứng, đặt hàng giao dịch) thông qua các cam kết được nhúng trên -xích.
4. Việc xác minh được thực hiện ở phía máy khách: Hầu hết công việc xác minh được thực hiện trên thiết bị của người dùng. Điều này có nghĩa là tất cả các nút mạng không cần tham gia xác minh từng giao dịch, chỉ những người tham gia 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 xác minh tài sản phía khách hàng, có một điểm khác cần lưu ý:

Khi giao dịch ngoài chuỗi và xác minh tài sản được khách hàng xác minh, bạn không chỉ phải hiển thị khóa riêng giữ tài sản mà còn phải hiển thị bằng chứng về đường dẫn merkel hoàn chỉnh của tài sản tương ứng.

Người tiên phong trong việc xác thực phía máy khách (CSV): RGB

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. Do sự nổi lên của Ethereum và sự phát triển của ICO và trước ICO, nhiều người đã cố gắng làm những việc ngoài Bitcoin, chẳng hạn như các dự án Mastercoin và Colored Coins. .

Giacomo Zucco bày tỏ sự thất vọng. Anh ấy tin rằng những dự án này kém hơn Bitcoin và anh ấy tin rằng những cách triển khai mã thông báo trên Bitcoin trước đây là không phù hợp. Trong quá trình này, anh đã gặp Peter Todd và bị mê hoặc bởi ý tưởng Xác thực phía khách hàng của Peter Todd. Sau đó anh ấy bắt đầu đề xuất ý tưởngRGB .

Sự khác biệt lớn nhất giữa RGB và các giao thức nội dung trước đó là ngoài các tính năng xác minh nội dung phía máy khách đã đề cập trước đó, nó còn bổ sung thêm một VM thực thi để triển khai công cụ thực thi hợp đồng hoàn chỉnh Turing. Ngoài ra, để đảm bảo tính bảo mật cho dữ liệu hợp đồng, Schema và Interface cũng được thiết kế. Schema tương tự như Ethereum, khai báo nội dung và chức năng của hợp đồng, còn Interface 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 các ngôn ngữ lập trình.

Các 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 không vượt quá hành vi mong đợi khi vm được thực thi, chẳng hạn như RGB20 và RGB21, chịu trách nhiệm tương ứng đối với một số hạn chế đối với giao dịch của mã thông báo có thể thay thế và mã thông báo không thể thay thế.

Cơ chế cam kết của RGB: Pedersen Hash

Về cơ chế cam kết, RGB áp dụng Pedersen Hash. Ưu điểm của nó nằm ở chỗ có thể 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 được bảo vệ quyền riêng tư và ẩn các giá trị bên trong nó. Cấu trúc này có thể được sử dụng trong một số giao thức bảo vệ quyền riêng tư cụ thể, 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 của RGB: Từ đơn giản đến AluVM

RGB không chỉ nhằm mục đích triển khai giao thức tài sản được khách hàng xác thực 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. Trong thiết kế ban đầu của RGB, nó tuyên bố sử dụng ngôn ngữ lập trình có tên là Đơn giản. Ngôn ngữ này có đặc điểm là tạo ra bằng chứng thực thi trong khi thực thi các biểu thức, giúp việc xác minh chính thức các hợp đồng được viết trong đó trở nên dễ dàng hơn (để tránh lỗi). Tuy nhiên, sự phát triển của ngôn ngữ này không được lý tưởng và cuối cùng đã gặp phải nhiều khó khăn. Điều này trực tiếp dẫn đến sự ra đời khó khăn của giao thức RGB vào năm đó. Cuối cùng, RGB bắt đầu sử dụng 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, hiện đang sử dụng Rust.

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

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

RGB và mạng Lightning

Nói một cách đơn giản, nguyên tắc của Lightning Network là hai bên tham gia vào một giao dịch sẽ ký một loạt hợp đồng (giao dịch cam kết) ngoài chuỗi. Những điều này đảm bảo rằng nếu bất kỳ bên nào vi phạm hợp đồng, 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 bên kia. 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 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 Lightning Network của riêng mình bằng cách thiết kế các quy tắc hợp đồng kênh thanh toán phù hợp với chính mình, nhưng độ phức tạp của Lightning Network là cực kỳ cao và việc xây dựng hệ thống này không phải là một nhiệm vụ dễ dàng. Tuy nhiên, ngược lại, Lightnling Labs đã phát triển lĩnh vực này trong nhiều năm và LND chiếm hơn 90% thị phần.

Sidechain của RGB: Prime

LNP-BP, hiện đang duy trì giao thức RGB, trong khi Maxim đưa ra một đề xuất có tên Prime vào tháng 6 năm 2023, một kế hoạch mở rộng tài sản được khách hàng xác thực. Trong đó, ông chỉ trích các kế hoạch mở rộng sidechain và Lightning Network hiện có là quá phức tạp trong quá trình phát triển. Maxim chỉ ra rằng ông 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, cả hai đều cần hơn hai năm phát triển. Tuy nhiên, Prime có thể được hoàn thành chỉ trong một năm.

Prime không phải là một thiết kế blockchain truyền thống mà là một lớp xuất bản bằng chứng mô-đun được thiết kế để xác thực ứng dụng khách, bao gồm bốn phần:

1. Dịch vụ dấu thời gian: Xác định chuỗi giao dịch nhanh nhất là 10 giây.

2. Bằng chứng: Được lưu trữ ở định dạng PMT, được sản xuất và xuất bản cùng với tiêu đề khối.

3. Con dấu một lần: Giao thức con dấu một lần trừu tượng, đảm bảo bảo vệ chi tiêu gấp đôi. Nếu đượ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ó thể phân đoạn - RGB (có thể thay thế).

Để giải quyết vấn đề về 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 các giao dịch ngoài chuỗi và gói gọn các giao dịch và ID thành các khối. Đồng thời, bằng chứng giao dịch trên Prime có thể được hợp nhất thêm thông qua PMT và sau đó được neo vào BTC theo cách tương tự như các đ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 sử dụng để phát hành tài sản được khách hàng xác thực 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 nằm ở việc tận dụng tính bảo mật và ổn định của mạng Bitcoin cũng như tốc độ, khả năng mở rộng và chi phí thấp của Lightning Network. Giao thức này được thiết kế và phát triển bởi CTO roasbeef của Lightnling Labs, người có thể là người duy nhất trên hành tinh này đã đí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), đồng thời có hiểu biết sâu sắc của 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 của hợp đồng thông minh (TapScript). Dựa trên điều này, việc mã hóa tài sản của Taproot Assets giống như việc tạo định nghĩa mã thông báo tương tự như 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 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 của Tài sản Taproot như sau: [Phần mô tả kết thúc ở đây, cho biết phần tiếp theo của bài viết có thể đi sâu vào các chi tiết kỹ thuật của cấu trúc mã hóa Tài sản Taproot.]

Hình ảnh qua Lightning Labs CTO roasbeef

Là giao thức tài sản CSV (CoinSwap), Tài sản Taproot được thiết kế để hợp lý hơn so với RGB. Họ tối đa hóa việc sử dụng các tiến bộ hiện tại trong hệ sinh thái BTC, chẳng hạn như nâng cấp Taproot và PSBT (Giao dịch Bitcoin được ký một phần). Sự khác biệt đáng kể nhất giữa Taproot Assets và RGB về khả năng mở rộng ứng dụng nằm ở VM thực thi (Máy ảo). Taproot Assets sử dụng TaprootScriptVM, giống như VM gốc được BTC sử dụng. Trong những năm gần đây, nhiều nghiên cứu về cơ sở hạ tầng cho BTC đều dựa trên TapScript. Tuy nhiên, do tốc độ nâng cấp BTC chậm nên các nghiên cứu này chưa được triển khai nhanh chóng, khiến Taproot Assets trở thành nơi thử nghiệm tiềm năng cho những ý tưởng mới này.

Tài sản Taproot và RGB khác nhau ở đâu?

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

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

1. Máy ảo thực thi

Tài sản Taproot xuất hiện sau khi nâng cấp Taproot. Họ sử dụng TaprootScriptVM, công cụ thực thi tập lệnh vốn có trong bản nâng cấp sau Taproot của Bitcoin và vPSBT, một biến thể của PSBT của BTC. Sau khi cơ chế kênh Lightning của Taproot Assets hoàn tất, nó có thể tái sử dụng ngay lập tức tất cả cơ sở hạ tầng LND hiện tại và các sản phẩm Lightning Labs trước đây (LND hiện thống trị hơn 90% mạng Lightning). Đề xuất BitVM gần đây, cũng dựa trên TaprootScript, về mặt lý thuyết hỗ trợ Tài sản Taproot. Tuy nhiên, VM và quy tắc xác thực (SCHema) của RGB là độc lập, tạo thành một hệ sinh thái tương đối khép kín. Sự phát triển của RGB phần lớn bị giới hạn trong hệ sinh thái của nó và sự tích hợp của nó với hệ sinh thái Bitcoin không chặt chẽ như người ta nghĩ. Ví dụ: mối quan hệ duy nhất của RGB với bản nâng cấp Taproot là mã hóa dữ liệu cam kết chuỗi vào TapLeaf của Witness.

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

Trong quá trình triển khai hiện tại của RGB, các hợp đồng và VM được nhấn mạnh rất nhiều. Tuy nhiên, hợp đồng thông minh vẫn chưa xuất hiện trong Taproot Assets. Hiện tại, RGB không giải thích cách các sửa đổi đối vớ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), cũng như cách các cam kết của Pedersen, chỉ đảm bảo tổng số lượng tài sản, phát hiện hành vi giả mạo với các trạng thái khác. Ngược lại, Taproot Assets, với thiết kế đơn giản hơn, hiện chỉ lưu trữ số dư tài sản và thiếu kho lưu trữ trạng thái rộng rãi, khiến việc thảo luận về hợp đồng thông minh trở nên sớm. Tuy nhiên, Lightning Labs đã chỉ ra rằng Taproot Assets sẽ tập trung vào thiết kế hợp đồng thông minh vào năm tới.

1. Trung tâm đồng bộ hóa

Như được hiểu từ các nguyên tắc cơ bản của việc xác minh tài sản phía khách hàng, việc giữ Bằng chứng cũng quan trọng như việc giữ khóa riêng. Nhưng điều gì sẽ xảy ra nếu Bằng chứng bị mất ở phía máy khách của người dùng? Trong Taproot Assets, vấn đề này có thể được giải quyết thông qua một '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 thông thường, Universe không lưu trữ 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 RGB, vai trò này do Storm đảm nhận, đồng bộ hóa dữ liệu bằng chứng ngoài chuỗi thông qua P2P. Tuy nhiên, vì lý do lịch sử của nhóm phát triển RGB, các định dạng in thử này hiện không tương thích. Nhóm hệ sinh thái của RGB, DIBA, được cho là đang phát triển 'carbonado' để giải quyết vấn đề này, mặc dù tiến độ vẫn chưa rõ ràng.

1. Thực hiện kỹ thuật

Tất cả các thư viện được Taproot Assets sử dụng đều đã được kiểm tra theo thời gian, vì Lightning Labs có ứng dụng khách Bitcoin (BTCD), ứng dụng khách mạng Lightning (LND) và nhiều triển khai lib ví. Ngược lại, hầu hết các thư viện được sử dụng trong RGB đều tự xác định và theo quan điểm tiêu chuẩn công nghiệp, việc triển khai RGB vẫn đang trong giai đoạn thử nghiệm.”

Thảo luận ngắn gọn về tương lai của việc mở rộng BTC

Khi cuộc thảo luận tiến triển, rõ ràng là việc xác thực các giao thức tài sản phía khách hàng đã vượt ra ngoài lĩnh vực thông số kỹ thuật giao thức và đang mạo hiểm hướng tới việc mở rộng tính toán.

Nhiều người tin rằng Bitcoin sẽ tồn tại dưới dạng vàng kỹ thuật số trong tương lai, cùng với các chuỗi khác tạo nên 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 diễn đàn BTC, chúng thường xoay quanh nhiều loại tiền thay thế khác nhau và sự tồn tại ngắn ngủi của chúng. Sự sụp đổ nhanh chóng của các altcoin này biến vốn và những nỗ lực xung quanh chúng thành bong bóng. Với nền tảng đồng thuận mạnh mẽ của Bitcoin, không cần phải xây dựng L1 mới cho các giao thức ứng dụng. Những gì chúng ta cần làm là tận dụng cơ sở hạ tầng mạnh mẽ này của Bitcoin để 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 thực trên chuỗi nhiều hơn

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

Xác thực xảy ra ở đâu? Cái này quan trọng

Đối với các nhà phát triển giao thức dựa trên Bitcoin, cách sử dụng Bitcoin để xác thực quan trọng hoặc thậm chí đặt xác thực ngoài chuỗi và cách thiết kế các sơ đồ bảo mật là những vấn đề đối với chính các nhà thiết kế giao thức. Những thứ này không nên và không cần phải được liên kết với chính chuỗi đó. Do đó, cách triển khai xác thực sẽ dẫn đến các chiến lược mở rộng khác nhau cho BTC.

Dựa trên quan điểm triển khai xác thực, chúng tôi có ba hướng mở rộng:

1. 1.Xác thực trên chuỗi (OP-ZKP)
2. Nếu OP-ZKP được triển khai trực tiếp trong TaprootScriptVM, điều đó có nghĩa là tích hợp khả năng xác thực ZKP vào chính BTC, cùng với một số thiết kế Covenant cho các giao thức thanh toán, tạo ra kế hoạch mở rộng Zk-Rollup kế thừa tính bảo mật của BTC. Tuy nhiên, không giống như việc triển khai hợp đồng xác thực trên Ethereum, quy trình nâng cấp chậm của BTC, cùng với mã hoạt động chuyên biệt và có khả năng cần nâng cấp, khiến việc này trở nên khó khăn.
4. 2.Xác thực bán trên chuỗi (BitVM)
5. Thiết kế của BitVM không nhằm mục đích phục vụ 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 thực này không xảy ra trên chuỗi mà xảy ra ngoài chuỗi. Tuy nhiên, lý do quan trọng để thiết kế xung quanh Taproot của BTC là sử dụng TapScriptVM để xác thực tính toán khi cần thiết, kế thừa tính bảo mật của BTC về mặt lý thuyết. Quá trình này cũng tạo ra một chuỗi tin cậy xác thực. Ví dụ: chỉ cần một trong số 'n' trình xác thực là trung thực, tương tự như Optimistic Rollups là đủ.
6. Chi phí trên chuỗi của BitVM cao, nhưng liệu nó có thể sử dụng bằng chứng gian lận ZK để cải thiện hiệu quả không? Câu trả lời là không, bởi vì việc triển khai bằng chứng gian lận ZK dựa trên khả năng thực hiện xác thực ZKP trên chuỗi, điều này đưa chúng ta trở lại vấn đề nan giải của kế hoạch OP-ZKP.
8. 3.Xác thực ngoài chuỗi (Xác thực phía máy khách, Lightning Network)
9. Với việc xác thực diễn ra hoàn toàn ngoài chuỗi, chúng tôi quay lại các giao thức tài sản CSV đã thảo luận trước đó và Lightning Network. Trong các cuộc thảo luận trước đây, đã lưu ý rằng trong thiết kế CSV, chúng tôi không thể ngăn chặn hoàn toàn hành vi giả mạo thông đồng. 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 phạm vi có thể kiểm soát được, khiến hành vi đó không có lợi.
10. Những ưu và nhược điểm của việc xác thực ngoài chuỗi là rõ ràng. Ưu điểm là sử dụng tối thiểu các tài nguyên trên chuỗi, có tiềm năng mở rộng to lớn. Nhược điểm là gần như không thể tận dụng tối đa tính bảo mật của BTC, hạn chế đáng kể các loại và phương thức giao dịch ngoài chuỗi. Hơn nữa, xác thực ngoài chuỗi cũng có nghĩa là dữ liệu được lưu giữ ngoài chuỗi, do người dùng quản lý, điều này đòi hỏi các 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à độ ổn định của phần mềm.

Xu hướng phát triển mở rộng

Hiện tại, Layer2 phổ biến trên Ethereum về bản chất sử dụng Layer1 để xác thực hiệu quả tính toán của Layer2. Nghĩa là, các tính toán trạng thái được đẩy xuống Lớp 2, nhưng việc xác thực vẫn ở Lớp 1. Trong tương lai, chúng ta có thể đẩy lùi các tính toán xác thực 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.