Vitalik의 새로운 기술 글: 이상적인 지갑의 비전 - 크로스체인 경험에서부터 프라이버시 보호까지의 종합적 업그레이드
Liraz Siri, Yoav Weiss 및 ImToken, Metamask, OKX 개발자들의 피드백과 검토에 깊이 감사드립니다.
이더리움 인프라 스택의 핵심 계층 중 하나는 지갑이지만, 종종 코어 L1 연구자들과 개발자들에 의해 과소평가됩니다. 지갑은 사용자와 이더리움 세계 사이의 창이며, 사용자는 지갑 자체가 탈중앙화, 검열 저항성, 보안, 프라이버시 등의 속성을 갖추고 있을 때만 이러한 특성의 혜택을 누릴 수 있습니다.
최근 이더리움 지갑은 사용자 경험, 보안 및 기능 측면에서 큰 진전을 이루었습니다. 본 글에서는 이상적인 이더리움 지갑이 가져야 할 몇 가지 특성에 대한 제 개인적인 견해를 제시하고자 합니다. 이 목록은 완전한 것은 아니며, 제 암호폐러크(cypherpunk) 성향에 따라 보안과 프라이버시에 초점을 맞추고 있으며, 사용자 경험 측면에서는 분명히 미흡할 수 있습니다. 그러나 저는 사용자 경험 최적화보다 피드백을 바탕으로 배포하고 반복하는 것이 더 효과적이라고 생각하기 때문에, 보안과 프라이버시 속성에 집중하는 것이 가장 가치 있다고 봅니다.
L2 간 거래의 사용자 경험
현재 L2 간 사용자 경험을 개선하기 위한 구체적인 로드맵이 존재하며, 단기적 요소와 장기적 요소로 나뉩니다. 여기서는 오늘날 이론적으로도 구현 가능한 단기적 아이디어에 대해 다루겠습니다.
핵심 아이디어는 (i) L2 간 전송 내장과 (ii) 체인별 주소 및 결제 요청입니다. 귀하의 지갑은 아래와 같은 형식의 주소(다음 ERC 초안 스타일 따름)를 제공해야 합니다:
누군가(또는 어떤 앱)가 위와 같은 형식의 주소를 제공하면, 이를 지갑의 "수신자" 필드에 복사하여 붙여넣고 "보내기"를 클릭하면 됩니다. 지갑은 가능한 모든 방법으로 자동으로 데이터 전송을 처리해야 합니다:
-
목표 체인에 필요한 종류의 토큰이 충분히 있다면, 직접 토큰을 전송
-
다른 체인에 필요한 종류의 토큰이 있다면(또는 여러 다른 체인), ERC-7683 등의 프로토콜(실질적으로 크로스체인 DEX)을 사용해 토큰 전송
-
같은 체인 또는 다른 체인에 다른 종류의 토큰이 있다면, 탈중앙화 거래소를 통해 변환하여 올바른 체인에 올바른 종류의 화폐를 보내야 합니다. 이 과정에는 사용자의 명시적 동의가 필요합니다. 사용자는 자신이 얼마의 수수료를 지불했는지, 수취인이 얼마나 받았는지를 확인할 수 있어야 합니다.
크로스체인 주소 지원을 포함한 잠재적 지갑 인터페이스 모델
위 내용은 "주소를 복사하여 붙여넣거나 ENS(vitalik.eth@optimism.eth 등)를 통해 누군가에게 돈을 받는" 시나리오에 적용됩니다. dApp이 예치금을 요청할 경우(예: Polymarket 예시 참조), 이상적인 절차는 web3 API를 확장하여 dApp이 체인별 결제 요청을 할 수 있도록 하는 것입니다. 그러면 지갑이 그 요청을 만족시키는 방식을 자유롭게 선택할 수 있습니다. 좋은 사용자 경험을 위해서는 getAvailableBalance 요청의 표준화도 필요하며, 지갑은 사용자 자산을 어느 체인에 기본 저장할지 신중하게 고려하여 보안성과 송금 편의성을 극대화해야 합니다.
체인별 결제 요청은 QR 코드에도 포함될 수 있으며, 모바일 지갑이 이를 스캔할 수 있습니다. 대면(또는 온라인) 소비자 결제 상황에서 수취인은 QR 코드 또는 web3 API 호출을 통해 “Z 체인에서 X 단위의 Y 토큰을 원하며, 참조 ID 또는 콜백 W를 포함한다”고 표시하면, 지갑은 자유롭게 그 요청을 수행할 수 있습니다. 또 다른 선택지는청구 링크(claim link) 프로토콜로, 사용자 지갑이 자신의 체인상 계약에서 일정 금액을 인출할 수 있는 권한을 포함한 QR 코드나 URL을 생성하고, 수취인이 그 자금을 자신의 지갑으로 어떻게 옮길지 결정하는 방식입니다.
관련된 또 다른 주제는 가스(Gas) 지불입니다. ETH가 없는 L2에서 자산을 받고 해당 L2에서 트랜잭션을 보내야 한다면, 지갑은RIP-7755와 같은 프로토콜을 자동으로 사용해 ETH가 있는 체인에서 가스를 지불할 수 있어야 합니다. 만약 지갑이 사용자가 앞으로 해당 L2에서 더 많은 트랜잭션을 수행할 것으로 예상한다면, 미래의 거래가 직접 가스를 사용할 수 있도록(비용 절감 효과) DEX를 통해 소량의 ETH(예: 수십만 가스 단위)를 사서 보낼 수도 있습니다.
계정 보안
계정 보안 문제를 제가 개념화하는 방식은, 좋은 지갑이 두 가지 측면에서 모두 잘 작동해야 한다는 것입니다: (i) 지갑 개발자의 해킹이나 악의적 행위로부터 사용자를 보호하고, (ii) 사용자의 실수로부터 사용자를 보호해야 합니다.
왼쪽의 '실수'는 의도하지 않은 것입니다. 그러나 제가 이 이미지를 보았을 때 문맥에 적합하다고 느껴져 유지하기로 결정했습니다.
저의 선호하는 해결책은, 10년 이상전부터 주장해온 사회적 복구(social recovery)와 다중 서명 지갑이며, 계층적 접근 제어를 포함합니다. 사용자 계정은 두 가지 유형의 키를 가집니다: 주 키와 N개의 후견인(guardian)(예: N = 5). 주 키는 낮은 가치 및 비재무적 작업을 수행할 수 있습니다. 대부분의 후견인이 필요로 하는 작업은 (i) 전체 자산 전송과 같은 고가치 작업, 또는 (ii) 주 키나 후견인 변경입니다. 필요 시, 주 키가 시간잠금(time lock)을 통해 고가치 작업을 수행하도록 허용할 수 있습니다.
위 내용은 기본 설계이며 확장 가능합니다. 세션 키 및ERC-7715와 같은 권한 메커니즘은 다양한 앱에서 편의성과 보안 간의 균형을 맞추는 데 도움이 됩니다. 다양한 임계값에서 여러 시간잠금 지속시간을 갖는 복잡한 후견인 아키텍처는 합법적 계정 복구 성공률을 극대화하면서 도난 위험을 최소화하는 데 도움이 됩니다.
위 내용은 기본 설계이며 확장 가능합니다. 세션 키 및ERC-7715와 같은 권한 메커니즘은 다양한 앱에서 편의성과 보안 간의 균형을 맞추는 데 도움이 됩니다. 다양한 임계값에서 여러 시간잠금 지속시간을 갖는 복잡한 후견인 아키텍처는 합법적 계정 복구 성공률을 극대화하면서 도난 위험을 최소화하는 데 도움이 됩니다.
후견인은 누구 또는 무엇이어야 하나?
암호화폐에 익숙한 커뮤니티 내 숙련된 사용자에게는 친구 및 가족의 키가 현실적인 선택입니다. 각자에게 새로운 주소를 요청하면, 누가 누구인지 알 필요가 없습니다. 실제로 후견인들은 서로가 누구인지 알 필요도 없습니다. 정보를 공유하지 않는 한, 공모 가능성은 매우 낮습니다. 그러나 대부분의 신규 사용자에게는 이 옵션이 불가능합니다.
두 번째 선택지는 기관 후견인입니다. 즉, 사용자의 추가 확인(예: 확인 코드 또는 고가치 사용자에 대한 화상 통화)이 있을 때만 서명하는 서비스를 제공하는 회사입니다. 오랫동안 이런 서비스를 만들려는 시도가 있었으며, 예를 들어 2013년에 제가 CryptoCorp를 소개한 바 있습니다. 그러나 지금까지 이런 회사는 크게 성공하지 못했습니다.
세 번째 선택지는 여러 개인 장치(예: 전화, 데스크탑, 하드웨어 지갑)입니다. 이것은 작동은 하지만 초보 사용자에게는 설정과 관리가 어렵습니다. 또한 같은 위치에 있을 경우 장치가 동시에 분실되거나 도난당할 위험이 있습니다.
최근 우리는 패스키(Passkey) 기반의 접근을 더 많이 보게 되었습니다. 패스키는 장치에만 백업되므로 개인 장치 기반 솔루션에 해당하거나, 클라우드에 백업되어 복잡한혼합된 암호 보안, 기관 및 신뢰할 수 있는 하드웨어 가정에 의존하게 됩니다. 실제로 패스키는 일반 사용자에게 중요한 보안 강화 수단이지만, 사용자의 생애 자산을 보호하기에는 아직 부족합니다.
다행히 ZK-SNARK 덕분에 네 번째 선택지도 있습니다: ZK로 포장된 중앙화된 ID. 여기에는 zk-email, Anon Aadhaar, Myna Wallet 등이 포함됩니다. 기본적으로 다양한 형태(회사 또는 정부)의 중앙화된 ID를 취해 이더리움 주소로 변환하며, 사용자는 해당 중앙화된 ID를 소유하고 있다는 ZK-SNARK 증명을 생성함으로써 트랜잭션을 전송할 수 있습니다.
이 보완을 통해 이제 광범위한 선택지를 갖게 되었으며, ZK로 포장된 중앙화된 ID는 독특한 "초보자 친화성"을 가집니다.
이를 위해선 단순하고 통합된 UI 구현이 필요합니다. 사용자는 단순히 "example@gmail.com"을 후견인으로 지정할 수 있어야 하며, 지갑이 자동으로 해당 zk-email 이더리움 주소를 내부에서 생성해야 합니다. 숙련된 사용자는 자신의 이메일(그리고 그 안에 저장된 개인정보 염값)을 오픈소스 제3자 앱에 입력하여 생성된 주소가 올바른지 확인할 수 있어야 합니다. 다른 모든 지원되는 후견인 유형도 마찬가지여야 합니다.
현재 zk-email이 직면한 실제적 과제는 DKIM 서명에 의존한다는 점인데, 이는 몇 달마다 교체되는 키를 사용하며, 그 키 자체는 다른 기관에 의해 서명되지 않습니다. 이는 현재의 zk-email이 제공업체 자체를 넘어서는 일정 수준의 신뢰를 요구한다는 것을 의미합니다. 이 문제는 TLSNotary를 신뢰할 수 있는 하드웨어 내에서 사용하여 업데이트된 키를 검증함으로써 줄일 수 있지만, 여전히 이상적이진 않습니다. 이메일 제공업체가 DKIM 키를 직접 서명하기 시작하기를 바랍니다. 현재 저는 zk-email을 하나의 후견인으로 추천하지만, 대부분의 후견인으로는 권장하지 않습니다. zk-email이 손상되었을 때 자금 접근이 불가능해지는 설정에 자금을 저장하지 마십시오.
신규 사용자와 앱 내 지갑
신규 사용자는처음 가입할 때 많은 수의 후견인을 입력하기를 원하지 않습니다. 따라서 지갑은 매우 간단한 선택지를 제공해야 합니다. 자연스러운 경로는 이메일 주소 기반 zk-email, 사용자 장치에 로컬 저장된 키(가능하면 패스키), 그리고 제공업체가 보유한 백업 키를 사용하는 2-of-3 구성입니다. 사용자가 더 숙련되거나 자산을 늘릴수록, 언젠가는 더 많은 후견인을 추가하도록 유도되어야 합니다.
앱에 통합된 지갑은 불가피합니다. 암호화폐가 아닌 사용자를 끌어들이려는 앱은 사용자에게 앱 자체와 이더리움 지갑이라는 두 개의 새 앱을 동시에 다운로드하게 하여 혼란스러운 경험을 제공하고 싶지 않기 때문입니다. 그러나 많은 앱 지갑의 사용자는 모든 지갑을 연결할 수 있어야 하며, 이로써 단 하나의 "접근 제어 문제"만 고려하면 됩니다. 가장 간단한 방법은 계층적 방식을 채택하는 것으로, 빠른 "연결(linking)" 절차를 통해 사용자가 자신의 메인 지갑을 모든 앱 내 지갑의 후견인으로 설정할 수 있게 하는 것입니다. Farcaster 클라이언트 Warpcast는 이미 이를 지원하고 있습니다:
기본적으로 Warpcast 계정 복구는 Warpcast 팀이 제어합니다. 그러나 사용자는 자신의 Farcaster 계정을 "인수(take over)"하여 복구 권한을 자신의 주소로 변경할 수 있습니다.
피싱 및 기타 외부 위협으로부터 사용자 보호
계정 보안 외에도, 현대 지갑은 위조 주소, 피싱, 사기 및 기타 외부 위협을 식별하고 사용자를 보호하기 위해 많은 노력을 하고 있습니다. 동시에 많은 대응 조치는 여전히 원시적입니다. 예를 들어, 100달러를 보내든 10만 달러를 보내든, 새로운 주소로 ETH나 다른 토큰을 보낼 때 클릭을 요구하는 것과 같습니다. 여기에는 만병통치약이 없습니다. 다양한 유형의 위협에 대한 지속적인 수정과 개선의 연속입니다. 그러나 이 분야에서 계속 개선하는 데는 큰 가치가 있습니다.
프라이버시
이제 이더리움의 프라이버시를 더욱 진지하게 다룰 시점입니다. ZK-SNARK 기술은 이미 매우 발전했으며, 규제 리스크를 낮추기 위해 백도어를 의존하지 않는 프라이버시 기술(예: 프라이버시 풀)이 점점 성숙해지고 있고, Waku나 ERC-4337 mempool과 같은 2차 인프라도 점차 안정화되고 있습니다. 그러나 지금까지 이더리움에서 프라이빗 트랜잭션을 수행하려면 사용자가 명시적으로 "프라이버시 지갑"(예: Railway 또는 스텔스 주소용Umbra)을 다운로드하고 사용해야 했습니다. 이는 큰 불편을 초래하며 프라이빗 트랜잭션을 수행하려는 사람 수를 줄였습니다. 해결책은 프라이빗 트랜잭션이 지갑에 직접 통합되어야 한다는 것입니다.
간단한 구현 예시는 다음과 같습니다. 지갑은 사용자 자산의 일부를 프라이버시 풀에 "프라이빗 잔고(private balance)"로 저장할 수 있습니다. 사용자가 송금할 때는 자동으로 프라이버시 풀에서 출금합니다. 사용자가 자금을 받을 필요가 있다면, 지갑이 자동으로 스텔스 주소를 생성할 수 있습니다.
또한 지갑은 사용자가 참여하는 각 앱마다 새로운 주소를 자동으로 생성할 수 있습니다(예: DeFi 프로토콜). 입금은 프라이버시 풀에서 이루어지고, 출금은 바로 프라이버시 풀로 들어갑니다. 이를 통해 사용자의 특정 앱 내 활동이 다른 앱의 활동과 연결되지 않도록 할 수 있습니다.
이 기술의 장점은 프라이버시 있는 자산 이동뿐 아니라 프라이버시 있는 정체성(identity)에도 자연스럽게 적용된다는 점입니다. 정체성은 이미 체인상에서 발생하고 있습니다. Gitcoin Grants와 같은 정체성 기반 게이팅 앱, 토큰 기반 채팅, 이더리움 팔로우 프로토콜 등은 모두 체인상 정체성입니다. 우리는 이 생태계도 프라이버시를 보호하기를 원합니다. 즉, 사용자의 체인상 활동이 한곳에 수집되어서는 안 되며, 각 프로젝트는 별도로 저장되어야 하고, 사용자의 지갑만이 모든 증명을 한눈에 볼 수 있는 "전체 보기(global view)"를 갖춰야 합니다. 각 사용자가 여러 계정을 갖는 원생(native) 생태계는 이를 달성하는 데 도움이 되며, EAS와 Zupass와 같은 오프체인 증명 프로토콜도 마찬가지입니다.
이는 중기적으로 이더리움 프라이버시에 대한 실용적인 비전을 나타냅니다. L1과 L2에 일부 기능을 도입해 프라이버시 보호 전송을 더욱 효율적이고 신뢰성 있게 만들 수 있지만, 지금 당장도 구현 가능합니다. 일부 프라이버시 옹호자들은 모든 것에 완전한 프라이버시만이 받아들일 만하다고 주장합니다. 즉, EVM 전체를 암호화하는 것 말입니다. 저는 이것이 이상적인 장기 결과일 수 있다고 생각하지만, 프로그래밍 모델에 더 근본적인 재고를 필요로 하며, 현재로서는 이더리움에 배포할 수 있을 만큼 성숙하지 않았습니다. 우리는 충분히 큰 익명 집합(anonymity set)을 위해 기본 프라이버시가 필요합니다. 그러나 먼저 (i) 계정 간 송금과 (ii) 정체성 및 정체성 관련 용례(예: 프라이빗 증명)에 집중하는 것은 실용적인 첫걸음이며, 더 쉽게 구현 가능하며, 지갑이 지금 바로 시작할 수 있습니다.
이더리움 지갑은 데이터 지갑이 되어야 함
모든 효과적인 프라이버시 솔루션의 결과 중 하나는 결제, 정체성 또는 기타 용례에 관계없이 오프체인 데이터 저장을 사용자에게 요구한다는 점입니다. Tornado Cash에서는 각각 0.1~100 ETH 예금을 나타내는 "티켓(ticket)"을 사용자가 보관해야 한다는 점에서 명확합니다. 더 현대적인 프라이버시 프로토콜은 때때로 체인상에 암호화된 데이터를 저장하고 단일 개인키로 해독합니다. 이는 키가 유출되거나 양자 컴퓨터가 실현 가능해질 경우 데이터가 모두 공개되기 때문에 위험합니다. EAS 및 Zupass와 같은 오프체인 증명은 오프체인 데이터 저장의 필요성을 더욱 명확히 드러냅니다.
지갑은 체인상 접근 권한을 저장하는 소프트웨어일 뿐 아니라, 사용자의 개인 데이터를 저장하는 소프트웨어가 되어야 합니다. 비암호화 세계에서도 점점 이를 인식하고 있으며, 예를 들어 Tim Berners-Lee의 개인 데이터 저장 관련 최근 작업을 참고하세요. 접근 권한 제어에 대한 강력한 보장을 해결해야 하는 것처럼, 데이터 접근성과 유출 방지에 대해서도 강력한 보장을 해결해야 합니다. 아마도 이러한 솔루션을 중첩할 수 있을 것입니다. N명의 후견인이 있다면, M-of-N 비밀 공유(M-of-N secret sharing)를 사용해 데이터를 후견인들 사이에 저장하는 것입니다. 데이터는 본질적으로 보호하기 어려우며, 누군가의 데이터 공유를 무효화할 수 없기 때문에, 가능한 한 안전한 탈중앙화된 호스팅 솔루션을 제안해야 합니다.
안전한 체인 접근
현재 지갑은 RPC 제공자가 체인에 관한 모든 정보를 알려줄 것이라고 믿습니다. 이는 두 가지 측면에서 취약점입니다:
-
RPC 제공자가 가짜 정보(예: 시장 가격)를 제공함으로써 돈을 훔치려 시도할 수 있음
-
RPC 제공자가 사용자가 상호작용하는 앱 및 다른 계정에 관한 개인정보를 추출할 수 있음
이상적으로는 두 취약점을 모두 차단하고자 합니다. 첫 번째 문제를 해결하기 위해 L1과 L2의 표준화된 라이트 클라이언트가 필요하며, 이는 블록체인 합의를 직접 검증할 수 있어야 합니다. Helios는 이미 L1에 대해 이를 수행하고 있으며, 일부 구체적인 L2 지원을 위한 초기 작업도 진행 중입니다. 모든 L2를 제대로 커버하기 위해선, L2를 나타내는 구성 계약(config contract)(체인별 주소에도 사용됨)이 함수를 선언할 수 있는 표준이 필요하며, 이는 ERC-3668과 유사한 방식으로 최근 상태 루트를 가져오고, 상태 및 해당 상태 루트에 대한 영수증 증명을 검증하는 로직을 포함해야 합니다. 이를 통해 지갑이 L1과 L2에서의 어떤 상태나 이벤트든 안전하게 검증할 수 있는 범용 라이트 클라이언트를 만들 수 있습니다.
프라이버시를 위해 현재 유일한 현실적인 방법은 자신의 풀 노드를 운영하는 것입니다. 그러나 이제 L2가 등장하면서 모든 것을 실행하는 풀 노드 운영은 점점 더 어려워지고 있습니다. 여기서 라이트 클라이언트에 해당하는 것은 개인정보 검색(PIR, Private Information Retrieval)입니다. PIR은 데이터 사본을 모두 보유한 서버와 암호화된 요청을 서버에 보내는 클라이언트를 포함합니다. 서버는 모든 데이터에 대해 계산을 수행하고, 클라이언트가 필요한 데이터를 클라이언트의 키로 암호화하여 반환하며, 서버는 클라이언트가 어떤 데이터에 접근했는지 알 수 없습니다.
서버의 정직성을 유지하기 위해, 각 데이터베이스 항목 자체가 메르클 브랜치이며, 클라이언트는 라이트 클라이언트를 사용해 이를 검증할 수 있습니다.
PIR(깊은 물결 주석: 일반적으로 "개인정보 검색(Private Information Retrieval)"을 의미하며, 데이터베이스에서 정보를 검색하면서 검색된 정보를 공개하지 않도록 하는 프로토콜 또는 기술입니다.)은 계산량이 매우 큽니다. 이를 해결하기 위한 몇 가지 접근 방식이 있습니다:
-
무차별 대입(Brute force): 알고리즘 또는 전용 하드웨어의 개선으로 PIR이 충분히 빠르게 작동할 수 있습니다. 이러한 기술은 사전 처리(preprocessing)에 의존할 수 있습니다. 서버는 각 클라이언트를 위해 암호화되고 섞인 데이터를 저장하고, 클라이언트는 그 데이터를 조회할 수 있습니다. 이더리움 환경의 주요 과제는 국가처럼 빠르게 변화하는 데이터셋에 이러한 기술을 적응시키는 것입니다. 이는 실시간 계산 비용을 낮추지만, 전체 계산 및 저장 비용을 더 높일 수 있습니다.
-
프라이버시 요구 약화: 예를 들어, 각 조회 시 100만 개의 "믹스인(mixins)"만 허용하여, 서버는 클라이언트가 접근할 수 있는 백만 개의 값 중 하나를 알 수 있으나, 더 세밀한 수준은 알 수 없습니다.
-
멀티서버 PIR: 여러 서버를 사용하고, 서버들 간의 정직성 가정이 1-of-N이라면, PIR 알고리즘이 일반적으로 더 빠릅니다.
-
기밀성 대신 익명성: 요청 내용을 숨기는 대신, 믹스 네트워크를 통해 요청을 보내어 요청 발신자를 숨길 수 있습니다. 그러나 이를 효과적으로 수행하면 불가피하게 지연이 증가하여 사용자 경험을 악화시킵니다.
이더리움 환경에서 프라이버시를 극대화하면서 실용성을 유지하기 위해 적절한 기술 조합을 찾는 것은 열린 연구 과제이며, 암호학자들이 이를 시도하기를 환영합니다.
이상적인 키저장소 지갑(Keystore Wallet)
송금 및 상태 접근 외에도 L2 간 맥락에서 원활하게 작동해야 하는 또 다른 중요한 작업은 계정의 검증 구성을 변경하는 것입니다: 키를 변경(예: 복구)하거나 계정의 전체 논리를 더 깊이 변경하는 경우입니다. 여기에는 난이도 순으로 나열된 세 가지 해결책 계층이 있습니다:
-
업데이트 재생: 사용자가 구성을 변경하면, 이 변경을 승인하는 메시지가 사용자가 자산을 보유한 각 체인에서 재생됩니다. 메시지 형식과 검증 규칙이 체인 독립적으로 설정될 수 있으며, 가능한 많은 체인에서 자동 재생이 가능할 수 있습니다.
-
L1 상의 키저장소: 구성 정보가 L1에 위치하며, L2의 지갑은 L1SLOAD 또는 원격 정적 호출(remote static call)을 사용해 이를 읽습니다. 이렇게 하면 L1에서만 구성 업데이트를 수행하면 자동으로 모든 L2에 적용됩니다.
-
L2 상의 키저장소: 구성 정보가 L2에 존재하며, L2 지갑은 ZK-SNARK를 사용해 이를 읽습니다. (2)와 동일하지만, 키저장소 업데이트는 더 저렴할 수 있으나, 반대로 읽기는 더 비쌉니다.
해결책 (3)은 특히 프라이버시와 잘 결합한다는 점에서 매우 강력합니다. 일반적인 "프라이버시 솔루션"에서 사용자는 비밀 s를 갖고, 체인상에 "잎 값(leaf value)" L을 공개하며, 사용자는 L = hash(s, 1)이고 N = hash(s, 2)임을 증명합니다. 무효화자(nullifier) N이 공개되어 동일한 잎 값의 미래 사용이 실패하도록 하되, L이 공개되지 않으며, 이는 사용자의 s 보안에 달려 있습니다. 복구 친화적인 프라이버시 솔루션은 s가 온체인의 위치(예: 주소 및 저장 슬롯)이며, 사용자가 상태 조회 L = hash(sload(s), 1)을 증명해야 한다고 말합니다.
dApp 보안
사용자 보안에서 가장 취약한 고리는 일반적으로 dApp입니다. 대부분의 경우 사용자는 웹사이트를 방문하여 앱과 상호작용하며, 웹사이트는 서버에서 실시간으로 사용자 인터페이스 코드를 암묵적으로 다운로드하여 브라우저에서 실행합니다. 서버나 DNS가 해킹되면 사용자는 위조된 인터페이스를 받게 되며, 이는 사용자를 속여 임의의 작업을 수행하게 할 수 있습니다. 트랜잭션 시뮬레이션과 같은 지갑 기능은 위험을 줄이는 데 도움이 되지만, 여전히 완벽하지 않습니다.
이상적으로는 생태계를 체인상 콘텐츠 버전 관리로 전환해야 합니다. 사용자는 ENS 이름을 통해 dApp에 접근하며, 이 이름은 인터페이스의 IPFS 해시 값을 포함합니다. 인터페이스 업데이트는 멀티시그 또는 DAO로부터의 체인상 트랜잭션이 필요합니다. 지갑은 사용자가 더 안전한 체인상 인터페이스와 상호작용하고 있는지, 아니면 보안성이 낮은 Web2 인터페이스와 상호작용하고 있는지를 알려줍니다. 지갑은 사용자가 안전한 체인(예: 단계 1+, 다중 보안 검토)과 상호작용하고 있는지 여부도 알려줄 수 있습니다.
프라이버시 중심 사용자를 위해 지갑은 **편집증 모드**(paranoid mode)를 추가할 수 있으며, 이는 HTTP 요청에도 클릭 승인을 요구하며, web3 작업에만 국한되지 않습니다:
편집증 모드의 가능한 인터페이스 모델
보다 진보된 접근은 HTML + Javascript를 넘어, 전용 언어(아마 Solidity나 Vyper 위의 얇은 레이어일 수 있음)로 dApp의 비즈니스 로직을 작성하는 것입니다. 이후 브라우저는 필요한 기능의 UI를 자동 생성할 수 있습니다. OKContract은 이미 이를 수행하고 있습니다.
또 다른 방향은 암호경제적 정보 방어입니다. dApp 개발자, 보안 회사, 체인 배포자 등은 보증금(bond)을 마련하여, dApp이 해킹되거나 매우 오도하는 방식으로 사용자에게 피해를 줄 경우, 영향을 받은 사용자에게 보상을 지급(체인상 판결 DAO에 의해 확인됨)할 수 있습니다. 지갑은 사용자에게 보증금 크기에 기반한 점수를 표시할 수 있습니다.
더 먼 미래
위의 모든 내용은 전통적인 인터페이스, 즉 클릭하고 텍스트 필드에 입력하는 것을 전제로 합니다. 그러나 우리는 패러다임이 더욱 깊은 변화를 겪는 시점에 서 있습니다:
-
인공지능: 클릭하고 입력하는 패러다임에서 "당신이 원하는 일을 말하면, 로봇이 알아서 처리하는" 패러다임으로 전환될 수 있음
-
뇌-컴퓨터 인터페이스: 눈동자 추적과 같은 "온화한" 방법부터 더 직접적이거나 심지어 침습적인 기술까지 포함(참고: Neuralink 첫 환자 인터뷰)
-
클라이언트 측 적극적 방어: Brave 브라우저는 광고, 추적기 및 기타 악성 요소로부터 사용자를 적극적으로 보호합니다. 많은 브라우저, 플러그인, 암호화 지갑은 다양한 보안 및 프라이버시 위협으로부터 사용자를 보호하기 위해 전담 팀을 운영하고 있습니다. 이러한 "적극적인 수호자들"은 향후 10년 동안 더욱 강력해질 것입니다.
이 세 가지 추세는 인터페이스 작동 방식에 대한 더 깊은 재고를 이끌어낼 것입니다. 자연어 입력, 눈동자 추적 또는 궁극적으로는 더 직접적인 뇌-컴퓨터 인터페이스를 통해, 그리고 사용자의 기록(모든 데이터가 로컬에서 처리된다면 문자 메시지도 포함)을 활용하면, "지갑"은 사용자가 무엇을 원하는지 명확하고 직관적으로 이해할 수 있습니다. 이후 AI는 이러한 직관을 구체적인 "행동 계획(action plan)"으로 변환할 수 있습니다. 즉, 사용자가 원하는 일을 수행하기 위한 일련의 체인상 및 체인외 상호작용입니다. 이는 제3자 사용자 인터페이스에 대한 필요성을 크게 줄일 수 있습니다. 사용자가 실제로 제3자 앱(또는 다른 사용자)과 상호작용할 경우, AI는 사용자를 대신해 적대적 사고를 수행하여 위협을 식별하고 위협을 회피하는 행동 계획을 제안해야 합니다. 이상적으로는 이러한 AI들이 다양한 편향과 인센티브 구조를 가진 다양한 그룹에 의해 만들어지는 개방형 생태계를 가져야 합니다.
이러한 더 급진적인 아이디어들은 현재 기술이 매우 미성숙하기 때문에, 저는 현재 이에 의존하는 지갑에 자산을 맡기지는 않을 것입니다. 그러나 비슷한 일들이 미래의 분명한 흐름처럼 보이므로, 이러한 방향으로 더 적극적으로 탐색을 시작할 가치가 있습니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@VitalikButerin
