작성자: 비탈릭 부테린
편집자: Yangz, Techub News
지갑은 Ethereum 인프라 스택의 중요한 계층이지만 핵심 L1 연구원 및 개발자는 종종 과소평가합니다. 지갑은 사용자와 이더리움 세계 사이의 창이며, 지갑 자체에 분산화, 검열 저항, 보안, 개인 정보 보호 또는 이더리움과 해당 애플리케이션에서 제공하는 기타 기능이 있는 경우에만 사용자가 혜택을 누릴 수 있습니다.
최근 몇 년 동안 우리는 이더리움 생태 지갑이 사용자 경험, 보안 및 기능을 향상시키는 데 큰 진전을 이루는 것을 보았습니다. 이 글의 목적은 이상적인 이더리움 지갑이 갖춰야 할 몇 가지 특성에 대한 개인적인 의견을 표현하는 것입니다. 이 목록은 완전하지는 않지만 내 사이퍼펑크 성향을 반영합니다. 지갑의 경우 사용자 경험 측면에서 완벽한 지갑은 거의 없기 때문에 보안과 개인 정보 보호를 더 중요하게 생각합니다. 위시리스트는 단순히 피드백을 기반으로 배포하고 반복하는 것만큼 사용자 경험을 최적화하는 데 효과적이라고 생각하지 않으며 보안 및 개인 정보 보호 속성에 초점을 맞추는 것이 가장 가치 있다고 생각합니다.
L2 간 트랜잭션에 대한 사용자 경험
현재 Cross-L2 사용자 경험을 개선하기 위한 경로는 단기 및 장기 부분을 포함하여 점점 더 세부화되었습니다. 여기서는 오늘날에도 이론적으로 가능한 단기적인 부분에 대해 이야기하고 싶습니다.
이 부분의 핵심 아이디어는 L2 간 트랜잭션은 물론 체인별 주소 및 결제 요청을 구축하는 것입니다. 지갑은 다음과 같은 주소를 제공해야 합니다.
누군가(또는 앱)가 이 형식의 주소를 제공하는 경우 지갑의 "받는 사람" 필드에 주소를 붙여넣은 다음 "보내기"를 누르면 지갑이 자동으로 처리합니다.
대상 체인에 필요한 유형의 토큰이 충분하면 직접 보내십시오.
다른 체인(또는 체인)에 필요한 유형의 토큰이 있는 경우 ERC-7683 (실제로는 크로스체인 DEX)과 같은 프로토콜을 사용하여 토큰을 보낼 수 있습니다.
동일한 체인이나 다른 체인에 다른 유형의 토큰이 있는 경우 DEX를 사용하여 올바른 체인에서 올바른 유형의 토큰으로 변환하여 보낼 수 있습니다. 물론 이를 위해서는 사용자의 명시적인 허가도 필요합니다. 즉, 사용자는 자신이 지불한 금액과 받는 사람이 받은 금액을 확인할 수 있습니다.
위는 "주소(또는 ENS, 예: Vitalik.eth@optimism.eth)를 복사하여 붙여넣고 누군가에게 돈을 지불하도록 하는" 사용 사례입니다. DApp에 예금이 이루어지는 경우( Polymarket 예제 참조) 이상적인 흐름은 DApp이 체인별 결제 요청을 할 수 있도록 Web3 API를 확장하는 것입니다. 이런 방식으로 사용자 지갑은 어떤 방식으로든 요청을 충족할 수 있습니다. 좋은 사용자 경험을 위해서는 getAvailableBalance 요청도 표준화되어야 하며, 지갑은 보안과 전송 용이성을 극대화하기 위해 기본적으로 사용자 자산이 어떤 체인에 저장될 것인지 고려해야 합니다.
특정 체인에 대한 지불 요청은 모바일 지갑에서 직접 스캔할 수 있도록 QR 코드에 배치될 수도 있습니다. 직접(또는 온라인) 소비 결제 시나리오에서 수취인은 QR 코드 또는 Web3 API를 통해 "참조 ID 또는 콜백 W를 사용하여 Z 체인에 X 단위의 Y 토큰을 원합니다"라고 호출할 수 있으며 지갑은 느낄 수 있습니다. 어떤 방식으로든 이 요청을 준수할 자유가 있습니다. 또 다른 해결책은 링크 프로토콜을 적용하는 것입니다. 즉, 사용자 지갑은 온체인 계약에서 일정 금액의 자금을 청구할 수 있는 권한이 포함된 QR 코드 또는 URL을 생성할 수 있으며 수취인의 임무는 이 자금을 이체하는 방법은 자신의 지갑으로 이체하는 것입니다.
또 다른 관련 주제는 가스 지불입니다. 아직 ETH를 보유하지 않은 L2에서 자산을 받고 해당 L2에서 거래를 보내야 하는 경우 지갑은 자동으로 프로토콜(예: RIP-7755 )을 사용하여 체인의 가스 비용을 지불할 수 있어야 합니다. 당신이 ETH를 소유한 곳. 지갑이 앞으로 해당 L2에서 더 많은 거래를 할 것으로 예상하는 경우 DEX를 사용하여 수백만 달러 상당의 ETH를 보내 향후 거래에서 가스를 직접 사용할 수 있도록 해야 합니다(또한 더 저렴합니다).
계정 보안
계정 보안 문제에 대한 제가 이해하는 바는 좋은 지갑은 해커나 지갑 개발자의 악의적인 공격, 그리고 자신의 실수로부터 사용자를 보호해야 한다는 것입니다.
세로축의 오타 "실수"는 정직한 실수입니다. 저는 이 오류가 문맥에 부합한다고 생각하여 수정하지 않았습니다.
10년 넘게 제가 선호하는 솔루션은 계층적 액세스 제어 기능을 갖춘 사회 복구 및 다중 서명 지갑이었습니다. 단일 사용자 계정은 마스터 키와 N개의 서명자(예: N = 5)를 포함하여 두 가지 수준의 키로 설정됩니다. 마스터 키를 사용하면 가치가 낮고 비재무적인 작업이 가능합니다. 그러나 계정의 모든 자산을 보내거나 마스터 키나 서명자를 변경하는 등 중요한 작업을 수행하려면 대다수의 서명자가 필요합니다. 원하는 경우 마스터 키가 시간 잠금을 통해 중요한 작업을 수행하도록 허용할 수 있습니다.
위의 내용은 기본 디자인일 뿐이며 확장할 수도 있습니다. 예를 들어 세션 키와 권한 메커니즘(예: ERC-7715 )은 편의성과 보안 간의 균형이 다른 다양한 애플리케이션을 지원하는 데 도움이 될 수 있습니다. 다양한 임계값에서 여러 시간 잠금 기간을 설정하는 등 보다 복잡한 서명자 아키텍처는 도난 위험을 최소화하면서 합법적인 계정을 성공적으로 복구할 가능성을 최대화하는 데 도움이 될 수 있습니다.
다중 서명 지갑의 서명자로 누구를 선택해야 합니까?
숙련된 암호화폐 사용자에게 실행 가능한 옵션은 친구와 가족입니다. 실제로 다중서명 지갑 서명자는 서로가 누구인지 알 필요조차 없습니다. 당신이 모르는 사이에 그들이 공모할 가능성은 거의 없습니다. 그러나 대부분의 신규 사용자에게는 이 옵션이 적합하지 않습니다.
두 번째 옵션은 서비스 제공을 전문으로 하는 회사인 대행사입니다. 이러한 서명자는 추가 확인 정보(예: 확인 코드 또는 고액 자산 사용자의 영상 통화)를 받은 후에만 거래에 서명합니다. 사람들은 오랫동안 이와 같은 회사를 만들려고 노력해 왔습니다. 예를 들어 저는 2013년에 CryptoCorp를 프로파일링했습니다. 그러나 지금까지 이러한 유형의 회사에 대한 성공적인 대표자는 없습니다.
세 번째 옵션은 여러 개인 장치(예: 모바일, 데스크톱, 하드웨어 지갑)를 사용하는 것입니다. 이 접근 방식은 효과적일 수 있지만 경험이 없는 사용자가 설정하고 관리하기 어려울 수도 있습니다. 또한, 특히 동일한 위치에 있는 경우 장치를 동시에 분실하거나 도난당할 위험이 있습니다.
최근에는 패스키 기반 지갑이 더 많이 등장하기 시작했습니다. 패스키는 장치에서만 백업할 수 있으므로 개인 대 장치 솔루션이 되거나 클라우드에서 보안이 암호 보안, 권한 및 신뢰할 수 있는 하드웨어 가정의 복잡한 조합 에 따라 달라집니다. 실제로 패스키는 일반 사용자에게 귀중한 보안 이점을 제공하지만 사용자의 생명을 보호하기에는 그 자체로는 충분하지 않습니다.
다행히 ZK-SNARK에는 네 번째 옵션인 ZK가 처리하는 중앙 집중식 ID가 있습니다. 이 유형에는 zk-email , Anon Aadhaar , Myna Wallet 등이 포함됩니다. 기본적으로 모든 형태의 중앙 집중식 ID(기업 또는 정부)를 가져와 이더리움 주소로 전환하고 해당 ID의 소유권에 대한 ZK-SNARK 증명을 생성해야만 해당 주소에서 트랜잭션을 보낼 수 있습니다.
이 새로운 기능을 통해 다양한 옵션이 제공되며 ZK가 처리하는 중앙 집중식 ID는 매우 초보자에게 친숙합니다.
이를 달성하려면 간소화된 통합 사용자 인터페이스를 사용해야 합니다. 사용자는 "example@gmail.com"을 서명자로 지정하기만 하면 지갑이 자동으로 해당 zk-email 이더리움 주소를 생성합니다. 또한 고급 사용자는 자신의 이메일(이메일에 저장될 수 있는 개인 정보 보호 솔트와 함께)을 오픈 소스 타사 애플리케이션에 입력하고 결과 주소가 올바른지 확인할 수 있어야 합니다. 지원되는 다른 서명자 유형의 경우에도 마찬가지입니다.
zk-email이 현재 직면하고 있는 실질적인 문제는 몇 달마다 교체되는 키를 사용하는 DKIM 서명 에 의존하고 있으며 키 자체는 다른 기관에서 서명하지 않는다는 것입니다. 이는 공급자 자체 이상의 신뢰 수준이 필요하다는 것을 의미합니다. zk-email이 신뢰할 수 있는 하드웨어에서 TLSNotary를 사용하여 업데이트된 키를 확인하는 경우 신뢰 요구 사항이 줄어들 수 있지만 이는 이상적이지 않습니다. 이메일 제공업체가 DKIM 키에 직접 서명하기를 바랍니다. 또한 다수의 서명자가 아닌 한 명의 서명자에게만 zk-email을 사용하는 것이 좋습니다. 이렇게 하면 zk-email이 충돌하더라도 자금에 대한 액세스 권한을 잃지 않을 것입니다.
신규 사용자 및 인앱 지갑
실제로 신규 사용자는 처음 가입할 때 다수의 다중 서명 지갑 서명자 정보를 입력하고 싶어하지 않을 것입니다. 따라서 지갑은 매우 간단한 옵션을 제공해야 합니다. 자연스러운 접근 방식은 3개의 서명 중 2개, 사용자 장치에 로컬로 저장된 키(패스키일 수 있음) 및 공급자가 보유한 백업 키에 대해 zk-email을 사용하는 것입니다. 사용자가 경험을 쌓거나 자산을 축적함에 따라 어떤 경우에는 더 많은 서명자를 추가하라는 메시지가 표시됩니다.
비암호화폐 사용자를 유치하려는 앱은 사용자가 두 개의 새로운 앱(앱 자체와 이더리움 지갑)을 동시에 다운로드하게 하여 나쁜 사용자 경험을 만들고 싶지 않기 때문에 지갑을 앱에 통합하는 것은 불가피합니다. 여러 지갑을 사용하는 사용자는 모든 지갑을 함께 연결할 수 있어야 하므로 "액세스 제어 문제"만 걱정하면 됩니다. 가장 간단한 접근 방식은 사용자가 빠른 "연결" 프로세스를 통해 모든 인앱 지갑에 대한 서명자로 기본 지갑을 설정할 수 있는 계층화된 접근 방식을 사용하는 것입니다. 현재 Farcaster 클라이언트 Warpcast는 이미 이 방법을 지원합니다.
기본적으로 Warpcast 계정 복구는 Warpcast 팀에서 관리합니다. 그러나 사용자는 Farcaster 계정을 "인계"하여 자신의 주소로 변경할 수 있습니다.
사기 및 기타 외부 위협으로부터 사용자를 보호하세요.
계정 보안 외에도 오늘날의 지갑은 가짜 주소, 피싱, 사기 및 기타 외부 위협을 식별하고 이러한 위협으로부터 사용자를 보호하기 위해 많은 노력을 기울이고 있습니다. 그러나 많은 대응책은 여전히 매우 원시적입니다. 예를 들어, 100달러를 보내든 100,000달러를 보내든 ETH나 기타 토큰을 새 주소로 보내는 것은 클릭 한 번이면 됩니다. 이와 관련하여 단일 솔루션은 없으며 오히려 다양한 종류의 위협에 대해 느리고 지속적인 일련의 수정 및 개선이 이루어지고 있습니다. 그러나 개선을 위해 지속적으로 노력하는 것에는 큰 가치가 있습니다.
은둔
ZK-SNARK 기술은 매우 발전했으며, 백도어 에 의존하지 않고 규제 위험을 줄일 수 있는 개인 정보 보호 풀과 같은 개인 정보 보호 기술도 점점 더 성숙해지고 있습니다. 그러나 지금까지 이더리움에서 개인 전송을 하려면 사용자는 Railway (또는 스텔스 주소의 경우 Umbra )와 같은 "개인 지갑"을 명시적으로 다운로드하여 사용해야 했습니다. 이는 사용자들에게 큰 불편을 안겨주고, 그러한 사용자의 수를 감소시킵니다. 이 문제에 대한 해결책은 이러한 전송을 지갑에 직접 통합하는 것입니다.
간단한 구현 방법은 지갑이 사용자 자산의 일부를 개인 정보 보호 풀의 "개인 잔고"로 저장할 수 있다는 것입니다. 사용자가 전송을 수행하면 먼저 개인 정보 보호 풀에서 자동으로 철회됩니다. 사용자가 자금을 받아야 하는 경우 지갑은 자동으로 스텔스 주소를 생성합니다. 또한 지갑은 사용자가 참여하는 각 애플리케이션(예: DeFi 프로토콜)에 대해 자동으로 새 주소를 생성할 수 있습니다. 예금은 프라이버시 풀에서 나오고, 출금은 프라이버시 풀로 직접 이동됩니다. 이렇게 하면 한 앱에서의 사용자 활동은 다른 앱에서의 활동과 무관합니다.
이 기술의 한 가지 장점은 자산 이전의 프라이버시뿐만 아니라 신원 인식의 프라이버시도 달성한다는 것입니다. 현재 신원 인식은 체인에서 구현됩니다. 개인 증명(예: Gitcoin Grants)을 사용하는 모든 애플리케이션, 특정 토큰이 필요한 모든 채팅 및 Ethereum Follow 프로토콜은 온체인 신원 인식입니다. 우리는 이 생태계가 프라이버시를 가질 수 있기를 바랍니다. 즉, 체인에서 사용자의 활동이 한 곳에 수집되어서는 안 되며, 각 프로젝트가 별도로 저장되어야 하며, 사용자의 지갑이 "글로벌 뷰"를 가진 유일한 것이어야 합니다. " , 모든 증명을 동시에 볼 수 있습니다. EAS 및 Zupass 와 같은 오프체인 인증 프로토콜과 마찬가지로 사용자당 여러 계정으로 구성된 기본 생태계가 이 목표를 달성하는 데 도움이 됩니다.
이는 중기적으로 이더리움 개인정보 보호에 대한 실용적인 비전을 나타냅니다. 현재 구현 가능하지만 L1 및 L2 단계에서 일부 기능을 도입하면 개인정보 보호 거래가 더욱 효율적이고 안정적으로 이루어질 것입니다. 일부 개인 정보 보호 옹호자들은 허용 가능한 유일한 방법은 모든 것이 완전히 비공개이고 전체 EVM이 암호화되는 것이라고 믿습니다. 그러나 나는 이것이 아마도 장기적으로 원하는 결과라고 생각하며 프로그래밍 모델에 대한 보다 근본적인 재검토가 필요하며 아직 이더리움에 배포할 만큼 성숙하지 않았습니다. 충분한 익명성을 달성하려면 "기본적으로 개인 정보 보호"가 필요합니다. 그러나 계정 간 전송의 개인정보 보호와 신원 및 신원 관련 사용 사례에 초점을 맞추는 것은 구현하기가 더 쉽고 이 단계에서 지갑용으로 구축할 수 있는 실용적인 첫 번째 단계입니다.
이더리움 지갑도 데이터 지갑이어야 합니다
결제, 신원 확인 또는 기타 사용 사례 등 효과적인 개인정보 보호 솔루션을 사용하려면 사용자가 오프체인 데이터를 저장해야 합니다. 이는 사용자가 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은 계산 비용이 많이 들지만 이 문제에 접근하는 방법에는 여러 가지가 있습니다.
무차별 대입: 알고리즘이나 특수 하드웨어의 개선으로 PIR을 충분히 빠르게 실행할 수 있습니다. 이러한 기술은 서버가 쿼리할 수 있는 각 클라이언트에 대해 암호화되고 섞인 데이터를 저장하는 전처리에 의존할 수 있습니다. Ethereum 환경에서 주요 과제는 빠르게 변화하는(예: 상태 변경) 데이터 세트에 이러한 기술을 적용하는 방법입니다. 이렇게 하면 실시간 컴퓨팅 비용이 줄어들지만 총 컴퓨팅 및 스토리지 비용이 증가할 가능성이 높습니다.
약화된 개인 정보 보호 요구 사항: 예를 들어 쿼리당 "믹스인"이 100만 개만 있을 수 있으므로 서버는 클라이언트가 액세스할 수 있는 100만 개의 가능한 값을 알 수 있지만 더 세밀한 세부 수준은 알 수 없습니다.
다중 서버 PIR: 여러 서버가 사용되고 이러한 서버 간의 정직성이 1-of-N으로 가정되는 경우 일반적으로 PIR 알고리즘이 훨씬 빠릅니다.
기밀성보다는 익명성: 요청 내용을 숨기는 대신 요청 발신자를 숨기는 하이브리드 네트워크를 통해 요청을 보낼 수 있습니다. 그러나 그렇게 하면 필연적으로 대기 시간이 늘어나고 사용자 경험이 악화됩니다.
이더리움 환경에서 실용성을 유지하면서 프라이버시를 극대화할 수 있는 기술의 조합을 찾는 것은 공개적인 연구 주제이며, 암호학자들은 이를 시도하는 것을 환영합니다.
이상적인 키 보관 지갑
전송 및 상태 액세스 외에도 L2 환경에서 원활하게 실행되어야 하는 또 다른 중요한 워크플로는 계정의 인증 구성을 변경하는 것입니다(키 변경 또는 계정의 전체 논리에 대한 심층적인 변경 여부). 점점 더 어려워지는 3계층 솔루션은 다음과 같습니다.
업데이트 재생: 사용자가 구성을 변경하면 지갑이 사용자가 자산을 소유하고 있음을 감지하는 모든 체인에서 인증 변경 메시지가 재생됩니다. 메시지 형식과 유효성 검사 규칙은 체인에 구애받지 않으므로 가능한 한 많은 체인에서 자동으로 재생될 수 있습니다.
L1에 키 저장: 구성 정보는 L1에 저장되며 L2의 지갑은 L1SLOAD 또는 REMOTESTATICCALL을 통해 구성 정보를 읽습니다. 이런 방식으로 L1의 구성만 업데이트하면 구성이 자동으로 적용됩니다.
L2에 키 저장: 구성 정보는 L2에 저장되며 L2의 지갑은 ZK-SNARK를 통해 구성 정보를 읽습니다. 이는 키 저장소 업데이트가 더 저렴하고 읽기 비용이 더 비싸다는 점을 제외하면 사례 (2)와 동일합니다.
세 번째 솔루션은 개인 정보 보호와 잘 결합되므로 특히 강력합니다. 일반적인 "개인 정보 보호 솔루션"에서는 사용자가 비밀 s를 가지고 있고 체인에 "리프 값" L을 게시한다고 가정하면 사용자는 L = 해시(s,1) 및 N = 해시(s,2)가 다음과 같다는 것을 증명합니다. 그것은 통제의 일부 (공개되지 않은) 비밀입니다. N은 동일한 리프에 대한 향후 지출이 실패하지 않고 L이 유출되지 않도록 게시됩니다. 계정 복구에 유리한 개인정보 보호 솔루션에서 s는 체인상의 위치(예: 주소, 저장 슬롯)이고 사용자는 상태 쿼리를 증명해야 합니다. 즉, L = hash(sload(s), 1).
DApp 보안
사용자 보안에서 가장 취약한 링크는 DApp인 경우가 많습니다. 대부분의 경우 사용자는 서버에서 실시간으로 사용자 인터페이스 코드를 다운로드한 다음 브라우저에서 실행하는 웹 사이트를 방문하여 애플리케이션과 상호 작용합니다. 서버가 해킹되거나 DNS가 해킹되면 사용자는 인터페이스의 가짜 복사본을 얻게 되며, 이는 사용자를 속여 임의의 작업을 수행할 수 있습니다. 거래 시뮬레이션과 같은 지갑 기능은 위험을 줄이는 데 도움이 되지만 그것만으로는 충분하지 않습니다.
이상적으로는 생태계를 온체인 콘텐츠 버전으로 이동해야 합니다. 여기서 사용자는 인터페이스의 IPFS 해시가 포함된 ENS 이름을 통해 DApp에 액세스하게 됩니다. 인터페이스를 업데이트하려면 다중 ID 또는 DAO의 온체인 트랜잭션이 필요합니다. 지갑은 사용자가 더 안전한 온체인 인터페이스와 상호 작용하는지 또는 덜 안전한 Web2 인터페이스와 상호 작용하는지 보여줍니다. 지갑은 또한 사용자가 보안 블록체인과 상호 작용하는지 여부(예: 1단계 이상, 여러 보안 감사)를 보여줄 수도 있습니다.
개인 정보 보호에 민감한 사용자의 경우 지갑이 약간 더 까다로워 사용자가 Web3 작업뿐만 아니라 HTTP 요청을 수락하려면 클릭해야 합니다.
좀 더 발전된 접근 방식은 HTML + Javascript를 넘어 Solidity나 Vyper에 상대적으로 가벼운 언어를 오버레이하는 등 DApp의 비즈니스 로직을 전용 언어로 작성하는 것입니다. 이런 방식으로 브라우저는 필요한 기능에 대한 사용자 인터페이스를 자동으로 생성할 수 있습니다. OKContract는 이미 이 작업을 수행하고 있습니다. 또 다른 방향은 암호화된 경제 정보 방어입니다. 즉, DApp 개발자, 보안 회사, 온체인 배포자 등이 보증금을 설정할 수 있습니다. DApp이 해킹되거나 기타 오해의 소지가 있는 방식으로 사용자에게 해를 끼치는 경우 보증금은 다음과 같습니다. 온체인 판결 DAO가 결정을 내리면 영향을 받은 사용자에게 지급됩니다. 지갑은 마진 크기를 기준으로 사용자에게 등급을 표시할 수 있습니다.
장기적인 미래
위의 작업은 모두 전통적인 맥락에서 수행되며 현재 모델에 중대한 변화가 발생하기 직전입니다.
인공 지능(AI)은 우리를 "클릭하고 입력하는" 모델에서 "말하고 봇이 알아내는" 모델로 변화시킬 수 있습니다.
뇌-컴퓨터 인터페이스: 시선 추적과 같은 상대적으로 "온건한" 방법뿐만 아니라 보다 직접적이고 심지어 침습적인 기술(예: 최초의 Neuralink 환자 )도 포함합니다.
사전 방어를 통한 클라이언트 측 참여: Brave Browser는 광고, 추적기 및 기타 원치 않는 개체로부터 사용자를 사전에 보호합니다. 많은 브라우저, 플러그인 및 암호화폐 지갑에는 다양한 보안 및 개인정보 위협으로부터 사용자를 보호하기 위해 전체 팀이 적극적으로 노력하고 있습니다. 향후 10년 동안 이러한 "활동적인 수호자"는 더욱 강력해질 것입니다.
이 세 가지 추세를 종합하면 지갑 작동 방식에 대한 더 깊은 재고를 촉발할 것입니다. 자연어 입력, 시선 추적 또는 궁극적으로 보다 직접적인 생체 인식(BCI)을 통해 사용자 이력에 대한 지식과 결합되어 "지갑"은 사용자가 원하는 작업을 직관적으로 정확하게 알 수 있습니다. 그런 다음 AI는 이러한 직관을 일련의 온체인 및 오프체인 상호 작용과 같은 특정 "실행 계획"으로 변환하여 사용자 의도를 달성할 수 있습니다. 이렇게 하면 타사 사용자 인터페이스의 필요성이 크게 줄어들 수 있습니다. 사용자가 타사 앱(또는 다른 사용자)과 상호 작용하는 경우 AI는 사용자를 대신하여 적대적으로 생각하여 위협을 식별하고 이를 피하기 위한 조치 계획을 제안해야 합니다. 이상적으로 이러한 AI는 다양한 편견과 인센티브 구조를 가진 다양한 그룹에 의해 생성된 개방형 생태계를 형성합니다.
물론 이러한 보다 급진적인 아이디어는 현재 극도로 미성숙한 기술에 의존하기 때문에 이러한 기술에 의존하는 지갑에 내 자산을 투자하지는 않을 것입니다. 하지만 이런 기술은 미래의 트렌드로 보여서 이 방향으로 좀 더 적극적으로 탐구해 볼 가치가 있다.
