Chia sẻ công nghệ: CAT20 - Giao thức Token trên BTC fractal

Tác giả: ZAN Team

Bài viết này chỉ dùng để chia sẻ công nghệ, không đưa ra bất kỳ lời khuyên đầu tư nào.

BTC cũng cần có hợp đồng thông minh riêng của nó à?

Gần đây trong sinh thái BTC, sau nhiều lần Testnet, Fractal BTC cuối cùng đã ra mắt Mạng chính vào tháng 9. Một trong những đặc điểm quan trọng của Fractal là khả năng có chức năng “hợp đồng thông minh”, và gần như đồng thời với việc ra mắt Mạng chính, Fractal cũng ra mắt một giao thức Token mới là CAT20. Thiết kế kỹ thuật của CAT20 có những điểm thiết kế tinh vi nào? Chúng ta có thể học được gì từ đó?

Bitcoin Fractal

Trước khi tìm hiểu về CAT20, chúng ta cần hiểu một cách đơn giản về Fractal Bitcoin, mối quan hệ của họ giống như ERC20 và ETH, giao thức CAT20 được triển khai trên Fractal Bitcoin.

Fractal Bitcoin cũng được gọi là BTC phân cấp, là một mạng “lớp hai” hoàn toàn tương thích với BTC. So với BTC, thời gian xác nhận Khối của nó nhanh hơn, chỉ mất 1 phút. Nguyên tắc cơ bản của nó đơn giản như tên gọi của nó, là sao chép mạng BTC mà mỗi chuỗi xử lý giao dịch và số nút có thể xử lý giao dịch nhiều hơn, do đó tốc độ tự nhiên cũng nhanh hơn. Tuy nhiên, các chi tiết cụ thể như cách các chuỗi khác nhau giao tiếp với nhau hiện vẫn chưa rõ ràng, và không có tài liệu kỹ thuật tương ứng mà có thể tham khảo.

Nếu chỉ là giao dịch trên một chuỗi lớp hai nhanh hơn, có vẻ không có điểm hấp dẫn. Nhưng trong Fractal, việc kích hoạt OP_CAT, một mã thao tác đã bị bỏ qua lâu đời vì lý do an toàn, đã đưa khả năng của Bitcoin Fractal lên một tầm cao mới, một số người nói rằng OP_CAT có thể làm cho BTC có khả năng Hợp đồng thông minh, điều này mở ra nhiều cơ hội tưởng tượng hơn.

Hiện tại, đã có người triển khai một giao thức tương tự như ERC20 trên Fractal Bitcoin.

Về tại sao OP_CAT bị loại bỏ và tại sao nó lại có thể được sử dụng trên Fractal Bitcoin, chúng tôi có thể giải thích sau này, ở đây chúng tôi theo dõi CAT20.

Giao thức CAT

以下内容参考White Paper：Introduction | CAT Protocol (*)

Và kho lưu trữ github:

GitHub - CATProtocol/cat-token-box: A monorepo for packages implementing CAT protocol (*)

Với sự hỗ trợ của OP_CAT ở tầng dưới, sớm sẽ có giao thức tương ứng, CAT Protocol. Hiện tại, một trong những giao thức thực tế đã được triển khai là giao thức CAT20, và cũng đã thêm bảng điều khiển tương ứng trên Unisat: *

Khi nhìn thấy tên CAT20, mọi người cũng có thể nhận ra rằng nó nên giống ERC20. So với giao thức ERC20 đã chín muồi, việc triển khai một Token đã trở nên rất thuận tiện, CAT20 đã thực hiện vòng đời tương tự như ERC20 như thế nào.

Triển khai

Trước khi triển khai, người dùng cần xác định Ví tiềnĐịa chỉ và thông tin cơ bản của Token của họ, thông tin cơ bản của Token tương tự như của ERC20:

Sẽ có một số điểm khác biệt. CAT20 có thể thiết lập giới hạn số lượng đào trước và mỗi lần Mint. Tất nhiên, ERC20 cũng có thể đạt được những khả năng này thông qua khả năng của hợp đồng.

Trong giai đoạn triển khai, sẽ có hai giao dịch được khởi xướng, có thể coi như là hai giai đoạn: “commit” và “reveal”. Trích dẫn từ hình ảnh chính thức, các giai đoạn triển khai như sau:

Trong giai đoạn “commit”, các thông tin cơ bản về Token như tên và ký hiệu của Token sẽ được viết vào kịch bản đầu ra của giao dịch. hashId của giao dịch được khởi tạo trong giai đoạn “commit” sẽ được sử dụng làm định danh cho Token đó, để phân biệt với các Token khác.

Bạn có thể thấy giao dịch này “bc1pucq…ashx” là UTXO tương ứng với mục “commit”. Sau đó, hai giao dịch còn lại trỏ đến “bc1pszp…rehc4”, giao dịch đầu tiên được sử dụng để thanh toán phí gas cho giai đoạn “reveal” dưới đây, trong khi giao dịch còn lại là tiền thối.

Ở giai đoạn “reveal”, bạn có thể thấy có hai đầu vào UTXO, tương ứng với hai đầu ra ở giai đoạn commit trước đó. Giao dịch này sẽ đầu tiên đầu ra một OP_RETURN, trong đó sẽ lưu trữ Hash trạng thái ban đầu của CAT20. Sau đó, nó sẽ đầu ra một Minter, nó sẽ đóng vai trò quan trọng trong quá trình Mint tiếp theo, để duy trì sự thay đổi trạng thái của quá trình Mint.

Nhìn lại quá trình triển khai tổng thể, “commit” và “reveal” tuân theo hai bước thông thường trong việc gửi và tiết lộ trên chuỗi, đây là một cách triển khai dự án phổ biến, một số dữ liệu của dự án chỉ được tiết lộ trong giai đoạn “reveal”.

Mint

Trước tiên, chúng ta hãy xem xét quá trình giao dịch của Mint Token.

Trong hình trên, bạn có thể thấy quá trình Mint có những đặc điểm sau đây.

• Đầu vào của mint là một minter, ban đầu được tạo ra khi triển khai.
• Mỗi lần mint đều có một và chỉ một người mint làm đầu vào, có bất kỳ số lượng người mint nào làm đầu ra (có một chút vấn đề)
• Mỗi lần mint đều chỉ có một token (có một vấn đề nhỏ)
• Thứ tự đầu ra là bắt buộc, phải là token sau minter

Hiểu quá trình Mint, chúng ta thực sự có thể phát hiện ra một số trường hợp đặc biệt, làm cho toàn bộ quá trình Mint trở nên thú vị.

Ví dụ, minter như một đầu ra giao dịch mint, nó có thể là 1, nhiều hoặc thậm chí là 0. Nếu mỗi lần Mint được thiết lập là 1, thì số lượng minter có thể sử dụng trong toàn mạng sẽ được duy trì không đổi (1), điều này sẽ khiến cho Mint trở nên đông đúc, mọi người đều cần tranh giành minter này, để tránh tình trạng này, cần thiết phải thiết lập số lượng minter đầu ra mỗi lần lớn hơn 1, sau khi mint, mọi người có thể sử dụng minter sẽ càng ngày càng nhiều.

Tuy nhiên, việc tăng một minter nghĩa là bạn cần phải thanh toán thêm một khoản utxo. Vì lợi ích kinh tế, nhiều người sẽ sẵn lòng đặt minter thành 0, điều này sẽ không thể tránh khỏi làm cho minter trở nên suy thoá, điều này đòi hỏi một số người phải hiến tặng, tự nguyện thanh toán phần minter thừa.

Trong phiên bản V2, mặc định sẽ tạo ra hai Minter và trạng thái của hai Minter sẽ cố gắng giữ nguyên mức độ tương đồng nhất có thể.

Xây dựng giao dịch

Có thể có bạn đã phát hiện ra một vấn đề, đó là tại sao có thể sử dụng utxo của minter để xây dựng giao dịch? Để hiểu vấn đề này, cần phân tích mã nguồn của ‘hợp đồng’.

1、tiết lộ utxo

Đầu tiên, chúng ta phân tích giao dịch trong quá trình tiết lộ và nhận thấy rằng anh ấy đã sử dụng commit của đầu ra giao dịch trước làm đầu vào. Tại sao anh ấy có thể sử dụng đầu vào giao dịch không phải là utxo của chúng tôi để xây dựng giao dịch?

Theo lý thường, một Khóa riêng tương ứng với một Khóa công khai, Khóa công khai tạo ra Địa chỉ. Khi xác minh tính hợp lệ của một utxo đầu vào, thông thường là bằng cách so sánh xem việc giải mã bằng Khóa công khai có trùng khớp với giao dịch ban đầu hay không để xác định. Phần logic này được viết trong kịch bản BTC. Vì vậy, chúng ta có thể thông minh thay đổi logic của kịch bản, viết logic trong kịch bản với Khóa riêng công khai là Địa chỉ của chính chúng ta, điều này giúp chúng ta có thể kiểm soát hai utxo của hai Địa chỉ khác nhau.

Chúng ta chỉ cần nhìn vào mã nguồn là có thể biết được đã xảy ra điều gì:

Ở đây còn một vấn đề nữa, đó là một Khóa riêng tương ứng với một Khóa công khai, vậy tại sao commit Địa chỉ được tạo ra lại khác với Địa chỉ của chúng ta? Điều này có thể được thấy từ mã nguồn.

Nói cách khác, Khóa riêng của chúng tôi sẽ được điều chỉnh dựa trên một ISSUE_PUBKEY để điều chỉnh Khóa công khai, đây cũng là một đặc điểm của Địa chỉ P2TR.

2、minter utxo

Trong quá trình tiết lộ, chúng tôi sử dụng các đầu ra utxo khác nhau như là đầu vào, nhưng thực tế là mã hóa của chìa khoá bảo mật là cùng một bộ, tức là của người triển khai. Nhưng trong giai đoạn minter, tất cả mọi người đều có thể sử dụng các đầu ra utxo này như là đầu vào, điều này làm thế nào được thực hiện?

Phần này tôi đoán là khả năng của OP_CAT đã nói trước đó, cũng chính là khả năng của hợp đồng thông minh, mỗi người tạo coin (minter) chính là một hợp đồng thông minh. Nhưng mã nguồn của phần này hiện tại chưa được công khai, nên tạm thời không biết cụ thể cách triển khai như thế nào.

Trạng thái Giao dịch (V2)

Trong minter, trạng thái được giữ lại. Trạng thái này tồn tại ở hai nơi: một là trong OP_RETURN của đầu ra giao dịch và hai là được lưu trữ trong hợp đồng thông minh, cũng là Minter và Token đã được đề cập ở trên.

Trong OP_RETURN là Hash trạng thái đầu ra giao dịch hiện tại, trong hợp đồng sẽ lưu trữ số lần Mint Token còn lại. Sau mỗi lần Mint, số lượng mint của Minter mới sẽ bằng số lần mint còn lại chia cho hai. Được biểu diễn như sau:

Khi kết thúc, số lượng Minter còn lại là 0.

Quay lại hình vẽ ban đầu, ngoài việc Minter là một hợp đồng thông minh, Token được tạo ra cũng là một hợp đồng thông minh, còn được gọi là CAT20. CAT20 có hai trạng thái cơ bản: số lượng và chủ sở hữu của Token (Địa chỉ). Như bạn có thể thấy, khác với BRC20 hoặc chữ khắc trước đây, CAT20 của bạn không nằm trên UTXO của bạn (Địa chỉ).

Chuyển khoản

Khi chuyển tiền, số lượng token trong các đầu vào và đầu ra của giao dịch cần phải giữ nguyên. Tất nhiên, trong cùng một giao dịch có thể có nhiều token khác nhau, chỉ cần số lượng đầu vào và đầu ra của các token khác nhau giữ nguyên là được.

Đốt cháy

Để đốt cháy TOKEN, bạn chỉ cần chuyển TOKEN đến một Địa chỉ thông thường.

Tổng kết

Có thể thấy, tất cả các hoạt động đều do người dùng tự xây dựng, linh hoạt rất lớn, vì vậy trong phần hợp đồng cần phải thực hiện rất nhiều logic kiểm tra. Một số lỗ hổng được phát hiện hiện nay cũng là do sự bất cẩn trong logic kiểm tra.

Thiết kế như vậy có thể mang lại một số lợi ích:

1. Nếu bạn muốn tìm kiếm tình hình sở hữu của tất cả các TOKEN, chỉ cần kiểm tra utxo của token là được, không cần tiếp tục tìm kiếm lên trên.
2. Nếu bạn muốn xem tình trạng hiện tại của mint, bạn có thể tìm kiếm giao dịch trong OP_RETURN có dữ liệu chứa từ khóa “cat”.