Vitalik 기술 신문: 이상적인 지갑의 비전 - 크로스 체인 경험에서 프라이버시 보호까지의 전방위 업그레이드

저자: Vitalik Buterin

특별히 Liraz Siri, Yoav Weiss, 그리고 ImToken, Metamask, OKX 개발자들의 피드백과 검토에 감사드립니다.

이더리움 인프라 스택의 핵심 레이어 중 하나는 지갑이지만, 종종 핵심 L1 연구자와 개발자들에 의해 과소평가됩니다. 지갑은 사용자와 이더리움 세계 사이의 창구이며, 사용자는 지갑 자체도 이러한 속성을 가지고 있는 한 이더리움 및 그 애플리케이션이 제공하는 모든 탈중앙화, 검열 저항, 보안, 프라이버시 또는 기타 속성으로부터 혜택을 받을 수 있습니다.

최근 우리는 이더리움 지갑이 사용자 경험, 보안 및 기능 개선에 있어 큰 발전을 이루는 것을 보았습니다. 이 글의 목적은 이상적인 이더리움 지갑이 가져야 할 몇 가지 특성에 대한 제 개인적인 견해를 제시하는 것입니다. 이는 완전한 목록이 아니며, 보안과 프라이버시에 중점을 두는 저의 암호 해커 성향을 반영하고 있으며, 사용자 경험 측면에서 거의 확실히 불완전합니다. 그러나 저는 사용자 경험을 최적화하는 데 있어 단순히 피드백에 따라 배포하고 반복하는 것이 더 효과적이라고 생각하기 때문에 보안 및 프라이버시 속성에 집중하는 것이 가장 가치 있다고 생각합니다.

L2 간 거래의 사용자 경험

현재 L2 간 사용자 경험을 개선하기 위한 점점 더 상세한 로드맵이 있으며, 이 로드맵에는 단기 및 장기 부분이 있습니다. 여기서 저는 단기 부분에 대해 이야기할 것입니다: 오늘날 이론적으로 여전히 구현할 수 있는 아이디어입니다.

핵심 아이디어는 (i) 내장된 L2 간 전송과 (ii) 체인 특정 주소 및 지불 요청입니다. 귀하의 지갑은 다음과 같은 형식의 주소를 제공할 수 있어야 합니다(이 ERC 초안 스타일을 따릅니다):

누군가(또는 특정 애플리케이션)가 귀하에게 이러한 형식의 주소를 제공할 때, 귀하는 이를 지갑의 "수신자" 필드에 붙여넣고 "전송"을 클릭할 수 있어야 합니다. 지갑은 가능한 모든 방법으로 전송 데이터를 자동으로 처리해야 합니다:

• 목표 체인에 필요한 유형의 토큰이 충분히 있는 경우, 토큰을 직접 전송합니다.

• 다른 체인에 필요한 유형의 토큰이 있는 경우(또는 여러 다른 체인), ERC-7683 등의 프로토콜(실제로는 크로스 체인 DEX)을 사용하여 토큰을 전송합니다.

• 동일한 체인 또는 다른 체인에 다른 유형의 토큰이 있는 경우, 탈중앙화 거래소를 사용하여 이를 올바른 체인에서 올바른 유형의 통화로 변환하고 전송합니다. 이는 사용자에게 명확한 허가를 요구해야 합니다: 사용자는 자신이 지불한 수수료와 수신자가 받은 수수료를 볼 수 있어야 합니다.

크로스 체인 주소 지원을 갖춘 가능한 지갑 인터페이스 모델

위의 내용은 "귀하가 주소를 복사하여 붙여넣습니다(또는 ENS, 예: vitalik.eth @ optimism.eth) 누군가가 귀하에게 지불합니다" 사용 사례에 적용됩니다. 만약 dapp이 예치금을 요청한다면(예: 이 Polymarket 예시 참조), 이상적인 프로세스는 web3 API를 확장하고 dapp이 체인 특정 지불 요청을 발행할 수 있도록 하는 것입니다. 그런 다음 귀하의 지갑은 필요한 방식으로 해당 요청을 충족할 수 있습니다. 사용자 경험을 좋게 하려면 getAvailableBalance 요청을 표준화해야 하며, 지갑은 사용자의 자산을 최대한 안전하고 전송 편리성을 높이기 위해 어떤 체인에 기본적으로 저장할지를 신중하게 고려해야 합니다.

체인 특정 지불 요청은 QR 코드에 포함될 수도 있으며, 모바일 지갑은 QR 코드를 스캔할 수 있습니다. 대면(또는 온라인) 소비자 결제 시나리오에서 수신자는 "나는 체인에서 X 단위의 토큰 Y Z를 원하며, 참조 ID 또는 콜백 W가 포함되어 있습니다"라는 QR 코드를 발행하거나 web3 API 호출을 합니다. 그러면 지갑은 해당 요청을 자유롭게 충족할 수 있습니다. 또 다른 선택지는 클레임 링크 프로토콜로, 사용자의 지갑이 QR 코드 또는 URL을 생성하여 그들의 체인 계약에서 일정량의 자금을 인출할 수 있는 클레임 권한을 포함합니다. 수신자의 작업은 이러한 자금을 자신의 지갑으로 어떻게 이전할지를 파악하는 것입니다.

또 다른 관련 주제는 가스 지불입니다. 만약 귀하가 ETH가 없는 L2에서 자산을 받고 해당 L2에서 거래를 전송해야 한다면, 지갑은 자동으로 프로토콜(예: RIP-7755)을 사용하여 체인에서 가스를 지불할 수 있어야 합니다. 귀하가 ETH를 가지고 있는 곳에서. 만약 지갑이 귀하가 향후 L2에서 더 많은 거래를 하기를 원한다면, 또한 DEX를 사용하여 예를 들어 수백만 가스의 ETH를 전송해야 하며, 향후 거래는 그곳에서 직접 가스를 사용할 수 있어야 합니다(이렇게 하는 것이 더 저렴하기 때문입니다).

계정 보안

제가 계정 보안 문제를 개념화하는 한 가지 방법은, 좋은 지갑이 두 가지 측면에서 동시에 작동해야 한다는 것입니다: (i) 사용자로부터 지갑 개발자의 해킹이나 악의적인 공격으로부터 보호하고, (ii) 사용자가 자신의 실수로부터 보호합니다.

왼쪽의 "실수"는 의도치 않은 것입니다. 그러나 제가 이를 보았을 때, 문맥에 매우 적합하다는 것을 깨달았고, 그래서 이를 유지하기로 결정했습니다.

저의 선호하는 해결책은, 10년 이상 지속되어 온 소셜 복구 및 다중 서명 지갑으로, 계층적 접근 제어를 갖추고 있습니다. 사용자의 계정에는 두 개의 키 레이어가 있습니다: 주 키와 N명의 보호자(예: N = 5). 주 키는 낮은 가치와 비재무적 작업을 수행할 수 있습니다. 대부분의 보호자는 (i) 계정의 전체 가치를 전송하는 것과 같은 고가치 작업을 수행하거나 (ii) 주 키 또는 보호자를 변경해야 합니다. 필요할 경우 주 키가 시간 잠금을 통해 고가치 작업을 수행할 수 있도록 허용할 수 있습니다.

위의 내용은 기본 설계이며, 확장할 수 있습니다. 세션 키 및 ERC-7715와 같은 권한 메커니즘은 다양한 애플리케이션의 편리함과 보안 간의 균형을 지원하는 데 도움이 될 수 있습니다. 서로 다른 임계값에서 여러 시간 잠금 기간을 가진 복잡한 보호자 구조는 합법적인 계정을 성공적으로 복구할 기회를 극대화하면서 도난 위험을 최소화하는 데 도움이 될 수 있습니다.

보호자는 누구 또는 무엇이어야 하는가?

경험이 풍부한 암호화폐 사용자 커뮤니티의 경험이 풍부한 암호 사용자에게 실행 가능한 선택은 친구 및 가족의 키입니다. 만약 여러분이 모든 사람에게 새로운 주소를 제공해 달라고 요청한다면, 아무도 그들이 누구인지 알 필요가 없습니다 - 사실, 여러분의 보호자는 서로가 누구인지 알 필요조차 없습니다. 그들이 여러분에게 누설하지 않는 한, 그들이 공모할 가능성은 매우 낮습니다. 그러나 대부분의 신규 사용자에게는 이 옵션이 사용할 수 없습니다.

두 번째 선택은 기관 보호자입니다: 요청을 받은 후에만 거래를 서명하는 서비스를 제공하는 회사입니다: 예를 들어 확인 코드, 또는 고가치 사용자를 위한 비디오 통화. 사람들은 오랫동안 이러한 것을 만들려고 노력해왔습니다, 예를 들어, 2013년에 CryptoCorp를 소개했습니다. 그러나 지금까지 이러한 회사들은 그리 성공적이지 않았습니다.

세 번째 선택은 여러 개인 장치(예: 전화, 데스크탑, 하드웨어 지갑)입니다. 이는 작동할 수 있지만, 경험이 없는 사용자에게는 설정하고 관리하기가 어렵습니다. 또한 장치가 동시에 분실되거나 도난당할 위험이 있으며, 특히 같은 장소에 있을 때 더욱 그렇습니다.

최근 우리는 만능 키 기반의 솔루션을 더 많이 보기 시작했습니다. 키는 사용자의 장치에만 백업할 수 있어 개인 장치 솔루션이 되며, 클라우드에 백업할 수도 있어 보안은 복잡한혼합 비밀번호 보안, 기관 및 신뢰할 수 있는 하드웨어 가정에 의존합니다. 실제로, 키는 일반 사용자에게 귀중한 보안 이점을 제공하지만, 그것만으로는 사용자의 평생 저축을 보호하기에는 부족합니다.

다행히도, ZK-SNARK 덕분에 우리는 네 번째 선택지를 갖게 되었습니다: ZK 포장된 중앙화 ID. 이러한 유형에는 zk-email, Anon Aadhaar, Myna Wallet 등이 포함됩니다. 기본적으로, 여러분은 다양한 형태(회사 또는 정부)의 중앙화 ID를 취득하고 이를 이더리움 주소로 변환할 수 있으며, 이를 통해 중앙화 ID를 소유하고 있다는 증명을 생성하여 거래를 보낼 수 있습니다.

이 보충을 통해 우리는 이제 광범위한 선택지를 갖게 되었으며, ZK 포장된 중앙화 ID는 독특한 "신규 사용자 친화성"을 가지고 있습니다.

이를 위해서는 간소화되고 통합된 UI를 통해 실현해야 합니다: 사용자는 단지 "example@gmail.com"을 보호자로 지정하고, 시스템은 자동으로 해당 zk-email 이더리움 주소를 생성해야 합니다. 고급 사용자는 자신의 이메일(그리고 해당 이메일에 저장된 프라이버시 소금)을 오픈 소스 제3자 애플리케이션에 입력하고 생성된 주소가 올바른지 확인할 수 있어야 합니다. 다른 지원되는 보호자 유형에 대해서도 마찬가지여야 합니다.

오늘날 zk-email이 직면한 실제 도전 중 하나는 DKIM 서명에 의존한다는 것입니다. 이 서명은 몇 개월마다 교체되는 키를 사용하며, 이러한 키는 다른 기관에 의해 서명되지 않습니다. 이는 오늘날 zk-email이 제공자 본인 이상의 신뢰 요구 사항을 가지고 있음을 의미합니다; zk-email이 신뢰할 수 있는 하드웨어 내에서 TLSNotary를 사용하여 업데이트된 키를 검증한다면 이러한 상황을 줄일 수 있지만, 이는 이상적이지 않습니다. 이메일 제공자가 DKIM 키를 직접 서명하기 시작하기를 바랍니다. 오늘날, 저는 zk-email을 보호자로 사용하는 것을 권장하지만, 대부분의 보호자에게는 권장하지 않습니다: zk-email이 손상되면 자금을 사용할 수 없는 설정이 됩니다.

신규 사용자 및 애플리케이션 내 지갑

신규 사용자는 실제로 첫 등록 시 많은 보호자를 입력하기를 원하지 않습니다. 따라서 지갑은 그들에게 매우 간단한 선택을 제공해야 합니다. 자연스러운 경로는 그들의 이메일 주소에서 zk-email, 사용자 장치에 로컬로 저장된 키(아마도 만능 키), 그리고 제공자가 보유한 백업 키를 사용하여 2-of-3 선택을 하는 것입니다. 사용자가 더 경험이 쌓이거나 더 많은 자산을 축적함에 따라, 어느 시점에서 그들에게 더 많은 보호자를 추가하라는 알림을 제공해야 합니다.

애플리케이션에 통합된 지갑은 불가피합니다. 비암호화 사용자들을 유치하려는 애플리케이션은 사용자가 두 개의 새로운 애플리케이션(애플리케이션 자체와 이더리움 지갑)을 동시에 다운로드하는 것을 원하지 않기 때문입니다. 그러나 많은 애플리케이션 지갑의 사용자는 모든 지갑을 연결할 수 있어야 하며, 이를 통해 단 하나의 "접근 제어 문제"만 걱정하면 됩니다. 가장 간단한 방법은 계층적 접근 방식을 채택하여 빠른 "링크" 프로세스를 통해 사용자가 주 지갑을 모든 애플리케이션 내 지갑의 보호자로 설정할 수 있도록 하는 것입니다. Farcaster 클라이언트 Warpcast는 이미 이를 지원하고 있습니다:

기본적으로, 귀하의 Warpcast 계정 복구는 Warpcast 팀에 의해 제어됩니다. 그러나 귀하는 귀하의 Farcaster 계정을 "인수"하고 복구를 귀하의 주소로 변경할 수 있습니다.

사용자를 사기 및 기타 외부 위협으로부터 보호하기

계정 보안 외에도, 오늘날의 지갑은 가짜 주소, 피싱, 사기 및 기타 외부 위협을 식별하고 사용자를 이러한 위협으로부터 보호하기 위해 많은 작업을 수행하고 있습니다. 동시에, 많은 대책은 여전히 상당히 원시적입니다: 예를 들어, ETH 또는 다른 토큰을 새로운 주소로 전송하기 위해 클릭을 요구하는 것입니다. 여기에는 단일한 만병통치약이 존재하지 않습니다. 이는 다양한 범주의 위협에 대한 일련의 느린 지속적인 수정 및 개선입니다. 그러나 여기에서 개선을 위해 계속 노력하는 것은 많은 가치를 가지고 있습니다.

프라이버시

이제 이더리움의 프라이버시를 더욱 진지하게 다룰 때입니다. ZK-SNARK 기술은 이제 매우 발전하여 후방 통로에 의존하지 않고 규제 위험을 줄이는 프라이버시 기술(예: 프라이버시 풀)이 점점 더 성숙해지고 있으며, Waku 및 ERC-4337 메모리풀과 같은 2차 인프라도 점차 안정화되고 있습니다. 그러나 지금까지 이더리움에서 개인 전송을 수행하려면 사용자가 명시적으로 "프라이버시 지갑"을 다운로드하고 사용해야 했습니다, 예를 들어 Railway (또는 은신 주소 용 Umbra). 이는 개인 전송을 수행할 의향이 있는 사람의 수를 크게 줄이고 큰 불편을 초래합니다. 해결책은 개인 전송이 지갑에 직접 통합되어야 한다는 것입니다.

간단한 구현은 다음과 같습니다. 지갑은 사용자의 자산 일부를 "개인 잔액"으로 프라이버시 풀에 저장할 수 있습니다. 사용자가 전송을 수행할 때, 자동으로 프라이버시 풀에서 나옵니다. 사용자가 자금을 수신해야 하는 경우, 지갑은 자동으로 은신 주소를 생성할 수 있습니다.

또한, 지갑은 사용자가 참여하는 각 애플리케이션에 대해 자동으로 새로운 주소를 생성할 수 있습니다(예: DeFi 프로토콜). 예치금은 프라이버시 풀에서 나오고, 인출금은 직접 프라이버시 풀로 들어갑니다. 이는 사용자가 한 애플리케이션에서의 활동을 다른 애플리케이션에서의 활동과 연결되지 않도록 합니다.

이 기술의 장점은 자산 이동의 프라이버시를 보호하는 자연스러운 방법일 뿐만 아니라, 신원의 프라이버시를 보호하는 자연스러운 방법이기도 하다는 것입니다. 신원은 체인에서 발생합니다: 신원 증명이 필요한 애플리케이션(예: Gitcoin Grants), 토큰 기반 채팅, 이더리움 준수 프로토콜 등은 모두 체인상의 신원입니다. 우리는 이 생태계가 또한 프라이버시를 보호하기를 바랍니다. 이는 사용자의 체인 상 활동이 한 곳에 수집되지 않아야 함을 의미합니다: 각 프로젝트는 개별적으로 저장되어야 하며, 사용자의 지갑만이 모든 증명을 동시에 볼 수 있는 "전역 보기"를 가져야 합니다. 각 사용자가 여러 계정을 갖는 원주율 생태계는 이를 달성하는 데 도움이 되며, EAS 및 Zupass와 같은 체인 외 증명 프로토콜도 마찬가지입니다.

이는 중기적으로 이더리움 프라이버시의 실용적인 비전을 나타냅니다. L1 및 L2에서 프라이버시 보호 전송을 보다 효율적이고 신뢰할 수 있게 만들기 위해 몇 가지 기능을 도입할 수 있지만, 지금 당장 구현할 수 있습니다. 일부 프라이버시 옹호자들은 모든 것의 완전한 프라이버시만이 수용 가능한 것이라고 주장합니다: EVM 전체를 암호화하는 것입니다. 저는 이것이 이상적인 장기 결과일 수 있다고 생각하지만, 이는 프로그래밍 모델에 대한 보다 근본적인 재고가 필요하며, 현재 이더리움에 배포할 준비가 된 성숙한 수준에 도달하지 않았습니다. 우리는 충분히 큰 익명 집단을 얻기 위해 기본적으로 프라이버시가 필요합니다. 그러나 먼저 (i) 계정 간 전송 및 (ii) 신원 및 신원 관련 사용 사례(예: 개인 증명)에 집중하는 것이 실용적인 첫 걸음이며, 이는 더 쉽게 구현할 수 있으며, 지갑은 지금 바로 시작할 수 있습니다.

이더리움 지갑은 데이터 지갑이 되어야 한다

모든 유효한 프라이버시 솔루션의 결과는, 지불, 신원 또는 기타 사용 사례에 관계없이 사용자가 체인 외 데이터를 저장할 필요가 있다는 것입니다. 이는 Tornado Cash에서 분명하게 나타나며, 사용자가 0.1-100 ETH 예치를 나타내는 "영수증"을 저장해야 합니다. 더 현대적인 프라이버시 프로토콜은 때때로 체인에 암호화된 데이터를 저장하고 단일 개인 키로 이를 해독합니다. 이는 위험이 있습니다. 왜냐하면 키가 유출되거나 양자 컴퓨터가 실현 가능해지면 데이터가 모두 공개되기 때문입니다. EAS 및 Zupass와 같은 체인 외 증명은 체인 외 데이터 저장의 필요성을 더욱 분명히 합니다.

지갑은 단순히 체인 상 접근 권한을 저장하는 소프트웨어가 아니라, 사용자의 개인 데이터를 저장하는 소프트웨어가 되어야 합니다. 비암호화 세계도 점점 더 이를 인식하고 있습니다, 예를 들어 Tim Berners-Lee의 최근 개인 데이터 저장 작업을 참조하십시오. 우리는 강력한 접근 권한 제어를 보장하는 문제를 해결해야 할 뿐만 아니라, 강력한 데이터 접근 가능성과 유출 방지를 보장하는 문제도 해결해야 합니다. 아마도 이러한 솔루션은 함께 겹칠 수 있습니다: 만약 여러분이 N명의 보호자를 가지고 있다면, 이 N명의 보호자 사이에서 M-of-N 비밀 공유를 사용하여 데이터를 저장하십시오. 데이터는 본질적으로 보호하기 더 어렵습니다. 왜냐하면 누군가의 데이터 지분을 철회할 수 없기 때문입니다. 그러나 우리는 가능한 한 안전한 탈중앙화 호스팅 솔루션을 제안해야 합니다.

안전한 체인 접근

오늘날 지갑은 RPC 제공자가 체인에 대한 모든 정보를 제공한다고 믿고 있습니다. 이는 두 가지 측면에서 취약점입니다:

1. RPC 제공자는 돈을 훔치기 위해 그들에게 잘못된 정보를 제공하려 할 수 있습니다, 예를 들어 시장 가격에 대한 정보입니다.

2. RPC 제공자는 사용자가 상호작용하는 애플리케이션 및 기타 계정에 대한 개인 정보를 추출할 수 있습니다.

이상적으로는, 우리는 이 두 가지 취약점을 막고 싶습니다. 첫 번째 문제를 해결하기 위해, 우리는 L1 및 L2의 표준화된 경량 클라이언트가 필요하며, 이들은 블록체인 합의를 직접 검증할 수 있습니다. Helios는 L1에서 그렇게 했으며, 특정 L2를 지원하기 위한 초기 작업을 계속하고 있습니다. 모든 L2를 올바르게 커버하기 위해, 우리는 L2를 대표하는 구성 계약이 함수 선언을 할 수 있는 표준이 필요합니다. 이는 ERC-3668와 유사한 방식으로, 최근 상태 루트를 가져오고 해당 루트에 대한 증명을 검증하는 논리를 포함할 수 있습니다. 이렇게 하면 우리는 지갑이 L1 및 L2에서 모든 상태나 이벤트를 안전하게 검증할 수 있는 범용 경량 클라이언트를 가질 수 있습니다.

프라이버시를 위해, 오늘날 유일한 현실적인 방법은 자신의 전체 노드를 실행하는 것입니다. 그러나 현재 L2가 사람들의 시야에 들어오면서 모든 것을 실행하는 전체 노드를 운영하는 것이 점점 더 어려워지고 있습니다. 여기서 경량 클라이언트와 유사한 것은 개인 정보 검색(PIR)입니다. PIR은 모든 데이터 사본을 저장하는 서버와 서버에 암호화된 요청을 보내는 클라이언트를 포함합니다. 서버는 모든 데이터에 대한 계산을 수행하고 클라이언트가 필요한 데이터를 반환하며, 클라이언트의 키로 암호화하여 클라이언트가 어떤 데이터에 접근했는지를 서버에 알리지 않습니다.

서버의 정직성을 유지하기 위해, 각 데이터베이스 프로젝트 자체가 Merkle 브랜치이므로 클라이언트는 경량 클라이언트를 사용하여 이를 검증할 수 있습니다.

PIR의 계산량은 매우 큽니다. 이 문제를 해결하는 방법에는 여러 가지가 있습니다:

• 무차별 대입: 알고리즘이나 전용 하드웨어의 개선이 PIR을 충분히 빠르게 실행할 수 있게 할 수 있습니다. 이러한 기술은 사전 처리에 의존할 수 있습니다: 서버는 각 클라이언트를 위해 암호화되고 섞인 데이터를 저장할 수 있으며, 클라이언트는 해당 데이터를 쿼리할 수 있습니다. 이더리움 환경에서 주요 도전 과제는 이러한 기술을 빠르게 변화하는 데이터 세트에 적응시키는 것입니다(국가처럼). 이는 실시간 계산 비용을 낮출 수 있지만, 총 계산 및 저장 비용을 높일 가능성이 큽니다.

• 프라이버시 요구 사항 완화: 예를 들어, 각 조회마다 최대 100만 개의 "믹스인"만 허용되므로 서버는 클라이언트가 접근할 수 있는 백만 개의 가능한 값을 알 수 있지만, 더 세부적인 정보는 알 수 없습니다.

• 다중 서버 PIR: 여러 서버를 사용하고 이 서버들 간의 정직성 가정이 1-of-N인 경우, PIR 알고리즘은 일반적으로 더 빠릅니다.

• 익명성 대신 기밀성: 요청을 혼합 네트워크를 통해 전송하여 요청의 발신자를 숨길 수 있지만, 요청의 내용을 숨기지는 않습니다. 그러나 이렇게 효과적으로 수행하는 것은 불가피하게 지연을 증가시켜 사용자 경험을 악화시킵니다.

이더리움 환경에서 프라이버시를 극대화하면서 실용성을 유지하기 위한 올바른 기술 조합을 찾는 것은 열린 연구 문제이며, 저는 암호학자들이 이를 시도하기를 환영합니다.

이상적인 키 저장소 지갑

전송 및 상태 접근 외에도, L2 간 맥락에서 원활하게 작동해야 하는 또 다른 중요한 작업 흐름은 계정의 검증 구성을 변경하는 것입니다: 키를 변경하는 경우(예: 복구) 또는 계정의 전체 논리를 더 깊이 변경하는 경우입니다. 여기에는 세 가지 계층의 솔루션이 있으며, 난이도에 따라 증가하는 순서로 배열됩니다:

1. 재생 업데이트: 사용자가 구성을 변경할 때, 이 변경을 승인하는 메시지가 사용자가 자산을 보유하고 있는 각 체인에서 재생됩니다. 메시지 형식과 검증 규칙은 체인에 독립적일 수 있으므로 가능한 한 많은 체인에서 자동으로 재생될 수 있습니다.

2. L1의 키 저장소: 구성 정보는 L1에 위치하며, L2의 지갑은 L1SLOAD로 이를 읽습니다. 이렇게 하면 L1에서 구성만 업데이트하면 구성은 자동으로 적용됩니다.

3. L2의 키 저장소: 구성 정보는 L2에 존재하며, L2의 지갑은 ZK-SNARK로 이를 읽습니다. 이는 (2)와 동일하지만, 키 저장소 업데이트가 더 저렴할 수 있는 반면, 읽기는 더 비쌀 수 있습니다.

솔루션 (3)은 특히 강력합니다. 왜냐하면 이는 프라이버시와 잘 결합될 수 있기 때문입니다. 일반적인 "프라이버시 솔루션"에서 사용자는 비밀 s를 소유하고 있으며, 체인에 "리프 값" L을 게시하고, 사용자는 L = hash(s, 1) 및 N = hash(s, 2)를 증명해야 합니다. 유효하지 않은 기호 N이 게시되어 동일한 리프의 미래 지출이 실패하도록 보장하며, 이는 사용자의 s 보안에 의존합니다. 복구 친화적인 프라이버시 솔루션은 s가 온체인 위치(예: 주소 및 저장 슬롯)이며, 사용자가 상태 쿼리를 증명해야 한다고 말합니다: L = hash(sload(s), 1).

Dapp 보안

사용자 보안의 가장 약한 고리는 종종 dapp입니다. 대부분의 경우, 사용자는 웹사이트에 접근하여 애플리케이션과 상호작용하며, 웹사이트는 서버에서 실시간으로 사용자 인터페이스 코드를 다운로드하여 브라우저에서 실행합니다. 서버가 해킹되거나 DNS가 해킹되면 사용자는 가짜 인터페이스를 얻게 되어 사용자가 임의의 작업을 수행하도록 유도할 수 있습니다. 거래 시뮬레이션과 같은 지갑 기능은 위험을 줄이는 데 매우 유용하지만, 여전히 완벽하지는 않습니다.

이상적으로는, 우리는 생태계를 체인 상 콘텐츠 버전 관리로 전환하고 싶습니다: 사용자는 ENS 이름을 통해 dapp에 접근하며, 해당 이름은 인터페이스의 IPFS 해시를 포함합니다. 인터페이스를 업데이트하려면 다중 서명 또는 DAO의 체인 상 거래가 필요합니다. 지갑은 사용자에게 그들이 더 안전한 체인 상 인터페이스와 상호작용하고 있는지, 아니면 보안성이 낮은 Web2 인터페이스와 상호작용하고 있는지를 보여줄 수 있습니다. 지갑은 또한 사용자에게 그들이 안전한 체인과 상호작용하고 있는지(예: 단계 1+, 다중 보안 감사) 보여줄 수 있습니다.

프라이버시를 중시하는 사용자에게는 지갑이 HTTP 요청을 수락하기 위해 클릭을 요구하는 편집 모드(paranoid mode)를 추가할 수 있습니다. 단순히 web3 작업뿐만 아니라:

편집 모드의 가능한 인터페이스 모델

보다 진보된 방법은 HTML + Javascript를 넘어 dapp의 비즈니스 로직을 전용 언어(아마도 Solidity 또는 Vyper 위의 상대적으로 얇은 커버)로 작성하는 것입니다. 그런 다음 브라우저는 필요한 기능의 UI를 자동으로 생성할 수 있습니다. OKContract는 이미 이를 수행하고 있습니다.

또 다른 방향은 암호 경제 정보 방어입니다: dapp 개발자, 보안 회사, 체인 배포자 및 기타 사람들이 채권을 설정할 수 있으며, dapp이 해킹되거나 사용자에게 매우 오해의 소지가 있는 방식으로 피해를 주면 해당 채권이 영향을 받은 사용자에게 지급됩니다(확인된 대로) 일부 체인 상 재판 DAO에 의해. 지갑은 사용자에게 채권 크기를 기반으로 한 점수를 보여줄 수 있습니다.

더 긴 미래

위의 모든 것은 클릭하고 사물을 지시하며 텍스트 필드에 입력하는 전통적인 인터페이스의 맥락에서 이루어집니다. 그러나 우리는 또한 패러다임이 더 깊이 변화하는 기로에 서 있습니다:

• 인공지능은 클릭 기반 타이핑 패러다임에서 "하고 싶은 것을 말하면 로봇이 알아낼 것"이라는 패러다임으로의 전환을 초래할 수 있습니다.

• 뇌-컴퓨터 인터페이스는 눈 추적과 같은 "부드러운" 방법과 더 직접적이고 심지어 침습적인 기술(예: 올해 첫 Neuralink 환자)이 있습니다.

• 클라이언트 능동 방어: Brave 브라우저는 사용자를 광고, 추적기 및 기타 많은 악성 객체로부터 능동적으로 보호합니다. 많은 브라우저, 플러그인 및 암호 지갑은 사용자 보호를 위해 전담 팀이 있습니다. 이러한 "능동적인 수호자"는 향후 10년 동안 더욱 강력해질 것입니다.

이 세 가지 추세는 사용자 인터페이스 작업 방식에 대한 보다 깊은 재고를 초래할 것입니다. 자연어 입력, 눈 추적 또는 궁극적으로 더 직접적인 뇌-컴퓨터 인터페이스와 함께, 여러분의 기록(모든 데이터가 로컬에서 처리되는 한 문자 메시지를 포함할 수 있음)을 통해 "지갑"은 여러분이 무엇을 하고 싶어하는지를 명확하고 직관적으로 이해할 수 있습니다. 그런 다음 인공지능은 이러한 직관을 구체적인 "행동 계획"으로 전환할 수 있습니다: 여러분이 원하는 것을 완료하기 위한 일련의 체인 상 및 체인 외 상호작용입니다. 이는 제3자 사용자 인터페이스에 대한 필요성을 크게 줄일 수 있습니다. 사용자가 실제로 제3자 애플리케이션(또는 다른 사용자)과 상호작용하는 경우, 인공지능은 사용자를 대신하여 적대적인 사고를 수행하고 모든 위협을 식별하며 위협을 피하기 위한 행동 계획을 제안해야 합니다. 이상적으로 이러한 인공지능은 다양한 편견과 유인 구조를 가진 다양한 집단에 의해 생성된 개방형 생태계를 가져야 합니다.

이러한 더 급진적인 아이디어는 기술이 오늘날 매우 미성숙하기 때문에, 저는 오늘날 그것들에 의존하는 지갑에 제 자산을 두지 않을 것입니다. 그러나 유사한 것들이 미래의 추세로 보이는 만큼, 이 방향으로 보다 적극적으로 탐색하기 시작하는 것은 가치가 있습니다.