인프라 토큰(예: L1 또는 L2)의 경우 블록 공간에 대한 수요와 공급 관계에 뿌리를 둔 경제 모델이 완전히 개발되고 이해되었습니다. 그러나 애플리케이션 토큰(블록체인 온체인 서비스를 배포하는 스마트 계약 프로토콜)의 경우 경제 모델은 여전히 개선되고 있습니다.
애플리케이션 토큰의 업무 모델은 기본 소프트웨어만큼 표현력이 풍부해야 합니다. 이를 위해 본 글에서는 애플리케이션 토큰의 현금흐름 개념을 소개한다. 이 접근 방식을 통해 애플리케이션은 사용자가 자신이 제공하는 가치에 대해 보상을 받는 방법을 선택할 수 있는 느슨하고 유연한 모델을 만들 수 있습니다. 이 접근 방식은 다양한 관할권의 규제 요구 사항에 따라 합법적인 활동에 대해 수수료를 부과함으로써 더 큰 규정 준수를 장려합니다. 또한 최소한의 거버넌스를 장려하면서 프로토콜의 가치를 극대화할 수 있습니다.
이 기사에서 공유된 원칙은 DeFi부터 탈중앙화 소셜 애플리케이션, DePIN 네트워크 및 그 사이의 모든 것에 이르기까지 모든 Web3 애플리케이션에 적용됩니다.
토큰 모델이 직면한 과제
인프라 토큰은 고유한 공급과 수요의 영향을 받습니다. 수요가 증가하면 공급이 감소하고 시장은 그에 따라 조정됩니다. 많은 인프라 토큰을 위한 이러한 기본 경제 기반은 모든 이더 거래에 대한 소각 메커니즘을 구현한 이더 개선 제안 1559(EIP-1559)에 의해 가속화되었습니다. 모델을 구매하고 소각하려는 시도가 산발적으로 있지만 애플리케이션 토큰에 대한 EIP-1559와 유사한 모델은 없습니다.
애플리케이션은 제공자가 아닌 블록 공간의 사용자이므로 자신의 블록 공간을 사용하는 다른 사람의 가스 요금에 의존할 수 없습니다. 그렇기 때문에 그들은 그들만의 경제 모델을 개발해야 합니다.
여기에는 몇 가지 법적 문제도 있습니다. 일반적인 블록체인 거래의 일반적인 특성과 이들이 사용하는 프로그래밍 메커니즘으로 인해 인프라 토큰 이코노미 모델은 법적 리스크 에 덜 취약합니다. 그러나 애플리케이션 토큰 이코노미 모델의 경우 관련 애플리케이션은 규제 활동에 의존할 수 있으며 토큰 보유자를 관리하는 중개자가 필요할 수 있으므로 경제가 더욱 복잡해집니다. 예를 들어 파생상품 거래(미국에서 고도로 규제되는 활동)를 촉진하는 탈중앙화 거래소 예를 들어 이더 과 완전히 다릅니다.
이러한 내부 및 외부 과제는 애플리케이션 토큰에 다른 경제 모델이 필요하다는 것을 의미합니다. 이를 염두에 두고 이 기사에서는 가능한 솔루션, 즉 프로토콜 수익을 최대화하고 규제 준수를 장려하며 거버넌스 최소화 서비스를 통합하는 동시에 애플리케이션 토큰 보유자에게 보상하는 프로토콜을 설계하는 방법을 제안합니다. 목표는 간단합니다. 많은 인프라 토큰이 이미 보유하고 있는 현금 흐름을 통해 동일한 경제적 기반을 애플리케이션 토큰에 제공하는 것입니다.
이 솔루션은 애플리케이션 토큰이 직면한 세 가지 문제를 해결하는 데 중점을 둡니다.
· 거버넌스 과제
· 가치 분배 문제
· 규제 문제
거버넌스 과제
애플리케이션 토큰에는 거버넌스 권한이 있는 경우가 많으며, DAO의 존재는 인프라 토큰이 직면하지 않는 불확실성을 가져올 수 있습니다. 미국에서 중요한 업무 하는 DAO의 경우 DAO가 프로토콜 수익을 통제하거나 프로토콜 경제 활동 및 프로그램을 위한 중개자 역할을 하면 리스크 발생할 수 있습니다. 이러한 리스크 피하기 위해 프로젝트는 거버넌스를 최소화하여 DAO에 대한 통제를 제거할 수 있습니다. 이를 수행할 수 없는 DAO를 위해 와이오밍에 새로 형성된 DUNA (탈중앙화 형 비법인 비영리 협회)는 이러한 리스크 완화하고 해당 세법을 준수하는 데 도움이 될 수 있는 탈중앙화 법인체를 제공합니다.
가치분배 도전
애플리케이션은 토큰 보유자에게 가치를 분배하기 위한 메커니즘을 신중하게 설계해야 합니다. 투표권과 경제적 권리를 결합하는 것은 미국 증권법에 따라 우려를 불러일으킬 수 있으며, 특히 비례 배분 및 토큰 구매 및 소각과 같은 간단하고 직접적인 메커니즘의 경우 더욱 그렇습니다. 이러한 메커니즘은 배당금 및 자사주 매입과 유사해 보이며 토큰이 주식과 다른 규제 프레임 따라야 한다는 주장을 약화시킬 수 있습니다.
프로젝트는 이해관계자 모델을 탐색하여 프로젝트에 이익이 되는 방식으로 토큰 보유자에게 기여에 대해 보상해야 합니다. 프런트엔드 운영(Liquity), 프로토콜 참여(Goldfinch), 보안 모듈 의 일부로 담보 스테이 스테이킹(Aave 등) 등 많은 프로젝트가 적극적인 참여를 장려하고 있습니다. 여기서 디자인 공간은 열려 있지만 좋은 출발점은 프로젝트의 모든 이해관계자를 계획하고, 각자가 취해야 할 행동을 식별하고, 프로토콜이 이 인센티브를 통해 창출할 수 있는 전반적인 가치를 결정하는 것입니다.
단순화를 위해 이 기사에서는 거버넌스 참여에 대해 토큰 보유자에게 보상하는 간단한 보상 모델을 가정합니다.
규제 문제
규제 활동을 촉진하는 애플리케이션은 토큰 보유자를 위한 가치 부가 메커니즘을 설계할 때에도 주의해야 합니다. 그러한 메커니즘이 해당 법률을 준수하지 않는 프런트 엔드 또는 API에서 가치를 파생하는 경우 토큰 보유자는 불법 활동으로 이익을 얻을 수 있습니다.
이 문제에 대해 제안된 대부분의 솔루션은 미국에서 허용되는 활동에 대한 가치 추가를 제한하는 데 중점을 둡니다. 예를 들어 특정 자산과 관련된 유동성 풀에 대해서만 프로토콜 수수료를 부과합니다. 이는 프로젝트를 규제적 접근 방식에 종속시키고 글로벌 자율 소프트웨어 프로토콜의 가치 제안을 약화시킵니다. 이는 또한 거버넌스를 최소화하려는 노력을 직접적으로 훼손합니다. DAO가 규제 준수 관점에서 어떤 수수료 전략이 효과적인지 결정하는 것은 적절하지 않습니다.
이상적인 세상에서 프로젝트는 허용되는 활동을 결정하기 위해 DAO에 의존할 필요 없이 그러한 활동을 허용하는 모든 관할권에서 수수료를 징수할 수 있습니다. 해결책은 프로토콜 수준에서 규정 준수를 요구하는 것이 아니라 해당 수수료를 생성하는 프런트엔드 또는 API가 프런트엔드가 실행되는 지역의 해당 법률 및 규정을 준수하는 경우에만 프로토콜에서 발생하는 수수료가 전달되도록 하는 것입니다. 위치하고 있습니다. 미국이 앱을 통해 촉진되는 특정 거래에 대한 수수료를 금지한다면, 전 세계 다른 국가에서 그러한 활동이 허용되더라도 앱 토큰의 경제적 가치가 0으로 줄어들 수 있습니다. 수수료 발생 및 할당의 유연성은 궁극적으로 규제 압력에 대한 탄력성과 동일합니다.
핵심 문제: 소급 수수료
계약에 대한 조사나 라이센스의 리스크 초래하지 않고 비준수로 인해 발생하는 잠재적인 리스크 해결하려면 수수료 추적성이 중요합니다. 추적성을 통해 애플리케이션은 토큰 보유자가 받는 모든 수수료가 토큰 보유자의 관할권 내에서 합법적이고 규정을 준수하는 프런트엔드에서만 발생하는지 확인할 수 있습니다. 수수료를 추적할 수 없는 경우, 규정을 준수하지 않는 프런트엔드에서 가치가 축적되지 않도록 토큰 보유자를 보호할 방법이 없으며, 이는 토큰 보유자를 리스크 에 빠뜨릴 수 있습니다.
비용을 추적 가능하게 만들기 위해 프로토콜은 두 단계로 설계될 수 있습니다.
· 1단계: 비용이 발생한 프런트 엔드 식별
· 2단계: 맞춤형 로직을 기반으로 수수료를 다른 풀로 라우팅
매핑 프런트엔드
수수료 추적성을 위해서는 도메인에서 공개/개인 키 쌍으로의 일대일 매핑이 필요합니다. 이러한 매핑이 없으면 악의적인 프런트엔드가 거래를 위조하고 정직한 도메인에서 제출된 것처럼 가장할 수 있습니다. 암호화를 사용하면 "등록된" 프런트엔드가 도메인-공개 키 매핑을 불변하게 기록하고 도메인이 실제로 해당 공개 키를 제어한다는 것을 증명하고 해당 개인 키를 사용하여 트랜잭션에 서명할 수 있습니다. 이를 통해 우리는 거래(및 수수료)를 특정 도메인에 귀속시킬 수 있습니다.
라우팅 비용
수수료 출처를 추적할 수 있게 되면 프로토콜은 토큰 보유자가 불법 거래에 대해 수수료를 청구하지 않고 DAO의 탈중앙화 거버넌스 부담을 증가시키지 않도록 이러한 수수료를 분배하는 방법을 결정할 수 있습니다. 이를 설명하기 위해 프런트엔드당 하나의 스테이킹 풀부터 모든 프런트엔드가 공유하는 단일 스테이킹 풀까지 토큰 스테이킹 적용하기 위한 다양한 디자인을 고려할 수 있습니다.
가장 간단한 구성에서는 각 프런트엔드의 수수료를 별도의 프런트엔드별 스테이킹 모듈 로 라우팅할 수 있습니다. 스테이킹 프런트엔드를 선택함으로써 토큰 보유자는 청구할 수수료를 결정하고 법적 리스크 에 처하게 되는 수수료를 피할 수 있습니다. 예를 들어, 토큰 보유자는 유럽의 모든 규제 당국에서 승인한 프런트엔드 관련 모듈 에만 스테이킹 할 수 있습니다. 이 디자인은 간단해 보이지만 실제로는 상당히 복잡합니다. 50개의 서로 다른 프런트엔드에 잠재적으로 50개의 스테이킹 풀이 있으므로 수수료 희석은 토큰 가치에 부정적인 영향을 미칠 수 있습니다.
반면, 각 프런트 엔드에 대한 수수료는 하나로 묶을 수 있지만 이는 수수료 추적의 목적을 상실합니다. 모든 비용을 합산하면 규정을 준수하는 프런트엔드와 비규정을 준수하는 프런트엔드의 비용을 구별할 수 있는 방법이 없습니다. 토큰 보유자는 수수료를 부과하지 않는 것과 자신의 관할권에서 규정을 준수하지 않는 프런트 엔드의 불법 활동으로부터 이익을 얻을 수 있는 풀에 지분을 보유하는 것 중에서 선택해야 합니다. — —이 옵션은 많은 토큰 보유자가 참여하는 것을 막을 수 있습니다. 시스템을 현재의 최적이 아닌 설계로 되돌릴 수 있습니다. 즉, DAO는 수수료가 적용될 수 있는 위치를 평가해야 합니다.
관리를 통한 비용 추적성 문제 해결
이러한 복잡성은 관리를 통해 해결될 수 있습니다. 수수료와 토큰이 포함된 무허가형 스마트 계약 프로토콜 애플리케이션을 생각해 보세요. 누구나 애플리케이션에 대한 프런트엔드를 만들 수 있고 모든 프런트엔드는 자체 스테이킹 모듈 가질 수 있습니다. 이 프로토콜에 대한 하나의 프런트엔드는 App.xyz라고 합니다.
App.xyz는 운영되는 관할권의 특정 규정 준수 규칙을 준수할 수 있습니다. app.xyz에서 시작되는 애플리케이션 활동에는 프로토콜 요금이 발생합니다. App.xyz에는 토큰 보유자가 자신의 토큰을 모듈 스테이킹 하거나 규정을 준수하는 것으로 간주되는 프런트엔드 바구니를 개별적으로 스테이킹 하려는 관리자에게 스테이킹할 수 있는 자체 스테이킹 모듈 있습니다. 이러한 토큰 스테이킹 자신이 스테이킹 한 프런트엔드 세트에서 수수료 형태로 혜택을 받게 됩니다. 프런트엔드가 $100의 수수료를 생성하고 100개의 엔터티가 각각 1개의 토큰을 스테이킹 경우 각 엔터티는 $1를 받을 자격이 있습니다. 관리자는 처음에 서비스 요금을 청구할 수 있습니다. 앞으로 정부는 관리 자동화라는 부가적인 이점과 함께 소비자를 보호하기 위해 온체인 관할권 내에서 프런트엔드 규정 준수를 인증할 수 있습니다.
이 모델의 잠재적인 리스크 중 하나는 비준수 프런트 엔드에는 준수 프런트 엔드만큼 관리 오버헤드가 없기 때문에 운영 비용이 더 낮을 수 있다는 것입니다. 또한 거래자 에게 프런트엔드 수수료를 회수하기 위한 모델을 설계할 수도 있습니다. 두 가지 요소가 이러한 리스크 완화합니다. 첫째, 대부분의 사용자는 실제로 특히 대규모 규제 기관의 경우 현지 법률 및 규정을 준수하기 위해 규정 준수 프런트엔드를 원합니다. 둘째, 반복적으로 규칙을 위반하고 애플리케이션의 실행 가능성을 위협하는 비준수 프런트 엔드의 경우 거버넌스를 최후의 수단으로 사용하거나 나쁜 행동을 방지하기 위해 "거부권"을 행사할 수 있습니다.
마지막으로, 등록된 프런트엔드를 통해 시작되지 않은 모든 거래 수수료는 단일 종합 스테이킹 모듈 에 예치되어 프로토콜이 봇 시작 거래 및 프로토콜 스마트 계약과의 기타 직접적인 상호 작용을 통해 수익을 창출할 수 있도록 합니다.
이론에서 구현까지: 방법을 실제로 적용
애플리케이션 토큰 스택에 대한 자세한 검토입니다. 프런트엔드 스테이킹 용이하게 하는 프로토콜의 경우 프런트엔드가 등록해야 하는 등록 스마트 계약의 설정이 필요합니다.
각 프런트 엔드 또는 API는 ENS DNS 통합과 같은 도메인의 DNS 레코드에 특수 TXT 레코드를 추가할 수 있습니다. 이 TXT 레코드에는 인증서라고 하는 프런트 엔드에서 한 번 생성된 키 쌍의 공개 키가 포함되어 있습니다.
그런 다음 프런트 엔드 클라이언트는 Register() 함수를 호출하고 도메인 이름을 소유하고 있음을 증명할 수 있습니다. 시스템은 도메인과 인증서 공개 키 간의 매핑을 저장하며 그 반대의 경우도 마찬가지입니다.
클라이언트를 통해 트랜잭션이 생성되면 인증서 공개 키를 사용하여 트랜잭션 페이로드에도 서명합니다. 이는 번들 형태로 애플리케이션의 스마트 계약에 전달됩니다.
애플리케이션의 스마트 계약은 인증서를 확인하고 그것이 올바른 tx 주체에 해당하는지 확인하고 등록됩니다. 그렇다면 거래가 처리됩니다. 거래로 인해 생성된 수수료는 도메인 이름(레지스트리에서)과 함께 FeeCollector 계약으로 전송됩니다.
FeeCollector를 사용하면 관리자, 사용자, 검증자 등이 단일 도메인 또는 도메인 집합에 직접 토큰을 스테이킹 할 수 있습니다. 이러한 계약은 각 도메인에 스테이킹 토큰 수, 각 주소의 스테이킹 점유율 및 스테이킹 기간을 추적해야 합니다. 유동성 채굴 의 대중적인 구현은 이 계약 논리의 출발점으로 사용될 수 있습니다.
관리자(또는 직접 수수료 관리 계약 자체)에 스테이킹 한 사용자는 도메인에 스테이킹 애플리케이션 토큰 수에 따라 수수료의 비례 지분을 클레임 할 수 있습니다. 아키텍처는 MetaMorpho/Morpho Blue와 유사할 수 있습니다.
이 기능을 도입한다고 해서 애플리케이션 DAO의 거버넌스 부담이 증가하지는 않습니다. 실제로, 프로토콜에 의해 촉진되는 모든 거래에 대해 수수료 전환이 영구적으로 활성화될 수 있으므로 거버넌스 책임이 줄어들 수 있으며, 이로써 프로토콜의 경제 모델에 대한 DAO의 모든 통제가 제거됩니다.
애플리케이션 유형에 따른 추가 고려 사항
이러한 원칙은 토큰 이코노미 모델에 광범위하게 적용되지만 애플리케이션 유형(L2 내부 또는 외부에서 구축된 애플리케이션, 애플리케이션 체인, 롤업을 사용하여 구축된 애플리케이션)에 따라 고려해야 할 다른 수수료가 있습니다.
L1/L2 애플리케이션
L1/L2 블록체인 온체인 애플리케이션은 스마트 계약을 온체인 에 직접 배포합니다. 사용자가 애플리케이션의 스마트 계약과 상호 작용할 때 수수료가 징수됩니다. 일반적으로 이는 개인 투자자 와 기본 스마트 계약 간의 인터페이스 역할을 하는 사용하기 쉬운 프런트 엔드(예: 앱 또는 웹 사이트)를 통해 발생합니다. 이 경우 모든 요금은 해당 프런트 엔드에서 발생합니다. app.xyz에 대한 위의 예는 L1 애플리케이션에서 수수료 시스템이 작동하는 방식을 보여줍니다.
관리자에게 프런트 엔드 요금을 필터링하는 것 외에도 애플리케이션은 화이트리스트 또는 블랙리스트 접근 방식을 사용하여 네트워크 요금을 증가시키는 프런트 엔드를 필터링할 수도 있습니다. 여기서도 목적은 토큰 보유자와 전체 프로토콜이 불법 활동으로 이익을 얻지 않도록 하고 특정 관할권의 법률 및 규정을 준수하도록 하는 것입니다.
화이트리스트 접근 방식에서 애플리케이션은 프런트엔드에 대한 일련의 규칙을 게시하고, 규칙을 준수하는 프런트엔드 레지스트리를 생성하고, 옵트인한 프런트엔드에 인증서를 발급하고, 일부를 받기 위해 프런트엔드가 토큰을 스테이킹 요구합니다. 신청 수수료. 프런트 엔드가 규칙을 준수하지 않는 경우 해당 프런트 엔드는 삭제되고 수수료 기여 인증서는 제거됩니다.
블랙리스트 접근 방식에서는 애플리케이션이 규칙을 생성할 필요가 없지만 애플리케이션 프런트엔드 실행은 무허가가 아닙니다. 대신, 응용 프로그램은 프런트 엔드가 응용 프로그램을 사용하도록 허용하기 전에 프런트 엔드가 해당 관할권을 준수함을 인증하는 법률 회사의 의견을 제공하도록 모든 프런트 엔드를 요구합니다. 의견이 접수되면 애플리케이션은 프런트엔드에 수수료 기부 인증서를 발급합니다. 이 인증서는 애플리케이션이 규제 기관으로부터 프런트엔드가 규정을 준수하지 않는다는 알림을 받은 경우에만 제거됩니다.
비용 채널은 이전 섹션에 제공된 예와 유사합니다.
두 접근 방식 모두 탈중앙화 거버넌스의 부담을 크게 증가시켜 DAO가 일련의 규칙을 수립 및 유지하거나 규정 준수에 관한 법적 의견을 평가하도록 요구합니다. 어떤 경우에는 이것이 허용될 수 있지만 대부분의 경우 이러한 규정 준수 부담을 관리자에게 아웃소싱하는 것이 더 좋습니다.
애플리케이션 체인
애플리케이션 체인은 해당 애플리케이션에 특정한 검증인이 있는 애플리케이션별 블록체인입니다.
이러한 검증인은 작업에 대한 대가로 보상을 받습니다. 일반적으로 검증인이 인플레이션을 통해 토큰을 발행하여 보상을 받는 L1 블록체인과 달리 일부 애플리케이션 체인(dYdX)은 고객 수수료를 검증인에게 이전합니다.
이 모델에서 토큰 보유자는 보상을 받기 위해 검증인에게 스테이킹 해야 합니다. 검증인은 선별된 스테이킹 모듈 됩니다.
이 작업 세트는 L1 검증기와 다릅니다. 애플리케이션 체인 유효성 검사기는 특정 애플리케이션의 특정 트랜잭션을 처리합니다. 이러한 차이로 인해 Lisk 검증인은 자신이 촉진하는 리스크 활동과 관련하여 더 큰 법적 리스크 부담할 수 있습니다. 따라서 프로토콜은 검증인에게 자신의 관할권 법률과 자신의 의지에 따라 수행할 수 있는 작업을 수행할 수 있는 자유를 부여해야 합니다. 중요한 것은 검증인 세트가 지리적으로 분산되어 있는 한 블록체인의 무허가 특성을 위태롭게 하거나 심각한 검열 리스크 에 노출시키지 않고 이를 수행할 수 있다는 것입니다.
비용 추적성을 활용하려는 애플리케이션 체인의 아키텍처는 L1 애플리케이션과 유사합니다. 그러나 검증인은 프런트엔드 매핑을 사용하여 트랜잭션을 처리할 프런트엔드를 결정할 수 있습니다. 특정 거래에 대한 수수료는 활성 검증인 세트로 전달되며, 참여하지 않기로 선택한 비활성 검증인은 해당 수수료를 잃게 됩니다. 수수료 측면에서 검증인은 위에서 설명한 스테이킹 모듈 관리자와 동일한 기능을 수행하며, 이러한 검증인의 스테이킹 불법 활동으로 인해 수입을 얻지 못한다는 것을 보장받습니다. 검증인은 각 관할권에서 어느 프런트엔드가 규정을 준수하는지 결정하기 위해 관리인을 선출할 수도 있습니다.
롤업
롤업에는 자체 블록 공간이 있지만 다른 체인의 보안을 상속받을 수 있습니다. 오늘날 대부분의 롤업에는 단일 순서 가 있습니다. 이러한 롤업이 애플리케이션별로 이루어지고 순서 유일한 유효성 검사기로 사용하는 경우 해당 순서 에 포함된 거래에 의해 생성된 수수료는 큐레이트된 규정 준수 프런트엔드 세트 또는 일반 풀을 기반으로 스테이킹 에게 배포될 수 있습니다.
Rollups가 순서 탈중앙화 하면 순서 사실상 주요 스테이 스테이킹 모듈 되며 청구 채널은 AppChain과 동일하게 됩니다. 순서 수수료 분배를 위해 검증자를 교체하며, 각 순서 수수료를 받을 프런트엔드를 스스로 결정할 수 있습니다.
애플리케이션 토큰에 사용할 수 있는 모델은 많지만 선별된 스테이킹 풀을 제공하면 애플리케이션 고유의 외부 문제를 해결하는 데 도움이 될 수 있습니다. 애플리케이션이 직면한 내부 및 외부 과제를 인식함으로써 창립자는 처음부터 프로젝트에 대한 애플리케이션 토큰 모델을 더 잘 설계할 수 있습니다.
블록비츠(Theblockbeats) BlockBeats 공식 커뮤니티 에 오신 것을 환영합니다.
텔레그램 구독 그룹: https://t.me/theblockbeats
텔레그램 커뮤니케이션 그룹: https://t.me/BlockBeats_App
공식 트위터 계정: https://twitter.com/BlockBeatsAsia
