a16z: 토큰 디자인의 함정, 해결책 및 미래 전망

출처 링크： Token디자인: Eddy Lazzarin과 함께하는 정신 모델, 능력 및 새로운 디자인 공간

비디오 저자：Eddy Lazzarin, a16z Crypto

편집：첸원, ChainCatcher

Eddy Lazzarin은 암호화폐 팀의 엔지니어링 책임자로, 이번 비디오는 여러 주제를 다루며, 사람들이 토큰 디자인을 고려할 때 흔히 겪는 함정과 가능한 해결책을 제시합니다. 그는 토큰 디자인이 실제로는 프로토콜 디자인이라고 생각하며, 토큰은 우리가 만들고자 하는 것이 아니라, 우리가 실제로 해야 할 것은 프로토콜이라고 강조합니다.

토큰은 프로토콜의 설계 방식과 달성할 수 있는 결과를 변화시키는 매우 흥미롭고 유용하며 강력한 새로운 도구입니다. 그러나 토큰은 디자인의 핵심 객체가 아닙니다. 현재의 프로토콜 디자인은 "연금술"과 같은 학문으로, 디자이너의 이해가 전면적이거나 과학적이지 않기 때문에 대부분의 프로젝트는 여전히 많은 실험이 필요합니다.

이번 내용은 세 부분으로 나뉘어 있습니다. 첫째는 토큰 디자인에서 흔히 볼 수 있는 사고 방식, 둘째는 토큰 분류로, 토큰이 무엇인지 및 우리가 그것들의 능력을 개발하고 강화하는 방법에 대해 구체적으로 이야기합니다. 마지막으로는 기술 트리 이론으로, 기술을 활용하여 우리의 디자인이 더 쉽게 성공할 수 있도록 하는 방법입니다.

1. 사고 방식

첫째, 토큰은 프로토콜을 위해 존재한다. 그것들은 단지 도구일 뿐이며, 디자인 과정의 일부일 뿐입니다. 그것들이 목표가 되어서는 안 됩니다. 만약 당신이 탈중앙화된 무언가를 만들고 싶다면, 토큰은 그 일부가 될 수 있습니다. 왜냐하면 그것은 사람들이 프로토콜에 대한 소유권을 가질 수 있게 해주고, 사람들을 일치시킬 수 있기 때문입니다.

디자인의 세 단계

나는 포트폴리오 회사와의 접촉을 통해 성공적인 디자인 과정에서 세 가지 단계를 요약했습니다.

첫 번째 단계： 목표 정의. 목표는 유효한 프로토콜 결과에 대한 간결한 설명으로, 명확해야 하며, 구체적인 디자인을 통해 달성되었는지 여부를 판단할 수 있어야 합니다. 따라서 성공과 실패에 대해 우리는 매우 명확한 구분이 필요합니다. 우리의 목표가 무엇인지 불확실하다면, 우리는 처음부터 다시 시작해야 하며, 먼저 토큰을 잊어야 합니다. 이상적으로 목표는 측정 가능해야 하며, 비록 우리가 성공을 어떻게 측정할지 확실하지 않더라도 말입니다.

두 번째 단계：제한 도입. 일반적으로 두 가지 제한이 있습니다. 하나는 내재적 제한이고, 다른 하나는 외재적 제한입니다. 내재적 제한은 디자인 과정을 단순화하기 위해 우리가 선택한 제한으로, 어떤 것을 포기해야 하거나 그 자체가 포기일 수 있습니다. 예를 들어, 우리가 좋아하는 흥미로운 특징을 제한할 수 있습니다. 나는 Subset 게임 팀의 강의를 본 적이 있으며, 그들은 《함정의 전투》와 《광속 초월》과 같은 매우 멋진 게임을 디자인했으며, 제한 조건 하에서 디자인을 진행했다고 언급했습니다. 나는 프로토콜을 디자인하는 모든 사람에게 이 강의를 추천합니다. 그들이 제한을 선택할 때 고려하는 것은 게임에서 무엇이 흥미로운가입니다. 내재적 제한은 여러 측면에서 올 수 있지만, 일반적으로 디자이너 자신이 결정합니다. 외재적 제한은 자연, 기술적 상황, 법규 및 다양한 것들이 당신에게 부과하는 것입니다. 나는 이후에 더 자세히 설명할 것입니다.

세 번째 단계：메커니즘 디자인. 일단 제한과 목표가 생기면, 우리는 이 목표를 충족할 수 있는 메커니즘을 명확하게 생각할 수 있습니다. 이제 우리가 메커니즘을 고려할 때, 그것이 이러한 제한 조건을 위반하는지, 목표에 더 가까워지게 하는지 명확히 이해해야 합니다. 프로토콜은 특정 목표를 향해 몇 가지 제한 조건에 따라 추진되는 메커니즘의 집합이 될 것입니다.

MakerDAO를 예로 들어보겠습니다. 그들의 목표는 안정적인 이더리움 네이티브 자산을 개발하는 것입니다. 물론 안정성과 네이티브는 여러 가지 해석이 가능합니다. 그들의 제한은 가격이 달러에 연동되어야 하며, 완전히 네이티브 체인 상 자산으로 지원되어야 한다는 것입니다.

흔한 함정

(1) 토큰에 대한 과도한 강조. 나는 이미 이 점을 언급했지만, 만약 당신이 항상 보상이나 토큰 분배에 대해 생각하고, 시스템 내에서 참여자 간의 일관성을 유지하는 방법에 대해 생각하지 않는다면, 당신은 프로토콜이 아니라 토큰에 대해 생각하고 있을 수 있습니다. 토큰은 프로토콜이 아니며, 토큰이 당신의 목표가 되어서는 안 됩니다. 그것은 단지 도구일 뿐입니다.

이 함정을 어떻게 피할 수 있을까요? 스스로에게 물어보세요: 만약 토큰이 없다면, 이 시스템은 어떻게 작동할까요? 만약 토큰을 완전히 제거했을 때 시스템이 완전히 실패한다면, 당신은 아마도 토큰의 역할을 과도하게 강조한 것입니다. 시스템의 몇 가지 핵심 부분이 실패했다면, 상황은 전자보다 나을 수 있습니다. 당신의 토큰은 실제로 중요하며, 전체적인 균형에 필요하지만, 그것이 없더라도 시스템은 여전히 일관되고 완전합니다. 따라서 당신은 시스템의 목표로 돌아가서 생각해야 합니다.

(2) 디자인 공간의 제한 없음. 디자인 과정에서 너무 많은 아이디어와 가능성이 있어 어디서부터 시작해야 할지 모르는 경우가 많습니다. 이는 일반적으로 목표가 불명확하기 때문에 발생하므로 목표를 구체화해야 합니다. 또한 외부에서 주어진 제한에 대한 이해가 부족하거나 이러한 제한을 받아들이지 않았기 때문일 수 있습니다.

이러한 제한을 도입하면 디자인 공간이 좁아지고 더 명확해질 것입니다. 디자인 공간을 제한하는 데 도움이 되는 두 가지 질문은, 스스로에게 물어보는 것입니다: 당신이 구축하고자 하는 강력한 개념은 무엇인가? 그것은 깊은 생각, 장점, 시대의 변화 등일 수 있습니다. 이 강력한 개념이 무엇인지 스스로에게 물어보세요. 당신은 그것을 최대한 활용하고 집중할 수 있는 방법은 무엇인가요? 또 다른 질문은: 이 디자인의 가장 큰 약점은 무엇인가? 무엇이 당신을 밤새 불안하게 만드는가? 그것은 당신이 가능성이 없다고 생각하는 지점, 걱정되는 지점, 주요 약점이며, 그것을 개선하기 위해 어떤 제한을 받아들일 수 있는가? 이는 디자인 공간을 크게 제한할 수 있습니다.

(3) 항상 커뮤니티에 의존하기. 시스템의 특정 부분에서 도전에 직면했을 때, 모든 문제를 커뮤니티에 떠넘기거나 보이지 않는 힘이 공백을 메우기를 기대하는 것은 매우 위험합니다. 비허가 시스템이 인기를 끌고 많은 놀라운 혁신을 가져왔지만, 커뮤니티의 행동을 예측할 수 없으며, 그들이 시스템의 가장 명백한 문제를 해결할 것이라고 기대해서는 안 됩니다.

스스로에게 물어봐야 할 몇 가지 핵심 질문이 있습니다. 우리는 커뮤니티에 대해 진정으로 무엇을 기대하고 있으며, 우리는 그들에게 무엇을 제공하고 있는가? 그들에게 충분한 토큰을 제공하고 있는가? 아니면 그들에게 어떤 권한을 부여하고 있는가? 그들에게 어떤 능력을 주고 있는가? 그들은 어떤 소유권을 가지고 있는가? 그들이 이러한 책임을 균형 있게 유지할 수 있는 충분한 권한을 부여받았는가?

만약 당신이 그들이 어떤 것을 고칠 것이라고 진정으로 기대한다면, 다른 야망 있는 사람들이 흥미로운 확장 기능을 추가하거나 시스템의 일부 구성 요소를 수정할 것이라고 기대한다면, 먼저 스스로에게 물어봐야 합니다. 당신은 여기서 무엇을 구축할 것인가? 만약 당신이 그것을 구축하지 않을 것이라면, 충분한 성장 공간, 충분한 힘 또는 충분한 유연성이 없다면, 다른 사람에게 기대할 필요는 없습니다.

2. 토큰 분류 학

이것은 완전한 목록이 아니며, 나는 팀원들과 이 문제에 대해 논의하고 있으며, 우리는 곧 수정할 것이라고 믿습니다. 그러나 이것은 우리가 지금까지 본 토큰이 나타내는 모든 능력을 나열하기 위한 것입니다.

토큰은 프로토콜 내의 도구로, 그것들은 도구이자 프로토콜이며, 더 추상적으로 말하면 데이터 구조입니다. 그렇다면 우리는 이 데이터 구조가 다양한 프로토콜에서 어떻게 사용되는지를 어떻게 볼 수 있을까요? 그것들은 다섯 가지 일반적인 범주로 나눌 수 있습니다: 지불, 투표, 이해관계, 메타데이터 및 소유권 (Claiming). 시간이 지남에 따라 각 범주에 대해 더 많은 해결책이 있을 것이며, 이러한 분류는 적어도 나에게는 직관적으로 느껴집니다.

지불

지불 기능은 세 가지 범주로 나눌 수 있습니다. 첫째는 커뮤니티나 프로젝트의 내부 통화로 사용되는 것입니다. 우리는 이러한 경우를 많이 보지 못했지만 몇 가지 예가 있습니다. 예를 들어, SourceCred는 흥미로운 예이며, FWB는 이 방향으로 나아가고 있을 수 있습니다. 이는 전통적인 지불 방식인 달러 지불과는 다릅니다. 왜냐하면 그것은 특정 커뮤니티 내에 존재하며, 그 커뮤니티는 해당 통화에 대한 통제권을 가지고 있으며, 그들은 이 내부 통화에 대해 통화 정책과 같은 수단을 사용할 수 있습니다. 예를 들어, 이 통화는 안정적이어야 하며, 다른 특정 자산의 가치에 연동되어야 하며, 아마도 그들은 구체적이고 전체 커뮤니티의 목표에 따라 그것을 발행하거나 소각할 것입니다.

둘째, 가장 일반적이고 이해하기 쉬운 암호화폐 지불 방식은 네트워크 자원으로 사용되는 것입니다. 이더리움과 비트코인도 이 범주에 속합니다. 당신은 계산 능력, 저장소 또는 기타 암호화폐 네트워크 자원에 대해 지불합니다. 우리는 EIP1559, 스테이킹, 유동성 등을 통해 토큰이 시스템 내에서 다양한 자원을 계산하는 데 어떻게 사용되는지를 결정합니다. 특히 계산 자원에 대해 말입니다.

세 번째 지불 토큰은 게임 화폐와 유사한 형태로 존재합니다. 예를 들어, 게임, 자원 또는 특정 프로토콜 자원이 안정적이어야 하며, 가격이 책정되어야 합니다. 왜냐하면 당신이 시스템을 사용해야 하고, 이러한 자원이 안정적이기 때문에 토큰 가격도 상대적으로 안정적이어야 합니다. 공급이 안정적이지 않은 것은 중요하지 않습니다. 왜냐하면 당신은 그것을 특정 애플리케이션의 일부를 실현하기 위해 사용하기 때문입니다.

그렇다면 스테이블코인은 어디에 위치해야 할까요? 물론, 스테이블코인은 위의 세 가지 방식으로 지불할 수 있습니다. 그러나 스테이블코인이 스테이블코인이 되는 이유는 그 뒤에 있는 안정화 메커니즘이기 때문에, 스테이블코인은 일반적으로 소유권 범주에 속합니다.

소유권

일반적으로 두 가지 소유권이 있습니다: 체인 상(예치)과 체인 외(소유권). 예치 토큰은 다른 토큰에 대한 소유권을 나타냅니다. 예를 들어, uniswap LP 토큰은 V2에서 erc20이고, V3에서는 NFT입니다. Maker 프로토콜에서 나온 스테이블코인 Dai도 체인 상 예치입니다. 왜냐하면 당신이나 금고 소유자가 그것을 사용하여 그들의 기본 담보를 청구하기 때문입니다. 따라서 예치 토큰은 비체인 환경에서 다른 토큰을 청구하는 데 사용할 수 있는 것을 의미합니다.

두 번째 유형의 토큰은 일부 체인 외 자산의 소유권을 나타냅니다. 따라서 이것은 현실 세계의 자산 토큰, 부동산 토큰 또는 유사한 것일 수 있습니다. 우리는 아직 이러한 예를 많이 보지 못했습니다. 더 현대적인 예는 현재 소위 말하는 상환 가능한 물건으로, 토큰이 실물로 교환될 수 있습니다. 예를 들어, NFT와 예술품을 교환하는 것이며, 이 NFT는 마당에 대한 소유권을 나타냅니다. 당신이 원한다면, 심지어 흥미로운 거래도 있습니다. 당신은 실물을 사용하여 NFT를 제어할 수 있으며, 칩과 같은 디지털 기능을 통해 후속 NFT의 소유권을 제어할 수 있습니다.

투표

투표를 사용하여 프로젝트에 자금을 지원하고, 자원을 할당하며, 집단적으로 지불하거나 송금할 수 있습니다. 또한 소프트웨어 업그레이드를 수행할 수도 있습니다. 사회적 합의의 수단으로 사용될 수도 있으며, 예를 들어 리더를 선택하여 프로젝트의 미래 계획을 결정하는 것입니다.

스테이킹

토큰은 스마트 계약을 통해 보상을 받을 수 있도록 설계될 수 있습니다. 여기에는 법적 계약이 없지만, 이 메커니즘의 작동은 토큰이 어떤 체인 상 활동으로부터 혜택을 받을 것임을 의미합니다. 예를 들어, Maker는 Maker가 잘 운영되고, 많은 토큰 보유자가 그들의 일을 잘 수행하며, 시스템이 정상적으로 작동하면, 그들은 일부 보상으로부터 혜택을 받을 것입니다. 이는 스마트 계약의 방식이며, 커뮤니티의 좋은 관리를 보상하기 위한 프로토콜의 설계 방식입니다.

당신은 또한 토큰을 법적 계약의 결과로 만들어 보상을 받을 권리를 가질 수 있습니다. 당신은 회사의 주식 일부 또는 주식 지분을 나타내는 토큰을 만들 수 있으며, 물론 다양한 법적 요구 사항과 제한이 있을 것입니다. 한때 일부 사람들은 안전한 토큰을 생성할 수 있다고 이론적으로 생각했지만, 우리는 아직 실질적인 사례를 많이 보지 못했습니다.

토큰은 또한 보상을 위해 위험을 보장하는 데 사용됩니다. Maker는 이 원리를 사용합니다. 만약 Maker 프로토콜에서 손실이 발생하면, 더 많은 Maker 토큰이 생성되어 Maker 보유자가 보유한 가치가 희석됩니다. Maker 토큰을 보유함으로써 보유자는 일부 위험을 감수하게 되며, 이는 Maker 보유자가 커뮤니티 구축을 추진하는 부분적인 이유입니다. 그들이 자신의 투자가 증가하기를 원한다면, 그들은 이 시스템의 발전을 지원해야 합니다.

메타데이터

첫째, 토큰은 멤버십을 나타냅니다. 특정 공간에 접근할 수 있는지, 특정 커뮤니티에 속해 있는지, 또는 어떤 그룹에 속해 있는지를 결정합니다. 프로토콜이나 제3자가 작성한 도구는 이 멤버십 속성을 다양한 방식으로 활용할 수 있으며, 이는 비허가적입니다. 예를 들어, 일부 NFT 커뮤니티는 토큰을 보유한 사람만 가입할 수 있도록 결정할 수 있으며, 이는 토큰을 보유한 사람에게 특정 기능을 제공하는 등의 방식입니다. 멤버십은 토큰이 제공하는 흥미로운 메타데이터 유형입니다.

토큰은 또한 신뢰를 나타냅니다. 일부 사람들은 신뢰가 양도 가능해야 하는지에 대해 논의하고 있으며, 개인적으로는 그렇지 않아야 한다고 생각합니다. 그러나 특정 상황에서는 동질적일 수 있으며, 다른 경우에는 비동질적일 수 있습니다. 당신의 성취를 지칭한다면, 그것은 비동질적일 수 있습니다. 정보 출처, 신용 또는 다양한 유형의 신용 점수 시스템을 지칭한다면, 그것은 동질적일 수 있습니다. 이는 연속적인 데이터이므로 메타데이터의 한 형태입니다.

토큰은 또한 신원 또는 참조를 나타냅니다. ENS는 이와 관련된 예입니다. ENS 이름은 주소를 가리킬 수 있으며, 업데이트할 수 있습니다. 이는 DNS 시스템과 다릅니다.

체인 외 데이터는 메타데이터의 한 형태가 될 수 있습니다. 예를 들어, 체인 외 KYC 또는 어떤 검증 가능한 증명서가 있습니다. 또 다른 좋은 예는 졸업장이나 학위입니다. 누군가가 이 증명서를 당신에게 주면, 그것은 공개적으로 보이고 추적 가능하며 진정성이 있습니다. 우리는 아직 권한과 능력을 체인 상에서 나타내는 많은 사례를 보지 못했습니다. 예를 들어, 어떤 실체가 당신에게 권한을 명확히 부여하는 경우, 함수 호출, 코드 변경 능력 또는 체인 상에서 어떤 것을 이전할 수 있는 능력 등이 있습니다. 심지어 토큰을 인터페이스로 사용할 수 있으며, 우리는 이미 이러한 예를 보았습니다. 토큰 URI에 SVG 데이터뿐만 아니라 전체 HTML 웹페이지를 포함할 수 있으며, 심지어 약간의 JavaScript를 포함할 수도 있습니다. 당신은 NFT에 인터페이스를 배치하고, 그 인터페이스를 제어할 수 있으며, 사람들이 소유하고 양도하는 객체에 인터페이스를 삽입할 수 있습니다.

흥미로운 예는 BEEP3R입니다. 당신은 먼저 텍스트로 NFT를 발행한 다음, 그것을 소유함으로써 다른 BEEP3R 보유자에게 텍스트를 방송할 수 있습니다. 이 텍스트는 BEEP3R의 작은 이미지에 표시됩니다. 당신이 BEEP3R 기계를 가지고 있다면, 다른 BEEP3R 기계 보유자에게 직접 메시지를 보낼 수도 있습니다. 마치 xmtb를 단독으로 사용하는 것처럼요.

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

이것은 또한 신원 토큰입니다. 왜냐하면 BP 보유자로서 당신은 정보를 수신하고 전송할 수 있기 때문입니다. 따라서 이 일은 그 집합 내에서만 발생합니다. 이것은 또한 신원 토큰입니다. 왜냐하면 그들은 당신의 BP 토큰 ID를 사용하여 당신에게 메시지를 보내기 때문입니다. 동시에 이것은 인터페이스로 존재하며, 해당 NFT와 관련된 정보를 볼 수 있습니다.

3. 기술 트리 이론

우리는 일부 분야가 현재 크게 발전하고 있음을 볼 수 있습니다. 예를 들어, 토큰이 지불 수단 및 네트워크 자원으로 사용되고 있지만, 일부 분야는 아직 성숙한 발전이 없습니다. 예를 들어, 인터페이스, 메타데이터 등이 그렇습니다. 그렇다면 왜 이런 현상이 발생할까요? 나는 완전한 답을 가지고 있지 않지만, 이것이 기술 트리와 관련이 있을 수 있다고 생각합니다. 물론 이 기술 트리는 아직 완성되지 않았습니다.

내 질문은, 왜 어떤 제품이 특정 시점에 등장하는지, 왜 어떤 제품이 다른 제품보다 더 오랜 시간 동안 등장하는지입니다. 예를 들어, 대출 프로토콜을 생각해보면, 스테이블코인이 없다면 대출 프로토콜이 작동하기 어려울 것입니다. 이는 대출 프로토콜에서 부채를 빌릴 때, 안정적인 자산으로 그것을 나타내고 싶기 때문입니다. 왜냐하면 이 자산의 가격을 예측할 수 있기 때문에 우리는 스테이블코인이 필요하며, 그래야만 진정한 대출 프로토콜이 존재할 수 있습니다.

마찬가지로, 우리는 AMM이 필요한 대출 프로토콜도 있습니다. 왜냐하면 대출 프로토콜을 사용하여 레버리지를 사용하고 싶다면, 특히 초기의 간단한 대출 프로토콜에서는 자산을 빌릴 수 있어야 하기 때문입니다. 예를 들어, 스테이블코인을 빌릴 수 있어야 합니다. 만약 당신이 그 스테이블코인을 사용하여 자산을 신속하게 교환하고 싶다면, 더 많은 위험 노출을 원한다면 AMM이 필요합니다. 정상적으로 작동하는 AMM과 스테이블코인이 있어야만 대출 프로토콜의 발전이 이루어질 수 있습니다.

그렇다면 정상적으로 작동하는 AMM과 스테이블코인을 어떻게 얻을 수 있을까요? 상호 운용 가능한 토큰 표준이 없다면, 이를 달성하기 어려울 것입니다. 왜냐하면 스테이블코인, AMM 및 그 주변의 모든 시스템은 다른 프로젝트가 그것들과 어떻게 연결되는지를 이해해야 하기 때문입니다. ERC20 토큰이 존재하려면 완전히 프로그래밍 가능한 스마트 계약이 필요합니다. 당신은 실제로 그것들을 필요로 하지 않을 수도 있지만, 이것이 이더리움에서 처음 등장한 방식입니다. 왜냐하면 이더리움은 ERC20 토큰 표준 없이 출시되었기 때문입니다. 우리는 충분히 개방된 디자인 공간을 남기기 위해 완전히 프로그래밍 가능성이 필요합니다. 물론 이 점은 더 논의될 수 있습니다. 그러나 요컨대, 나는 기술 트리가 존재하며, 특정 기술이 다른 기술의 전제 조건이 된다고 생각합니다.

여기 두 가지 질문이 있습니다: 미래의 응용 프로그램과 프로토콜을 여는 핵심 기술은 무엇인가? 즉, 유용한 신뢰 시스템이나 탈중앙화되고 신뢰 없는 인터페이스를 개발하기 위해 어떤 기술이 필요한가? 두 번째 질문은 첫 번째 질문과 반대입니다. 어떤 응용 프로그램과 프로토콜이 다가오는 기술에 의해 열릴 것인가?

예를 들어, 계정 추상화, EIP4844, 수직 트리, 제로 지식 기계 학습 등이 있습니다. 이러한 질문이 흥미로운 이유는 우리가 특정 기술의 도래를 예측할 수 있다면, 그 기술이 디자인 제한을 완화하거나 도입할 수 있다면, 이것이 우리의 디자인에 어떤 변화를 가져올 것인가? 특정 기술이 제한을 완화할 수 있다면, 우리는 그것들을 개발하는 데 에너지를 쏟아야 할까요?

사물을 기술 트리로 본다면, 이는 우리가 원하는 제한을 달성하기 위해 다가오는 것 또는 필요한 것을 추론하는 데 도움이 될 수 있습니다. 따라서 이것을 내가 처음 언급한 제한 점과 연결하면, 나는 새로운 기술이 우리가 이전에 직면했던 제한을 완화한다고 생각합니다. 예를 들어, 만약 ERC20 표준이 없다면, 어떤 AMM이나 스테이블코인 디자인의 제한은 그것이 표준을 도입해야 하거나 다양한 디자인에 대응할 수 있어야 한다는 것입니다.

일반적인 AMM을 설계한다고 상상해보세요. 그러나 특정 토큰 표준을 사용하지 않는다면, 이는 매우 매우 어려울 것입니다. 나는 이것이 거의 넘을 수 없는 제한이 될 것이라고 생각합니다. 그러나 상호 운용성 표준이 있다는 것은 우리가 ERC20 토큰을 직접 지원할 수 있다는 것을 의미하며, 이는 디자인 공간을 제한하고 실현 가능하게 만듭니다.

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