토큰은 프로토콜 설계 방식과 달성 가능한 내용을 변경하는 매우 흥미롭고 유용하며 강력한 새 도구이지만 토큰은 설계의 중심이 아닙니다. 오늘날의 프로토콜 디자인은 디자이너의 이해가 포괄적이거나 과학적인 것과는 거리가 멀고 대부분의 프로젝트에는 여전히 많은 실험이 필요하기 때문에 학문이라기보다는 "연금술"에 가깝습니다.

이 세션은 토큰 디자인에 대한 일반적인 사고방식부터 시작하여 토큰 분류, 토큰이 실제로 무엇인지, 토큰의 기능을 개발하고 강화하는 방법에 대해 보다 구체적으로 설명하는 세 부분으로 구성됩니다. 마지막은 기술 트리 이론으로, 기술을 사용하여 디자인을 더 쉽게 성공시키는 방법을 설명합니다.

사고 모드

첫째, 토큰은 프로토콜을 위한 것이며 도구이자 설계 프로세스의 일부이며 목표가 되어서는 안 됩니다. 분산화된 작업을 수행하려는 경우 토큰은 아마도 그 일부일 것입니다. 왜냐하면 사람들이 프로토콜에 대한 소유권을 갖고 사람들을 정렬시키는 데 유용하기 때문입니다.

디자인의 3단계

1단계: 목표 정의

목표는 유효한 프로토콜의 결과에 대한 간결한 설명이며 특정 설계에 의해 달성되었는지 여부가 모호하지 않아야 합니다. 그러므로 우리는 성공과 실패를 매우 명확하게 구분해야 합니다. 우리의 목표가 무엇인지 명확하지 않다면 다시 시작하고 토큰에 대해서는 잊어야 합니다. 이상적으로는 아직 성공을 측정하는 방법을 모르더라도 목표는 측정 가능합니다.

2단계: 제한사항 도입

일반적으로 제약 조건에는 두 가지 유형이 있습니다. 하나는 내재적 제약이고 다른 하나는 외생적 제약입니다. 내재 제약은 일부 절충이 필요하기 때문에 설계 프로세스를 단순화하기 위해 선택하는 제약입니다. 그들 자신.

본질적인 제약 조건은 다양한 소스에서 나올 수 있지만 일반적으로 디자이너가 직접 결정합니다. 자연, 기술 상태, 규제 및 모든 종류의 것들에 의해 외생적인 제약이 부과됩니다. 나중에 그것에 대해 이야기하겠습니다.

3단계: 설계 메커니즘

제약 조건과 목표가 있으면 해당 목표를 충족할 메커니즘에 대해 명시적으로 생각할 수 있습니다. 이제 우리가 기계공에 대해 생각할 때마다 그것이 그러한 제약을 위반하고 우리를 그 목표에 더 가깝게 만드는지 정말 명확해야 합니다. 프로토콜은 일부 제약 조건에 따라 특정 목표를 향해 추진되는 일련의 메커니즘이 될 것입니다.

받아 MakerDAO 예로서. 그들의 목표는 안정적으로 발전하는 것입니다. 이더리움 네이티브 자산. 물론 안정성과 고유성에 대한 해석은 다양합니다. 이들의 한계는 USD에 고정된 가격, 기본 온체인 자산 등으로 완전히 뒷받침된다는 것입니다.

일반적인 함정

토큰을 너무 강조합니다. 토큰은 프로토콜이 아니며 토큰이 목표가 되어서는 안 됩니다. 그것은 단지 도구일 뿐입니다.

이 함정에서 벗어나는 방법은 무엇입니까? 스스로에게 물어보세요: 토큰 없이 이 시스템이 어떻게 작동할까요? 토큰을 완전히 제거했는데 시스템이 완전히 실패한다면 토큰의 역할을 지나치게 강조하는 것일 수 있습니다. 시스템의 몇 가지 주요 부분이 실패하는 것보다 낫습니다. 토큰은 중요하고 전체 균형에 필요하지만 시스템은 토큰 없이도 일관성을 유지합니다. 그러므로 시스템의 목표에 대해 계속 생각해야 합니다.

디자인 공간은 무제한입니다. 디자인에는 아이디어가 너무 많고, 할 수 있는 일이 너무 많아서 어디서부터 시작해야 할지조차 모르는 가능성이 너무 많습니다. 이는 대개 목표가 명확하지 않기 때문에 목표를 다듬는 것이 필요합니다. 그것은 또한 외부 세계가 당신에게 가한 한계에 대한 이해가 부족하거나 그것을 받아들이지 않았기 때문일 수도 있습니다.

이러한 제약 조건을 혼합하면 디자인 공간이 줄어들고 훨씬 더 명확해집니다. 디자인 공간을 제한하는 데 도움이 되는 두 가지 질문은 스스로에게 물어보는 것입니다. 구축하려는 강력한 컨셉은 무엇입니까? 그것은 심도 있는 아이디어일 수도 있고, 장점일 수도 있고, 시대적 흐름의 변화일 수도 있습니다. 이 강력한 개념이 무엇인지 스스로에게 물어보세요. 전체 시스템을 먼저 생각하는 대신 어떻게 최대한 활용하고 집중할 수 있습니까? 또 다른 질문은 이 디자인의 가장 큰 약점은 무엇입니까? 당신을 밤잠 못 들게 하는 것은 무엇이고, 효과가 없을 것이라고 생각하는 점, 걱정하는 점, 주요 약점, 그리고 그것을 개선하기 위해 받아들일 수 있는 제약은 무엇입니까? 이로 인해 설계 공간이 크게 제한될 수 있습니다.

항상 커뮤니티에 알리세요. 시스템의 특정 부분을 설계하고, 모든 부분을 커뮤니티에 전달하여 해결하도록 하거나, 보이지 않는 힘이 격차를 메울 것으로 기대하는 데에는 어려움이 있습니다. 항상 사람들이 문제를 찾아 해결하기를 기대하는데, 이는 매우 위험합니다. 무허가형 시스템의 인기와 놀라운 혁신에도 불구하고 커뮤니티의 행동을 예측할 수 없으며 커뮤니티가 시스템의 가장 명백한 문제를 해결할 것이라고 기대해서도 안 됩니다.

스스로에게 물어봐야 할 몇 가지 주요 질문이 있습니다. 우리는 커뮤니티에서 실제로 무엇을 기대하며, 우리는 그들에게 무엇을 제공하고 있습니까? 그들에게 충분한 토큰을 달라고 요청하는 것만으로도 충분하지 않나요? 오히려 우리는 그들에게 어떤 권한을 주었나요? 그들에게는 어떤 능력이 주어졌나요? 그들은 어떤 소유권을 갖고 있나요? 그들은 이 책임의 균형을 맞출 만큼 충분한 권한을 갖고 있습니까?

정말로 그들이 뭔가를 고칠 것이라고 기대한다면, 다른 야심 찬 사람들이 흥미로운 확장을 추가하거나 시스템의 일부 구성 요소를 고칠 것이라고 기대한다면 먼저 스스로에게 물어봐야 합니다. 여기에 구축하시겠습니까? 충분한 상승 여력, 충분한 힘, 충분한 유연성이 없기 때문에 그렇게 하지 않을 경우에는 더 이상 보지 마십시오.

토큰 분류

토큰은 프로토콜의 도구이며 도구이자 프로토콜이며 더 추상적으로는 데이터 구조입니다. 그렇다면 이 데이터 구조가 다른 프로토콜에서 사용되는 것을 어떻게 알 수 있습니까? 이는 지불, 투표, 이해관계자, 메타데이터 및 청구라는 다섯 가지 매우 일반적인 범주로 그룹화될 수 있습니다.

지불

지불 기능은 세 가지 범주로 더 나뉘며, 첫 번째는 커뮤니티 또는 프로젝트의 내부 통화입니다. 우리는 이와 같은 것을 많이 본 적이 없지만 몇 가지 예가 있습니다. 예를 들어, 소스크레드 흥미로운 예이고, FWB 이 방향으로 움직일 수도 있습니다.

이는 통화를 통제하는 특정 커뮤니티 내에 존재하고 이 내부 통화에 대해 통화 정책 및 기타 수단을 사용할 수 있다는 점에서 USD 결제와 같은 전통적인 결제 방법과 다릅니다. 다른 특정 자산의 가치는 커뮤니티 전체의 특정 목표에 따라 주조되거나 소각될 수 있습니다.

두 번째이자 아마도 가장 일반적으로 사용되고 가장 잘 이해되는 암호화폐 사용 결제 방식은 온라인 리소스로서, 이더리움과 비트코인도 이 범주에 속합니다. 컴퓨팅 성능, 스토리지 또는 기타 암호화폐 네트워크 리소스에 대한 비용을 지불합니다. 우리는 EIP1559, 스테이킹, 유동성 등을 통해 토큰을 사용하여 시스템 내의 다양한 리소스, 특히 컴퓨팅 리소스를 계산하는 방법을 결정합니다.

세 번째 결제 토큰은 유사한 게임 화폐로 존재합니다. 예를 들어, 게임, 리소스 또는 일부 프로토콜 리소스는 안정적이어야 하며 가격이 책정되어야 합니다. 왜냐하면 시스템을 사용하고 이러한 리소스가 안정적이라면 토큰 가격도 상대적으로 안정적이어야 하기 때문입니다. 안정적인 공급 여부는 중요하지 않습니다. 애플리케이션의 특정 부분을 구현하는 데만 사용하기 때문입니다.

그렇다면 스테이블코인은 어디에 배치해야 할까요? 물론 위의 세 가지 방법으로 안정적인 통화를 결제 수단으로 사용할 수 있습니다. 그러나 스테이블코인을 스테이블코인으로 만드는 것은 스테이블코인을 안정화하는 메커니즘이므로 스테이블코인은 일반적으로 소유권 범주에 속합니다.

소유권

일반적으로 소유권에는 온체인(예금)과 오프체인(소유권)의 두 가지 유형이 있습니다. 예금 토큰은 다른 토큰에 대한 소유권을 나타냅니다. 예를 들면 다음과 같습니다. Uniswap LP 토큰, 이는 ERC-20 V2에서는 NFT, V3에서는 NFT입니다. Maker 프로토콜에서 나오는 스테이블 코인인 DAI는 귀하 또는 볼트 보유자가 기본 담보를 청구하는 데 사용하기 때문에 온체인 예금이기도 합니다. 따라서 예금 토큰은 오프체인 환경에서 다른 토큰을 청구하는 데 사용될 수 있음을 의미합니다.

두 번째 토큰은 일부 오프체인 자산의 소유권을 나타내므로 실제 자산 토큰, 부동산 토큰 등이 될 수 있습니다. 우리는 이에 대한 많은 예를 본 적이 없습니다. 보다 현대적인 예는 토큰을 물리적 개체로 교환할 수 있는 현재 상환 가능한 것입니다. 예를 들어 NFT는 예술 작품과 예술 작품을 교환하는 데 사용되며, 이 NFT는 마당의 소유권을 나타냅니다. 원한다면 재미있는 거래도 있습니다. 물리적 객체를 사용하여 NFT를 제어하고 칩과 같은 일부 디지털 기능을 통해 후속 NFT의 소유권을 제어할 수 있습니다.

투표

투표는 프로젝트 자금 조달, 자원 할당(즉, 그룹 단위로 지불 또는 이전), 소프트웨어 업그레이드에 사용될 수 있습니다. 또한, 프로젝트의 향후 계획을 결정하기 위한 리더 선정 등 사회적 합의의 척도로도 활용될 수 있습니다.

서약

토큰은 스마트 계약을 통해 보상을 받을 수 있도록 설계될 수 있으며 여기에는 법적 합의가 없지만 메커니즘은 토큰이 일종의 온체인 활동으로부터 이익을 얻을 수 있음을 의미합니다. 한 가지 예는 Maker입니다. Maker 토큰 보유자가 업무를 잘 수행하고 시스템이 제대로 작동한다면 일부 수익을 얻을 수 있습니다. 이것이 스마트 계약의 방식이며, 프로토콜이 설계된 방식이며, 커뮤니티의 훌륭한 거버넌스를 보상합니다.

또한 반품 자격을 부여하는 법적 계약의 결과로 토큰을 만들 수도 있습니다. 물론 다양한 법적 요구 사항 및 제한 사항에 따라 회사의 지분율이나 지분을 나타내는 토큰을 만들 수 있습니다. 이론적으로 증권토큰을 만들 수 있는 사람들이 있던 시절이 있었지만, 그런 경우는 많이 본 적이 없습니다.

토큰은 수익에 대한 대가로 위험을 인수하는 데에도 사용됩니다. 메이커는 이 원리를 사용합니다. Maker 프로토콜에 손실이 발생하면 더 많은 Maker 토큰이 생성되어 Maker 보유자가 보유한 가치가 희석됩니다. Maker 토큰을 보유함으로써 보유자는 약간의 위험을 감수하게 되며, 이는 Maker 보유자가 커뮤니티 구축을 촉진하도록 유도하는 요소의 일부입니다. 투자 가치가 증가하는 것을 보고 싶다면 이 시스템의 개발을 지원해야 합니다.

메타 데이터

첫째, 토큰은 멤버십을 나타내며 특정 공간에 대한 액세스 권한이 있는지, 특정 커뮤니티에 속해 있는지 또는 일부 그룹에 속해 있는지 여부를 결정합니다. 일부 제3자가 작성한 프로토콜이나 도구는 이 멤버십 속성을 무허가 방식으로 사용할 수 있습니다. 예를 들어, 일부 NFT 커뮤니티에서는 이 토큰을 보유하는 등 토큰을 보유한 사람만 가입할 수 있도록 결정할 수 있습니다. 특정 기능 등을 제공하는 것. 멤버십은 토큰이 제공하는 흥미로운 메타데이터 유형입니다.

토큰은 평판을 나타내기도 합니다. 어떤 사람들은 평판을 양도할 수 있어야 하는지에 대해 논쟁을 벌이고 있습니다. 그러나 어떤 경우에는 동질적일 수도 있고 다른 경우에는 비균질적일 수도 있습니다. 귀하의 업적을 언급하는 경우에는 동질적이지 않을 수 있습니다. 정보 소스, 신용 또는 다양한 유형의 신용 평가 시스템을 언급하는 경우 동질적일 수 있습니다. 이는 연속적인 데이터이므로 일종의 메타데이터입니다.

토큰은 ID 또는 참조를 나타내기도 합니다. 엔스가 그 예이다. ENS 이름은 주소를 가리킬 수 있고 업데이트될 수 있습니다. DNS 시스템.

오프체인 데이터는 일종의 메타데이터일 수 있습니다. 예를 들어 오프체인 KYC 또는 일종의 검증 가능한 인증서가 있습니다. 또 다른 좋은 예는 졸업장이나 학업 자격입니다. 누군가가 이 인증서를 건네주면 공개적으로 표시되고 추적 가능하며 진품입니다. 우리는 온체인에서 권한과 능력을 표현하는 사례를 많이 본 적이 없습니다.

일부 엔터티는 함수 호출, 코드 변경 또는 온체인 전송 기능과 같은 권한을 명시적으로 부여합니다. 토큰을 인터페이스로 사용하는 것도 가능합니다. 우리는 이에 대한 예를 보았습니다. 토큰 URI에 SVG 데이터를 넣을 수 있을 뿐만 아니라 전체 HTML 웹 페이지를 넣을 수 있고 심지어 약간의 JavaScript도 넣을 수 있습니다. nft에 인터페이스를 넣을 수도 있고, 인터페이스를 제어할 수도 있고, 사람들이 소유하고 양도하는 객체에 인터페이스를 내장할 수도 있습니다.

흥미로운 예는 다음과 같습니다. 삐3R, 먼저 NFT에 텍스트를 작성한 다음 해당 텍스트를 다른 사람에게 브로드캐스팅할 수 있습니다. 삐3R 그것을 소유함으로써 보유자. 이 텍스트는 작은 이미지에 표시됩니다. 삐3R. 당신이 삐3R 다른 사람에게 직접 메시지를 보낼 수도 있습니다. 삐3R XMTB만 사용하는 것과 같습니다.

그렇다면 이 토큰의 기능은 무엇입니까? 이는 멤버십 토큰이며, 이 토큰으로 메시지를 받을 수 있습니다. 애니메이션 URL을 올바르게 나타내는 지갑 인터페이스는 이 표준을 지원하는 한 귀하가 받는 모든 메시지를 표시할 수 있습니다.

BP 보유자로서 정보를 주고받을 수 있기 때문에 이는 신원 토큰이기도 합니다. 그래서 이런 일은 그 세트에서만 발생합니다. 이는 BP의 토큰 ID로 메시지를 보내기 때문에 ID 토큰이기도 합니다. 동시에 인터페이스로도 존재하며 NFT와 관련된 정보를 볼 수 있습니다.

테크 트리 이론

결제 수단으로서의 토큰, 네트워크 자원 등 일부 분야는 큰 발전을 이룬 반면, 인터페이스, 메타데이터 등 일부 분야는 아직 개발되지 않은 것을 볼 수 있습니다. 그럼 왜 이런 일이 일어나는 걸까요?

일부 제품이 특정 시간에 나타나는 이유는 무엇이며, 일부 제품이 다른 제품보다 나타나는 데 시간이 더 오래 걸리는 이유는 무엇입니까? 대출 프로토콜을 예로 들면, 스테이블코인 없이 대출 프로토콜이 작동하는 것을 상상하기 어렵습니다. 이는 대출 계약에서 부채를 빌려줄 때 이 자산의 가격을 예측할 수 있기 때문에 이를 안정적인 자산으로 표현하고 싶기 때문에 실제로 대출 계약을 체결하기 전에 스테이블코인이 필요하기 때문입니다.

마찬가지로, 우리는 또한 다음을 요구하는 대출 계약을 맺었습니다. AMM 왜냐하면 대출계약을 레버리지로 활용하려면, 특히 초기 단순대출 계약에서는 스테이블코인과 같은 자산을 빌릴 수 있어야 하기 때문입니다. 스테이블코인을 해당 자산으로 매우 빠르게 교환하고 더 많은 노출을 원할 경우 AMM이 필요합니다. 대출 프로토콜이 발전한 것은 AMM과 스테이블코인이 작동하기 전까지는 아니었습니다.

하지만 작동하는 AMM과 스테이블 코인을 얻는 방법은 무엇입니까? 스테이블코인, AMM 및 주변의 모든 시스템은 다른 프로젝트가 이들과 어떻게 인터페이스하는지 이해해야 하기 때문에 상호 운용 가능한 토큰 표준 없이는 이를 수행하기 어렵습니다. 그리고 ERC-20 토큰을 가지려면 완전히 프로그래밍 가능한 스마트 계약이 필요합니다. 실제로는 필요하지 않을 수도 있지만 Ethereum은 ERC-20 토큰 표준 없이 출시되었기 때문에 Ethereum에 처음 등장한 방식입니다. 충분한 개방형 디자인 공간을 확보하려면 완전한 프로그래밍 기능이 필요합니다. 물론 이것은 더 논의될 수 있다. 하지만 결론적으로 특정 기술이 다른 기술의 전제 조건이 되는 기술 트리가 있다고 생각합니다.

여기에는 두 가지 질문이 있습니다. 미래의 애플리케이션과 프로토콜을 실현할 핵심 기술은 무엇입니까? 즉, 유용한 평판 시스템이나 분산화되고 신뢰할 수 없는 인터페이스를 개발하려면 어떤 기술이 필요합니까? 그리고 두 번째 질문은 역으로 첫 번째 질문과 약간 비슷합니다. 곧 출시될 기술로 어떤 애플리케이션과 프로토콜이 잠금 해제될까요?

예를 들어 계정 추상화, EIP4844, 수직 트리, 영지식 기계 학습 등 이러한 질문은 흥미롭습니다. 왜냐하면 설계 제약을 완화하거나 도입하는 특정 기술의 도래를 예측할 수 있다면 그것이 우리의 설계를 어떻게 변화시킬 수 있기 때문입니다. 이러한 제약을 완화할 수 있는 구체적인 기술이 있다면 이를 개발하는 데 에너지를 투자해야 할까요?

사물을 기술 트리로 생각하면 앞으로 나올 내용이나 원하는 제약 조건에 도달하는 데 필요한 것이 무엇인지 추론하는 데 도움이 될 수 있습니다. 그래서 제가 원래 가졌던 한계점과 다시 연결해보면, 새로운 기술이 우리가 이전에 겪었던 한계점을 완화시켜준다고 생각합니다. 예를 들어 ERC-20 표준이 없는 경우 AMM 또는 스테이블코인 설계에 대한 제약은 표준을 도입해야 하거나 다양한 설계에 대처할 수 있어야 한다는 것입니다.

범용 AMM을 설계하지만 특정 토큰 표준을 사용하지 않는다고 상상해 보십시오. 이는 매우 어려울 것입니다. 이는 거의 극복할 수 없는 한계라고 생각했지만, 상호 운용성 표준이 있다는 것은 ERC-20 토큰을 직접 지원할 수 있다는 것을 의미하며, 이는 설계 공간을 제한하고 이를 가능하게 합니다.

미래에 어떤 기술이 등장할지 예측할 수 있다면 이것이 프로토콜 설계에 대한 제약에 어떤 영향을 미칠까요? 구체적인 목표나 제약이 있는 경우 어떤 기술이 필요합니까? 기술은 이러한 한계를 완화하고 새로운 메커니즘을 통해 이러한 목표를 다시 가능하게 만들 수 있습니다.

면책 조항: 이 웹사이트의 정보는 일반적인 시장 논평으로 제공되며 투자 조언을 구성하지 않습니다. 투자하기 전에 스스로 조사하는 것이 좋습니다.

뉴스를 추적하려면 우리와 함께하십시오: https://linktr.ee/coincu

웹 사이트: 코인쿠닷컴

해롤드

코인쿠 뉴스