원제: "A&T View: 전체 네트워크에서 DID 트랙에 대한 가장 자세한 리뷰 + DID 영혼에 대한 세 가지 질문"

저자: Lin Chuan, A&T Capital 수석 애널리스트

요약

요약

• DID는 이제 일반적으로 "Decentralized Identity"(Decentralized Identity)의 약자입니다. 중앙 집중식 조직의 최종 보증이 없는 디지털 ID입니다. Web3에서 Web2의 "사용자 초상화" 개념의 확장 및 확장입니다.

• DID 관련 트랙은 주로 애플리케이션 시나리오, ID 및 자격 증명의 세 가지 레이어로 나뉩니다. 자격 증명 계층은 DID의 구성 요소이고 ID 계층은 DID의 특정 형식이며 애플리케이션 시나리오 계층은 DID의 가치 구체화입니다.

• DID 개발의 최종 형태는 각 사용자가 여러 세분화된 시나리오에서 고유한 네트워크 전체 ID 및 부분 ID를 갖는 것일 수 있습니다. 사용자는 도메인 이름을 통해 DID를 기억 및 식별하고, 지갑을 통해 DID를 관리하고 애플리케이션 프로젝트와 상호 작용하고, 지갑 통합에서 다양한 프로토콜을 통해 여러 체인에서 다양한 자격 증명 및 부분 ID를 통합합니다.

• DID는 현재 사용자의 직접적인 요구가 아니라 애플리케이션 시나리오 프로젝트 당사자의 요구가 더 많습니다.

• DID의 개발은 아직 초기 단계에 있으며 반복이 상대적으로 느리다.지금까지 어떤 DID 시스템도 일정한 네트워크 효과를 축적하지 못했는데, 이는 주로 현재 Web3 비금융 애플리케이션 프로젝트 개발의 어려움 때문이다.

• DID 1단계 투자의 전반적인 논리: 사용자부터 시작하여 애플리케이션이 계약보다 우선합니다.

서문: 널리 사용되고 심지어 남용되는 개념인 DID

DID는 Web3 분야에서 널리 사용되는 개념입니다. Twitter에는 거의 매주 DID에 대해 논의하는 Twitter Space가 있습니다; 다양한 오프라인 Web3 공유 세션에서 DID는 지속적인 핫 토픽 중 하나입니다. 기타 애플리케이션 프로젝트 또는 지갑, 도메인 이름, 퍼블릭 체인과 같은 인프라/미들웨어 프로젝트는 DID를 이야기에 추가할 수 있습니다.

그러나 이러한 높은 인기는 필연적으로 DID라는 용어를 널리 사용하고 심지어 남용하게 만듭니다.

• 처음에 DID의 전체 이름은 "Decentralized Identifiers"였으며 문자 그대로 "Decentralized Identifiers"로 번역되었습니다. Web2 중앙 집중식 ID 시스템에 대한 우려에서 가장 영향력 있는 국제 인터넷 기술 표준 기구인 W3C(World Wide Web Consortium)가 주도하는 일련의 표준입니다. DID의 개념은 처음에는 블록체인/Web3와 직접적인 관련이 없었지만 "DID"를 직접 검색하면 여전히 많은 기사에서 논의되는 DID가 이 특정 표준임을 알 수 있습니다.

• 현재 Web3 통신에서 DID는 "Decentralized Identity"의 약자로 간주되는 경우가 더 많습니다. 그러나 탈중앙화 아이덴티티 자체도 명확한 정의가 없는 어휘입니다.누구나 언뜻 그 일반적인 의미를 이해할 수 있지만, 다른 시나리오에서는 다른 것을 지칭할 수 있으며, Web3의 세계에서는 Anything이 관련될 수 있는 것 같습니다. 그것에. 이것이 현재 DID에 대한 논의에서 많은 개념적 혼란이 있는 이유입니다.

이 기사에서 다음에 논의되는 DID는 "분산형 디지털 신원"이라는 후자의 개념을 채택할 것이며 혼란을 피하기 위해 DID를 사용하여 W3C의 분산형 식별자 표준을 참조할 것입니다.

이 기사는 첫 번째 부분과 다음 부분으로 나뉩니다. 1부에서는 응용 시나리오 계층, ID 계층, 데이터 계층으로 나누어 DID 트랙을 체계적으로 검토하여 독자들이 다양한 개념 간의 차이점과 연관성을 이해할 수 있도록 돕고, 2부에서는 저자가 독자가 생각하고 소통할 수 있도록 벽돌을 던지기 위해 DID 트랙의 향후 개발 및 초기 투자에 대한 주관적인 견해를 설명하십시오.

이전: DID(Decentralized Identity) 트랙의 파노라마 해석

Web2에서 디지털 아이덴티티는 플랫폼을 중심으로 하고 같은 그룹의 다른 제품은 계정 시스템을 통해 연결됩니다. 예를 들어, Tencent의 우편함, 게임, 금융 등은 모두 동일한 계정을 사용할 수 있으며 Google, Facebook 및 기타 주요 인터넷 기업도 자체 계정 시스템을 보유하고 있습니다. 이 ID 시스템은 구성하기 편리하지만 단점은 잘 알려져 있습니다. 플랫폼 간의 계정이 상호 운용되지 않고 사용자가 자신의 ID 데이터를 제어할 방법이 없습니다.

현재 Web3에서 사용자 상호 작용은 주로 지갑 주소를 기반으로 하므로 주소를 중심으로 일련의 활동이 Web3의 가장 독창적인 디지털 ID를 구성합니다. 그러나 새 주소를 만드는 데 드는 비용은 거의 무시할 정도이며 주소에 자신을 묶는 사람은 거의 없습니다. 이로 인해 사용자는 언제든지 주소가 나타내는 "신원"을 포기할 수 있고 비용 없이 많은 수의 주소 "신원"을 생성할 수 있으므로 이 디지털 신원의 응용 시나리오가 제한됩니다. .

DID가 해결하고자 하는 문제는 분산된 디지털 세계에서 개인의 신원을 묘사하는 것입니다.

1. DID의 적용 시나리오: 이미 성숙한 DID 세트가 있다면...

DID는 추상적인 개념입니다.직관적으로 더 잘 이해하기 위해 애플리케이션 시나리오부터 시작하여 DID가 구현되는 방법에 대한 세부 정보를 보호하겠습니다. 합니까?

저자는 애플리케이션 시나리오 계층에서 DID의 내러티브를 평판(reputation)과 관계(relationship)의 두 가지 범주로 크게 나눈다.

그것들을 구별하는 주된 방법은 당신이 기존의 "디지털 아이덴티티"를 포기한다면 상대적으로 짧은 기간에 당신을 대표할 수 있는 새로운 아이덴티티를 재건할 수 있다고 가정하는 것입니다.

전자라면 Reputation 클래스이고 후자라면 Relationship 클래스입니다.

1.1 평판: 평판/이력서/사회적 존재감

이러한 유형의 애플리케이션 시나리오는 신속한 선별 효과를 달성하기 위해 디지털 ID를 명시적이고 신뢰할 수 있는 레이블로 단순화하여 사용자를 평가하고 분류하는 데 중점을 둡니다. 다음은 세 가지 구체적인 예입니다. 신용 대출, 구직, 낯선 사람과 사귀기:

• Web3 신용 대출, 신용 대출에서 감면 또는 면제될 수 있는 금액을 계산하기 위해 사용자의 계정 주소에 "신용 점수"를 부여하기를 희망합니다. 이러한 종류의 신용 점수는 오프체인 신원/자산 증명을 통해 달성하거나 사용자 온체인 주소의 과거 작업 기록 분석과 결합할 수 있습니다.

• Web3 구직 및 채용의 경우 사용자의 이력서가 체인에서 생성되어 사용자가 Web3 프로젝트 파티/DAO/커뮤니티 등에 신속하게 자신의 능력을 증명하고 Web3 작업에서 정보 마찰을 줄일 수 있기를 바랍니다. 사냥과 모집 과정. 이력서의 업무 경험, Web3 능력 및 기타 인증은 체인에 대한 주소 분석, 이전 소유자의 다중 서명 지갑 주소 서명 및 Web2 회사 이메일 인증을 통해 완료할 수 있습니다.

• Web3 Stranger Social(이성애 소셜, 관심사 소셜 등 포함), 사용자를 위한 태그 설명을 신속하게 구축하기를 바랍니다. 이러한 종류의 라벨에 대한 설명은 NFT 보유 여부에 따라 달라질 수 있습니다. 사용자는 이러한 태그를 통합하고 표시하기 위해 소셜 홈페이지에 표시할 수 있으며, 사용자는 이러한 태그를 기반으로 소셜화하려는 개체를 빠르게 필터링하고 자신의 관심사와 선호도를 미리 이해할 수 있습니다.

1.2 관계: DID의 관계형 애플리케이션 시나리오 내러티브

이러한 유형의 애플리케이션 시나리오는 디지털 ID를 Web3에서 축적된 사용자 데이터로 취급하여 좀 더 복잡하고 포괄적인 애플리케이션 분석을 수행하는 데 중점을 둡니다. 다음은 4가지 구체적인 관련 예입니다.

• Web3 추천 시스템은 사용자의 Web3 관련 데이터의 축적을 통해 사용자 초상화를 형성한 다음 맞춤형 개인화 추천 및 광고 표시를 수행하기를 희망합니다. 이 사용자 초상화 세트의 내러티브는 실제로 모바일 인터넷 시대의 플랫폼 제조업체의 핵심 논리에서 상속되었으며 실현 가능성이 입증되었습니다. 그리고 Web3에서는 신원 데이터가 플랫폼 간에 상호 운용될 수 있을 뿐만 아니라 사용자가 자신의 신원 데이터에 대한 소유권 및 공개 공유 권한을 가질 수 있으므로 이러한 방식으로 구축된 사용자 초상화 시스템은 Web2보다 사용자 친화적일 수 있습니다.

• Web3 지인 소셜 인터랙션, Web3에서 사용자의 소셜 인터랙션의 축적을 통해 일련의 사용자 소셜 그래프를 형성하고 다양한 새로운 앱에서 사용할 수 있기를 바랍니다. 이와 같이 사용자가 새로운 애플리케이션을 사용하거나 새로운 게임에 들어갈 때 Web2처럼 다시 추가할 필요 없이 지인, 친구를 빠르게 찾을 수 있습니다.

• Web3 게임의 경우 Web3 게임에서 사용자 데이터의 축적을 통해 게임에 대한 사용자의 관심과 능력을 설명하는 게임 계정 시스템(GameID)을 구축할 수 있기를 기대합니다. 예를 들어, 사용자 A는 특정 Web3 카드 게임에 대한 초기 참여 기록을 가지고 있을 수 있으며 GameID에 기록될 수 있으므로 새로운 카드 게임이 초기 사용자를 찾고자 하는 경우 A에게 우선 순위를 부여할 수 있습니다.

• DAO 투표 거버넌스는 때때로 "1인 1표"의 공정한 투표를 실시하기를 희망합니다. 하지만 스와이프 투표(Sybil attack)를 위해 여러 계정을 등록하는 대신 한 사람이 한 번만 투표한다는 것을 어떻게 증명할 것인지는 어려운 문제입니다. 이 문제는 사용자의 주소 기록 분석이나 실명 인증을 통해 해결할 수 있습니다.

1.3 두 가지 유형의 애플리케이션 시나리오 간의 연결: 점에서 표면으로, 표면에서 점으로

사실 Reputation과 Relationship 애플리케이션 간의 관계는 그렇게 명확하지 않고 네트워크와 같은 관계에 가깝습니다.

보다 정확하게는 다양한 명시적이고 신뢰할 수 있는 태그는 "포인트"와 같습니다. 시간이 지남에 따라 이러한 포인트는 동일한 정체성 주위에 축적되어 최종적으로 사용자의 초상화에 대한 완전한 "얼굴"을 생성합니다. 사용자 또는 프로젝트 당사자가 정말로 사용하고 싶을 때 이 "얼굴"을 설명하고 이해하기 쉬운 몇 가지 "점"으로 단순화하려면 추가 처리가 필요합니다.

예를 들어 NFT 보유량의 경우 초기에는 BAYC 보유자, Azuki 보유자 등만 사용자에게 태그(포인트)를 부여할 수 있지만 시간이 지나면서 인기 있는 종목이 있을 때마다 NFT가 나타날 때 , 이 사용자는 거래(얼굴)에 참여하고 귀납적 분석을 수행하고 그를 "인기 NFT 거래자"(포인트)로 표시할 수 있습니다.

위의 내용은 기본적으로 애플리케이션 시나리오 수준의 모든 DID 내러티브를 요약한 것입니다. 기본적으로 Web3 애플리케이션 계층의 거의 모든 내러티브를 다루고 있음을 알 수 있으며, 이것이 DID가 Web3 애플리케이션의 "ID 인프라"라고도 불리는 이유입니다.

2. 원본 데이터 형식 및 자격 증명: DID를 구성하는 속성은 어디에서 오는가?

독자들은 위에서 언급한 다양한 응용 시나리오의 내러티브에서 각 디지털 ID가 실제로 다른 것을 지칭하지만 모두 "DID"라고 부를 수 있다고 느꼈을 수 있습니다. 여기에는 실제로 두 가지 주요 문제가 있습니다.

• 이 "분산형 ID"는 어떤 특정 레이블/속성/자격 증명으로 구성되어 있습니까? 예를 들어 연결하려는 것은 사용자의 NFT 보유, 온체인 상호 작용 기록, 사용자의 사회적 관계 또는 사용자의 오프체인 신원 정보입니까?

• 이 "분산형 ID", 어떤 식별자(식별자, ID)가 집계되는지 또는 외부 상호 작용을 위한 기본 인터페이스는 무엇입니까? 예를 들어 ID를 나타내기 위해 NFT, 주소 또는 도메인 이름을 사용합니까, 응용 프로그램 측과 상호 작용하기 위해 ID를 어떻게 사용합니까?

이 두 가지 문제를 명확히 하고 나면 ID 계층에서 DID의 다양하고 복잡한 프로젝트를 명확하게 볼 수 있습니다.

DID를 구성하는 속성이 정확히 어디에서 오는지 첫 번째 질문을 살펴보겠습니다.

2.1 자격 증명: 탈중앙화 ID에 왜 중요한가요?

먼저 다음 예를 살펴보겠습니다. 새로운 사람을 만났는데 그가 말합니다. 그는 당신에게 무언가를 원하지만, 당신은 왠지 그의 자기 소개에 대해 큰 불신을 가지고 있습니다. 그러면 그가 말한 것이 진실임을 어떻게 증명해야 합니까?

이름과 나이를 증명하고 싶다면 신분증을 보여주면 되고, 경찰서에 함께 가서 신분증이 자신의 것임을 증명할 수도 있고, 학력을 증명하고 싶다면 신분증 졸업 증명서 또는 Xuexin.com에서 보낸 증명서; 그가 아버지를 잘 알고 있음을 증명하고 싶다면 아버지에게 연락하여 설명을 할 수 있습니다. 반대로, 그가 당신에게 요구하고 자신의 신원을 증명하기를 원하지만 당신이 그에게 요구할 때 위에서 언급한 구체적인 증거를 제공하지 않는다면 당신은 그의 진술의 진위를 의심할 충분한 이유가 있습니다.

따라서 우리는 방금 장산이 자신에게 한 진술에서 정체성이 이름, 출생연도, 학력, 사회계 및 기타 속성과 같은 많은 속성으로 구성되어 있음을 알 수 있습니다. 그러나 해당하는 특정 자격 증명이 없으면 이러한 속성은 신뢰성이 없으며 대부분의 애플리케이션 시나리오는 신뢰성이 없는 디지털 ID를 채택하지 않습니다. Web3에서는 신원의 속성 출처가 다양하고 잠재적인 사용자가 더 많기 때문에 중앙 집중식 보증인을 찾기가 어렵기 때문에 각 속성에 대한 자격 증명 검증이 더욱 두드러집니다.

2.2 바우처 원본 데이터 소스의 분류

따라서 DID의 특정 구성을 연구할 때 실제로는 특정 자격 증명에 중점을 둡니다.

사용자의 온체인 데이터는 기본 블록체인의 변조 불가능한 특성으로 인해 가장 자연스럽고 직관적인 자격 증명 데이터 소스입니다. 이러한 종류의 신뢰도 특정 인증서 발급자가 필요 없이 기본 퍼블릭 체인에만 기반을 둘 수 있습니다. 예를 들어 지갑 주소 A가 실제로 지갑 주소 B로 돈을 이체했음을 증명하려면 해당 정보를 체인에서 확인하기만 하면 됩니다. 인증서 발급자가 없는 이러한 종류의 신뢰는 다른 인증서 데이터 소스에서는 사용할 수 없으며 블록체인의 핵심 매력 중 하나이기도 합니다. 체인의 데이터를 통합 분석하는 Web3 도구 제품이 꽤 많이 있습니다.

그러나 현재 Web3 세계에서 온체인 데이터는 주로 전송, DeFi 상호 작용 및 NFT 거래/보유로 구성되며 가져올 수 있는 신원 정보는 제한적입니다. 그러나 현실 세계에서 많은 경우 인증서를 신뢰하기 위한 전제 조건은 인증서 발급자를 신뢰하는 것이지만 이러한 신뢰 관계의 설정은 Web2 또는 현실 세계에 있습니다. 많은 경우에 운전 면허증과 같은 전체 검증 프로세스를 체인에 두는 것은 어렵습니다. 테스트 자체는 여전히 실제 세계에서 이루어집니다.

현재 Web2 및 실제 데이터와 신뢰 관계를 신뢰할 수 있는 자격 증명으로 만드는 세 가지 주요 형태인 SBT, VC 및 PoP가 있습니다.

2.2.1 소울 바운드 토큰(SBT)

SBT(Soul Bound Token) 또는 Soul Bound Token은 2022년 5월 Vitalik 등이 발행한 "탈중앙화 사회" 기사에서 자세히 설명된 새로운 개념입니다.

SBT는 현재 공통된 명확한 기준이 없기 때문에 사실 현재 SBT는 단순히 양도할 수 없는 토큰, 즉 "양도할 수 없는 토큰"으로 이해될 수 있습니다. 실제로 POAP, Project Galaxy에서 발행한 것과 같은 토큰 형태의 자격 증명이 이미 존재합니다.

SBT의 구현은 가장 단순하며 자연스럽게 상호 운용성과 개방성이 매우 우수합니다. 그리고 SBT는 체인에 고유하기 때문에 온체인 신용 점수와 같은 온체인 데이터 분석 방법에 대한 "결과 인증서"로도 사용할 수 있습니다.

SBT의 주요 문제는 개방성으로 인해 발생하는 사용자 개인 정보 관련 문제입니다. SBT의 공개적 특성으로 인해 누구나 쉽게 사람에 대해 연상하고 추론할 수 있으며 사생활 보호를 불가능하게 하고 일부 형태의 차별을 조장할 수 있습니다. 예를 들어, 구직자의 지갑을 들여다보면 Black Lives Matter 이벤트가 드러난다는 이유로 인종 차별적 고용주가 잠재적인 직원을 차별할 수 있습니다.

이론적으로 ZK 기술과 SBT의 결합을 통해 사용자 개인 정보 보호를 실현할 수 있습니다. 그러나 이것은 특정 기술 구현에 약간의 어려움을 수반할 뿐만 아니라 SBT의 개방성과 상호 운용성에 영향을 미칠 수 있습니다.

2.2.2 검증 가능한 인증서(VC)

검증 가능한 자격 증명, 문자 그대로 번역하면 "검증 가능한 인증서"입니다.

이 글의 서두에서 언급했듯이 블록체인이 없던 시절 디지털 세상에서 분권화된 아이덴티티에 대해 생각하기 시작한 사람들도 있고, VC도 W3C가 제안한 개념이자 표준 시스템의 일부이다.

다음과 같은 국제운전면허증의 예를 통해 VC를 직관적으로 이해해 보자.

• 독일인 Hans가 운전면허증을 취득하면 독일 정부에 DID(분산식 식별자)로 VC를 발급하고 서명하도록 신청할 수 있습니다. 이 VC는 Hans가 운전면허증을 취득할 수 있는 증명서인 디지털 문서의 형태로 존재하며 Hans 자신이 보관하고 있습니다.

• Hans가 호주에 가서 자율주행 투어를 시작하면 운전면허증을 제시해야 할 때 독일 관리로부터 받은 VC를 호주 정부에 보여줄 수 있습니다. 위의 정보를 바탕으로 Hans는 운전 능력이 있다고 생각할 수 있습니다.

엄밀히 말하면 VC의 특정 작성에는 W3C에서 정의한 표준 세트가 있으며 그 안에 있는 분산 식별자도 W3C 시스템의 DID입니다. 그러나 Web3의 관점에서 볼 때 이 분산 식별자를 넓은 의미의 지갑 주소로 대체하는 것이 논리적으로 가능합니다.다음 그림은 사용자, VC 발행자 및 VC 검증자 간의 관계를 보여줍니다.

SBT와 비교할 때 VC의 주요 장점은 사용자 개인 정보 보호에 있으며 사용자는 자연스럽게 자신의 정보를 선택적으로 공개할 수 있습니다. 또한 그 구현은 블록체인 기술과 관련이 없을 수 있습니다. 즉, Web2와도 잘 호환됩니다.

VC의 주요 문제는 비교적 인정받는 표준 세트가 있지만 이 표준 세트는 DID의 지원이 필요하고(자세한 내용은 아래 참조) DID의 발전이 상대적으로 느리다는 것입니다. 프로젝트 당사자나 Web3 커뮤니티가 VC 운영 프로세스 표준을 설정하려는 경우 이 표준을 홍보하는 방법도 어려운 지점이 될 것입니다.

2.2.3 성격 증명(PoP)

개인 증명, 가장 중요한 것은 실제 사람의 정보를 체인 아래에 묶어 디지털 신원의 고유성을 증명하는 것입니다. Proof of Humanity, BrightID, IDENA가 대표적인 프로젝트입니다.

구체적인 실현은 주로 KYC와 비디오 얼굴 인식의 두 가지 기술을 통해 이루어집니다. KYC는 거래소에서 널리 사용되는 고전적인 인증 방법입니다.KYC를 통해 디지털 신원은 체인에서 귀하의 법인 정보(이름, 국적 등)에 연결되며 BrightID와 같은 얼굴 인식은 주로 귀하의 얼굴 정보를 사용합니다. 한 사람이 프로젝트 ID 시스템에 하나의 ID만 등록할 수 있도록 데이터베이스.

PoP 인증의 가장 직접적인 적용 시나리오는 Anti-Sybil 공격임을 알 수 있습니다. 또한, 모든 국가가 암호화폐 규제를 고려하고 있는 배경에서 KYC는 "법적 신원" 확립을 위한 필수 조건이 될 수 있습니다.

2.3 바우처 관련 항목

분산형 디지털 ID의 구체적인 구성은 매우 복잡할 수 있지만 최종 분석에서는 주로 체인의 원본 데이터, SBT, VC 및 PoP의 네 가지 유형의 자격 증명으로 구성됨을 알 수 있습니다.

엄밀히 말하면 SBT도 체인에 있는 원본 데이터의 일부이지만 SBT는 어떤 방식으로든 재처리되어야 하며 그 신뢰는 발행자에 따라 달라질 수 있습니다. 퍼블릭 체인 트러스트.

자격 증명과 관련된 특정 유형의 Web3 프로젝트는 무엇입니까?

대부분의 경우, 많은 인증서의 인증 규칙은 사용자가 체인에서 거래를 완료했는지 여부를 확인하거나 사용자가 프로젝트 당사자의 Twitter 전달을 도왔는지 확인하거나 사용자 뒤에 있는 실제 사람이 다음과 같은지 여부를 확인하는 등 상호 운용성이 높습니다. 먼저 자격 증명을 얻으려고 시도합니다. 이러한 맥락에서 인증서 발급자는 인증서 발급을 위한 일련의 도구를 만들 필요가 없습니다.

따라서 이 부문의 많은 프로젝트 유형은 실제로 인증서 발급을 위한 도구/플랫폼입니다. Project Galaxy를 예로 들면 프로젝트 당사자는 Project Galaxy에 작업을 게시할 수 있으며 사용자는 플랫폼에서 작업을 완료하고 인증을 수행한 후 프로젝트 당사자가 발급한 자격 증명을 얻을 수 있습니다.

그러나 일부 복잡한 상황에서 인증서 발급자는 사용자를 인증하기 위한 자체 규칙을 설계하려고 합니다. 특히 평가가 특정 수준에 따라 달라지는 일부 복잡한 시나리오에서는 더욱 그렇습니다. 앞서 언급한 인적증명서도 증명서 발급사업으로 분류할 수 있다.

다른 예는 다음과 같습니다.

• 래빗홀은 "학습 인증" 프로젝트의 대표주자로, 사용자가 보다 복잡한 작업을 완료해야 하는 다양한 Web3 타이틀(예: NFT Creator, Explorer 등)의 인증을 제공합니다. 과정 수료 시점은 매우 유사하며, Rabbithole은 "Web3 온라인 교육"의 원형이라고도 할 수 있습니다.

• ARCx는 각 DeFi Passport 보유자의 신용 점수를 기반으로 온체인 주소의 신용도를 정량화하기를 희망합니다. 신용 점수는 보유자의 이더리움 주소의 과거 활동을 분석하여 결정되며 범위는 0~999점으로 설정되며 신용 점수는 프로토콜이 사용자에게 제공하는 모기지 금리를 결정합니다. 신용 점수가 높은 주소의 경우 DeFi Passport는 경쟁력 있는 대출 담보를 제공할 수 있습니다.

• FirstBatch는 AI를 사용하여 Web2 소셜 미디어에서 사용자 인증 데이터를 읽어 체인에서 사용자 관심 태그를 생성하고 개인 정보 보호를 위해 ZK 기술을 사용하기를 희망합니다.

3. ID 계층: 애플리케이션 시나리오와 자격 증명의 연결, 특정 DID 형식

우리는 DID의 특정 애플리케이션 시나리오에 대해 논의했으며 DID ID 자격 증명의 특정 구성에 대해서도 논의했습니다. 사용 사례와 자격 증명을 연결하는 것은 ID 계층 프로젝트가 수행하는 작업입니다. 예를 들어 도메인 이름, 지갑, 소셜 그래프, 주소 연결 분석...

프로젝트가 ID 집계를 수행하는지 여부를 구별하는 방법은 무엇입니까? 여기서 저자는 판단 방법을 제안한다: 프로젝트(또는 프로젝트 모듈)가 특정 사용자 중심 시나리오에서 DID를 사용하지 않거나 사용자에 대한 새로운 자격 증명을 생성하지 않는 작업을 수행하는 경우 가장 중요한 것은 다양한 "바인딩"인 경우 fixed” 및 “connected”이면 ID 집계 계층의 항목이 될 가능성이 높습니다.

그러나 Web3 ID 집계를 수행하는 방법, 프로젝트 유형에 따라 다른 경로와 사고 방식이 제공됩니다. 크게 두 가지 범주로 나눌 수 있습니다. 원시 데이터 및 다양한 자격 증명을 체인에서 처리 및 집계하는 것과 사용자가 데이터 주권을 달성하는 데 도움이 되는 사용자 중심의 ID 관리 도구입니다.

3.1 정보 집계 프로토콜

체인에 있는 사용자의 데이터는 종종 여러 퍼블릭 체인과 여러 프로젝트 스마트 계약에 분산되어 있으므로 ID를 형성하기 위해 처리하고 집계해야 합니다. 많은 프로젝트가 이러한 정보 집계 프로토콜을 수행하고 있습니다.

이러한 계약은 종종 사용자를 직접 지향하는 제품이 없으며 주로 프로젝트 당사자 및 기타 계약을 지향하며 정보 집계에서 서로 협력할 수 있습니다. 예는 다음과 같습니다.

• Cyberconnect는 사용자의 소셜 관계 데이터를 집계하여 온체인 소셜 그래프를 구축하기를 희망합니다.

• KNN3 Network는 Footprints 연관 분석, Cyberconnect 및 기타 소셜 그래프의 통합을 통해 여러 체인에서 사용자 소셜 관계 그래프를 구축하기를 희망합니다.

• RSS3는 체인 상의 콘텐츠와 소셜 정보의 집합체가 되기를 희망하며 Web3 정보 유통 및 추천 시스템 방향으로 발전할 수 있습니다.

다음 유형의 ID 관리 도구 프로젝트는 모두 사용자에게 데이터 주권을 달성하기 위한 직접적인 도구인 능동적 ID 관리 기능을 사용자에게 제공하기를 희망합니다.

3.2 ID 관리 도구 - 지갑

지갑은 사용자를 직접 지향하며 현재 "Web3 입구"로 인식됩니다. 그 자체로 DID 적용 시나리오라고 할 수는 없지만, 적용 시나리오와 사용자 자격 증명을 연결하는 자연스러운 채널입니다.

이상적인 "DID 지갑"은 다음과 같을 수 있습니다: 첫째, 기본 서명, 전송 및 기타 트랜잭션을 보유하면서 모든 주류 퍼블릭 체인의 주소를 집계하고 사용자의 조각난 데이터를 다른 체인에 통합할 수 있습니다. 사용자가 소유한 SBT/VC/PoP 자격 증명 애플리케이션 프로젝트와 상호 작용할 때 사용자는 프로젝트에 공개할 데이터를 독립적으로 승인하여 사용자가 데이터 주권을 실현하도록 돕습니다. Unipass, ABT Wallet, Selfkey 등과 같은 많은 지갑에서 DID의 내러티브를 언급할 것입니다.

그러나 Metamask와 같은 현재 주류 지갑에는 이러한 기능이 없습니다. 중요한 이유는 이들이 기본적으로 EOA 지갑이고 이러한 지갑은 기본적으로 체인에서 주소의 가장 기본적인 작업(쿼리 및 전송)만 지원하기 때문입니다. 스마트 컨트랙트 월렛은 월렛 기능이 더욱 확장될 것으로 기대됩니다. 실제로 DID 지갑 관련 기술 구현에는 많은 어려움이 있지만, 그만큼 기대해볼 만하다.

3.3 ID 관리 도구 - 도메인 이름

우리 각자는 고유한 ID 번호를 가지고 있지만 일상 생활에서 일반적으로 사람의 신원을 식별하는 식별자로 "이름"을 사용합니다(중복 이름이 있을 수 있음). 일상적인 의사소통에 더 편리하기 때문입니다.

Web3의 세계에도 이 문제가 있습니다. 사람들의 현재 상호 작용은 주로 지갑 주소를 기반으로 하지만 아무도 그 긴 문자열을 기억하려고 하지 않습니다. Web3의 디지털 ID에 "이름"이 필요한 경우 도메인 이름 프로젝트가 수행하는 작업은 이 "이름"이 되는 것입니다.

ENS는 도메인 이름에서 가장 잘 알려진 프로젝트입니다.Ethereum Foundation의 공식 지원을 받고 .eth 접미사가 있는 도메인 이름에 대한 등록 서비스를 제공합니다.현재 거의 180만 건의 등록이 있습니다. SpruceID가 EIP-4361: Sign In With Ethereum을 홍보하기 위해 ENS와 협력하고 있다는 점은 주목할 가치가 있습니다. 제안이 성공적으로 구현되면 Connect Wallet을 대체하여 도메인 이름이 지갑 주소 위의 Web3 입구가 될 수 있습니다. 또한 ENS는 도메인 이름에 일련의 ID를 통합하여 "Web3 이름"이라는 비전을 완성하기를 희망합니다.

주목할 만한 또 다른 도메인 이름 프로젝트는 Binance에서 공식적으로 지원하고 접미사가 .bnb인 도메인 이름에 대한 등록 서비스를 제공하는 Space ID입니다. Space ID는 또한 .bnb 도메인 이름과 서로 다른 체인에 있는 사용자의 여러 주소, 사용자의 Twitter 및 기타 Web2 계정을 식별하여 Web3 필드에서 범용 이름이 되기를 희망합니다. ENS와 비교할 때 Space ID의 제품 반복 속도와 랜딩 속도는 더 빠를 것입니다.

ENS와 Space ID 외에도 .bit와 Unstoppable Domain도 최근 비교적 많은 양의 자금 조달을 완료했습니다. 그들이 DID에 대해 말하는 내러티브는 기본적으로 동일합니다.

도메인 이름과 지갑 모두 ID 관리 도구로 사용할 수 있지만 역할이 매우 다르다는 점은 주목할 가치가 있습니다. 이론적으로는 충돌하지 않지만 긴밀하게 협력할 수 있습니다: 지갑은 도메인 이름을 지갑 계정 이름 대신 사용할 수 있으며 애플리케이션과 상호 작용할 때 "이름"으로 사용할 수 있습니다. 체인 또는 여러 지갑 계정의 주소.

3.4 기타 ID 관리 도구 - Next.ID를 예로 들어 보겠습니다.

아이덴티티 관리 제품도 있고 아이덴티티 관리 구현에 대한 구체적인 이해는 이전 프로젝트들과 다르지만 작업의 핵심은 주로 다양한 연결과 집계이며 특정 분야에 국한되지 않고 네트워크를 구축할 수 있기를 바랍니다. -와이드 아이덴티티 통합. Mask Network에서 만든 새로운 ID 관리 제품인 Next.ID를 예로 들어 보겠습니다.

사용자 중심이 아닌 ID 집계 프로토콜 프로젝트와 달리 Next.ID는 사용자 중심의 제품입니다. V1 버전에서 사용자는 마스크 네트워크를 사용하여 Web2 플랫폼 계정과 Web3 퍼블릭 체인 지갑 주소의 연결 및 집계를 실현하고 활성 ID 관리를 수행할 수 있으며 도메인 이름 및 DID와 비교하여 Next.ID도 집계 중입니다. 통합 디지털 신원의 경우 명시적인 식별자가 강조되지 않고 신원이 집계된 후 앱 호출을 위한 인프라로 만들어지기를 기대합니다. Next.ID가 자체 도메인 이름을 홍보하거나 마스크 계정 사용자 이름과 같은 식별자를 홍보하기 시작하면 Space ID 및 ENS와 같은 도메인 이름 프로젝트와 어느 정도 중복됩니다.

그러나 사용자 측의 집계 외에도 개발자는 Next.ID의 Avatar 시스템을 사용하여 아래 그림과 같이 제품에서 사용자 계정의 특정 작업과 Next.ID 간의 상호 운용성을 실현할 수 있습니다. 어느 정도 ID 집계 프로토콜이 원하는 대로 이러한 프로토콜과 협력하고 다시 집계하도록 선택할 수도 있습니다.

출처: Next.ID 공식 문서

3.5 로컬 장면 ID 관리 도구

3.5.1 GameID

전체 네트워크에서 사용자 데이터를 집계하려는 일부 ID 관리 도구 프로젝트 외에도 로컬 시나리오를 기반으로 ID 관리 도구를 만드는 일부 프로젝트도 있습니다.

이해하기 쉬운 예는 작년에 인기를 끌었던 Loots와 같은 체인의 다양한 게임에 대한 사용자 정보를 집계하는 GameID입니다.

GameID의 ID는 Web2의 Shanda 계정 및 QQ 계정과 유사하게 생태계 내에서 소통하는 계정 시스템을 더 의미합니다. 네트워크 전반에 걸친 디지털 ID.

따라서 DID라고 하기보다는 사용자 DID의 일부 조각, 퍼즐 조각이라고 표현하는 것이 좋습니다.

예를 들어, Zhang San은 zhangsan.eth라는 도메인 이름을 등록했고 그의 "Shanda" ID는 123456이며 다른 "Shanda 시리즈" 게임 프로젝트의 인증서 5개를 포함하고 그의 "Tencent" ID는 567890이며 Tencent의 인증서 9개를 포함하는 " " 시리즈' 게임 프로젝트 인증서. 따라서 "Shanda" 및 "Tencent"에는 사용자가 해당 플랫폼 계정을 관리하는 데 도움이 되는 전용 ID 관리 도구가 있을 수 있지만 모두 zhangsan.eth의 "Web3 이름"으로 집계되어 zhangsan.eth ID의 일부가 될 수 있습니다. .라벨.

3.5.2 DIDs

수년간의 연구와 논의 끝에 W3C는 마침내 2022년 7월 분산 식별자(DID, 분산 식별자)에 대한 v1.0 공식 표준을 출시했습니다. "DID"의 초기 정의로 W3C의 DID와 현재 Web3 DID 시스템 간의 관계를 명확히 하는 것도 필요합니다.

W3C 표준 분산 식별자 아키텍처에서 사용자는 식별자와 해당 문서를 직접 제어합니다. APP는 비즈니스 실현을 위해 사용자의 권한으로 DID 연동 문서를 열람할 수 있으며, 문서에는 서명, 암호화 데이터 등 디지털 신원 관련 정보가 포함되어 있습니다. 사용자는 암호화 서명을 통해 DID의 소유권을 증명합니다. 사용자 데이터는 신뢰할 수 있는 데이터베이스(예: 블록체인)에 저장되며 ID 데이터는 APP에 의존하지 않습니다.

DID에는 아래 그림과 같이 세 가지 구성 요소가 있습니다: http, ipfs 및 기타 메서드 선언과 유사한 DID 스키마 DID 메서드는 특정 메서드에 대한 식별자로, DID ID 시스템을 구축하려는 각 프로젝트는 하나를 신청할 수 있습니다. 예를 들어 Tencent는 QQ에 대한 tencentqq 식별자를 신청할 수 있습니다. QQ 번호 123456789.

DID의 세부적인 동작 과정과 기술적인 내용은 비교적 복잡하기 때문에 여기서는 자세히 소개하지 않겠습니다.

DID는 Web3 도메인 이름과 어느 정도 경쟁합니다. 다음은 DID와 도메인 이름의 주요 차이점을 비교한 것입니다.

• 가독성 측면에서 DID는 도메인 이름에 비해 사용자 수준의 가독성이 부족하지만 DID 방식이 존재하기 때문에 추가 의미 계층과 더 나은 유연성을 가질 수 있습니다.

• 정보 집계의 잠재력 측면에서 DID는 VC와 같은 검증 방법과 함께 이론적으로 더 많은 오프체인 정보, 특히 권위 있는 조직에서 제공하는 디지털 인증서를 집계할 수 있습니다. -체인 정보 기반, 더 나은 오프체인 정보 집계를 원한다면 일치하는 VC 표준이 필요할 수 있습니다.

• 데이터 저장 측면에서 DID의 데이터 저장은 지정되지 않으며 퍼블릭 체인 또는 일부 분산 데이터 네트워크(예: Ceramic Network)에 직접 저장할 수 있으며 사용자 자신을 위해 직접 저장할 수도 있습니다. 의 도메인 이름 프로젝트 스토리지는 모두 온체인에 있습니다.

전반적으로 DID 시스템은 하향식 설계이며 보다 포괄적이고 호환 가능한 표준입니다. 또한 Ontology와 같이 디지털 ID를 구현하기 위해 DID 경로를 채택하는 많은 프로젝트가 있습니다.

그러나 DID는 사용자의 가독성이 부족하여 장기적으로 사용자가 일상에서 기억하는 "Web3 이름"이 되기 어렵습니다. 장기적으로 도메인 이름으로 집계된 개체일 수 있으므로 "분할된 시나리오/로컬 ID 관리를 위한 식별자"라고 할 수 있습니다. 또한 이론적으로 DID는 오프체인 정보와 좋은 호환성을 가지고 있지만, 관심 고려 사항에서 현재 Web2 회사는 DID를 기반으로 관련 추천을 거의 하지 않으며 DID를 홍보하는 방법도 문제입니다.

3.6 신원 관리 도구: 전체 네트워크 신원 대 부분 신원

GameID 및 DID의 로컬 ID 집계 특성은 ID 관리에 대한 전체 및 로컬 사고로 이어집니다.

귀하의 ID 관리 제품이 사용자의 전체 네트워크의 디지털 ID 제품을 통합할 수 없거나 통합할 수 없는 경우, 즉 사용자의 "Web3 이름"이 되지 않는 경우 체인 데이터의 상호 운용성으로 인해 귀하의 ID는 해당 부분이 될 수 있습니다. 더 큰 신원 관리 제안의. 예를 들어 작은 GameID는 큰 GameID로 집계되고 GameID는 .eth 도메인으로 집계되며 .eth 도메인도 .bnb 도메인으로 집계될 수 있습니다. 위에서 언급한 DID는 앞으로 이런 종류의 "부분적 정체성"이 될 가능성이 높습니다. 어느 정도는 하나의 지갑 주소도 "부분적인 신원"이라고 할 수 있습니다.

그러나 로컬 ID 관리 도구도 가치가 있습니다. 특정 애플리케이션 시나리오에 대해 더 많은 기능을 생성할 수 있기 때문입니다. 이는 네트워크 전체 ID 관리 도구가 반드시 수행할 필요는 없으며 그렇지 않으면 비대해집니다. 예를 들어, GameID 관리 플랫폼에서 사용자는 다른 GameID가 표시하는 정보를 기반으로 동일한 MMORPG에서 동일한 마술 직업의 플레이어와 친구를 만들 수 있지만 지갑/도메인 이름 프로젝트에 여러 세분화된 기능이 필요한 경우, 제품의 복잡성이 증가하고 많은 제품 설계 문제에 직면하게 됩니다.

4. DID의 향후 발전의 궁극적 형태에 대한 고찰

우선, 미래에는 모든 사람이 일상 생활과 밀접하게 연결된 디지털 ID를 갖게 될 것입니다.

• 각 사람은 전체 Web3 네트워크에서 사용되는 하나의 DID(PoP를 통해)만 가질 수 있으며 오프체인 세계와 더 잘 상호 작용하기 위해 KYC 및 기타 방법을 통해 사용자의 실제 신원에 바인딩될 수도 있습니다.

• Web3 도메인 이름은 Web3의 사용자 이름인 이 DID의 고유 식별자입니다.

• 사용자는 현재보다 훨씬 강력한 기능을 갖춘 지갑을 통해 이 DID를 관리하며, 지갑 내부에는 여러 ID 집계 프로토콜을 통합하여 사용자의 다중 주소 및 다중 계약의 데이터 집계를 실현하고 사용자의 정보를 종합적으로 표시할 수 있습니다. 각 체인의 상태, 각 주소의 자격 증명, 부분 ID, 관계 그래프 등을 전체 사용자 초상화로 표시합니다.

• 사용자는 지갑을 통해 소셜 네트워킹, 채용 및 DAO 거버넌스와 같은 애플리케이션 시나리오와 상호 작용합니다. 암호화 기술을 통해 사용자는 프로젝트 당사자의 데이터 획득 권한을 독립적으로 제어하여 데이터 주권이 사용자에게 있음을 실현할 수 있습니다.

둘째, 각 사람은 일부 로컬 시나리오(예: 게임 플랫폼) 또는 PoP가 필요하지 않은 일부 시나리오에서 여러 다른 디지털 ID를 가지므로 서로 다른 시나리오에서 서로 다른 자아를 보여줄 수 있습니다. 사용자는 이러한 ID 간의 상호 연결을 자유롭게 제어하고 특정 시나리오에서 해당 ID를 사용할 수 있습니다.

V. 이전 기사 요약

위의 정리를 통해 독자들이 앞으로 DID 관련 내러티브를 이야기하는 프로젝트를 볼 때 이 "DID"가 어떤 종류의 "탈중앙화 아이덴티티"를 가리키는지 명확하게 알 수 있기를 바랍니다. 특정 자격 증명의 릴리스는 여전히 다양한 자격 증명을 ID로 집계하는 프로세스에 대해 이야기하고 있습니까, 아니면 사용자의 ID 관리에 대해 이야기하고 있습니까, 아니면 이 ID 시스템의 특정 응용 프로그램 시나리오에 대해 이야기하고 있습니까?

DID 관련 프로젝트는 종종 하나 이상의 레이어를 가지고 있다는 것을 언급할 가치가 있습니다; 예를 들어 이전에 분석된 Next.ID는 도메인 이름과 같은 사용자 측 ID 상호 작용을 수행할 뿐만 아니라 많은 ID 프로토콜과 같은 ID 집계를 수행합니다. ARCx는 신용등급 증명서 발급을 준비하고 있을 뿐만 아니라 관련 응용 프로그램도 만들고 있습니다.

아래 그림은 이전 글의 끝부분에서 DID 관련 트랙을 정리한 것입니다.

다음: DID Soul의 세 가지 질문

다음 기사에서 저자는 세 가지 질문을 통해 DID 분야에 대한 자신의 생각과 이해를 설명할 것입니다.

• 지금 DID가 정확히 필요한 사람은 누구입니까?

• DID가 아직 초기 단계이고 개발 속도가 느린 이유는 무엇입니까?

• DID 추적, 어떻게 투표해야 하나요?

1. DID, 지금 누구의 요구인가?

1.1 DID, 지금은 사용자의 요구가 아니다

이전 빗질을 통해 많은 독자들이 DID 자체가 사용자의 직접적인 요구가 아닌 경우가 많다는 것을 발견했을 것입니다! 제품 관리자의 관점에서 DID가 사용자를 지향하려면 특정 애플리케이션 시나리오를 거쳐야 하는 경우가 많습니다.

현재 특정 애플리케이션 요구 사항이 없는 경우 다양한 자격 증명(예: 비디오 얼굴 인증을 위해 BrightID로 이동)을 적극적으로 얻거나 일부 ID 집계/관리 도구(예: Next.id)로 이동하는 데 관심이 있다고 상상해 보십시오. 이메일, 트위터, 지갑 주소가 모두 연결되어 있나요? 나는 대부분의 사용자가 그렇지 않을 것이라고 믿습니다.

프로젝트 당사자가 일정한 인센티브를 제공한다면 분명 일부 사용자를 유치할 수 있겠지만 DID 제품의 특성상 이 인센티브 자체만으로는 사용자를 지속적으로 유지하기 어렵다는 점에서 다른 유형의 DID 제품과는 다릅니다. NFT 및 GameFi와 같은 프로젝트.

장기적으로 DID 개발이 점진적으로 개선됨에 따라 사용자는 개인 신원 데이터의 관리 및 활용에 대해 점점 더 인식하게 될 것이므로 신원 관리의 필요성이 특정 애플리케이션 시나리오에 선행하는 상황이 있을 수 있습니다. 그러나 DID 트랙이 아직 초기 단계이기 때문에 지금은 그런 일이 일어날 것 같지 않습니다.

1.2 DID는 응용 시나리오 프로젝트 당사자의 요구 사항입니다.

실제로 DID에서 더 많은 혜택을 받는 것은 특정 애플리케이션 시나리오의 프로젝트 당사자입니다. 자격 증명을 기반으로 한 빠른 심사이든 Web3에서 사용자 초상화를 빠르게 얻는 것이든 콜드 스타트 ​​단계에서 프로젝트 측에 직접적인 이점을 가져다 줄 것입니다.

그러나 응용 시나리오가 실제로 DID를 사용하고 DID를 구축할 때 사용자에게 DID 개념을 강조할 필요는 없으며 제품의 논리에서 추상화됩니다. 따라서 DID 개념이 특정 애플리케이션 시나리오보다 프로젝트 내러티브 및 토론에 더 자주 등장하는 것은 놀라운 일이 아닙니다.

2. DID 트랙이 아직 초기 단계이고 느리게 발전하는 이유는 무엇입니까?

DID의 개념은 Web2 시대로 거슬러 올라갈 수 있으며 작년 11월 ENS가 발행된 이후 대중화되었지만 현재 DID 트랙은 아직 초기 단계입니다. DID와 관련된 많은 프로젝트가 있지만 DID의 형태는 아직 결정되지 않았으며 어떤 DID 시스템의 데이터 축적에도 네트워크 효과의 징후가 없습니다.

DID 개발에는 특정 애플리케이션 시나리오가 필요하다는 점을 명확히 한 후 이 문제를 이해하는 것은 어렵지 않습니다. 이는 현재 Web3 개발의 "슈퍼 금융화"와 비금융 Web3 프로젝트의 느린 개발과 관련이 있습니다. DID 내러티브와 관련된 애플리케이션 시나리오를 살펴보면 거의 모든 비금융 Web3 프로젝트에서 DID 내러티브를 도입할 수 있음을 알 수 있습니다.

따라서 이 질문에 답하기 위해서는 각 DID 관련 Web3 애플리케이션 시나리오와 관련된 트랙의 개발이 느린 이유를 답하는 것이 본질적이다.

2.1 Web3 비재무 애플리케이션 시나리오의 느린 개발에 대한 세 가지 이유

저자는 소셜 네트워킹, 게임, 채용 등 모든 Web3 비금융 애플리케이션 시나리오 프로젝트 분석에 다음 세 가지 논리가 적용 가능하다고 생각합니다. (지갑과 같이 일부 도구 속성이 있는 항목은 논의 범위에서 벗어남)

• Web3 애플리케이션의 사용자 경험은 해당 Web2 애플리케이션의 사용자 경험과는 거리가 멉니다. 제품 사용 임계값이든 네트워크 지연이든 운영 비용이든 모두 Web2보다 높습니다.

• Web3 애플리케이션의 사용자 기반은 Web2보다 훨씬 작으며 전 세계에 흩어져 있습니다. 이것은 실제 세계와 온체인 세계 간의 연결을 방해할 뿐만 아니라 네트워크 효과의 축적에 더 많은 어려움을 가져옵니다.

• 현재 약세장 주기에서 많은 사용자가 자산을 잃고 체인의 활동 빈도가 감소했습니다.일부 사용자는 2018년에 그랬던 것처럼 전체 산업을 의심하기 시작했고 직접 "원에서 은퇴"했습니다. Web3 응용 프로그램 프로젝트를 시작하기가 더 어렵습니다.

위의 각 항목은 Web3 응용 시나리오 프로젝트가 개발되기 어려운 중요한 이유가 될 수 있습니다. Web3 애플리케이션 프로젝트에 개발 기회가 없다는 뜻인가요? 설마. Web3는 기본이고 Web2는 그렇지 않은 일부 시나리오에서는 위의 문제가 존재하더라도 관련 제품이 여전히 그 가치를 반영할 수 있습니다.

2.2 C씨의 신용대출은 중·단기적으로 허위명제

(To B의 신용 대출은 CeFi의 논리에 더 많이 관여하므로 여기서는 주로 To C의 신용 대출에 대해 논의합니다)

신용 대출은 DID의 가장 금융화된 애플리케이션 시나리오입니다. 이는 거의 모든 기존 DeFi가 담보가 과도하고 자본 활용 효율성이 낮기 때문에 자주 발생하는 주제이기도 합니다.이론적으로 신용 대출은 사용자의 자본 활용 효율성을 향상시킬 수 있으며 Web3 사용자도 이에 대한 수요가 강할 것입니다.

그러나 저자는 To C 신용 대출이 단기 또는 중기(예: 3년 이내)에서 잘못된 제안이거나 극히 틈새 분야라고 생각합니다.

주된 이유는 Web3 세계에는 Web2와 같은 미상환 대출에 대한 의지 메커니즘이 없기 때문입니다. 따라서 대출금을 상환하지 않는 궁극적인 비용은 일련의 온체인 ID의 가용성 손실입니다.

어떤 사람들은 디지털 신원 자체도 가치가 있다고 말할 수 있으며, 위의 다양한 자격 증명 및 관계 데이터의 축적을 포함하여 수년 동안 사용해온 주소, 도메인 이름 및 기타 신원을 포기하고 싶지 않을 수 있습니다. 그러나 문제는 스스로에게 물어보십시오. 대부분의 Web3 사용자의 현재 온체인 ID의 가치는 얼마입니까? 100U를 "신용 대출"할 수 있다면 돈을 갚지 않고 자신의 신원을 재건하는 것에 대해 생각하는 사용자가 얼마나 될까요? 신용 검토에 대한 임계값이 극도로 높지 않은 한, 이것은 또한 매우 틈새 상품이 될 것입니다.

어떤 사람들은 KYC와 얼굴 인식을 하면 이 문제를 피할 수 있을지도 모른다고 말할 수 있습니다. 그러나 실제로 저개발 국가의 농촌 지역에는 가치 없는 개인 실명 데이터가 넘쳐난다. "거래소의 KYC 계정은 일괄 판매됩니다"와 같이 매일 보는 정보에 대해 생각하십시오. "신용 한도"가 ID의 구성 비용보다 높으면 전문적인 "계정 유지 관리" " 사용자 및 배치 건설은 요구 사항을 충족합니다. 신원을 확인한 다음 대출 상환을 거부하고 프로젝트 당사자의 털을 움켜 잡습니다.

To C 신용 대출의 성숙은 전체 DID 시스템의 성숙을 기다려야 할 수 있습니다. 한편으로는 다양한 고가 인증서 및 다양한 데이터 관계의 축적, 디지털 ID의 구축 비용 및 한편으로는 여러 국가에서 감독이 보급됨에 따라 Web3 대출은 법적 상환 메커니즘을 구축하여 대출을 상환하지 않는 사용자의 비용을 증가시킬 수 있습니다.

3. DID 트랙 레벨 투자의 논리는 무엇인가?

여기에서 저자는 DID 트랙 수준의 전반적인 투자에 대한 개인적인 생각을 공유합니다.

• 전반적인 논리: 사용자로부터 시작하여 응용 프로그램이 동의를 선행합니다.

• 특정 우선 순위: ID 관리 > 애플리케이션 시나리오 > 자격 증명 발급 > (사용자 중심이 아닌) ID 집계 프로토콜

3.1 전체 논리: 사용자부터 시작하여 응용 프로그램이 프로토콜보다 우선합니다.

여기서 "애플리케이션"은 특정 시나리오, ID 관리 및 자격 증명 발급을 위한 "프로토콜"을 포함하는 "사용자 지향"의 광범위한 개념입니다. 일반적으로 사용자를 직접 지향하지 않는 다양한 프로토콜 제품을 말합니다. 그들은 종종 API 호출 형식 애플리케이션 프로젝트 당사자 또는 기타 계약

다음과 같이 생각할 수 있는 일부 계약 프로젝트 당사자가 있습니다: 계약으로서 더 많은 애플리케이션 프로젝트 당사자가 내 계약에 참여하도록 계속 설득할 것입니다. 어쨌든 내 데이터가 축적되고 데이터 장벽과 네트워크 효과가 있어 내 가치가 점점 높아지고 점점 더 많은 응용 계층 프로젝트가 협력하게 될 것이며 마침내 API를 청구할 수 있습니다. , 또는 관련 부가 가치 서비스를 제공합니다. 위의 논리가 합리적이고 가능한 것은 사실입니다.

그러나 저자는 주로 다음과 같은 이유로 애플리케이션을 먼저 선호합니다.

• 우선 데이터 흐름 방향에서 응용 프로그램이 프로토콜보다 앞서야 하므로 더 큰 주도권을 갖게 됩니다. 프로토콜 대 애플리케이션 논쟁은 언뜻 보기에 "닭과 달걀"처럼 보일 수 있지만 그렇지 않습니다. 위에서 설명한 것처럼 DID 데이터의 축적은 특정 애플리케이션 시나리오에서 사용자의 상호 작용에 따라 달라집니다.

• 둘째, 프로토콜 프로젝트 측에서 수행하는 작업이 성숙하지 않고 아직 개념/테스트 단계에 있을 수 있으며, 성숙하더라도 애플리케이션 프로젝트 측의 요구를 잘 충족하지 못할 수 있습니다. 프로토콜 당사자에게 피드백을 제공하고 반복을 기대하는 대신 애플리케이션 측에서 자체적으로 피드백을 만들어야 합니다.

• 보다 현실적인 관점에서 볼 때 데이터 장벽과 네트워크 효과는 Web2에 의해 검증된 훌륭한 내러티브입니다.트랙 개발의 초기 단계에서 뛰어나고 야심찬 응용 프로젝트 팀은 이 내러티브를 자발적으로 포기하지 않을 것입니다.캡처 이 값의 값은 완전히 다른 프로젝트 당사자의 합의에 맡겨집니다.

• 결국 Web3 응용 프로젝트의 현재 자금 조달은 매우 어려운데 응용 프로그램 프로젝트 당사자도 프로토콜과 관련된 DID 내러티브를 평가 지원으로 이야기하지 않는 이유는 무엇입니까? 예를 들어 먼저 사용자의 참여를 유도하고 애플리케이션 자체를 통해 데이터를 축적한 다음 애플리케이션에서 사용자의 데이터를 관련 파트너 및 생태계에서 사용할 수 있도록 프로토콜화하여 데이터를 더 축적하고 최종적으로 DID 시스템으로 발전합니다. 이 내러티브는 여러 번 완벽하게 이해됩니다.

• 또한 대부분의 DID 프로토콜은 실제로 기술적 장벽이 부족하고 장벽은 어느 정도의 엔지니어링 복잡성에 더 많이 반영됩니다. 파티 초기 제품을 빠르게 반복하기 위해 다른 프로토콜을 사용합니다.응용 프로그램이 특정 성공을 달성할 수 있는 경우 프로젝트 당사자는 자체 개발 프로토콜을 고려하여 프로젝트의 개발 한도를 높일 수 있습니다.

3.2 주목할만한 구체적인 세분화 트랙

• 우선 순위: ID 관리 > 애플리케이션 시나리오 ≈ 자격 증명 릴리스 > (사용자 지향 아님) ID 집계 프로토콜

• ID 관리 도구 프로젝트: 지갑 및 도메인 이름 프로젝트가 선호됩니다. 결국 DID의 궁극적인 형태에 대한 미래 작가의 개념에서 둘 다 매우 핵심적인 위치를 차지합니다.

• 애플리케이션 시나리오의 프로젝트: 앞서 언급한 바와 같이 Web2 제품의 재생산보다는 Web3의 원래 애플리케이션 요구 사항에 더 많은 기회가 나타납니다. 자격 증명 기반 Web3 모집, NFT 기반 관심사 소셜/이성애 소셜 등 모두 대체 불가능한 Web3 시나리오에 속합니다.

• 원본 링크

원본 링크