원본 기사 - Casey Rodarmor
컴파일 - 오데일리
어제 Ordinals 제작자 Casey Rodarmor가 게시했습니다.블로그, 새로운 대체 가능 토큰(FT) 프로토콜 Runes를 도입했습니다.
비트코인에 FT가 필요한지 여부에 대해 Casey Rodarmor트윗FT에는 양면이 있다는 의미입니다. 한편으로는 FT의 99.99%가 비트코인의 순수성을 약화시키는 똥과 사기이며, 다른 한편으로는 비트코인 생태계에 많은 수수료 수입, 개발자 및 사용자를 가져옵니다. “사람들은 토큰을 좋아하고 사이버펑크 카지노와 같기 때문에 (사이버) 보안 예산에 대한 우려가 완전히 완화될 때까지 수수료 수익은 상당하고 지속될 가능성이 높습니다.”
그는 BRC-20, RGB, Taproot와 같은 FT 프로토콜이 이미 등장했다고 덧붙였습니다. 단순한 온체인 프로토콜에 비해 RGB 및 Taproot와 같은 프로토콜은 복잡하며 사용자 경험에 문제를 일으킬 수 있습니다. BRC-20은 오프체인 데이터 저장 및 검색 인프라가 필요한 RGB/Taproot에 비해 매우 간단하고 좋은 사용자 경험을 제공할 수 있지만, BRC 20 토큰의 문제점은 쓰레기 UTXO를 생성하고 비트코인 공간을 점유한다는 것입니다.
Rodarmor는 Runes가 비트코인에 더 자연스럽게 맞는 UTXO 기반 프로토콜이며 정크 UTXO 생성을 방지하여 UTXO 컬렉션의 최소화를 촉진한다고 말했습니다.
다음 내용은 Casey Rodarmor의 블로그 게시물에서 발췌하고 Odaily에서 편집한 내용입니다.
비트코인을 위한 새로운 대체 가능 토큰(FT) 프로토콜을 만드는 것이 좋은 생각인지 잘 모르겠습니다. FT의 99.9%는 사기, 밈입니다. 그러나 카지노가 곧 사라질 것 같지 않은 것처럼 그들은 곧 사라질 것 같지 않습니다.
비트코인을 위한 좋은 FT 프로토콜을 만들면 상당한 거래 수수료 수입, 개발자의 관심, 사용자를 비트코인으로 가져올 수 있습니다. 또한 프로토콜의 온체인 공간이 더 작고 책임감 있는 UTXO 관리를 장려하는 경우 기존 프로토콜에 비해 피해를 줄일 수 있습니다. 예를 들어, 현재 인기 있는 BRC-20은 대량의 정크 UTXO 생성을 가져왔습니다.
기존 FT 프로토콜을 비교해 보면 몇 가지 중요한 차이점이 있음을 알 수 있습니다.
복잡성: 계약이 얼마나 복잡합니까? 구현하기 쉬운가요? 입양이 쉽나요?
사용자 경험: 사용자 경험에 부정적인 영향을 미치는 구현 세부 사항이 있습니까? 특히, 오프체인 데이터에 의존하는 프로토콜은 온체인 공간이 더 가볍지만 상당한 복잡성을 가져오고 사용자가 자체 서버를 실행하거나 기존 서버를 검색하고 상호 작용해야 합니다.
상태 모델: UTXO 기반 프로토콜은 비트코인에 더 자연스럽게 적합하며 정크 UTXO 생성을 방지하여 UTXO 세트 최소화를 촉진합니다.
기본 토큰: 프로토콜 작동에 필요한 기본 토큰이 있는 프로토콜은 번거롭고 철회 가능하며 자연스럽게 덜 널리 채택됩니다.
위의 차원을 바탕으로 비트코인 생태계의 기존 FT 프로토콜을 비교한 결과는 다음과 같습니다.
BRC-20: UTXO를 기반으로 하지 않으며 일부 작업에서 순서 이론을 사용해야 하므로 매우 복잡합니다.
RGB: 매우 복잡하고 오프체인 데이터에 의존하며 오랫동안 개발되었지만 채택되지 않았습니다.
상대방: UTXO 기반이 아닌 특정 작업에 필요한 기본 토큰이 있습니다.
옴니 레이어: UTXO 기반이 아닌 특정 작업에 필요한 기본 토큰이 있습니다.
탭루트 자산: 약간 복잡하며 오프체인 데이터에 의존합니다.
비트코인의 경우 좋은 사용자 경험을 제공하는 간단한 UTXO 기반 FT 프로토콜은 어떤 모습일까요? 다음으로 Runes라는 아주 멋진 솔루션을 소개하고 싶습니다.
(1. 개요
룬 잔액은 UTXO에 보관되며 UTXO에는 원하는 수의 룬이 포함될 수 있습니다.
스크립트 공개 키에 OP_RETURN과 ASCII 대문자 R이 포함된 데이터 푸시가 포함된 출력이 포함된 경우 트랜잭션에는 프로토콜 메시지가 포함됩니다. 프로토콜 메시지는 첫 번째 메시지 이후에 푸시된 모든 데이터입니다.
유효하지 않은 프로토콜 메시지가 있는 거래에 입력된 룬은 폐기되므로 향후 업그레이드에서 룬 할당 또는 생성 방법을 변경할 수 있으며, 이전 클라이언트에서 룬 잔액을 잘못 할당하는 일이 방지됩니다.
정수는 접두사 varint로 인코딩됩니다. 여기서 varint의 선행 숫자에 따라 길이(바이트)가 결정됩니다.
(2) 환승
프로토콜 메시지의 첫 번째 데이터 푸시는 정수 시퀀스로 디코딩됩니다.
이러한 정수는 (ID, OUTPUT, AMOUNT) 튜플의 시퀀스로 해석됩니다. 디코딩된 정수의 수가 3의 배수가 아닌 경우 프로토콜 메시지는 유효하지 않습니다.
ID는 할당할 실행의 숫자 ID입니다.
OUTPUT은 할당할 출력의 인덱스입니다.
AMOUNT는 할당할 실행의 양입니다.
ID는 델타로 인코딩됩니다. 이를 통해 전체 룬 ID가 중복되는 것을 방지하기 위해 동일한 룬을 여러 번 할당할 수 있습니다. 예를 들어 튜플: [( 100, 1, 20), ( 0, 2 10), ( 20, 1, 5)]
다음을 할당합니다.
ID 100, 출력 1, 룬 20개
ID 100, 출력 2, 룬 10개
ID 120, 출력 1, 룬 5개
AMOUNT 0은 나머지 모든 룬을 의미합니다.
모든 튜플 할당이 처리된 후 할당되지 않은 룬은 첫 번째 비OP_RETURN 출력(있는 경우)에 할당됩니다. 추가 할당은 무시됩니다.
룬은 프로토콜 메시지가 포함된 OP_RETURN 출력에 할당하여 태울 수 있습니다.
(3)발행
프로토콜 메시지에 두 번째 데이터 푸시가 있는 경우 이는 이슈 트랜잭션입니다. 두 번째 데이터 푸시는 SYMBOL과 DECIMALS라는 두 개의 정수로 디코딩됩니다. 추가 정수가 남아 있으면 프로토콜 메시지가 유효하지 않습니다.
이슈 트랜잭션은 할당 튜플의 ID 0을 사용하여 최대 2^128 - 1 까지 원하는 수의 이슈 룬을 생성할 수 있습니다.
SYMBOL은 사람이 읽을 수 있는 26비트 기본 인코딩 기호로, 서수 sat 이름에 사용되는 기호와 유사합니다. 유효한 문자는 A - Z 뿐입니다.
DECIMALS는 발행된 룬을 표시할 때 사용해야 하는 소수점 이하 자릿수입니다.
SYMBOL이 아직 할당되지 않은 경우 게시된 룬에 할당되고 게시된 룬은 사용 가능한 다음 숫자 룬 ID(1부터 시작)를 받습니다.
SYMBOL이 이미 할당되었거나 BITCOIN, BTC 또는 XBT인 경우 새 룬이 생성되지 않습니다. 룬 ID 0을 사용하는 이슈 트랜잭션 할당은 무시되지만 다른 할당은 계속 처리됩니다.
(4) 주의
UTXO 잔액을 표시할 때 UTXO의 기본 비트코인 잔액은 룬 ID 0과 기호 BITCOIN, BTC 또는 XBT로 표시될 수 있습니다.
프로토콜을 단순하게 유지하기 위해 (룬즈)는 심볼 스쿼트를 방지하는 메커니즘을 채택하지 않습니다. 실제로 기호 연결을 방지하는 효율적이고 간단한 방법은 특정 길이 이상의 기호 할당만 허용하는 것입니다. 이는 시간이 지남에 따라 감소하다가 결국 0에 도달하여 모든 기호를 허용합니다. 이렇게 하면 프로토콜 초기에 짧고 이상적인 기호를 할당하는 것을 방지하고 후발 사용자가 이상적인 기호를 놓고 경쟁하도록 장려할 수 있습니다.
마지막에 쓰세요
이 솔루션이 실제로 시장에 효과가 있나요? 나는 모른다.
이는 최대한 간단하고, 오프체인 데이터에 의존하지 않으며, 기본 토큰이 없으며, 비트코인의 기본 UTXO 모델에 완벽하게 들어맞습니다. 이러한 계획은 온체인 공간이 더 나쁜 다른 계획의 사용자를 끌어들이고 개발자와 사용자의 관심을 비트코인으로 돌려 비트코인 자체를 채택하도록 장려할 수 있습니다.
반면에 FT의 세계는 완전히 씻을 수 없는 기만과 탐욕의 심연이어서 씻겨 나갈 수도 있습니다.
