a16z: 토큰 설계 결함을 피하기 위한 7가지 조언

원문 제목：7 Sanity Checks Before Designing a Token

저자：Guy Wuollet

편집：Katie 辜，Odaily 星球日报

토큰은 다양한 방식으로 정의할 수 있는 강력한 새로운 원시입니다. 토큰 디자인 공간은 매우 풍부하지만 우리는 여전히 탐색의 초기 단계에 있습니다.

실제로 많은 팀이 그들의 프로젝트에 "올바른" 토큰 디자인을 찾기 위해 노력하고 있습니다. 그러나 이 산업은 검증된 디자인 프레임워크가 부족하여 후속 팀들이 선행 팀과 동일한 도전에 반복적으로 직면하게 됩니다. 다행히도 (소수의) 초기 성공적인 토큰 디자인의 사례도 존재합니다. 대부분의 유효한 토큰 모델은 그 목표에 대한 독특한 요소를 가지고 있지만, 대부분의 결함이 있는 토큰 디자인은 몇 가지 공통된 버그를 가지고 있습니다. 따라서 본문에서는 왜 우리가 "토큰 경제"뿐만 아니라 토큰의 연구와 디자인을 고려해야 하는지를 논의하고, 일곱 가지 "피해야 할" 작은 팁을 나열합니다.

#1 토큰 디자인의 목표 명확히 하기

토큰 디자인에서 가장 큰 문제는 목표를 명확히 하기 전에 복잡한 토큰 모델을 어떻게 구축할 것인가입니다. 첫 번째 단계는 목표를 설정하고 팀 전체가 이를 완전히 이해하도록 하는 것입니다: 그것이 무엇인지, 왜 중요한지, 당신이 정말로 이루고자 하는 것은 무엇인지? 목표를 엄격하게 정의하지 못하면 재설계와 시간 낭비로 이어지는 경우가 많습니다. 목표를 명확히 하는 것은 "토큰 경제를 디자인하기 위해 만들어진 토큰 경제" 문제를 피하는 데에도 도움이 됩니다. 이는 일부 토큰 경제 디자인에서 흔히 발생하는 현상입니다.

또한 목표는 토큰 자체를 중심으로 설정해야 하지만, 이 점은 종종 간과됩니다. 목표를 명확히 하는 예시에는 다음과 같은 것들이 있습니다:

• 최적의 확장성을 달성하고 모델링을 지원하는 토큰 모델 게임 설계.

• DeFi 프로토콜이 참여자 간에 합리적으로 위험을 분배하는 토큰 모델을 설계하고자 함.

• 담보 자금의 신뢰성 프로토콜을 설계하되, 신뢰를 직접 대체하지 않도록 함 (예: 유동성과 신뢰 신호를 분리함).

• 낮은 지연 시간에서 파일의 가용성을 보장하는 저장 네트워크 설계.

• 최대 경제적 안전성을 제공하는 스테이킹 네트워크 설계.

• 진정한 사용자 선호도나 최대 참여도를 이끌어낼 수 있는 거버넌스 메커니즘 설계.

이런 예시는 무수히 많습니다. 토큰이 모든 사용 사례를 지원하고 모든 목표를 달성할 수 있도록 해야 하며, 그 반대가 되어서는 안 됩니다.

그렇다면 명확한 목표를 정의하기 위해 어떻게 시작할까요? 명확히 정의된 목표는 종종 "프로젝트 미션"에서 비롯됩니다. "프로젝트 미션"은 종종 고차원적이고 추상적이지만, 목표는 구체적이어야 하며 가장 기본적인 형태로 단순화되어야 합니다.

EIP-1559를 예로 들어 보겠습니다. Roughgarden은 EIP-1559에 대한 명확한 목표를 다음과 같이 설명했습니다: "EIP-1559는 수요가 급증하는 시기에 '명백한 최적 입찰' 형태로 사용자 경험을 개선하기 위해 간단한 수수료 추정을 통해 작동해야 합니다."

그는 또 다른 명확한 목표를 제시했습니다: "우리가 이더리움의 거래 수수료 메커니즘을 재설계하여 거래 Gas 가격을 설정하는 것이 아마존에서 쇼핑하는 것처럼 '부드럽게' 만들 수 있을까요? 이상적으로는 각 사용자에게 Gas 가격을 수용하거나 포기할 수 있는 메커니즘을 제공하는 가격 발표 메커니즘이 필요합니다."

이 두 예시의 공통점은 고차원적인 목표를 진술하고, 다른 사람들이 당신의 목표를 이해하는 데 도움이 되는 관련 비유를 제공한 다음, 이 목표를 지원하는 디자인 솔루션을 개략적으로 설명하는 것입니다.

#2 기본 원칙에 따라 기존 작업 평가하기

새로운 것을 창조할 때 기존의 것을 연구하는 것은 좋은 아이디어입니다. 기존 프로토콜과 기존 문헌을 평가할 때는 기술적 장점에 따라 객관적으로 평가해야 합니다.

토큰 모델은 일반적으로 토큰의 가격이나 관련 프로젝트의 인기도에 따라 평가됩니다. 이러한 요소는 토큰 모델이 설정된 목표를 달성하는 능력과는 무관할 수 있습니다. 가치 평가, 인기도 또는 토큰 모델을 평가하는 다른 간단한 방법은 Builder가 "우회"하도록 만들 수 있습니다. 다른 토큰 모델이 정상적으로 작동한다고 가정하면, 실제로는 그렇지 않은 경우 "선천적으로 결함이 있는" 토큰 모델이 생성될 수 있습니다.

#3 당신의 가정을 명확히 하기

당신의 가정을 명확히 표현하세요. 토큰을 구축하는 데 집중할 때, 기본 가정을 당연하게 여기는 것이 쉽습니다. 또한 당신이 실제로 하고 있는 가정을 잘못 표현하는 것도 쉽습니다.

예를 들어, 하드웨어 병목 현상이 계산 속도라고 가정하는 새로운 프로토콜이 있다고 가정해 보겠습니다. 이 가정을 토큰 모델의 일부로 삼는 것(예: 프로토콜에 참여하는 데 필요한 하드웨어 비용을 제한함)은 디자인과 기대 행동을 일치시키는 데 도움이 될 수 있습니다.

그러나 프로토콜과 토큰 디자이너가 그들의 가정을 명확히 표현하지 않거나, 그들이 표현한 가정이 잘못된 경우, 이러한 불일치를 인식한 참여자는 프로토콜에서 가치를 추출할 수 있습니다. 해커는 종종 시스템을 처음 구축한 사람보다 시스템을 더 잘 이해하는 사람들입니다.

당신의 가정을 명확히 하면 사람들은 당신의 토큰 디자인을 더 쉽게 이해하고 정상적으로 작동하는지 확인할 수 있습니다. 가정을 명확히 하지 않으면 당신의 가정을 검증할 수 없습니다.

#4 당신의 가정을 검증하기

"당신이 모르는 것이 당신을 곤경에 빠뜨리는 것이 아닙니다. 당신이 확신하는 것이 사실이 아닐 때입니다."

토큰 모델은 일반적으로 일련의 가정을 합니다. 이 접근 방식은 부분적으로 비잔틴 시스템 디자인에서 비롯되며, 이는 블록체인의 영감입니다. 시스템은 가정을 하고, 그 가정이 참일 경우 특정 출력을 보장하는 함수를 구축합니다. 예를 들어, 비트코인은 동기화된 네트워크 모델에서 활동성을 보장하며, 네트워크의 51% 해시 파워가 정직할 경우 일관성을 보장합니다. 몇몇 작은 블록체인은 51% 공격을 당해 사토시의 합의가 블록체인이 정상적으로 작동하기 위해 요구하는 정직한 가정의 수를 위반했습니다.

토큰 디자이너는 여러 방법으로 그들의 가정을 검증할 수 있습니다. 엄격한 통계 모델링, 일반적으로 에이전트 기반 모델의 형태로, 이러한 가정을 테스트하는 데 도움이 될 수 있습니다. 사용자 행동에 대한 가정은 사용자와 대화하거나 사람들이 실제로 무엇을 했는지(그들이 무엇을 했다고 말하는 것이 아니라)를 관찰함으로써 검증할 수 있습니다. 이렇게 성공적으로 검증할 가능성이 높아지며, 특히 샌드박스 환경에서 경험적 결과를 생성하는 인센티브 테스트 네트워크를 통해 더욱 그렇습니다. 공식적인 검증이나 집중적인 감사도 코드베이스가 예상대로 작동하는지 확인하는 데 도움이 될 것입니다.

#5 "추상 장벽" 명확히 하기

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

토큰 디자인에서 추상 장벽을 제거하는 목표는 복잡성을 최소화하는 것입니다. 토큰 모델의 다양한 구성 요소 간의 (내부) 의존성을 줄이면 더 간결한 코드, 더 적은 버그 및 더 나은 토큰 디자인을 생성할 수 있습니다.

예를 들어, 많은 블록체인은 대규모 엔지니어링 팀에 의해 구축됩니다. 한 팀은 일정 기간 동안의 하드웨어 비용에 대한 가정을 하고, 이를 사용하여 주어진 토큰 가격으로 블록체인에 기여할 수 있는 채굴자의 수를 결정합니다. 만약 다른 팀이 토큰 가격을 매개변수로 의존하지만, 첫 번째 팀의 하드웨어 비용에 대한 가정을 모른다면, 그들은 서로 모순된 가정을 쉽게 하게 됩니다.

응용 프로그램 계층에서 명확한 추상 장벽은 조합 가능성을 실현하는 데 필수적입니다. 점점 더 많은 프로토콜이 서로 조합됨에 따라, 적응하고, 구축하고, 확장하고, 재혼합하는 능력은 점점 더 중요해질 것입니다. 더 큰 구성은 더 큰 가능성을 가져오지만, 더 큰 복잡성도 가져옵니다. 응용 프로그램이 조합하고자 할 때, 그들은 사용하고 있는 조합 프로토콜의 세부 사항을 이해해야 합니다.

불투명한 가정과 인터페이스는 때때로 모호한 버그를 초래하며, 특히 초기 DeFi 프로토콜에서 그러합니다. 모호한 추상 장벽은 프로토콜의 다양한 구성 요소를 처리하는 팀 간의 커뮤니케이션 효율성을 증가시켜 개발 시간을 연장합니다. 모호한 추상 장벽은 또한 프로토콜의 복잡성을 증가시켜 그 메커니즘을 완전히 이해하기 어렵게 만듭니다.

명확한 추상 장벽을 생성함으로써, 토큰 디자이너는 특정 변경이 토큰 디자인의 각 부분에 어떻게 영향을 미칠지를 더 쉽게 예측할 수 있습니다. 명확한 추상 장벽은 또한 토큰이나 프로토콜을 확장하는 것을 더 쉽게 만들고, 더 포괄적이고 확장 가능한 Builder 커뮤니티를 만드는 데 기여합니다.

#6 외부 매개변수에 대한 의존성 줄이기

외부 매개변수는 시스템에 내재된 것이 아니지만, 전체 성능과 성공에 영향을 미칩니다. 예를 들어, 토큰 모델의 생성 초기 단계에서의 계산 자원의 비용, 거래량 또는 지연 등이 있습니다.

그러나 토큰 모델이 매개변수가 제한된 범위 내에서만 작동할 때, 예상치 못한 행동이 발생할 수 있습니다. 예를 들어, 서비스를 판매하고 고정된 토큰 보상의 형태로 리베이트를 제공하는 프로토콜이 있다면, 토큰의 가격이 예상보다 높을 경우, 토큰 보상의 가치는 서비스의 비용을 초과할 수 있습니다. 이 경우, 프로토콜에서 무한정 서비스를 구매하는 것이 상당히 유리하게 되어, 토큰 보상과 서비스를 최대한 활용하게 됩니다.

또 다른 예로, 분산 네트워크는 종종 해결하기 어려운 암호 알고리즘이나 계산 문제에 의존합니다. 난이도는 일반적으로 외부 변수에 따라 달라지며, 예를 들어 컴퓨터가 해시 함수를 계산하거나 제로 지식 증명을 수행하는 속도에 따라 달라집니다. 예를 들어, 특정 해시 함수를 계산하는 속도를 가정하고 그에 따라 토큰 보상을 지급하는 프로토콜이 있다고 가정해 보겠습니다. 만약 누군가 더 빠르게 해시 함수를 계산하는 새로운 방법을 발명하거나, 시스템 내에서 실제 작업과 비례하지 않는 초대형 자원을 보유하고 있다면, 그들은 예상치 못한 막대한 토큰 보상을 받을 수 있습니다.

#7 가정 재검증하기

토큰을 설계하는 것은 적대적 시스템을 설계하는 것과 같아야 합니다. 사용자의 행동은 토큰이 작동하는 방식에 따라 변화할 것입니다.

일반적인 실수는 임의의 사용자 행동이 여전히 수용 가능한 결과를 생성할 수 있도록 보장하지 않고 토큰 모델을 조정하는 것입니다. 사용자 행동이 토큰 모델의 변화에 따라 변하지 않을 것이라고 생각하지 마십시오. 이러한 실수는 종종 디자인 과정의 후반부에서 발생하며, 누군가는 토큰의 목표를 정의하고, 기능을 정의하며, 예상대로 작동하는지 확인하는 데 많은 시간을 소비합니다. 그런 다음, 그들은 특정 예외를 식별하고 이를 수용하기 위해 토큰 디자인을 변경하지만, 전체 토큰 모델을 재검증하는 것을 잊습니다. 특정 예외를 수정함으로써, 그들은 또 다른(또는 여러 개의) 예상치 못한 결과를 초래하게 됩니다.

힘들게 한 작업이 헛되지 않도록 기억하세요. 프로젝트가 토큰 모델을 변경할 때마다 그것이 예상대로 작동하는지 재검증해야 합니다.