계정 아키텍처 논의: 3개 키 시스템이 이상적인 솔루션인 이유는 무엇입니까?
원작자: Norswap
원본 편집: Deep Chao TechFlow
저는 0x Fable의 지갑과 사용자 온보딩에 대해 많이 생각했습니다. 다음은 내 의견 중 일부입니다. 우리는 논의 할 것이다:
나의 이상적인 계정 구조;
보안 고려 사항;
기존 Web3 로그인 공급자 개요
분명히 사용자에게 지갑 소프트웨어를 설치하고 온보딩 프로세스 중에 니모닉 문구를 저장하도록 요구하는 것은 바람직하지 않습니다. 우리에게는 우호적이고 상대적으로 안전하며 어느 정도 미래지향적인 접근 방식이 필요합니다.
건축학
각 사용자는 세 가지 키가 포함된 자신만의 스마트 어카운트를 갖게 됩니다.
장치 키 - 처음에는 로컬에 저장할 수 있지만 앞으로는 패스키/웹 인증이 사용될 것입니다.
공급자가 제어하고 소셜 로그인을 통해 잠금 해제되는 것과 같은 보조 키입니다.
키를 제3자에게 백업하세요(단순히 이메일 첨부 파일로 사용하거나 Dropbox/Google Drive에 보관할 수 있음).
이것이 기술 수준이 낮거나 안전하지 않은 것처럼 들리면 공급자의 달콤한 말에 속으신 것 같습니다. 실제로는 그보다 더 안전하지 않기 때문입니다(예를 들어 키 (2) 및 (3) ) )는 동일한 당사자에 의해 제어됩니다).
이 설정에서는 장치 키를 사용하여 사용자 개입 없이 작동할 수 있습니다. 자산과 관련된 양도 및 거래의 경우 보조키 사용을 요청할 수 있습니다.
간단한 패턴은 사용자가 Google/Apple/Facebook 등으로 로그인한 다음 확인 메시지를 추가하는 것입니다. 이렇게 하면 쉽게 시작할 수 있습니다. 그러나 사용자에게 더 많은 보안이 필요한 경우 이 키를 기존 EOA로 대체할 수 있습니다. 또한 어떤 키 쌍이라도 백업 키를 대체하는 데 사용할 수 있으며 백업 키는 클라우드에서 호스팅되는 파일이어야 합니다.
보안 분석
얼마나 안전합니까? 대부분의 경우 그는 안전합니다. 자금 손실이 발생하려면 두 개의 장치 또는 개체가 동시에 손상되어야 합니다.
가장 중요한 점은 보안을 저하시킬 수 있는 일부 구성 위험이 있다는 것입니다. 예를 들어 Google 계정에 보조 키를 할당하는 동시에 Google Drive에서 백업 키를 호스팅할 수 있습니다. 또는 장치 키와 동일한 위험을 수반하는 핫 지갑을 보조 키로 사용하세요. 사용자는 백업을 잃을 수 있습니다. 사용자에게 장치 키를 교체하라는 메시지를 주기적으로 표시하여 사용자가 백업 키를 찾도록 하는 것이 좋습니다.
백업 키가 공개적으로 저장되면 도난 위험도 매우 높습니다. 이는 디스크의 키를 암호화하고 메모리에서 암호를 해독해야 하는 핫 지갑보다 훨씬 더 나쁩니다. 그럼에도 불구하고 (장치 인증을 사용하여 앱에 로그인할 수 있는) 패스 키를 추가하면 이 문제가 해결됩니다.
소셜 로그인은 공급자를 신뢰한다는 것을 의미한다는 것을 이해하십시오. 제공자는 기본적으로 자신이 원하는 대로 사용할 수 있는 키를 가지고 있지만, 귀하가 소셜 계정에 로그인한 후에만 귀하의 요청에 따라 이를 사용할 것이라고 약속합니다. 마지막으로, dapp 제작자가 보조 키를 제공하거나 확인 메시지가 없는 경우 dapp 제작자가 사용자를 속이기 매우 쉽습니다(그들이 장치 키를 소유한 프런트엔드를 작성하고 소유하거나 보충 키를 제어할 수 있습니다.)
기존 공급자 개요
오늘 누가 이것을 제공합니까? 내가 아는 한, 아니오. 문제는 일반적으로 백업 키가 없거나 동일한 주체(예: Coinbase 지갑)가 보유하고 있다는 것입니다.
시장은 크게 두 가지 범주로 나뉜다.
통합 다중 키 솔루션을 제공하는 공급자는 스마트 계정을 사용하거나 MPC(다자간 계산, 암호화 기술)를 사용하여 여러 키를 단일 EOA로 결합합니다.
귀하를 위해 사용자 키를 보유하고 로그인 후 로그인을 허용하는 하위 수준 공급자입니다.
Particle Network, Privy, Alembic Tech, Magic, Web3 Auth, Turnkey, Dynamic, 0x Pass, Fireblocks, Portal, Capsule, ZeroDev, Keyp, Circle Developers 등 풀 스택 제공업체가 많이 있습니다.
다음과 같은 주요 관리인: Lit Protocol, Amazon.
네, 그런 게 많아요. 기본적으로 그들 사이에는 차이가 없습니다. 비즈니스 모델이 투명한 경우 일반적으로 사용자당 연간 0.02~0.05달러를 청구합니다. 나에게는 이것이 꽤 합리적으로 보인다.
흥미롭게도 이들 모두는 개발 도구로 자리잡고 있습니다. 사용자를 위한 기본 지갑이 되기 위해 이러한 기술을 적용하려는 회사는 없는 것 같습니다.
물론, 기존 dapp과 연동하려면 지갑 소프트웨어를 설치해야 합니다. 따라서 니모닉 문구를 제거하는 것만으로도 시스템의 이점이 줄어듭니다. 그러나 dapp이 시작하는 가장 쉬운 방법으로 귀하를 홍보하도록 할 수도 있습니다(통합하는 경우 지갑 소프트웨어를 설치하지 않고도). 사용자를 확보하면 dapp을 무료로 쉽게 시작할 수 있습니다. 윈윈.
공급자에 대한 우려
이상적인 아키텍처를 구현하지 않는 것 외에도 이러한 솔루션은 종종 REST API와 같은 대규모 중앙 집중화 요소나 사업이 중단되면 스스로 수행할 수 없는 일부 MPC 계산을 도입합니다. ).
해당 서비스 제공자와의 협력을 중단하면 어떤 일이 일어날지는 확실하지 않습니다. 그들은 사용자의 키(일부)를 가지고 있습니다! 이는 서비스형 롤업에 대한 나의 우려와 매우 유사합니다.
그 후 한 RaaS 창립자는 쉬운 종료를 허용하는 것과 창립자가 사용자를 속이는 것을 방지하는 것(RaaS에 나쁜 영향을 미칠 수 있음) 사이에는 상충 관계가 있다고 말했습니다.
위 아키텍처를 사용하여 공급자를 쉽게 전환하는 방법은 다음과 같습니다. 사용자는 온체인 소셜 계정의 해시를 제출합니다(예: gavin@hooli.xyz). 각 소셜 로그인 제공업체에는 고유한 개인 키가 있습니다(각 사용자마다 하나씩 가질 필요는 없으며 일반적으로 더 안전하지 않습니다). 스마트 계정은 현재 공급자의 계정을 보유하는 싱글톤 계약을 참조합니다. 제공업체를 바꾸는 것은 이 계정을 변경하는 것만큼 쉽습니다.
마지막 생각들
우리는 분명히 이상적인 온보딩 목표를 향해 나아가고 있습니다. 이상적으로는 이러한 진입하기 쉬운 지갑은 사용자와 직접적인 관계를 갖습니다. 그런 다음 Dapp은 이 문제를 완전히 무시하고 지갑과 파트너십을 체결하여 기본 로그인 지갑이 누구인지 결정할 수 있습니다.
이것이 실패한다면 내 해결책은 내 자신의 시스템을 출시하는 것이어야 합니다. 위의 아키텍처 내에서 내 자신의 소셜 로그인 공급자를 만드는 것은 어렵지 않을 것입니다. 그러나 나는 차라리 외부 공급자를 사용하고 싶습니다. 위에서 언급했듯이 dapp 제작자가 무료 키를 제어하는 경우 시스템은 완전히 분산되지 않습니다.
