피드백과 검토를 해주신 Liraz Siri, Yoav Weiss 및 ImToken, Metamask 및 OKX 개발자에게 특별히 감사드립니다.
핵심 L1 연구원 및 개발자가 종종 과소평가하는 Ethereum 인프라 스택의 중요한 계층은 지갑입니다. 지갑은 사용자와 이더리움 세계 사이의 창이며 사용자는 지갑 자체가 해당 속성을 보유하고 있는 경우에만 이더리움 및 해당 애플리케이션에서 제공하는 분산화, 검열 저항, 보안, 개인 정보 보호 또는 기타 속성의 혜택을 누릴 수 있습니다.
최근 우리는 Ethereum 지갑이 사용자 경험, 보안 및 기능을 향상시키는 데 큰 진전을 이루는 것을 보았습니다. 이 글의 목적은 이상적인 이더리움 지갑이 갖춰야 할 몇 가지 기능에 대한 내 의견을 제시하는 것입니다. 이것은 포괄적인 목록이 아닙니다. 이는 내 사이퍼펑크 성향을 반영하고 보안과 개인 정보 보호에 중점을 두고 있으며 사용자 경험 측면에서 거의 불완전합니다. 그러나 위시리스트는 단순히 피드백을 기반으로 배포하고 반복하는 것만큼 사용자 경험을 최적화하는 데 효과적이라고 생각하지 않으므로 보안 및 개인 정보 보호 속성에 집중하는 것이 가장 가치 있다고 생각합니다.
L2 간 트랜잭션에 대한 사용자 경험
이제 단기 및 장기 부분을 포함하여 L2 전반에 걸쳐 사용자 경험을 개선하기 위한 점점 더 상세한 로드맵이 있습니다. 여기서는 단기적인 부분, 즉 오늘날에도 이론적으로 여전히 구현이 가능한 아이디어에 대해 이야기하겠습니다.
핵심 아이디어는 (i) 내장된 교차 L2 전송, (ii) 체인별 주소 및 결제 요청입니다. 귀하의 지갑은 다음과 같은 주소( 이 ERC 초안 의 스타일에 따라)를 제공할 수 있어야 합니다.
누군가(또는 일부 애플리케이션)가 이 형식으로 주소를 제공하면 지갑의 받는 사람 필드에 주소를 붙여넣고 보내기를 클릭할 수 있어야 합니다. 지갑은 가능한 모든 방법으로 전송된 데이터를 자동으로 처리해야 합니다.
대상 체인에 필요한 유형의 토큰이 이미 충분하다면 토큰을 직접 보내십시오.
다른 체인(또는 다른 여러 체인)에 원하는 유형의 토큰이 있는 경우 ERC-7683 (실제로는 크로스체인 DEX)과 같은 프로토콜을 사용하여 토큰을 보내세요.
동일한 체인이나 다른 체인에 다른 유형의 토큰이 있는 경우 탈중앙화 거래소를 사용하여 이를 올바른 체인에서 올바른 유형의 통화로 변환하고 보내십시오. 이를 위해서는 사용자의 명시적인 허가가 필요합니다. 사용자는 자신이 지불한 금액과 수령인이 받은 금액을 확인할 수 있습니다.
크로스체인 주소를 지원하는 지갑 인터페이스 모델
위는 주소(또는 ENS, 예: Vitalik.eth @optimism.eth)를 복사하여 붙여넣고 누군가가 귀하에게 비용을 지불하는 사용 사례에 대한 것입니다. dapp이 예금을 요청하는 경우(예: 이 Polymarket 예시 참조) 이상적인 흐름은 web3 API를 확장하고 dapp이 체인별 결제 요청을 할 수 있도록 허용하는 것입니다. 그러면 귀하의 지갑은 필요한 어떤 방식으로든 요청을 이행할 수 있습니다. 좋은 사용자 경험을 위해서는 getAvailableBalance 요청도 표준화되어야 하며, 지갑은 보안과 전송 편의성을 극대화하기 위해 기본적으로 사용자 자산이 어떤 체인에 저장될 것인지 신중하게 고려해야 합니다.
체인별 결제 요청은 모바일 지갑으로 스캔할 수 있는 QR 코드에 넣을 수도 있습니다. 직접(또는 온라인) 소비자 결제 시나리오에서 수신자는 참조 ID 또는 콜백 W를 사용하여 체인에 X 단위의 토큰 YZ를 원합니다라고 말하는 QR 코드 또는 web3 API 호출을 발행하고 지갑은 다음을 수행할 수 있습니다. 어떤 방식으로든 이 요청을 이행하시기 바랍니다. 또 다른 옵션은 청구 연결 프로토콜입니다. 사용자의 지갑은 온체인 계약에서 특정 금액의 자금을 얻기 위해 청구 승인이 포함된 QR 코드 또는 URL을 생성하고, 해당 자금을 이체하는 방법을 알아내는 것은 수신자의 임무입니다. 지갑 속 자신에게.
또 다른 관련 주제는 가스 지불입니다. 아직 ETH가 없는 L2에서 자산을 받고 해당 L2에서 거래를 보내야 하는 경우 지갑은 자동으로 프로토콜(예: RIP-7755 )을 사용하여 온체인 가스 비용을 지불할 수 있어야 합니다. ETH가 있는 곳. 예를 들어 지갑이 향후 L2에서 더 많은 트랜잭션을 수행하기를 원한다면 DEX를 통해서만 보내야 합니다. 향후 거래에서 가스를 직접 사용할 수 있도록 수백만 가스 상당의 ETH를 사용합니다(더 저렴하기 때문).
계정 보안
제가 계정 보안 문제를 개념화하는 한 가지 방법은 좋은 지갑은 두 가지 작업을 동시에 수행해야 한다는 것입니다. (i) 지갑 개발자의 해킹이나 악의적인 공격으로부터 사용자를 보호하고, (ii) 자신의 실수로 인해 사용자가 영향을 받지 않도록 보호합니다.
왼쪽의 오류는 의도하지 않은 것입니다. 그런데 막상 보니까 내용이 딱 맞는 것 같아서 그대로 두기로 했어요.
이에 대해 제가 10년 넘게 선호한 솔루션은 계층적 액세스 제어 기능을 갖춘 사회적 복구 및 다중 서명 지갑이었습니다. 사용자 계정에는 마스터 키와 N명의 보호자(예: N = 5)라는 두 가지 수준의 키가 있습니다. 기본 키는 낮은 가치와 비재무적 작업을 수행할 수 있습니다. 대부분의 가디언은 (i) 계정의 전체 가치를 전송하거나 (ii) 마스터 키 또는 가디언을 변경하는 등의 고부가가치 작업을 수행해야 합니다. 원하는 경우 기본 키가 시간 잠금을 통해 중요한 작업을 수행하도록 허용할 수 있습니다.
위는 기본 디자인이며 확장 가능합니다. 세션 키 및 ERC-7715 와 같은 권한 메커니즘은 다양한 애플리케이션에 대해 편의성과 보안의 다양한 균형을 지원하는 데 도움이 될 수 있습니다. 다양한 임계값에서 여러 시간 잠금 기간을 갖는 등 보다 복잡한 보호 아키텍처는 도난 위험을 최소화하면서 합법적인 계정을 성공적으로 복구할 가능성을 최대화하는 데 도움이 될 수 있습니다.
위는 기본 디자인이며 확장 가능합니다. 세션 키 및 ERC-7715 와 같은 권한 메커니즘은 다양한 애플리케이션에 대해 편의성과 보안의 다양한 균형을 지원하는 데 도움이 될 수 있습니다. 다양한 임계값에서 여러 시간 잠금 기간을 갖는 등 보다 복잡한 보호 아키텍처는 도난 위험을 최소화하면서 합법적인 계정을 성공적으로 복구할 가능성을 최대화하는 데 도움이 될 수 있습니다.
후견인은 누구 또는 무엇이 되어야 합니까?
숙련된 암호화폐 사용자 커뮤니티에서 숙련된 암호화폐 사용자를 위한 실행 가능한 옵션은 친구와 가족의 키입니다. 모든 사람에게 새 주소를 제공하도록 요청하는 경우 아무도 자신이 누구인지 알 필요가 없습니다. 실제로 보호자는 서로가 누구인지 알 필요조차 없습니다. 그들이 당신에게 정보를 제공하지 않았다면 공모할 가능성은 희박합니다. 그러나 대부분의 신규 사용자는 이 옵션을 사용할 수 없습니다.
두 번째 옵션은 기관 후견인입니다. 귀하의 요청에 대한 추가 확인을 받은 경우에만 거래에 서명하는 서비스를 전문적으로 제공하는 회사입니다. 고가치 사용자를 위한 확인 코드 또는 화상 통화. 예를 들어, 사람들은 오랫동안 이런 것들을 만들려고 노력해 왔습니다. 나는 2013년에 CryptoCorp를 프로파일링했습니다 . 그러나 이들 회사는 지금까지 큰 성공을 거두지 못했습니다.
세 번째 옵션은 여러 개인 장치(예: 휴대폰, 데스크톱, 하드웨어 지갑)입니다. 이는 효과가 있지만 경험이 없는 사용자가 설정하고 관리하기가 어렵습니다. 특히 동일한 위치에 있는 경우 장치를 동시에 분실하거나 도난당할 위험도 있습니다.
최근에는 마스터 키 기반 솔루션이 더 많이 보이기 시작했습니다. 키는 귀하의 장치에서만 백업할 수 있으므로 개인용 장치 솔루션으로 만들거나 클라우드에서만 백업할 수 있으므로 보안은 암호화 보안, 권한 및 신뢰할 수 있는 하드웨어 가정의 복잡한조합 에 따라 달라집니다. 실제로 키는 일반 사용자에게 귀중한 보안 이점을 제공하지만 키만으로는 사용자의 생명을 보호하기에는 충분하지 않습니다.
다행히 ZK-SNARK에는 네 번째 옵션인 ZK 패키지의 중앙 집중식 ID가 있습니다. 이 유형에는 zk-email , Anon Aadhaar , Myna Wallet 등이 포함됩니다. 기본적으로 어떤 형태(기업이든 정부든)의 중앙화된 ID를 가져와 이더리움 주소로 변환하고, 중앙화된 ID를 가지고 있음을 증명하는 ZK-SNARK를 생성해야만 거래를 보낼 수 있습니다.
이 추가를 통해 이제 우리는 ZK로 포장된 중앙 집중식 ID의 고유한 초보자 친화성과 다양한 옵션을 갖게 되었습니다.
이를 위해서는 단순화되고 통합된 UI를 통해 구현되어야 합니다. example@gmail.com을 보호자로 지정하도록 지정할 수 있어야 하며 아래에 해당 zk-email 이더리움 주소를 자동으로 생성해야 합니다. 후드. 고급 사용자는 자신의 이메일(및 해당 이메일에 저장된 개인 정보 보호 소금)을 오픈 소스 타사 애플리케이션에 입력하고 결과 주소가 올바른지 확인할 수 있어야 합니다. 지원되는 다른 보호자 유형의 경우에도 마찬가지입니다.
오늘날 zk-email이 직면하고 있는 실질적인 문제는 몇 달에 한 번씩 교체되는 키를 사용하고 다른 기관에서 자체적으로 서명하지 않는 DKIM 서명 에 의존한다는 것입니다. 이는 오늘날의 zk-email이 공급자 자체를 넘어서는 일정 수준의 신뢰 요구 사항을 가지고 있음을 의미합니다. zk-email이 신뢰할 수 있는 하드웨어 내에서 TLSNotary를 사용하여 업데이트된 키를 확인하는 경우 이는 줄어들 수 있지만 이상적이지는 않습니다. 이메일 제공업체가 DKIM 키에 직접 서명하기를 바랍니다. 오늘 저는 한 명의 보호자에게 zk-email을 추천하지만 대부분의 보호자에게는 그렇지 않습니다. 깨진 zk-email이 자금을 사용할 수 없다는 것을 의미하는 설정에 자금을 저장하지 마십시오.
신규 사용자 및 인앱 지갑
신규 사용자는 실제로 처음 가입할 때 많은 수의 보호자를 입력하고 싶어하지 않습니다. 따라서 지갑은 매우 간단한 옵션을 제공해야 합니다. 자연스러운 경로는 이메일 주소, 사용자 장치에 로컬로 저장된 키(아마도 마스터 키) 및 공급자가 선택한 백업 키에 대해 zk-email을 사용하여 2-3을 수행하는 것입니다. 사용자가 더 많은 경험을 쌓거나 더 많은 자산을 축적함에 따라 어느 시점에 더 많은 보호자를 추가하라는 메시지가 표시되어야 합니다.
암호화폐를 사용하지 않는 사용자에게 어필하려는 앱은 사용자가 두 개의 새로운 앱(앱 자체와 이더리움 지갑)을 동시에 다운로드하는 혼란스러운 사용자 경험을 원하지 않기 때문에 앱에 지갑을 통합하는 것은 불가피합니다. 그러나 많은 앱 지갑 사용자는 모든 지갑을 함께 연결하여 걱정할 액세스 제어 문제가 하나만 있을 수 있어야 합니다. 가장 간단한 접근 방식은 사용자가 자신의 기본 지갑을 모든 앱 내 지갑의 수호자로 설정할 수 있는 빠른 연결 프로세스가 있는 계층형 구성표를 채택하는 것입니다. Farcaster 클라이언트 Warpcast는 이미 다음을 지원합니다.
기본적으로 Warpcast 계정 복구는 Warpcast 팀에서 관리합니다. 그러나 Farcaster 계정을 인계하고 복구 주소를 자신의 주소로 변경할 수 있습니다.
사기 및 기타 외부 위협으로부터 사용자를 보호하세요.
계정 보안 외에도 오늘날의 지갑은 가짜 주소, 피싱, 사기 및 기타 외부 위협을 식별하고 그러한 위협으로부터 사용자를 보호하기 위해 많은 노력을 기울이고 있습니다. 동시에, 많은 대응책은 여전히 매우 원시적입니다. 예를 들어 $100를 보내든 $100,000를 보내든 관계없이 새 주소로 ETH 또는 기타 토큰을 보내려면 클릭을 요구합니다. 여기에는 마법의 총알이 하나도 없습니다. 이는 다양한 종류의 위협에 대한 느리고 지속적인 수정 및 개선 작업입니다. 그러나 여기서 개선 작업을 계속하는 데는 많은 가치가 있습니다.
은둔
이제 이더리움의 개인정보 보호를 더욱 심각하게 받아들여야 할 때입니다. ZK-SNARK 기술은 이제 매우 발전했으며, 규제 위험을 줄이기 위해 백도어에 의존하지 않는 개인 정보 보호 기술(예: 개인 정보 보호 풀 )은 더욱 성숙해지고 있으며 Waku 및 ERC-4337 멤풀과 같은 보조 인프라는 점차 안정되고 있습니다. 그러나 지금까지 이더리움에서 개인 전송을 하려면 사용자는 Railway (또는 스텔스 주소 의 경우 Umbra )와 같은 개인 지갑을 명시적으로 다운로드하고 사용해야 했습니다. 이는 상당한 불편을 가중시키고 개인 이동을 원하는 사람들의 수를 줄입니다. 해결책은 개인 전송을 지갑에 직접 통합해야 한다는 것입니다.
간단한 구현은 다음과 같습니다. 지갑은 사용자 자산의 일부를 개인 정보 보호 풀의 개인 잔액으로 저장할 수 있습니다. 사용자가 전송을 수행하면 먼저 자동으로 개인정보 풀에서 종료됩니다. 사용자가 자금을 받아야 하는 경우 지갑은 자동으로 스텔스 주소를 생성할 수 있습니다.
또한 지갑은 사용자가 참여하는 각 애플리케이션(예: defi 프로토콜)에 대해 자동으로 새 주소를 생성할 수 있습니다. 입금은 프라이버시 풀에서 이루어지며 출금은 프라이버시 풀로 직접 이동됩니다. 이를 통해 한 앱에서의 사용자 활동을 다른 앱에서의 활동과 연결 해제할 수 있습니다.
이 기술의 한 가지 장점은 개인 정보 보호 자산 이전뿐만 아니라 개인 정보 보호 신원에 대한 자연스러운 경로라는 것입니다. 신원은 이미 온체인에서 발생합니다. 신원 증명 게이팅(예: Gitcoin Grants)을 사용하는 모든 애플리케이션, 토큰 게이트 채팅, 프로토콜을 따르는 Ethereum 등은 온체인 신원입니다. 우리는 이 생태계가 개인 정보도 보호하기를 원합니다. 이는 사용자의 온체인 활동이 한 곳에 수집되어서는 안 된다는 것을 의미합니다. 각 프로젝트는 별도로 저장되어야 하며, 사용자의 지갑은 모든 증거를 동시에 볼 수 있는 전역 보기를 갖춘 유일한 것이어야 합니다. . EAS 및 Zupass 와 같은 오프체인 증명 프로토콜과 마찬가지로 사용자당 여러 계정으로 구성된 기본 생태계가 이를 달성하는 데 도움이 됩니다.
이는 중기적으로 이더리움 개인정보 보호에 대한 실용적인 비전을 나타냅니다. 개인 정보 보호 전송을 보다 효율적이고 안정적으로 만들기 위해 L1 및 L2에 일부 기능을 도입할 수 있지만 지금은 구현할 수 있습니다. 일부 개인 정보 보호 옹호자들은 허용되는 유일한 일은 모든 것에 대한 완전한 개인 정보 보호, 즉 전체 EVM을 암호화하는 것이라고 믿습니다. 나는 이것이 이상적인 장기적 결과일 수 있다고 생각하지만 프로그래밍 모델에 대한 보다 근본적인 재검토가 필요하며 아직 이더리움에 배포할 준비가 된 성숙도 수준에 이르지 못했습니다. 충분히 큰 익명성 세트를 얻으려면 기본적으로 개인 정보 보호가 필요합니다. 그러나 (i) 계정 간 전송, (ii) 신원 및 신원 관련 사용 사례(예: 개인 증명)에 먼저 초점을 맞추는 것이 구현하기 더 쉬운 실용적인 첫 번째 단계이며 이제 지갑을 사용할 수 있습니다.
이더리움 지갑도 데이터 지갑이어야 합니다
결제, 신원 확인 또는 기타 사용 사례를 위한 효과적인 개인 정보 보호 솔루션의 한 가지 결과는 사용자가 자신의 데이터를 오프체인에 저장할 필요성이 생긴다는 것입니다. 이는 사용자가 각각 0.1-100 ETH의 예치금을 나타내는 티켓을 저장해야 하는 Tornado Cash에서 분명하게 드러납니다. 보다 현대적인 개인 정보 보호 프로토콜은 때때로 암호화된 데이터를 온체인에 유지하고 단일 개인 키를 사용하여 이를 해독합니다. 키가 유출되거나 양자 컴퓨터가 가능해지면 데이터가 모두 공개되기 때문에 이는 위험합니다. EAS 및 Zupass와 같은 오프체인 증명은 오프체인 데이터 저장에 대한 필요성이 더욱 분명합니다.
지갑은 온체인 액세스 권한뿐만 아니라 개인 데이터도 저장하는 소프트웨어여야 합니다. 예를 들어 암호화폐가 아닌 세계에서도 이를 점점 더 인식하고 있습니다. 개인 데이터 저장에 관한 Tim Berners-Lee의 최근 연구를 참조하십시오. 액세스 제어를 강력하게 보장하는 것과 관련하여 해결해야 할 모든 문제는 데이터에 액세스할 수 있고 유출되지 않도록 확실하게 보장하는 문제도 해결해야 합니다. 어쩌면 이러한 솔루션이 쌓일 수도 있습니다. N명의 가디언이 있는 경우 해당 N명의 가디언 간에 M-of-N 비밀 공유를 사용하여 데이터를 저장하세요. 데이터에 대한 누군가의 공유를 취소할 수 없기 때문에 데이터는 본질적으로 보호하기가 더 어렵습니다. 그러나 우리는 가능한 한 안전한 분산형 호스팅 솔루션을 마련해야 합니다.
안전한 체인 접근
오늘날 지갑은 RPC 공급자를 신뢰하여 체인에 대한 모든 정보를 알려줍니다. 이는 두 가지 측면에서 취약점입니다.
예를 들어, RPC 제공업체는 거짓 정보를 제공하여 돈을 훔치려고 할 수 있습니다. 시장 가격에 대해.
RPC 공급자는 사용자가 상호 작용하는 애플리케이션 및 기타 계정에 대한 개인 정보를 추출할 수 있습니다.
이상적으로 우리는 이 두 가지 허점을 모두 메우고 싶습니다. 첫 번째 문제를 해결하려면 블록체인 합의를 직접 검증할 수 있는 L1 및 L2용 표준화된 라이트 클라이언트가 필요합니다. Helios는 이미 L1에 대해 이 작업을 수행했으며 일부 특정 L2를 지원하기 위한 몇 가지 예비 작업을 수행해 왔습니다. 모든 L2를 적절하게 처리하려면 L2(체인별 주소에도 사용됨)를 나타내는 구성 계약이 ERC-3668 과 유사한 방식으로 함수를 선언할 수 있는 표준이 필요합니다. 상태 루트 및 해당 상태의 루트에 대해 인증 및 영수증의 논리적 상태를 확인합니다. 이렇게 하면 지갑이 L1 및 L2의 모든 상태나 이벤트를 안전하게 확인할 수 있는 범용 라이트 클라이언트를 가질 수 있습니다.
개인 정보 보호를 위해 오늘날 유일한 현실적인 접근 방식은 자체 전체 노드를 실행하는 것입니다. 그러나 이제 L2가 등장하면서 모든 것을 갖춘 풀 노드를 실행하는 것이 점점 더 어려워지고 있습니다. 여기서 라이트 클라이언트에 해당하는 것은 PIR(Private Information Retrieval) 입니다. PIR에는 모든 데이터의 복사본을 보관하는 서버와 암호화된 요청을 서버에 보내는 클라이언트가 포함됩니다. 서버는 모든 데이터에 대해 계산을 수행하여 클라이언트가 액세스한 데이터 조각을 서버에 공개하지 않고 클라이언트에 필요한 데이터를 클라이언트의 키로 암호화하여 반환합니다.
서버를 정직하게 유지하기 위해 개별 데이터베이스 프로젝트 자체는 Merkle 포크이므로 클라이언트는 라이트 클라이언트를 사용하여 이를 확인할 수 있습니다.
PIR(Deep Chao 참고: 일반적으로 사용자가 검색된 정보를 공개하지 않고 데이터베이스에서 정보를 검색할 수 있도록 하는 프로토콜 또는 기술인 Private Information Retrieval(Private Information Retrieval)을 말합니다.) 계산량이 매우 많습니다. 이 문제를 해결하는 방법에는 여러 가지가 있습니다.
무차별 대입: 알고리즘이나 특수 하드웨어의 개선으로 PIR이 충분히 빠르게 실행될 수 있습니다. 이러한 기술은 전처리에 따라 달라질 수 있습니다. 서버는 각 클라이언트에 대해 암호화되고 스크램블된 데이터를 저장할 수 있으며 클라이언트는 해당 데이터를 쿼리할 수 있습니다. Ethereum 환경의 주요 과제는 이러한 기술을 (국가와 마찬가지로) 빠르게 변화하는 데이터 세트에 적용하는 것입니다. 이로 인해 실시간 계산이 더 저렴해지지만 총 계산 및 저장 비용이 더 높아질 가능성이 높습니다.
개인 정보 보호 요구 사항 약화: 예를 들어 조회당 믹스인이 100만 개만 있을 수 있으므로 서버는 클라이언트가 액세스할 수 있는 가능한 값 100만 개에 대해 알 수 있지만 더 세밀한 세부 수준은 알 수 없습니다.
다중 서버 PIR: 여러 서버를 사용하고 이러한 서버 간의 정직성이 1-of-N으로 가정되는 경우 일반적으로 PIR 알고리즘이 더 빠릅니다.
기밀성 대신 익명성: 요청 내용을 숨기는 대신 요청 발신자를 숨기는 하이브리드 네트워크를 통해 요청을 보낼 수 있습니다. 그러나 그렇게 하면 필연적으로 대기 시간이 늘어나 사용자 경험이 악화됩니다.
이더리움 환경에서 실용성을 유지하면서 개인정보 보호를 극대화하기 위한 올바른 기술 조합을 찾는 것은 공개적인 연구 문제이며, 저는 암호학자들이 그렇게 하려는 시도를 환영합니다.
이상적인 키스토어 지갑
전송 및 상태 액세스 외에도 L2 컨텍스트에서 원활하게 작동해야 하는 또 다른 중요한 워크플로는 계정의 인증 구성을 변경하는 것입니다. 계정을 변경합니다. 여기에는 난이도가 높아지는 순서에 따라 세 가지 계층의 솔루션이 있습니다.
업데이트 재생: 사용자가 구성을 변경하면 이 변경을 승인하는 메시지가 사용자가 자산을 소유하고 있음을 지갑이 감지하는 모든 체인에서 재생됩니다. 잠재적으로 메시지 형식과 유효성 검사 규칙은 체인 독립적일 수 있으므로 가능한 한 많은 체인에서 자동으로 재생됩니다.
L1의 키 저장소: 구성 정보는 L1에 있으며 L2의 지갑은 L1S LOAD 또는 원격 정적 호출을 사용하여 이를 읽습니다. 이런 방식으로 L1의 구성만 업데이트하면 구성이 자동으로 적용됩니다.
L2의 키 저장소: 구성 정보는 L2에 존재하며 L2의 지갑은 ZK-SNARK를 사용하여 이를 읽습니다. 이는 키 저장소 업데이트가 더 저렴할 수 있다는 점을 제외하면 (2)와 동일하지만 읽기는 더 비쌉니다.
솔루션 (3)은 개인 정보 보호와 잘 작동하기 때문에 특히 강력합니다. 일반적인 개인 정보 보호 솔루션에서 사용자는 비밀 s를 갖고 체인에 리프 값 L을 게시하며 사용자는 일부에 대해 L = 해시(s, 1) 및 N = 해시(s, 2)임을 증명합니다. (s, 2) 그들은 한 번도 공개된 적이 없는 비밀을 통제합니다.) 사용자의 보안에 의존하는 L을 공개하지 않고 동일한 리프의 향후 지불을 보장하지 못하도록 무효화기 N이 발행됩니다. 복구 친화적인 개인 정보 보호 솔루션은 다음과 같이 말합니다: s는 온체인 위치(예: 주소 및 저장 슬롯)이며 사용자는 상태 쿼리를 증명해야 합니다: L = hash(sload(s), 1).
Dapp 보안
사용자 보안에서 가장 약한 고리는 dapp인 경우가 많습니다. 대부분의 경우 사용자는 서버에서 실시간으로 사용자 인터페이스 코드를 암시적으로 다운로드한 다음 브라우저에서 실행하는 웹 사이트를 방문하여 애플리케이션과 상호 작용합니다. 서버가 해킹되거나 DNS가 해킹되면 사용자는 인터페이스의 가짜 복사본을 얻게 되며 이를 통해 임의의 작업을 수행하도록 속일 수 있습니다. 거래 시뮬레이션과 같은 지갑 기능은 위험을 줄이는 데 매우 도움이 되지만 완벽하지는 않습니다.
이상적으로는 생태계를 온체인 콘텐츠 버전 관리로 전환할 것입니다. 사용자는 인터페이스의 IPFS 해시가 포함된 ENS 이름을 통해 dapp에 액세스하게 됩니다. 인터페이스를 업데이트하려면 다중 서명 또는 DAO의 온체인 트랜잭션이 필요합니다. 지갑은 사용자가 더 안전한 온체인 인터페이스와 상호 작용하는지 또는 덜 안전한 Web2 인터페이스와 상호 작용하는지 보여줍니다. 지갑은 사용자가 보안 체인과 상호 작용하는지 여부도 보여줄 수 있습니다(예: 1단계 이상, 여러 보안 감사).
개인 정보 보호에 민감한 사용자를 위해 지갑은 편집증 모드를 추가하여 사용자가 web3 작업뿐만 아니라 HTTP 요청을 수락하려면 클릭하도록 요구할 수도 있습니다.
편집증 모드에 가능한 인터페이스 모델
보다 발전된 접근 방식은 HTML + Javascript를 넘어서 dapp의 비즈니스 로직을 전용 언어(아마도 Solidity 또는 Vyper의 상대적으로 얇은 오버레이)로 작성하는 것입니다. 그러면 브라우저는 원하는 기능에 대한 UI를 자동으로 생성할 수 있습니다. OKContract가 이미 이 작업을 수행하고 있습니다.
또 다른 방향은 암호화폐 정보 방어입니다. dapp 개발자, 보안 회사, 체인 배포자 등은 dapp이 해킹되거나 사용자에게 매우 오해의 소지가 있는 방식으로 해를 끼칠 경우 수신자에게 지급될 채권을 설정할 수 있습니다. )은 일부 온체인 DAO에 의해 판정됩니다. 지갑은 채권 규모에 따라 사용자에게 점수를 표시할 수 있습니다.
장기적인 미래
위의 내용은 모두 가리키고 클릭하고 텍스트 필드에 입력하는 전통적인 인터페이스의 맥락에 있습니다. 그러나 우리는 또한 보다 심오한 패러다임 전환의 정점에 서 있습니다.
클릭하여 입력하는 패러다임에서 무엇을 하고 싶은지 말하면 로봇이 알아낼 것 패러다임으로 우리를 이끌 수 있는 인공 지능
뇌-컴퓨터 인터페이스는 시선 추적과 같은 부드러운 방법부터 보다 직접적이고 심지어 침습적인 기술까지 다양합니다(참조: 올해 첫 Neuralink 환자 ).
클라이언트 측 사전 방어: Brave Browser는 광고, 추적기 및 기타 원치 않는 개체로부터 사용자를 사전에 보호합니다 . 많은 브라우저, 플러그인 및 암호화폐 지갑에는 다양한 보안 및 개인정보 위협으로부터 사용자를 보호하기 위해 전체 팀이 적극적으로 노력하고 있습니다. 이러한 긍정적 수호자는 향후 10년 동안 더욱 강력해질 것입니다.
이 세 가지 추세는 인터페이스 작동 방식에 대한 더 깊은 재고로 이어질 것입니다. 자연어 입력, 시선 추적 또는 궁극적으로 보다 직접적인 뇌-컴퓨터 인터페이스를 통해 귀하의 기록(모든 데이터가 로컬로 처리되는 한 문자 메시지 포함)과 결합되어 지갑은 귀하가 원하는 위치를 명확하고 직관적으로 이해할 수 있습니다. 가. 그런 다음 AI는 이러한 직관을 구체적인 실행 계획, 즉 원하는 것을 달성하기 위한 일련의 온체인 및 오프체인 상호 작용으로 변환할 수 있습니다. 이렇게 하면 타사 사용자 인터페이스의 필요성이 크게 줄어들 수 있습니다. 사용자가 타사 애플리케이션(또는 다른 사용자)과 상호 작용하는 경우 AI는 사용자를 대신하여 적대적으로 생각하고 위협을 식별하고 이를 피하기 위한 조치 계획을 제안해야 합니다. 이상적으로 이러한 AI는 다양한 편견과 인센티브 구조를 가진 다양한 그룹이 생산하는 개방형 생태계를 가져야 합니다.
이런 좀 더 급진적인 아이디어는 오늘날 매우 미성숙한 기술에 의존하고 있기 때문에 나는 오늘날 그 기술에 의존하는 지갑에 내 자산을 넣지 않을 것입니다. 하지만 이와 같은 것이 미래의 방식임은 분명해 보이기 때문에 이 방향에 대해 좀 더 적극적으로 탐구해 볼 가치가 있다.
