계정 구조의 재정의: 왜 3개의 키 시스템이 이상적인 해결책인가?
작성: Norswap
번역: TechFlow
나는 0xFable을 위해 지갑과 사용자 입문 방식에 관해 많은 고민을 해왔다. 아래는 나의 몇 가지 생각이다. 우리는 다음 주제들에 대해 논의할 것이다:
-
내가 이상적으로 생각하는 계정 구조;
-
보안 고려사항;
-
기존 Web3 로그인 제공업체들의 현황.
분명히, 사용자가 입문 과정에서 지갑 앱을 설치하고 복구 문구를 저장하도록 요구하는 것은 바람직하지 않다. 우리는 친숙하고 비교적 안전하며 미래지향적인 방법이 필요하다.
구조
모든 사용자는 각각 자신의 스마트 계정을 가지며, 이 계정은 세 개의 키를 포함한다:
-
장치 키——처음에는 로컬에 저장되지만, 장래에는 패스키(Passkey)/WebAuthn을 사용하기를 희망함.
-
보조 키, 예를 들어 제공업체가 소유하고 소셜 로그인으로 잠금 해제되는 키.
-
백업 키, 예를 들어 제3자가 보관하며 (단순한 이메일 첨부파일이나 Dropbox/Google Drive에 저장 가능).
이 내용이 기술적으로 단순하거나 안전하지 않아 보인다면, 아마도 당신은 제공업체들의 달콤한 말에 속고 있는 것이다. 왜냐하면 실제로 그들은 이것보다 더 안전하지 않으며(종종 더 불안전하다——예: 키 (2)와 (3) 모두 동일한 측에서 제어됨) 때문이다.
이 설정에서는 장치 키를 사용하여 사용자 상호작용 없이도 작업을 수행할 수 있다. 자산 이체 및 트랜잭션과 관련된 작업의 경우 보조 키 사용을 요구할 수 있다.
간단한 방식은 사용자가 Google/Apple/Facebook 등으로 로그인한 후 확인 프롬프트를 추가하는 것이다. 이를 통해 입문이 쉬워진다. 그러나 사용자가 더 높은 보안을 원한다면 전통적인 EOA로 이 키를 대체할 수 있다. 또한 어떤 두 개의 키 조합으로도 백업 키를 교체할 수 있으며, 백업 키는 클라우드에 저장된 파일일 뿐이다.
보안 분석
이 방식은 얼마나 안전한가? 대부분의 경우 안전하다. 자금 손실이 발생하려면 두 개의 장치 또는 개체가 동시에 침해되어야 하기 때문이다.
주요 위험 요소는 보안을 낮출 수 있는 구성 실수들이다. 예를 들어, Google 드라이브에 백업 키를 저장하면서 보조 키를 Google 계정에 할당하는 경우. 혹은 장치 키와 동일한 위험을 갖는 핫월렛을 보조 키로 사용하는 경우. 사용자가 백업을 분실할 수도 있다. 정기적으로 장치 키를 교체하도록 유도하여 사용자가 백업 키를 찾도록 하는 것이 좋다.
백업 키가 공개적으로 저장되면 도난당하기 매우 쉬우며, 이는 디스크상에서 키를 암호화하고 메모리 내에서 비밀번호로 해독해야 하는 핫월렛보다 더 나쁘다. 어쨌든 패스키(passkey)의 도입(장치 인증을 통해 앱에 로그인 가능하게 함)은 이 문제를 해결할 것이다.
소셜 로그인은 제공업체를 신뢰한다는 것을 의미한다. 제공업체는 본질적으로 마음대로 사용할 수 있는 키를 가지지만, 당신이 소셜 계정으로 로그인한 후에만 당신의 요청에 따라 사용하겠다고 약속하는 것이다. 마지막으로, 보조 키가 dapp 제작자가 제공하거나 확인 프롬프트가 없는 경우, dapp 제작자는 쉽게 사용자를 속일 수 있음을 기억하라(왜냐하면 그들은 장치 키를 가진 프론트엔드를 작성하고 보조 키를 소유하거나 제어할 수 있기 때문이다).
기존 제공업체 현황
현재 누가 이런 서비스를 제공하고 있는가? 내가 아는 한 아무도 없다. 문제는 보통 백업 키가 아예 없거나, 동일한 실체가 보관하고 있다는 점이다(예: Coinbase Wallet).
시장은 대체로 두 부류로 나뉜다:
-
스마트 계정을 사용하거나 MPC(다자간 계산, 암호학 기술)을 이용해 여러 키를 단일 EOA로 결합하는 다중 키 솔루션을 통합 제공하는 업체들.
-
사용자의 키를 대신 보관해주고, 로그인 후 서명을 허용하는 저수준 제공업체들.
여기에는 많은 풀스택 제공업체들이 있다: Particle Network, Privy, Alembic Tech, Magic, Web3Auth, Turnkey, Dynamic, 0xPass, Fireblocks, Portal, Capsule, ZeroDev, Keyp, Circle Developers.
키 보관 제공업체 예시: Lit Protocol, Amazon.
맞다, 이런 것들이 많이 존재한다. 사실상 서로 큰 차이가 없다. 비즈니스 모델이 투명할 경우, 일반적으로 사용자당 연간 0.02~0.05달러 정도의 요금을 부과한다. 개인적으로는 꽤 합리적인 수준이라고 생각한다.
흥미롭게도, 이 모든 서비스들은 개발 도구로서 포지셔닝되고 있다. 아직 어느 회사도 이러한 기술을 사용해 사용자의 주요 지갑이 되려는 시도를 하고 있지 않다.
물론 기존 dapp들과 협력하려면 여전히 지갑 앱 설치가 필요하다. 따라서 시스템의 이점은 복구 문구 제거로 줄어든다. 하지만 dapp들이 당신을 가장 쉬운 입문 방식으로 홍보하게 만들 수도 있다(심지어 지갑 설치 없이도 당신을 통합한다면). 그러면 당신은 사용자를 얻고, dapp은 무료로 간편한 입문을 제공받는다. 윈윈이다.
제공업체에 대한 우려
내가 이상적으로 생각하는 구조를 구현하지 않는다는 점 외에도, 이러한 솔루션들은 종종 REST API나 일부 MPC 계산과 같은 중앙 집중화 요소를 도입한다. 만약 해당 업체가 폐업하면 직접 계산을 수행할 수 없게 된다(오픈소스 공개라도 되어 있는가? 감사되었는가?).
또한 제공업체와의 협업을 중단했을 때 어떻게 되는지도 명확하지 않다. 그들은 사용자의 키를 (일부) 보유하고 있기 때문이다! 이것은 내게 롤업-애즈-어-서비스(RaaS)에 대한 우려와 매우 유사하다.
이후 한 RaaS 창립자가 나에게 말했다. 즉, 쉽게 탈퇴할 수 있도록 허용하는 것과 창립자가 사용자를 기만하는 것을 방지하는 사이에는 균형이 있다고. (이는 RaaS 생태계에 부정적인 영향을 미칠 것이다.)
다음은 위 아키텍처를 활용해 제공업체를 쉽게 전환하는 방법이다: 사용자가 체인 상에 자신의 소셜 계정 해시(예: [email protected])를 제출한다. 각 소셜 로그인 제공업체는 자체의 비밀키를 갖는다(각 사용자마다 별도의 키를 가질 필요는 없으며, 일반적으로 더 안전하지도 않다). 스마트 계정은 현재 제공업체의 계정을 저장하는 싱글톤(singleton) 컨트랙트를 참조한다. 제공업체를 전환하는 것은 단지 이 계정을 변경하는 것만으로 간단하다.
마지막 생각
우리는 분명히 이상적인 온보딩 목표를 향해 나아가고 있다. 이상적인 상황은 이러한 쉬운 입문 지갑들이 사용자와 직접 관계를 맺는 것이다. 그러면 dapp들은 이 문제를 완전히 무시하고, 기본 로그인 지갑 파트너십을 맺기만 하면 된다.
그렇게 하지 못한다면, 내 해결책은 스스로 시스템을 출시하는 것이다——위 아키텍처를 기반으로 자신만의 소셜 로그인 제공업체를 만드는 것은 어렵지 않다. 그러나 나는 외부 제공업체를 사용하는 것을 '선호'한다. 위에서 언급했듯이, dapp 제작자가 무료 키를 통제한다면 시스템은 완전히 탈중앙화되지 않는다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@norswap
