이 기사는 a16z crypto이 기사는

, 원저자: Guy Wuollet, 오데일리 번역가 Katie Gu가 편집.

실제로 많은 팀이 프로젝트에 "올바른" 토큰 디자인을 찾는 데 어려움을 겪고 있습니다. 그러나 업계에는 검증된 설계 프레임워크가 부족하므로 미래 세대는 이전 세대와 동일한 문제에 반복적으로 직면합니다. 다행스럽게도 성공적인 토큰 디자인의 초기 사례도 (몇 가지) 있습니다. 가장 효과적인 토큰 모델에는 목표에 맞는 고유한 요소가 있지만 대부분의 결함이 있는 토큰 디자인에는 몇 가지 일반적인 버그가 있습니다. 따라서 이 글에서는 단순히 "토큰 경제학"이 아닌 토큰 연구 및 설계를 고려해야 하는 이유에 대해 논의하고 7가지 "함정" 팁을 나열합니다.

보조 제목

#1 토큰 설계의 목표를 명확히 하십시오.토큰 설계에서 가장 큰 문제는 명확한 목표 이전에 복잡한 토큰 모델을 구축하는 방법입니다. 첫 번째 단계는 목표를 정의하고 팀 전체가 목표가 무엇인지, 왜 중요한지,당신이 정말로 성취하려고 하는 것은 무엇입니까?

목표를 엄격하게 정의하지 못하면 종종 재설계 및 시간 낭비가 발생합니다. 또한 목적의 명확성은 일부 토큰 경제 설계에서 흔히 발생하는 "토큰 경제 설계를 위한 토큰 경제 발명" 문제를 피하는 데 도움이 됩니다.

• 또한 목표는 토큰 자체를 중심으로 해야 하지만 이는 종종 간과됩니다. 명확한 목표의 예는 다음과 같습니다.

• 최적의 확장성을 허용하고 모델링을 지원하는 토큰 모델로 게임을 설계합니다.

• DeFi 프로토콜은 참여자 간에 위험을 합리적으로 할당하는 토큰 모델을 설계하기를 희망합니다.

• 돈을 보장하는 평판 프로토콜을 설계하는 것은 평판을 직접 대체할 수 없습니다(예: 평판 신호에서 유동성을 분리함으로써).

• 대기 시간이 짧은 파일을 계속 사용할 수 있는 스토리지 네트워크를 설계합니다.

• 최대의 경제적 보안을 제공하는 스테이킹 네트워크를 설계합니다.

진정한 사용자 선호도 또는 최대 참여를 유도하는 거버넌스 메커니즘을 설계합니다.

목록은 계속됩니다. 토큰이 모든 사용 사례를 지원하고 목표를 달성하도록 하십시오. 그 반대는 아닙니다.그렇다면 명확한 목표를 정의하기 시작하는 방법은 무엇입니까?

잘 정의된 목표는 종종 "프로젝트 임무"에서 파생됩니다. "프로젝트 임무"는 높은 수준의 추상적인 경향이 있지만 목표는 구체적이고 가장 기본적인 형태로 축소되어야 합니다.

EIP-1559를 예로 들어 보겠습니다. Roughgarden은 EIP-1559에 대한 명확한 목표를 밝혔습니다.

이 두 가지 예의 공통점은 높은 수준의 목표를 설명하고 다른 사람들이 목표를 이해하는 데 도움이 되는 관련 비유를 제공한 다음 해당 목표를 가장 잘 지원하는 설계 대안의 개요를 설명하는 것입니다.

보조 제목

#2 기본 원칙에 따라 기존 작업을 평가합니다.

새로운 것을 만들 때는 이미 가지고 있는 것부터 시작하는 것이 좋습니다. 기존 프로토콜과 기존 문헌을 평가할 때 기술적 장점에 대해 객관적으로 평가해야 합니다.이러한 요소는 명시된 목표를 달성하기 위한 토큰 모델의 능력과 관련이 없을 수 있습니다. 토큰 모델을 평가하는 평가, 인기 또는 기타 단순한 방법으로 인해 빌더가 "더 많은 우회"를 할 수 있습니다. 다른 토큰 모델이 실제로는 제대로 작동하지 않는데 제대로 작동한다고 가정한다면 "본질적으로 결함이 있는" 토큰 모델을 만들고 있는 것일 수 있습니다.

보조 제목

#3 가정을 명확히 하라

당신의 가정을 분명히 하십시오. 토큰 구축에 집중할 때 기본 가정을 당연시하기 쉽습니다. 또한 당신이 실제로 만들고 있는 가정을 잘못 전달하기 쉽습니다.

예를 들어, 하드웨어 병목 현상이 계산 속도라고 가정하는 새로운 프로토콜을 생각해 보십시오. 그 가정을 토큰 모델의 일부로 만들면(예를 들어, 프로토콜에 참여하는 데 필요한 하드웨어 비용을 제한함으로써) 디자인을 원하는 동작에 맞추는 데 도움이 될 수 있습니다.

가정을 명확히 하면 토큰 디자인을 더 쉽게 이해하고 제대로 작동하는지 확인할 수 있습니다. 또한 가정에 대해 명시하지 않고 가정을 테스트할 수 없습니다.

보조 제목

#4 가정을 검증하십시오

"당신이 문제에 빠지는 것은 당신이 모르는 것이 아니라 당신이 확실히 그렇지 않다는 것을 아는 것입니다."라는 말이 있습니다.

토큰 설계자는 다양한 방법으로 가정을 검증할 수 있습니다. 종종 에이전트 기반 모델 형태의 엄격한 통계 모델링은 이러한 가설을 테스트하는 데 도움이 될 수 있습니다. 사용자 행동에 대한 가설은 종종 사용자와 대화를 통해 테스트할 수 있으며, 가급적이면 사람들이 실제로 행동하는 것을 관찰함으로써 테스트할 수 있습니다. 이는 특히 샌드박스 환경에서 경험적 결과를 생성하는 인센티브화된 테스트넷을 통해 성공적인 검증 가능성이 높습니다. 정식 검증 또는 집중 감사는 코드 기반이 예상대로 작동하는지 확인하는 데 도움이 됩니다.

보조 제목

#5 "추상적인 장벽"을 명확히 하십시오.

"추상 장벽"은 시스템 또는 프로토콜의 서로 다른 계층 간의 인터페이스입니다. 시스템의 서로 다른 구성 요소를 분리하는 데 사용되므로 각 구성 요소를 독립적으로 설계, 구현 및 수정할 수 있습니다. 명확한 추상화 장벽은 엔지니어링의 모든 분야, 특히 소프트웨어 설계에 유용하지만 분산형 개발 및 개인이 이해할 수 없는 복잡한 시스템을 구축하는 대규모 팀에 더욱 필요합니다.

토큰 설계에서 추상화 장벽을 제거하는 목표는 복잡성을 최소화하는 것입니다. 토큰 모델의 서로 다른 구성 요소 간의 (내부) 종속성을 줄이면 코드가 더 깨끗해지고 버그가 줄어들며 토큰 디자인이 개선됩니다.

예를 들어 많은 블록체인은 대규모 엔지니어링 팀에 의해 구축됩니다. 팀은 시간이 지남에 따라 하드웨어 비용에 대해 가정하고 이를 사용하여 주어진 토큰 가격으로 블록체인에 하드웨어를 제공하는 광부 수를 결정할 수 있습니다. 다른 팀이 매개 변수로 토큰 가격에 의존하지만 하드웨어 비용에 대한 첫 번째 팀의 가정을 모르는 경우 상충되는 가정을 쉽게 만들 수 있습니다.

응용 프로그램 계층에서 명확한 추상화 장벽은 구성 가능성을 활성화하는 데 중요합니다. 점점 더 많은 프로토콜이 서로 결합됨에 따라 적응, 구축, 확장 및 리믹스 기능이 더욱 중요해질 것입니다. 구성이 클수록 가능성이 커지지만 복잡성도 커집니다. 응용 프로그램이 구성을 원할 때 사용하는 구성 프로토콜의 세부 사항을 이해해야 합니다.

명확한 추상화 장벽을 생성함으로써 토큰 설계자는 특정 변경 사항이 토큰 설계의 각 부분에 어떤 영향을 미칠지 보다 쉽게 ​​예측할 수 있습니다. 명확한 추상화 장벽을 통해 토큰 또는 프로토콜을 더 쉽게 확장하고 더 포괄적이고 확장 가능한 빌더 커뮤니티를 만들 수 있습니다.

보조 제목

#6 외부 매개변수에 대한 의존도 감소

외부 매개 변수는 시스템에 내재되어 있지 않지만 컴퓨팅 리소스 비용, 트랜잭션 볼륨 또는 토큰 모델 생성 초기 단계의 대기 시간과 같은 전반적인 성능과 성공에 영향을 미칠 수 있습니다.그러나 토큰 모델은 매개변수가 제한된 범위 내에서 유지될 때만 작동하지만,예기치 않은 동작을 보일 수 있음

또는 다른 예를 들자면, 분산형 네트워크는 종종 해결하기 어렵지만 불가능하지는 않은 암호화 알고리즘 또는 계산 퍼즐에 의존합니다. 컴퓨터가 얼마나 빨리 해시 함수나 영지식 증명을 계산할 수 있는지와 같은 외생 변수에 따라 난이도가 달라지는 경우가 많습니다. 주어진 해시 함수가 얼마나 빨리 계산될 수 있는지에 대한 가정을 하고 그에 따라 토큰 보상을 지불하는 프로토콜을 고려하십시오. 누군가가 해시 함수를 더 빨리 계산하는 새로운 방법을 발명하거나 시스템에서 실제 작업에 비례하지 않는 문제를 해결하기 위해 단순히 리소스를 초과하는 경우 예상치 못한 큰 토큰으로 보상을 받을 수 있습니다.

보조 제목

#7 가정 재확인

토큰을 설계하는 것은 적대적 시스템을 설계하는 것과 같아야 합니다. 토큰이 작동하는 방식이 변경되면 사용자 행동도 변경됩니다.일반적인 실수는 임의의 사용자 작업이 여전히 허용 가능한 결과를 생성하는지 확인하지 않고 토큰 모델을 조정하는 것입니다. 토큰 모델 변경으로 인해 사용자 행동이 동일하게 유지될 것이라고 가정하지 마십시오.

일반적으로 이런 종류의 실수는 누군가가 토큰의 목표를 정의하고, 기능을 정의하고, 의도한 대로 작동하는지 확인하기 위해 유효성 검사를 수행하는 데 많은 시간을 소비하는 설계 프로세스 후반에 발생합니다. 그런 다음 특별한 경우를 식별하고 이를 수용하기 위해 토큰 디자인을 변경했지만 전체 토큰 모델을 재검증하는 것을 잊었습니다. 하나의 특수한 사례를 수정함으로써 그들은 또 다른(또는 여러 가지) 의도하지 않은 결과를 낳았습니다.