심층 분석丨미래의 블록체인 지갑은 어떤 모습이어야 할까?

이 글은 암호화 계곡 Live에 게시되었으며, 저자는 Billy Rennekamp이고, 번역자는 이한博, Edward입니다. 포럼 게시물 《범용 지갑으로서의 Cosmos Hub》에서, 나는 사용자와 블록체인 간의 미래 지향적인 관계를 제안했으며, 이는 현재의 Cosmos-SDK와 다가오는 기능의 조합을 포함합니다. "서브 개인 키"(또는 Msg 권한 부여)는 Interchain Accounts(ICS-27) 표준과 Cosmos Hub 자체의 보안성을 지칭합니다.

이는 상상력이 풍부한 제안이지만, 우리는 안전하고 여러 블록체인과 쉽게 상호작용할 수 있는 미래로 나아가야 한다고 생각하게 만듭니다. 그러나 이를 위해 어떤 단계가 필요한지, 나는 초점을 분리하고 새로운 유형의 지갑을 구축하여 계좌 조정 기능을 설립하는 길을 제안했습니다.

현재 지갑 상태

지금까지 우리는 동시에 많은 일을 시도하는 여러 지갑 솔루션을 보았습니다. 현재까지 지갑의 기능은 완전하지 않지만, 사용자가 여러 네트워크와 상호작용하기를 원하는 세계로 나아가면서, 현재 확장할 수 없는 아키텍처는 이러한 요구를 충족할 수 없습니다. 높은 수준에서 지갑의 다양한 책임은 다음과 같습니다:

• 개인 키 관리

• 애플리케이션 인터페이스

• 거래 관리

Ethereum은 EVM과 같은 튜링 완전 가상 머신이 거의 모든 종류의 애플리케이션을 허용하고, 이들이 모두 하나의 지갑에서 작동하기를 기대하기 때문에 이러한 성장의 고통을 겪었습니다. Ethereum 지갑은 다양한 애플리케이션에 대한 인터페이스를 제공하기 위해 프로토콜과 기발한 솔루션을 제안했지만, 여전히 이러한 애플리케이션이 범용 EVM 인프라에서 온다고 기대하고 있습니다. 특정 애플리케이션 블록체인의 패턴이 현실이 되면서, IBC를 통해 Ethereum이 다양한 애플리케이션의 경계를 어떻게 처리할지는 무너질 것입니다.

실행 가능한 방법은 초점을 분리하는 것입니다. 이 세 가지 작업을 독립적인 솔루션으로 존재하게 하여 각각이 자신의 고유한 작업에 집중할 수 있도록 합니다. 이는 새로운 유형의 서비스에 대한 수요를 드러내며, 나는 이를 계좌 조정 기능이라고 부릅니다.

개인 키 관리

암호학은 어렵습니다. 당신이 전문가가 아니라면 실수를 할 확률이 높고, 그 결과는 재앙적일 수 있습니다. 모든 지갑과 dApp 개발자가 내부적으로 이러한 전문 지식을 갖추고 있다고 기대하는 것은 불공평합니다. 전통적인 애플리케이션은 이를 인식하고 있으며, 종종 인증을 oAuth 표준을 사용하는 제3자에게 위임하여 해결합니다.

당신은 지갑의 유일한 진정한 책임이 당신의 개인 키를 안전하게 보장하는 것이라고 생각할 수 있습니다. 그러나 내가 다른 일반적인 기능을 소개할 때, 당신은 이것이 결코 그렇지 않다는 것을 알게 될 것입니다. 사실, 이는 종종 지갑 구축자가 가장 부족한 능력입니다. 암호학 및 보안 전문가는 업계 표준 솔루션을 개발하고 개인 키 저장의 모범 사례를 구현하는 책임이 있어야 합니다. 이는 그들의 전부 비즈니스여야 하지만, 반대로 우리는 현재의 지갑이 보안 측면에서 잘하고 있는 것을 보지만--암호학과 관련해서는 충분하지 않습니다.

개인 키 저장의 책임을 지갑에서 제거하면, 서로 다른 가정에 의존하고 서로 다른 기능을 제공하는 더 많은 종류의 보안 솔루션이 생길 수 있습니다. 현재 전통적인 소프트웨어 저장을 넘어선 많은 개인 키 솔루션이 있습니다: Ledger의 하드웨어 보안 모듈, Torus가 사용하는 Shamir 비밀 공유, ZenGo가 사용하는 임계값 솔루션, 다자간 계산 또는 새로운 제로 지식 기술. 나는 개인 키 관리의 공동 책임 공간이 완전히 개발되지 않았다고 생각합니다.

개인 키가 어떻게 저장되든, 저장 솔루션의 책임은 사실 여기까지입니다. 그것은 단지 한 가지 일을 하고, 그것을 잘해야 합니다--개인 키를 저장하는 것입니다. 개인 키에 대한 접근은 유사한 보안 권한 기술을 통해 처리되어야 합니다.

WalletConnect 또는 개인 키 관리기와 애플리케이션 간의 데이터 전송을 위한 유사한 프로토콜은 추가 권한 부여가 발생해야 하는 곳입니다.

애플리케이션 인터페이스

오늘날, 지갑의 애플리케이션 인터페이스 범위는 상당히 광범위합니다. 한편으로, 일부 지갑은 애플리케이션 기능에 대한 깊은 통합 접근을 제공합니다. Argent와 Gnosis Safe는 각 애플리케이션의 기반에서 점점 더 많은 사용자 정의 인터페이스를 지원합니다. 이것은 대부분의 Cosmos 지갑의 경로이기도 하며, 네트워크는 최소한의 스테이크 및 거버넌스 인터페이스를 기대합니다. 지갑 내에서 사용자 정의 인터페이스를 직접 제공하는 것은 더 나은 사용자 경험을 보장할 수 있지만, 지갑이 접근할 수 있는 애플리케이션의 수를 제한하고, 지갑이 새로운 애플리케이션으로 발전하는 것을 제한합니다.

반대편에서는, 대부분의 인터페이스 책임을 애플리케이션 개발자에게 넘기려는 지갑이 있습니다. 일반적으로 지갑은 web3.js 또는 cosmJS를 사용하여 API 또는 인터페이스를 애플리케이션에 연결합니다. 또는 지갑이 자체 브라우저를 포함하고 API를 통합했을 수도 있습니다(예: Mist, Metamask Mobile, Status 및 Coinbase Wallet). 그들은 또한 브라우저 확장을 활용하여 API에 연결할 수 있습니다(예: Metamask, Keplr). WalletConnect는 모바일 및 데스크탑 브라우저 간, 그리고 모바일 간의 인터페이스 전송을 허용합니다. 어떤 방식이든, 애플리케이션 개발자가 지갑 API에 접근하고 이를 활용하여 사용자에게 서명 기능을 제공해야 합니다. 이 경로는 지갑이 애플리케이션에 접근하는 병목 현상을 제거하지만, 보안성과 원활한 사용자 경험이라는 자체적인 도전을 가져옵니다.

애플리케이션이 서명 기능에 접근할 수 있도록 보장하는 안전한 권한 부여 기술을 고려해야 하며, 이는 확인 인터페이스로 인해 사용자가 퇴짜를 맞지 않도록 하며, 동시에 사용자가 실수로 서명하는 상황에 빠지지 않도록 해야 합니다. MetaMask는 이 문제를 해결하기 위해 노력해왔으며, 개인 키와 애플리케이션 간의 통신을 위한 조합 가능한 안전 인터페이스인 "Snaps"를 만들었습니다. 이는 Agoric의 수석 과학자 Mark Miller의 객체 능력 작업을 대폭 차용하였으며, 객체 능력은 환경 간에 전송할 수 있는 정확한 객체 수준의 제어를 인코딩합니다. Snaps는 애플리케이션과 개인 키 관리기 간의 연결에 필요한 보안성과 표준화를 제공하지만, 나는 Metamask가 이 아키텍처에서 더 나아가지 않았다고 생각합니다. 왜냐하면 모든 세 가지 지갑 기능이 격리되어 이 모델로 구성될 수 있기 때문입니다.

거래 관리

우리는 많은 지갑이 애플리케이션 인터페이스 제공의 중대한 책임을 맡고 있는 것을 보았지만, 나는 여전히 지금까지 지갑의 주요 책임이 개인 키 관리라고 생각합니다. 이는 지갑의 세 번째 책임인 거래 관리의 자원이 심각하게 부족하게 만듭니다. 나는 이것이 지갑의 주요 책임이 되기를 바라며, 애플리케이션 인터페이스와 개인 키 관리가 지정된 제3자의 책임이 되기를 바랍니다.

거래 관리는 애플리케이션과 서명 솔루션 간의 실제 인터페이스로 간주될 수 있습니다. 이는 일부 작업 요청이 개인 키로 서명할 수 있는 형식으로 해석되는 단계입니다. 여기에는 애플리케이션과의 통신 및 개인 키 관리와의 통신이 포함됩니다. 이 두 가지 사이에서, 서명해야 할 데이터는 해석되어야 하며, 사용자가 서명하고 있는 내용과 이유를 이해할 수 있는 방식으로 사용자에게 표시되어야 합니다. 또한, 이러한 서명 요청의 역사와 상태는 기록되어 사용자에게 제공되어야 합니다.

Ethereum을 사용할 때, 거래 관리는 매우 까다롭습니다. 기본적으로 하나의 거래 유형(eth_send)만 있지만, 데이터 필드가 포함되어 있으며, 스마트 계약을 대상으로 할 때는 무수히 많은 메서드를 참조할 수 있습니다. 운이 좋다면, 지갑은 상호작용하는 특정 계약의 ABI 파일에 접근할 수 있어 데이터 필드를 함수 이름과 매개변수로 변환할 수 있습니다. ABI 파일은 또한 지갑이 거래가 성공적으로 처리된 후 발행된 이벤트를 표시할 수 있게 해줍니다. 이는 블록 탐색기의 영역으로 들어가며, 이는 계좌 역사와 전체 네트워크의 역사를 위해 기본적으로 전념하는 완전한 서비스입니다. 그러나 지금까지 블록 탐색기는 네트워크 측면에서 대부분 단일합니다.

이 공간에서 거래에 포함될 수 있는 다양한 메시지가 있습니다. 이러한 메시지 각각은 서로 다른 기능을 가지지만, 전통적으로는 자체적으로 실행되므로 외부 ABI 파일이 필요하지 않습니다. protobuf로의 마이그레이션이 진행됨에 따라, 우리는 이러한 특성을 유지하면서 protobuf가 가져오는 모든 성능 향상을 보장하는 방법에 대한 논의가 진행되고 있습니다. 하나의 선택은 protobuf 파일에서 ABI처럼 사용하는 것이지만, 여전히 탐색 중인 많은 다른 솔루션이 있습니다.

네트워크 아키텍처가 어떻게 되든, 이는 까다로운 문제이며, 사용자가 자신이 무엇을 하고 있는지 검증할 수 있도록 보장하는 것이 중요합니다. 추가 개인 키가 이 조합에 추가될 때, 이 문제는 더욱 복잡해집니다. 일부 지갑은 공통의 니모닉과 개인 키 파생 경로에서 여러 계좌를 생성할 수 있도록 허용합니다. 이는 자신의 DeFi 계좌와 게임 계좌를 혼합하고 싶지 않은 사용자에게 유용한 기능입니다. 개인 키 파생을 통해 네트워크 간에 전환할 수 있지만, 어떤 Ethereum 지갑이 여러 니모닉과 개인 키를 지원하여 계좌를 통합할 수 있는지는 모르겠습니다(하지만 Keplr는 가능합니다). 이는 사용자에게 어떤 신원이 어떤 개인 키와 연관되어 있는지를 추적해야 하는 부담을 줍니다.

계좌 조정 기능

거래 관리는 충분한 서비스를 받지 못했으며, 네트워크의 증가와 그에 따른 개인 키의 증가로 인해 이 문제는 더욱 심각해질 것입니다. 서브 개인 키가 특정 개인 키에 계좌 능력을 할당하는 능력이 증가함에 따라, 이 문제는 기하급수적으로 증가할 것입니다. 책임 범위의 확대는 이 역할에 새로운 이름을 붙일 가치가 있습니다. 나는 새로운 유형의 지갑이 계좌 조정 서비스가 되는 것을 제안하고 싶습니다.

계좌 조정 기능의 주요 목표는 어떤 개인 키가 어떤 네트워크에서 어떤 기능을 가지고 있는지를 추적하는 것입니다--그리고 WalletConnect와 같은 프로토콜을 통해 이러한 개인 키의 서명 기능에 접근하는 방법입니다. 이는 외부의 프라이버시와 익명성을 달성하기 위해 노력해야 하지만, 사용자 관점에서 모든 dApp, 개인 키 저장 및 네트워크의 활동에 대한 완전한 개요를 제공해야 합니다. 이는 모든 가능한 공개 키를 도출하기 위해 개인 키 니모닉의 주 공개 키를 요구할 수 있습니다. 이는 계좌 조정 기능이 모든 가능한 네트워크에서 모든 가능한 계좌를 확인하여 사용자가 그곳에서 상호작용한 적이 있는지를 확인할 수 있게 합니다. 이는 개인 키가 다중 서명, 계약 기반 지갑, 그룹 모듈 또는 서브 개인 키의 일부인지 감지할 것입니다. 당신의 확인과 함께, 이는 당신의 모든 계좌를 추적하기 시작하고, 어떤 개인 키를 언제 사용할지를 기억할 것입니다.

계좌 조정 기능은 당신이 각 애플리케이션에서의 상호작용을 감사할 수 있도록 허용하며, 일관된 역사를 유지합니다--구글의 oAuth가 현재 로그인된 서비스와 장치를 알려주는 것처럼 말입니다. 궁극적으로 이는 사용자 중심의 다중 네트워크 블록 탐색기처럼 보일 것이며, 당신의 모든 개인 키를 추적하고 이를 조정할 것입니다. 이는 당신이 사용했던 또는 미래에 상호작용할 가능성이 있는 여러 네트워크에 대한 방대한 양의 정보를 필요로 할 것입니다. 이러한 정보는 다양한 출처에서 수집될 수 있으며, 당신이 직면한 애플리케이션의 종류에 따라 달라질 것입니다. 나는 대부분의 정보가 애플리케이션 자체에서 제공되기를 상상하며, WalletConnect와 같은 인터페이스를 통해 이루어질 것입니다.

계좌 조정 기능은 당신의 개인 키와 애플리케이션 사이에 단단히 자리 잡고, 양측 간의 중개자로 작용하며, 블록체인 기반 네트워크에서의 모든 상호작용을 추가할 것입니다. 그 구축은 오직 당신을 위해 서비스될 것이므로, 비록 그것이 당신의 정보 저장소를 가질지라도, 접근 여부는 전적으로 당신이 결정할 수 있습니다.