CAT20：Fractal BTC上的Token giao thức

Bài viết này chỉ được sử dụng để chia sẻ về công nghệ, không cấu thành bất kỳ lời khuyên đầu tư nào.

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

Trong sinh quyển BTC gần đây, sau nhiều lần trải qua Testnet, Fractal BTC cuối cùng cũng đã ra mắt vào tháng 9 trên Mạng chính. Điểm đặc biệt lớn của Fractal là khả năng có "Hợp đồng thông minh" và gần như ngay khi ra mắt Mạng chính, họ cũng đã ra mắt một giao thức Token mới là CAT 20. CAT 20 có những thiết kế kỹ thuật tinh tế nào? Chúng ta có thể học được gì từ đó?

Fractal Bitcoin

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

Fractal Bitcoin, also known as fractal BTC, is a "second layer" network that is fully compatible with BTC. Compared to BTC, its confirmation time is faster, taking only 1 minute. The basic principle is as simple as its name suggests, which is to replicate the BTC network several times, with each chain processing transactions and more nodes to process transactions, thus naturally increasing the speed. However, the specific details, such as how different chains communicate with each other, are currently unclear, and there are no corresponding technical documents available from the official website to refer to.

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

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

Về tại sao OP_CAT bị bỏ bỏ và tại sao nó lại có thể được sử dụng trên Fractal Bitcoin, chúng ta có thể nói rõ hơn trong tương lai, ở đây chúng tôi theo dõi CAT 20.

Giao thức CAT Nội dung sau đây tham khảo White Paper: Giới thiệu | Giao thức CAT ()

Và kho github: GitHub - CATProtocol/cat-token-box: Một monorepo cho các gói thực hiện giao thức CAT ()

Với sự hỗ trợ của OP_CAT ở tầng dưới, nhanh chóng đã có giao thức tương ứng, giao thức CAT. Hiện tại, một giao thức CAT 20 đã được triển khai thực tế và đã thêm bảng điều khiển tương ứng trên Unisat.

Khi nhìn thấy tên gọi CAT 20, mọi người cũng có thể nhận ra rằng nó giống ERC 20. So với giao thức ERC 20 đã trưởng thành, triển khai một Token đã trở nên rất thuận tiện, CAT 20 làm thế nào để thực hiện một vòng đời tương tự ERC 20?

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ư ERC 20:

Sẽ có một số điểm khác biệt. CAT 20 có thể thiết lập trước đào và giới hạn số lượng Mint mỗi lần. Tất nhiên, ERC 20 cũng có thể thực hiện 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 là hai giai đoạn: "commit" và "reveal". Theo hình ảnh chính thức, giai đoạn triển khai như sau:

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

Có thể thấy giao dịch này " bc 1 pucq...ashx " là utxo tương ứng với commit. Sau đó, hai giao dịch còn lại trỏ đến " bc 1 pszp...rehc 4 ", giao dịch đầu tiên được sử dụng để thanh toán phí gas cho giai đoạn "reveal" phía dưới, giao dịch còn lại là tiền thối.

Trong giai đoạn "reveal", bạn có thể thấy có hai đầu vào utxo, tương ứng với hai đầu ra đầu tiên trong giai đoạn cam kết trước đó. Giao dịch này sẽ đầu tiên đầu ra một OP_RETURN, trong OP_RETURN sẽ lưu trữ Hash trạng thái ban đầu của CAT 20. Sau đó sẽ đầu ra một Minter khác, nó sẽ đóng vai trò quan trọng trong quá trình Mint tiếp theo, được sử dụng để duy trì sự thay đổi trạng thái trong quá trình Mint.

Quay lại quá trình triển khai, "commit" và "reveal" tuân theo hai bước thường được sử dụng trên chuỗi on-chain, 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

Chúng ta hãy xem xét cách giao dịch khi Mint Token, như sau.

Trong biểu đồ trê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 người tạo tiền, ban đầu được tạo ra khi triển khai.
• Mỗi lần mint đều chỉ có một minter là đầu vào và có thể có bất kỳ số lượng minter nào là đầu ra (một chút vấn đề)
• Mỗi lần mint đều chỉ có một token (có một chút vấn đề)
• Thứ tự đầu ra được yêu cầu, sau 'minter' phải là 'token'

Sau khi 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, khiến cho toàn bộ quá trình Mint trở nên thú vị.

Ví dụ, minter là đầu ra của giao dịch mint, có thể là 1, nhiều hoặc thậm chí là 0. Nếu mỗi lần Mint đều được đặt là 1, lượng minter có thể sử dụng trong toàn bộ mạng sẽ không thay đổi (1), điều này sẽ làm cho Mint trở nên đông đúc, mọi người đều cần tranh giành minter này, để tránh tình huống này, cần thiết phải đặt 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 ngày càng nhiều.

Tuy nhiên, mỗi lần xuất hiện thêm một minter đều đồng nghĩa với việc 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 thiết lập minter thành 0, điều này sẽ không tránh khỏi việc làm cho minter trở nên thu hẹp, điều này đòi hỏi một số người phải tự nguyện chi trả thêm minter.

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àng giống nhau càng tốt.

Xây dựng giao dịch

Có thể có một số 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, chúng ta cần phân tích mã nguồn của 'hợp đồng'.

1、tiết lộ utxo

Đầu tiên, chúng tôi phân tích giao dịch trong quá trình tiết lộ và phát hiện rằng anh ấy sử dụng commit đầu ra của giao dịch trước làm đầu vào. Tại sao anh ấy có thể sử dụng đầu vào của giao dịch không phải là Địa chỉ 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 đầu vào utxo, thường là bằng cách so sánh chữ ký được giải mã bằng Khóa công khai có khớp với giao dịch ban đầu hay không. Phần logic này được viết trong BTC script. Vì vậy, chúng ta có thể thông minh thay đổi logic của script, viết Khóa riêng công khai trong script là Địa chỉ của chính chúng ta, từ đó chúng ta có thể kiểm soát hai utxo của hai Địa chỉ khác nhau.

Chỉ cần xem mã nguồn, chúng ta có thể biết đã xảy ra điều gì:

Ở đây cũng sẽ có một vấn đề, đó 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? Ở đây có thể thấy trong mã nguồn

Nghĩa là, 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ỉ P 2 TR.

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ưng thực tế là mã hóa chìa khoá bảo mật là giống nhau, tức là khóa riêng 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 làm đầu vào, điều này làm thế nào?

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 một người khai thác đều là một hợp đồng thông minh. Nhưng hiện tại mã nguồn của phần này chưa được công bố, tạm thời không biết cụ thể cách thức triển khai như thế nào.

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

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

Trong OP_RETURN được lưu trữ 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 còn lại của Token. Sau mỗi lần Mint, số lượng mint mới của Minter sẽ bằng số lượng có thể mint còn lại chia cho hai. Được biểu thị như sau:

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

Quay lại bức tranh 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ụ thể là CAT 20. CAT 20 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 BRC 20 hoặc chữ khắc trước đó, CAT 20 của bạn không nằm trên UTXO của bạn (Địa chỉ).

Chuyển khoản

Khi thực hiện Transfer, 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 nhau. 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 token đầu vào và đầu ra của các token khác nhau giữ nguyên nhau là được.

Đốt Cháy

Để đốt 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 phát hiện gần đây cũng là do sự sơ suất trong logic kiểm tra.

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

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

ZAN Không cần cửa để nhận nước đến rồi!

Lưu ý: Bạn có thể nhận 0,01 ETH miễn phí trên mạng thử nghiệm mỗi 24 giờ để hỗ trợ trải nghiệm và thử nghiệm các dự án Web3 trên mạng ETH. Nhấn vào đây để nhận ngay:

Sắp có thêm nhiều chuỗi khối công cộng được hỗ trợ～

Bài viết này được viết bởi Yeezo (tài khoản X @GaoYeezo 75065) của ZAN Team (tài khoản X @zan_team).