기술 공유: CAT20 - 프랙탈 BTC의 토큰 프로토콜

저자: ZAN 팀

이 기사는 기술적 공유만을 목적으로 하며 어떠한 투자 조언도 포함하지 않습니다.

비트코인에 자체 스마트 컨트랙트가 있을 예정인가요?

최근 비트코인 생태계에서 프랙탈 BTC는 여러 테스트넷을 거쳐 마침내 9월 메인넷에 출시되었습니다. 프랙탈의 주요 특징 중 하나는 '스마트 계약'을 가질 수 있다는 점이며, 메인넷 출시와 거의 동시에 프랙탈은 CAT20의 기술적 영리함은 무엇인가요? 그리고 우리는 무엇을 배울 수 있을까요?

프랙탈 비트코인

CAT20에 대해 자세히 알아보기 전에 ERC20과 ETH에 가까운 프랙탈 비트코인에 대해 간략히 살펴볼 필요가 있습니다. ERC20과 이더리움과 마찬가지로 CAT20 프로토콜은 프랙탈 비트코인에 배포됩니다.

프랙탈 비트코인은 프랙탈 비트코인으로도 알려져 있으며, BTC와 완전히 호환되는 '레이어 2' 네트워크입니다. BTC에 비해 블록 확인 시간이 1분으로 더 빠릅니다. 기본 원리는 이름에서 알 수 있듯이 간단합니다. BTC 네트워크는 여러 번 복사되어 각 체인이 거래를 처리하며, 거래를 처리할 수 있는 노드가 많을수록 더 빨라집니다. 그러나 서로 다른 체인이 서로 통신하는 방법에 대한 세부 사항은 명확하지 않으며, 공식적인 기술 문서도 없습니다.

더 빠른 트랜잭션을 처리하는 것이 단지 2계층 체인이라면 흥분할 필요는 없을 것 같습니다. 그러나 BTC가 보안상의 이유로 오래 전에 포기한 연산 코드인 프랙탈에서 OP_CAT을 활성화하면 프랙탈 비트코인의 기능이 한 단계 더 발전하고, OP_CAT이 BTC에 스마트 계약을 수행할 수 있는 기능을 제공한다는 이야기가 나오고 있어 상상의 여지가 훨씬 더 많아졌습니다.

이제 누군가가 프랙탈 비트코인에 ERC20과 유사한 프로토콜을 구현했습니다.

OP_CAT이 버려진 이유와 현재 프랙탈 비트코인에서 사용할 수 있는 이유에 대해서는 앞으로 더 자세히 다룰 예정이지만 여기서는 CAT20에 집중하겠습니다.

CAT 프로토콜

다음은 참고할 만한 자료입니다. 백서: 소개 | CAT 프로토콜(https://catprotocol.org/)

그리고 깃허브 저장소:

GitHub - CATProtocol/cat-. 토큰 박스: CAT 프로토콜을 구현하는 패키지를 위한 모노레포(https://github.com/CATProtocol/cat-token-box)

기본 OP_CAT 지원과 함께 얼마 지나지 않아 대응 프로토콜인 CAT 프로토콜이 등장했습니다. 이미 현실 세계에서 실행되고 있는 프로토콜 중 하나는 CAT20 프로토콜이며, 이에 해당하는 패널이 Unisat에 추가되었습니다: https://explorer.unisat. io/fractal-mainnet/cat20.

CAT20이라는 이름에서 예상할 수 있듯이, 이 프로토콜은 ERC20과 유사합니다. 이미 토큰 배포가 매우 쉬운 성숙한 ERC20 프로토콜과 비교했을 때, CAT20은 어떻게 ERC20과 비슷한 수명 주기를 달성할 수 있을까요?

배포

토큰을 배포하기 전에 사용자는 지갑 주소와 토큰에 대한 기본 정보를 지정해야 하며, 이는 ERC20과 유사합니다:

CAT20이 설정할 수 있는 몇 가지 차이점이 있습니다. 사전 채굴 및 민트당 수량 제한을 설정할 수 있습니다. 물론 ERC20도 계약 기능을 통해 이를 수행할 수 있습니다.

배포 단계에서는 두 개의 트랜잭션이 시작되며, 이는 "커밋"과 "공개"의 두 단계로 생각할 수 있습니다. 공식 다이어그램을 인용하자면, 배포 단계는 다음과 같습니다:

"커밋" 단계에서 트랜잭션의 출력 스크립트는 토큰의 이름, 심볼 등과 같은 토큰에 대한 기본 정보를 기록합니다. "커밋" 단계에서 시작된 트랜잭션의 해시아이디는 토큰을 다른 토큰과 구별하기 위해 토큰의 심볼로 사용됩니다.

보실 수 있습니다. 이 거래 " bc1pucq.... . ashx;"는 커밋에 해당하고 나머지 두 개는 " bc1pszp...rehc4"를 가리키고 있습니다. .rehc4" 트랜잭션에서 첫 번째는 다음 "공개" 단계에 대한 가스 요금을 지불하는 데 사용되며, 다른 하나는 변경입니다.

"reveal" 단계에서는 이전 커밋 단계의 처음 두 출력에 해당하는 두 개의 utxo 입력이 있는 것을 볼 수 있습니다. 이 트랜잭션은 먼저 CAT20의 초기 상태 해시가 저장되는 OP_RETURN을 출력한 다음, 이후 Mint 프로세스에서 중요한 역할을 하며 Mint 프로세스의 상태 변화를 유지하는 데 사용되는 Minter를 출력합니다.

전체 배포 프로세스를 살펴보면 가장 먼저 "commit"을 수행할 수 있습니다. 전체 배포 프로세스는 블록체인에서 일반적으로 사용되는 커밋과 공개라는 두 단계를 따르며, 프로젝트의 일부 데이터는 "공개" 단계에서만 공개되는 비교적 일반적인 프로젝트 배포 방식입니다.

민트

거래가 다음과 같이 보일 때 민트 토큰을 살펴보는 것부터 시작하겠습니다.

위 이미지에서 볼 수 있습니다. 에서 Mint의 프로세스는 다음과 같은 특징을 가지고 있음을 알 수 있습니다.

• 민트에 대한 입력은 처음에 배포를 통해 생성되는 채굴자입니다.

• 모든 민트에는 입력으로 단 하나의 채굴자만 있고 출력으로 원하는 수의 채굴자가 있습니다(약간 문제가 있습니다)

• 모든 민트에는 단 하나의 토큰만 있습니다(약간의 문제)

• 출력 순서는 필수이며, 채굴자 다음에 토큰이 와야 합니다

민트 프로세스를 알면 실제로 전체 민트 프로세스를 흥미롭게 만드는 몇 가지 특별한 경우를 찾을 수 있습니다.

예를 들어, 민트 트랜잭션의 결과물인 민터는 1, 다수, 심지어 0이 될 수도 있습니다. 모든 채굴기를 1로 설정하면 전체 네트워크에서 사용할 수 있는 채굴기의 수는 동일하게(1) 유지되어 채굴기가 혼잡해지고 모두가 채굴기를 잡아야 하므로 이러한 상황을 피하기 위해 매번 채굴기의 수를 1보다 크게 설정하여 채굴 후 사용할 수 있는 채굴기의 수가 점점 더 많아지도록 해야 합니다. 민터는 민트 이후 모든 사람이 점점 더 많이 사용할 수 있게 될 것입니다.

그러나 민터를 추가할 때마다 추가 유틸리티를 지불해야 하며, 경제적 이유로 민터를 0으로 설정하는 사람이 많아지면 민터가 줄어들 수밖에 없으므로 자발적으로 추가 민터를 지불하는 사람의 헌신이 필요합니다.

V2에서는 기본적으로 두 개의 채굴자가 생성되며, 두 채굴자의 상태는 최대한 비슷하게 유지됩니다.

트랜잭션 구성

몇 분 중 일부는 문제를 발견했을 수 있는데, 바로 왜 마이너의 utxo를 사용하여 트랜잭션을 구성할 수 있는 것일까요? 이를 이해하려면 "컨트랙트"의 소스 코드를 분석해야 합니다.

1. utxo 공개

먼저, 공개 과정의 트랜잭션을 분석해보면 이전 트랜잭션인 commit의 출력을 입력으로 사용한다는 것을 알 수 있습니다. 커밋을 입력으로 사용합니다. 어떻게 우리 주소가 아닌 utxo를 트랜잭션의 입력으로 사용할 수 있을까요?

상식적으로 개인 키는 공개 키에 대응하고, 공개 키는 주소를 도출합니다. 수신되는 UTXO의 유효성을 확인할 때는 일반적으로 공개 키로 해독한 서명이 원래 트랜잭션과 일치하는지 비교하여 결정합니다. 로직의 이 부분은 비트코인 스크립트에 작성되어 있습니다. 따라서 스크립트의 로직을 영리하게 재작성하여 자신의 주소에 대한 공개-개인 키 쌍을 포함하도록 하여 두 개의 다른 주소에 대한 utxo를 제어할 수 있습니다.

소스 코드를 보면 어떤 일이 벌어지고 있는지 알 수 있습니다.

또 다른 질문이 있는데, 개인 키는 공개 키에 해당하는데 왜 생성된 커밋 주소가 우리 키와 다른가 하는 것입니다. 다음은 소스 코드입니다

. 왼쪽;">즉, 개인 키는 P2TR 주소의 기능인 ISSUE_PUBKEY를 기반으로 공개 키를 조정합니다.

2. minter utxo

공개 과정에서는 다른 utxo를 입력으로 사용하지만 실제로는 암호화 키는 동일합니다! 즉, 배포자의 개인 키입니다. 하지만 채굴 단계에서는 누구나 이 utxo를 입력으로 사용할 수 있는데, 어떻게 작동할까요?

이 부분은 앞서 말씀드린 OP_CAT 기능으로, 각 마이너가 스마트 컨트랙트인 스마트 컨트랙트의 기능입니다. 다만 이 부분에 대한 소스코드는 공개되어 있지 않아서 어떻게 구현되어 있는지 모르겠습니다.

트랜잭션의 상태(V2)

마이너에는 상태도 있습니다. 이 상태는 트랜잭션 출력의 OP_RETURN과 앞서 언급한 민터와 토큰인 스마트 컨트랙트의 두 곳에 존재합니다.

OP_RETURN에는 트랜잭션 출력의 현재 상태의 해시가 저장되고 컨트랙트에는 토큰의 남은 민트가 저장됩니다. 컨트랙트에는 토큰의 남은 민트 수가 저장됩니다. 각 민트 이후, 새로 생성된 민터의 민트 수는 남은 민트 수를 2로 나눈 수와 같습니다. 이는 다이어그램으로 표시됩니다:

원래 다이어그램으로 돌아가서, 민터가 스마트 컨트랙트일 뿐만 아니라 생성된 토큰도 스마트 컨트랙트인 CAT20이며, 두 가지 기본 상태를 가지고 있습니다. CAT20은 토큰이 속한 사람의 번호와 주소라는 두 가지 기본 상태를 가지고 있습니다. 앞서 보신 것처럼 BRC20이나 민터와 달리 CAT20은 주소의 UTXO에 없습니다.

Transfer

Transfer는 생성된 트랜잭션의 입력 토큰과 출력 토큰의 개수가 일치해야 합니다. 물론 동일한 트랜잭션에 여러 개의 토큰이 있을 수 있으므로 서로 다른 토큰의 입력과 출력 토큰 수를 일관되게 유지하기만 하면 됩니다.

소각

토큰을 소각하려면 일반 주소로 토큰을 전송하기만 하면 됩니다.

요약

보시다시피 모든 연산이 사용자에 의해 구성되고 유연성이 많기 때문에 컨트랙트 부분에 많은 체크 로직이 있습니다. 지금까지 발견된 취약점 중 일부는 체크섬 로직에 대한 관리 소홀로 인한 것이기도 합니다.

이 디자인에는 몇 가지 장점이 있습니다.

1. 모든 토큰이 어떻게 보유되는지 알고 싶다면 토큰의 utxo만 확인하면 됩니다. 토큰의 utxo보다 더 멀리 갈 필요는 없습니다.

2. 민트의 현재 상태를 확인하려면 OP_RETURN에서 cat으로 트랜잭션을 검색할 수 있습니다.