이 글은 기술적 공유만을 위한 것이며 투자 조언을 구성하지 않습니다.
BTC에도 자체 스마트 계약이 있나요?
최근 비트코인 생태계에서 프랙탈 BTC는 수많은 테스트넷을 거쳐 마침내 9월에 메인넷을 출시했습니다. Fractal의 주요 특징은 스마트 계약을 가질 수 있는 능력이며, 메인넷이 출시됨과 거의 동시에 새로운 토큰 프로토콜 CAT 20이 출시되었습니다. CAT 20에는 어떤 기술적 독창성이 있습니까? 우리는 무엇을 배울 수 있나요?
프랙탈 비트코인
CAT 20을 이해하기 전에 Fractal Bitcoin의 관계를 간략하게 이해해야 합니다. CAT 20 프로토콜은 Fractal Bitcoin에 배포됩니다.
프랙탈 비트코인(Fractal Bitcoin)이라고도 알려진 프랙탈 비트코인(Fractal Bitcoin)은 BTC와 완벽하게 호환되는 두 번째 계층 네트워크입니다. BTC에 비해 블록 확인 시간이 1분 밖에 걸리지 않아 더 빠릅니다. 기본 원칙은 이름에서 알 수 있듯이 BTC 네트워크를 여러 번 복제하는 것입니다. 각 체인은 트랜잭션을 처리할 수 있는 노드가 많을수록 자연스럽게 더 빨라집니다. 그러나 서로 다른 체인이 어떻게 통신하는지 등 구체적인 세부 사항은 아직 명확하지 않으며 참고할 수 있는 해당 공식 기술 문서도 없습니다.
2계층 체인 거래만 빠르면 별 감흥이 없을 것 같습니다. 그러나 오래전 보안상의 이유로 BTC가 포기했던 Fractal에서 OP_CAT의 활성화로 인해 Fractal Bitcoin의 기능이 더 높은 수준으로 향상되었습니다. 상상의 여지가 더 많습니다.
이제 누군가 Fractal Bitcoin에서 ERC 20과 유사한 프로토콜을 구현했습니다.
OP_CAT이 폐기된 이유와 Fractal Bitcoin에서 사용할 수 있는 이유에 대해서는 나중에 CAT 20에 초점을 맞춰 이야기하겠습니다.
CAT 프로토콜 다음 내용은 백서를 참조하십시오. CAT 프로토콜 소개( https://catprotocol.org/ )
그리고 github 저장소: GitHub - CATProtocol/cat-token-box: CAT 프로토콜을 구현하는 패키지용 모노레포( https://github.com/CATProtocol/cat-token-box )
기본 OP_CAT 지원을 통해 해당 프로토콜인 CAT 프로토콜이 곧 제공될 예정입니다. 현재 실제로 실행되고 있는 프로토콜은 CAT 20 프로토콜이며, Unisat에 해당 패널이 추가되었습니다: https://explorer.unisat.io/fractal-mainnet/cat20 .
CAT 20이라는 이름을 보면 누구나 반응할 수 있어야 합니다. ERC 20과 더 유사해야 합니다. 성숙한 ERC 20 프로토콜과 비교하면 모든 사람이 토큰을 배포하는 것이 매우 편리합니다. CAT 20은 ERC 20과 유사한 수명 주기를 어떻게 구현합니까?
배포
배포하기 전에 사용자는 지갑 주소와 토큰에 대한 기본 정보를 지정해야 합니다. 토큰에 대한 기본 정보는 ERC 20의 정보와 유사합니다.
CAT 20은 각 민트에 대해 사전 채굴 및 수량 제한을 설정할 수 있습니다. 물론 ERC 20은 계약 기능을 통해 이러한 기능을 실현할 수도 있습니다.
배포 단계에서는 두 개의 트랜잭션이 시작됩니다. 이는 커밋과 공개의 두 단계로 간주될 수 있습니다. 공식 다이어그램을 인용하면 배포 단계는 다음과 같습니다.
커밋 단계에서는 토큰의 이름, 기호 등 토큰의 기본 정보가 트랜잭션의 출력 스크립트에 기록됩니다. 커밋 단계에서 시작된 트랜잭션의 hashId는 다른 토큰을 구별하기 위한 토큰의 기호로 사용됩니다.
이 트랜잭션 bc 1 pucq...ashx 의 utxo가 커밋에 해당함을 알 수 있습니다. 그런 다음 bc 1 pszp...rehc 4를 가리키는 두 개의 남은 트랜잭션이 있습니다. 첫 번째 트랜잭션은 다음 공개 단계에 대한 가스 요금을 지불하는 데 사용되고 다른 트랜잭션은 변경입니다.
공개 단계에서는 이전 커밋 단계의 처음 두 출력에 해당하는 두 개의 utxo 입력이 있음을 확인할 수 있습니다. 이 트랜잭션은 먼저 CAT 20의 초기 상태 해시가 저장되는 OP_RETURN을 출력합니다. 그런 다음 후속 Mint 프로세스에서 중요한 역할을 하고 Mint 프로세스의 상태 변경을 유지하는 데 사용되는 Minter가 출력됩니다.
전체 배포 프로세스를 되돌아보면 커밋과 공개는 블록체인에서 일반적으로 사용되는 제출 및 공개의 두 단계를 따릅니다. 이는 프로젝트의 일부 데이터가 공개에만 있는 비교적 일반적인 방법입니다. .스테이지가 공개됩니다.
박하
먼저 Mint Token을 살펴보면 트랜잭션은 이렇습니다.
위 그림에서 볼 수 있듯이 민트의 프로세스는 다음과 같은 특징을 가지고 있습니다.
mint의 입력은 배포 중에 처음 생성되는 minter입니다.
각 민트에는 입력으로 단 하나의 민트가 있고 출력으로 민트가 여러 개 있습니다(약간 문제가 있음)
각 민트에는 토큰이 하나만 있습니다(약간 문제가 있음).
출력 순서가 필요하며, minter 다음에 토큰이 와야 합니다.
Mint 프로세스를 알면 전체 Mint 프로세스를 흥미롭게 만드는 몇 가지 특별한 상황을 실제로 찾을 수 있습니다.
예를 들어 minter는 mint 트랜잭션의 출력이며 1, 배수 또는 0일 수도 있습니다. Mint를 매번 1로 설정하면 전체 네트워크에서 사용할 수 있는 Minter 수는 변경되지 않고(1) Mint가 혼잡해지며 이를 방지하려면 모두가 이 Minter를 가져와야 합니다. 이 경우, 매번 출력되는 민터 수를 1보다 크게 설정해야 민트 후에 더 많은 민터를 사용할 수 있습니다.
그러나 Minter의 추가 출력은 추가 utxo를 지불해야 함을 의미합니다. 경제적인 이유로 더 많은 사람들이 기꺼이 Minter를 0으로 설정하게 되며 이는 필연적으로 Minter 디플레이션을 초래하므로 일부 사람들은 기부하고 지불해야 합니다. 여분의 민트는 자발적으로.
V2 버전에서는 기본적으로 2개의 Minter가 생성되며, 두 Minter의 상태는 최대한 유사하게 됩니다.
거래 구조화
일부 친구들은 문제를 발견했을 수도 있습니다. 즉, 왜 Minter의 utxo를 사용하여 트랜잭션을 구성할 수 있습니까? 이 문제를 이해하려면 계약의 소스 코드를 분석해야 합니다.
1.UTXO 공개
먼저 공개 과정에서 트랜잭션을 분석한 결과 이전 트랜잭션의 출력 커밋을 입력으로 사용하는 것을 발견했습니다. 거래 입력을 구성하기 위해 우리 주소가 아닌 utxo를 사용할 수 있는 이유는 무엇입니까?
상식적으로 보면 개인키는 공개키에 해당하고, 공개키가 주소를 파생시킨다. 입력된 UTXO가 유효한지 검증할 때 일반적으로 공개키로 복호화된 서명이 원래 거래와 일치하는지 비교하여 판단한다. 로직의 이 부분은 비트코인 스크립트로 작성되었습니다. 따라서 우리는 스크립트의 논리를 영리하게 다시 작성할 수 있습니다. 스크립트에 작성된 공개 키와 개인 키 쌍은 우리 자신의 주소이므로 두 개의 다른 주소의 utxo를 제어할 수 있습니다.
소스 코드를 보면 무슨 일이 일어났는지 알 수 있습니다.
여기에는 또 다른 문제가 있습니다. 즉, 개인 키는 공개 키에 해당하는데 생성된 커밋 주소는 왜 우리 주소와 다른가요? 여기서 소스코드를 보면 알 수 있다
즉, 우리의 개인 키는 P 2 TR 주소의 특성이기도 한 ISSUE_PUBKEY에 따라 공개 키를 조정합니다.
2. 민터 UTXO
공개 프로세스 동안 우리는 다른 utxo를 입력으로 사용하지만 실제로 암호화 키는 배포자의 개인 키와 동일합니다. 그러나 Minter 단계에서는 모든 사람이 이러한 utxo를 입력으로 사용할 수 있습니다.
이 부분이 앞서 언급한 OP_CAT의 능력, 즉 스마트 컨트랙트의 능력이 아닐까 싶습니다. 하지만 이 부분의 소스코드는 현재 공개되지 않았으며, 구체적인 구현 방식도 아직 알려지지 않았다.
거래상태(V2)
minter에서는 상태도 보존됩니다. 이 상태는 두 곳에 존재합니다. 하나는 트랜잭션 출력의 OP_RETURN에 있고, 다른 하나는 위에서 언급한 Minter와 Token인 스마트 계약에 저장되어 있습니다.
OP_RETURN에 저장되는 것은 현재 거래 출력 상태의 Hash이며, Token의 남은 Mint 시간은 Contract에 저장됩니다. 각 민트 이후 새로 생성된 민트의 민트 수는 남은 민트 수를 2로 나눈 값과 같습니다. 다이어그램으로 표현:
게임이 끝나면 모든 Minter의 남은 수는 0이 됩니다.
원래 그림으로 돌아가면 Minter가 스마트 계약일 뿐만 아니라 생성된 토큰도 스마트 계약인 CAT 20입니다. CAT 20에는 수량과 토큰 소유자 주소라는 두 가지 기본 상태가 있습니다. 이전 BRC 20이나 비문과 달리 CAT 20이 주소의 UTXO에 없는 것을 확인할 수 있습니다.
옮기다
전송할 때 트랜잭션의 입력 및 출력 토큰이 일관되어야 합니다. 물론, 서로 다른 토큰의 입력 및 출력 양이 일관적이라면 동일한 거래에 여러 개의 서로 다른 토큰이 있을 수 있습니다.
불타다
토큰을 소각하려면 토큰을 일반 주소로 전송하기만 하면 됩니다.
요약
모든 작업은 사용자가 직접 구성한다는 것을 알 수 있는데 이는 매우 유연하므로 계약 부분에서 많은 검증 로직을 수행해야 합니다. 지금까지 노출된 취약점 중 일부는 검증 로직의 소홀로 인한 것이기도 합니다.
이러한 디자인에는 다음과 같은 이점이 있습니다.
모든 토큰의 보유 현황을 알고 싶다면 해당 토큰의 utxo만 확인하면 되며, 계속해서 확인할 필요는 없습니다.
mint의 현재 상황을 확인하고 싶다면 OP_RETURN의 데이터에서 cat을 포함한 트랜잭션을 검색하면 됩니다.
ZAN은 문턱 없이 물을 얻으러 왔습니다!
팁: Ethereum 생태계에서 Web3 프로젝트를 경험하고 테스트할 수 있도록 24시간마다 0.01 ETH 무료 테스트넷 토큰을 받을 수 있습니다. 지금 받으려면 클릭하세요: https://zan.top/faucet?chInfo=ch_WZ
더 많은 퍼블릭 체인이 곧 지원될 예정입니다~
이 글은 ZAN Team(X 계정 @zan_team )의 Yeezo(X 계정 @GaoYeezo 75065 )가 작성했습니다.
