ORC-20 토큰 해설: 오디널스 생태계 내 새로운 토큰 발행 규칙
*TechFlow는 xiyu의 허가를 받아 전재합니다.
ordinals에서 JSON을 사용해 명문(inscription)을 발행한 후 이를 해석하는 방식은 대부분 명문을 일회용 종이처럼 사용하는 것이며, 중심화된 서비스에 과도하게 의존할 위험이 따릅니다.
1. 배경
brc20에는 여러 제약 사항이 있습니다. 예를 들어, 코인 이름은 4자로 제한되며, 업그레이드가 불가능하고, 이중 지불(double-spending) 리스크가 있으며, 거래 취소도 불가능합니다. orc20은 이러한 제약을 제거하기 위한 것으로, brc20의 하드포크라고 할 수 있습니다. 여기까지 읽고 나면 익숙한 느낌이 들지 않나요? 비트코인 생태계의 오랜 전통인 포크 모델입니다.
2. orc20란 무엇인가?
ORC-20은 비트코인 네트워크 상의 순서형 토큰(ordered token) 기능을 강화하기 위한 개방형 표준으로, 인기 있는 BRC-20 순서형 토큰 표준을 개선하는 것을 목표로 합니다. orc20은 BRC-20과의 하위 호환성을 유지하면서 적응성, 확장성 및 보안성을 향상시키고, 중복 소비 가능성도 제거합니다.
3. orc20의 변화
3.1 초기 공급량과 최대 발행량 변경 가능. 저는 이것을 진보라고 보긴 어렵습니다. 초기 공급량과 총량을 고정하는 것은 결점이 아닙니다. orc20은 단지 ordinals 기반 토큰 발행 형식을 더 유연하게 만들었을 뿐이며, 고정 여부와 유연성은 단지 선택의 문제일 뿐, 우열을 가르는 요소는 아닙니다.
3.2 이름 공간에 고정된 제한이 없으며, 임의의 길이의 이름 사용이 가능합니다. 이름 부여는 실제로 큰 문제였으며, 특히 대부분의 brc20 4글자 단어들이 이미 선점되어버린 상황에서는 더욱 그렇습니다.
3.3 UTXO 모델을 통해 거래 과정에서 중복 소비가 없는지 확인합니다. UTXO 모델이 무엇인지 궁금하신 분은 검색해보시기 바랍니다. 한 번의 거래를 보낼 때 잔액 역시 잔돈 주소로 보내는 또 다른 거래로 처리되는 방식입니다. 이를 통해 어느 정도 이중 지불 문제를 완화할 수 있습니다.
예를 들어 ID가 1인 ORC 10,000개를 두 부분으로 나누어 수신 주소에 전송한다고 가정합시다. 각 거래는 고유한 nonce 값을 가져야 합니다. 단계 1: 수신자에게 송금 이벤트를 기록하여 1,000개를 송금(nonce는 5). 단계 2: 송신자에게 남은 잔액을 다시 송금하는 이벤트를 기록(nonce는 6). 남은 잔액이 성공적으로 반환된 후에야 전체 거래가 완료됩니다.
3.4 거래 취소를 허용하며, "op": "cancel" 명령을 사용하면 해당 nonce의 거래를 취소할 수 있습니다.
3.5 기존에 배포된 brc20 토큰이 orc20으로 이전하는 것을 허용합니다. 단, brc20의 배포자만이 이전 명령을 실행할 수 있습니다.
4. orc20의 새로운 규칙
4.1 id 식별자, 기본값은 1. 동일한 식별자를 공유하는 ORC-20 간에 id는 유일해야 하며, 동일한 식별자와 동일한 ID를 갖는 ORC-20이 두 개 존재할 경우 “선점 원칙(first principle)”이 적용되며, 두 번째 ORC-20은 무효가 됩니다.
4.2 nonce는 각 거래와 연결된 고유 식별자로, 발신자가 자신의 부분 거래를 추적할 수 있게 해줍니다. 각 거래에 nonce를 포함함으로써 발신자는 각 부분 거래가 고유하다는 것을 보장할 수 있으며, 실수나 악의적인 복제를 방지할 수 있습니다. 그렇지 않을 경우 거래 보안이 위협받을 수 있습니다. nonce를 활용하면 발신자는 특정 부분 거래를 취소할 때 해당 nonce를 지정하여 취소할 수 있어, ORC-20 토큰 표준에 추가적인 보안성과 유연성을 제공합니다.
4.3 "op": "cancel", 특정 부분 거래를 취소하는 작업입니다.
4.4 ug 필드, 업그레이드 가능 여부: true 또는 false, 기본값은 true. 배포자가 이후에 ORC-20을 업그레이드할 수 있도록 허용합니다.
4.5 wp 필드, 마이그레이션(migration): true 또는 false, 기본값은 false. 토큰 이전 목적을 위해 사용되며, 한 번 수행되면 되돌릴 수 없습니다. 원본 BRC-20의 배포자만이 마이그레이션 이벤트를 배포할 수 있습니다. 이 래퍼(wrapper)는 최대 공급량과 발행 제한 등 원본 BRC-20의 메타데이터를 복사합니다.
4.6 Version(버전): ORC-20을 업그레이드할 때 유용한 정보입니다. 일반적으로 업그레이드할 때마다 버전 번호를 업데이트해야 하며, 이를 통해 서로 다른 계약 버전을 쉽게 식별할 수 있어 이후 개발, 관리 및 사용이 용이해집니다.
4.7 msg: 메시지: 사용자 정의 텍스트, 메시지 또는 선언문으로, 크기에 제한이 없습니다. 이 필드를 통해 토큰의 목적, 비전, 사용 사례 등을 설명할 수 있으며, 사용자가 토큰의 가치와 용도를 더 잘 이해하고 신뢰를 높이는 데 도움이 됩니다.
4.8 Custom Key(사용자 정의 키). 사용자 정의 구현에만 사용되며, 예를 들어 세금(tax) - 강제 거래세, 로열티(royalty); 발행자(minter) - 특수 발행 주소; 이미지(image) - 토큰 이미지; tkid - 토큰 ID; url - 토큰 정보 URL 등을 포함할 수 있습니다.
이러한 선택적 필드는 표준 ORC-20 프로토콜에서 제공하지 않는 특수 기능을 확장할 때 사용될 수 있습니다. 예를 들어, 세금은 매 거래 시 일정 수수료를 징수하는 데 사용할 수 있고, 로열티는 원작자에게 작품 사용료를 지급하는 데 사용할 수 있습니다. 또한 발행자는 특정 주소를 지정하여 토큰 발행 권한을 부여할 수 있습니다.
5. orc20의 한계
5.1 복잡성: 비트코인 생태계의 ordinals 기반에서는 단순함 자체가 장점이 될 수 있지만, brc20이 토큰 발행 문제를 이미 복잡하게 만든 상황에서 orc20은 이를 더욱 복잡하게 만듭니다. 더 많은 정의와 번거로운 작업은 오히려 더 많은 문제를 초래할 수 있습니다. 예를 들어 마이그레이션 작업은 두 개의 토큰이 존재하는 상황을 만들어냅니다.
5.2 중심화: JSON을 사용하는 목적은 검색을 쉽게 하기 위해서입니다. 그러나 검색은 반드시 중심화된 서비스에 의존하게 되며, 이것이 현재 ordinals 생태계에서 NFT를 제외한 다른 애플리케이션이 가지는 본질적 결점입니다.
5.3 강제 로열티: 거래 시장에서 로열티를 받는 방식을 규칙에 내장한 것입니다. 토큰에 로열티를 도입한 것은 작성자의 사고가 다소 혼란스럽다고 생각됩니다. NFT는 예술 작품이라는 속성을 가지므로 예술가에게 로열티를 지급하는 것은 이해할 수 있습니다. 창작자와 소유자는 창작과 사용의 관계이기 때문입니다. 하지만 토큰의 경우, 보유자는 투자자에 가깝습니다. 투자자가 프로젝트에 자금을 지원한 후에도 프로젝트 운영자에게 로열티를 계속 지급해야 한다는 것은 다소 납득하기 어려운 구조입니다.
5.4 경로 의존성: 해석을 통해 알 수 있듯이 orc20은 비트코인 기반 토큰 발행 방식을 rc20에 더 가깝게 만들려는 노력을 하고 있습니다. 그렇다면 왜 바로 ERC-20을 사용하지 않는가 하는 질문이 자연스럽게 제기됩니다.
6. 요약
한 문장으로 요약하면, orc20은 brc20의 일부 제한을 제거하고 더 많은 작업을 정의한 것입니다.
사실 ordinals 상에서 토큰을 발행하는 핵심 경쟁력은 표준이 아니라 중심화된 서비스입니다. 인증 절차 전반을 체인 상에서 완전히 폐쇄적인 형태로 처리할 때만 중심화 리스크를 방지할 수 있습니다.
brc20의 가장 큰 문제는 제한이 많다는 것이 아니라 중심화된 서비스에 의존한다는 점입니다. orc20은 이 문제를 해결하지 못했으며, brc20을 경쟁자로 삼아 시장을 선점하려는 목적이 있습니다. orc20은 ordinals 생태계 자체에는 큰 영향을 미치지 않으며, brc20에 대한 영향도 제한적입니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
xiyu
