Web2 사용자의 ID를 Web3에 연결하는 방법은 무엇입니까?

공식 계정에서 다시 게시됨: old yuppie

이 기사에서는 Web2가 Web3 생태계로 전환되는 방식과 여기에서 ID가 중요한 역할을 하는 방식에 대한 질문을 살펴봅니다.

나는 Web3가 잠시 동안 여기에 있다고 생각합니다. Web3는 사용자 선택과 소유권을 우선시하고 분산형 서비스를 구축하는 데 사용할 수 있는 철학, 개념 및 기술을 의미합니다. 블록체인(예: Ethereum , Solana), 토큰, 프로토콜(예: IPFS, TheGraph, Lit), 서비스(예: ENS, Filecoin), dApp 및 사용자 키가 Web3를 구성합니다(여기에 전체 목록을 나열하지는 않았습니다).

얼마나 성공할지 모르겠고 오늘은 아무 일도 일어나지 않을 것 같습니다. 하지만 효과가 있을 것이라고 생각합니다. 어떤 면에서는 성공적이었다고 생각합니다.

나는 또한 Web3가 존재하는 "유일한" 웹이 아니라고 생각합니다. 적어도 몇 년(10년) 동안은 Web2와 공존할 것입니다. 나는 그렇게 생각하는 유일한 사람이 아닙니다.

그 이후에는 또 다른 패러다임이 등장할지도 모릅니다. 개발자로서, 특히 다른 개발자를 위한 제품을 만드는 사람으로서 저는 이것이 무엇을 의미하는지 생각하는 데 많은 시간을 보냅니다. 내 생각을 글로 공유하면 재미있을 것 같다는 생각이 들었다.

이 문서는 주로 다음을 대상으로 합니다.

• Web3 서비스와 통신하는 Web2 애플리케이션을 구축하는 개발자

• Web2 애플리케이션에서 사용할 Web3 서비스를 구축하는 개발자

이 게시물에서는 이더리움 의 문서와 개념에 대해 가장 잘 알고 있고 오늘날 가장 큰 개발자 플랫폼이기 때문에 이더리움에 대한 링크를 제공합니다. 다른 많은 체인에도 유사한 사항이 적용됩니다.

Web3 아키텍처를 사용하는 Web2 애플리케이션

Web2 애플리케이션은 Web3 구성을 통해 사용자 경험을 향상시킬 수 있습니다.

——Shopify는 사용자의 NFT를 기반으로 쇼핑 경험을 사용자 지정하기 위해 "토큰화된 상거래"에 뛰어들고 있습니다. 다음은 주제에 대한 매우 명확하고 심층적인 기사입니다. 토큰화된 상거래는 훌륭한 아이디어입니다. 당신이 가진 것은 당신이 좋아하는 것에 대해 많은 것을 말해줍니다. NFT를 기반으로 쇼핑 경험을 사용자 정의하는 것은 자연스럽게 느껴집니다. (
https://help.shopify.com/en-US/manual/products/digital-service-product/nfts)

— Twitter와 Stripe는 암호화폐 결제를 허용하기 위해 협력하여 콘텐츠 제작자가 암호화폐로 쉽게 결제할 수 있도록 합니다. (
https://stripe.com/blog/expanding-global-payouts-with-crypto)

- Reddit은 블록체인 위에 커뮤니티 포인트 시스템을 구축하고 있습니다. (
https://www.reddit.com/community-points/)

이들은 대규모 소비자 대면 플랫폼입니다. 그들은 dApp이 되는 것이 아니라 Web 3에 손을 대고 있습니다.

이것은 개발자에게 무엇을 의미합니까?

개발자는 Web2 및 Web3 세계를 통합하는 방법을 파악해야 합니다. 우리는 이미 이것이 다른 방식으로 진행되는 것을 보기 시작했지만 개발자 도구와 인프라를 만드는 회사는 Web3 통합을 탐색하고 구현하고 있습니다.

• Stripe는 Web3 결제 인프라를 구축하고 있습니다(https://stripe.com/use-cases/crypto).

• Auth0는 이더리움 로그인 지원을 발표했습니다(https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/).

• Google Cloud는 Web3 팀을 구성하고 있습니다.

패턴: Web2 개발 인프라를 구축한 이러한 대기업은 이제 Web2 앱 개발자가 Web3 개념(NFT, 암호 화폐, ENS 등) dApp)과 쉽게 통합할 수 있도록 하는 구성 요소를 만들고 있습니다.

그들은 Web2와 Web3 세계 사이에 다리를 만들고 있습니다. 이들의 브리지는 Web2 개발자가 이 게시물의 초점인 Web3 패브릭과 상호 작용할 수 있도록 하는 것입니다.

브리징의 또 다른 측면은 Web3 개발자가 Web2 데이터를 사용할 수 있도록 하는 것입니다. 이 기사가 개발자의 관심을 끌면 다른 블로그 게시물을 작성할 수 있습니다.

Web3의 신뢰 모델

Web3의 아이디어는 분산화입니다. 모든 사용자는 자신의 데이터, $토큰 등을 소유합니다.

Web3의 신뢰 모델은 신뢰의 소스가 사용자의 개인 키인 비대칭 암호화에 의존합니다.

위임에 대한 몇 가지 사용 사례가 있지만 일반적으로 사용자는 제3자를 신뢰할 수 있는 대리인으로 선택하지 않으며 위임은 사용자의 선택입니다.

Web2와 Web3 사이의 브리지가 존재하려면 사용자 주소 소유권에 대한 신뢰가 양방향으로 흘러야 합니다.

정체성은 다리의 구조다

결국 Web3의 맥락에서 사용자의 주소는 그들의 "신원"입니다. 이것은 그들이 누구인지를 나타냅니다. 따라서 그들은 한 종류 또는 다른 종류의 많은 정체성을 가질 수 있으며 각각은 서로 다른 맥락에서 제시하는 별도의 "정체성"입니다.

Web2와 Web3 세계를 연결한다는 것은 다리 양쪽에서 ID를 확인하고 개발자가 그 위에 쉽게 구축할 수 있도록 하는 것을 의미합니다.

물론 웹 3의 원칙은 브리지를 구축할 때 손상되어서는 안 됩니다. Web3 ID 프로토콜(예: OIDC:
https://openid.net/connect/, OAuth 2: https://oauth.net/2/) 및 Web 3의 요구와 개념에 적응하기 위한 표준 작업 방법.

모든 것은 주소에서 시작됩니다

Web3 주소에는 연결된 개인 및 공개 키가 있습니다.

주소 수가 빠르게 증가하고 있습니다.

이더리움 주소(https://etherscan.io/chart/address)

그러나 활성 주소의 수는 더 느리게 증가했습니다.

활성 이더리움 주소 https://etherscan.io/chart/active-address

위의 그래프에서 우리는 이더리움 주소를 적극적으로 사용하는 인터넷 사용자의 비율이 낮다는 것을 추론할 수 있습니다. Metamask는 두 달 전에 월 활성 사용자가 3천만 명이라고 밝혔습니다. 그러나 주소를 소유하지 않은 사용자는 어떻습니까?

Web3가 대량 사용자의 장기적 채택을 달성하려면 대량 사용자 채택을 위한 포장된 경로가 있어야 합니다. 모든 사람이 암호 화폐 세계에 관심이 있는 것은 아닙니다. 사용자가 익숙한 패턴(Facebook, Google, Twitter 등으로 로그인)을 계속 사용하고 나중에 블록체인(및 키)에 대해 알고 싶을 때만 깨달을 수 있는 방법은 매우 가치가 있습니다.

주소의 수가 매우 빠르게 증가하고 있는 동안 상대적으로 적은 수의 모든 인터넷 사용자 그룹이 오프라인에서 키 쌍을 생성하거나 하드웨어 지갑을 통해 개인 키를 소유하고 있습니다. 대부분 "수탁지갑" 형태로 존재하며 키는 서비스 기관에서 관리합니다. Binance 또는 Coinbase 와 같은 중앙 집중식 교환이 가장 일반적인 예입니다.

이것은 Web3/탈중앙화 관점에서 "순수"하지 않을 수 있지만 매우 긍정적입니다. Web 3의 아이디어 중 일부를 대중에게 제공합니다.

개발자 관점에서 Web2 및 Web3 세계를 연결한다는 것은 호스팅 서비스가 블록체인 주소를 사용자 계정과 연결하고, 키를 안전하게 관리하고, Wallet 상호 작용을 관리하기 위한 제어 기능(최소한 다른 내부 개발 팀에)을 제공해야 함을 의미합니다.

magic.link, bitski 및 venly와 같은 서비스는 Web2가 Web3 세계에 연결되도록 돕고 일반적인 Web2 로그인 메커니즘을 위한 키 쌍을 만들고 개발자가 이러한 개인 키를 관리할 수 있는 API 및 UI를 제공합니다.

사용자가 개인 키를 제어하면 여기에서 재미가 시작됩니다 :)

내 개인 키로 로그인

비교적 간단한 시나리오를 살펴보고 이것이 Web2 및 Web3 애플리케이션에서 어떻게 작동하는지 살펴보겠습니다. 사용자:

• 하나의 앱에서 인식됩니다.

• 아바타를 {입력 A}로 변경하고 저장합니다.

• 그들이 #2에서 실수를 했다는 것을 깨달았습니다.

• 아바타를 {입력 B}로 변경하고 저장합니다.

Web3 애플리케이션(dApp)을 사용하면 사용자가 자신의 주소 중 하나를 "연결"할 수 있습니다. 이 작업은 기본적으로 브라우저에 사용자의 블록체인 주소를 제공합니다. 블록체인 및 기타 탈중앙화 서비스 외에는 "백엔드"가 없습니다. 일반적으로 Web3 구성 요소에서 사용자를 인증해야 하는 작업에는 사용자의 개인 키에서 서명된 정보가 필요합니다.

웹 3의 사례

Web2 프로토콜을 사용하면 사용자는 작동할 때마다 신원을 증명하기 위해 조치를 취할 필요가 없습니다. 사용자는 일반적으로 한 번만 로그인하면 되며 클라이언트/브라우저는 자격 증명을 저장하고 후속 요청 시 이를 백엔드로 보내 사용자를 인증하는 데 사용합니다.

웹 2 사례

위의 다이어그램은 요점을 위해 지나치게 단순화되었습니다.

Web2의 사용자 경험이 더 좋습니다. Web2 세계와 Web3 세계를 연결하려면 Web2와 유사한 사용자 경험을 유지하여 사용자가 개인 키를 제어하고 블록체인(또는 다른 Web3 네이티브 서비스)을 호출할 때 각각의 특정 작업을 수행할 의도가 있음을 증명해야 합니다.

개발자는 Web2 애플리케이션의 일부로 주소를 사용자 계정과 어떻게 연결합니까?

이전 섹션에서 언급한 서비스는 이미 개인 키를 사용자 계정과 연결합니다. 그러나 그렇지 않은 서비스는 어떻습니까? 사용자가 Metamask, Argent, Trezor 또는 기타 유형의 지갑을 사용하는 경우 어떻게 됩니까?

이것은 이더리움 로그인(
https://eips.ethereum.org/EIPS/eip-4361). 이를 통해 사용자는 개인 키를 주소 소유권을 증명하는 자격 증명으로 사용하여 서비스와 세션(Web2 의미에서)을 설정할 수 있습니다.

이미지 출처: https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/

흥미롭게 들린다면 @signinwitheth 및 @SpruceID를 따라야 합니다.

그리고 Web2 애플리케이션이 사용자의 블록체인 주소가 사실임을 알게 되면 가능성의 세계가 열립니다.

잠재적 사용 사례

사용자의 Web3 ID가 알려지면 Web2 개발자는 당연히 더 나아가고 싶어할 것입니다. 이는 다음을 의미합니다.

• 주소와 관련된 공개적으로 사용 가능한 데이터(예: 온체인 데이터)를 읽고 쓰고 비즈니스 로직에 사용합니다. 이를 "사용자 인증이 필요하지 않은 작업"이라고 합니다.

• 인증이 필요한 데이터 읽기/쓰기(예: 분산 저장소에 저장된 사용자의 개인 비디오 또는 온체인 트랜잭션 수행). 이러한 "사용자 인증이 필요한 작업"이라고 합시다.

작동 방식을 이해하기 위해 각각을 자세히 살펴보겠습니다.

사용자 인증이 필요하지 않은 작업

이것은 가장 간단한 경우입니다. 개발자는 주소가 필요하고 인증이 필요하지 않은 모든 API를 호출할 수 있습니다. 떠오르는 몇 가지 사용 사례는 다음과 같습니다.

• 프로필 데이터에 대한 ENS(https://ens.domains/) 또는 Unstoppable Domains(https://unstoppabledomains.com/)를 읽고 이를 표시합니다. 사용자가 이를 선택하면 "전역 공용 사용자 이름 및 구성"이 됩니다. 파일 그림'은 가능성을 열어줍니다.

• 토큰 액세스 제어는 사용자의 POAP를 획득하고 이러한 POAP(https://poap.xyz/)를 기반으로 리소스에 대한 액세스를 제한함으로써 달성됩니다.

• 자산을 사용자의 온체인 주소로 전송합니다.

• 다음 단계는 주류가 되면 Proof of Humanity와 같은 서비스를 사용하여 가짜 사용자 계정을 방지하는 것입니다.

디지털로 검증 가능한 인증서로 이러한 목표 중 일부를 달성할 수 있는 다른 방법이 있으며 여기에는 공개 데이터가 필요하지 않습니다. 그러나 그것은 다른 기사에 대한 이야기입니다 ...

사용자 인증이 필요한 작업

오, 상황이 까다로워지기 시작했습니다 :) 우리는 모두 이와 같은 대화에 익숙합니다.

Web2 앱이 Gmail 데이터에 액세스하기를 원하는 경우 Google로 로그인하면 Web2 앱이 액세스할 계정의 리소스에 동의하는 대화 상자가 나타납니다.

이것이 Web 3 서비스에 대해 어떻게 작동해야 합니까? Web2 애플리케이션이 서로 다른 두 Web3 서비스에 있는 데이터를 읽으려는 경우.

• 모두 동시에 "로그인"해야 합니까?

• 아니면 둘 다에게 앱 권한을 부여하는 데 동의하시겠습니까?

• 각각의 경우에 사용자 경험은 어떻습니까?

Web2 애플리케이션의 맥락에서 인증 서버(이전 예에서는 Google)에서 발급한 토큰을 사용하여 Gmail의 API에 액세스합니다(Gmail은 "리소스 서버"임). 웹 2 애플리케이션은 사용자를 대신하여 API를 여러 번 호출할 때 이 토큰을 보냅니다. Web3 서비스의 경우 어떻게 작동해야 할까요?

• 사용자는 Web3 서비스와의 모든 상호 작용에 대해 계약서에 서명해야 합니까? 최고의 사용자 경험이 아닙니다...

• 애플리케이션에 권한을 위임해야 합니까? 위탁하는 방법?

• Web3 서비스는 이러한 인증 상황에 어떻게 맞춰야 합니까?

Spruce의 개발자들은 이미 이 문제를 해결하는 방법에 대해 생각하기 시작했습니다. 긍정적인 진전이라고 생각합니다. 모든 개발자를 위해 이러한 사례를 반복 가능한 패턴/지침으로 일반화하려면 사용 사례와 실제 시나리오를 이해해야 합니다.

그것이 앞으로의 도전의 큰 부분이라고 생각합니다.

요약하다

제가 적극적으로 생각하고 이 문제를 파악하려고 노력하고 있기 때문에 이에 대해 어떻게 생각하시는지 알고 싶습니다. Auth0Lab에서 우리 팀 작업의 일환으로 우리는 하나의 애플리케이션의 맥락에서뿐만 아니라 모든 개발자에게 도구를 제공하는 맥락에서 Web2와 Web3 세계를 연결할 수 있는 방법을 모색하고 있습니다.