비탈릭: 제가 생각하는 이상적인 이더리움 지갑의 모습

원래 으로 게시되었습니다. 지갑에서 보고 싶은 것들

저자: Vitalik, Ether 창립자; 컴파일러: Deng Tong, Golden Finance

피드백과 리뷰를 제공해 주신 Liraz Siri, Yoav Weiss, ImToken, Metamask, OKX의 개발자들에게 특별히 감사드립니다. 그리고 검토해 주셔서 감사합니다.

핵심 L1 연구자와 개발자들이 종종 과소평가하는 이더리움 인프라 스택의 핵심 레이어 중 하나는 지갑입니다. 지갑은 사용자와 이더의 세계를 연결하는 창구이며, 사용자는 지갑 자체에 이러한 속성이 있어야만 이더와 애플리케이션이 제공하는 탈중앙화, 검열 저항, 보안, 프라이버시 또는 기타 속성의 이점을 누릴 수 있습니다.

최근 이더 지갑의 사용자 경험, 보안, 기능 개선에 많은 진전이 있었습니다. 이 글의 목적은 이상적인 이더 지갑이 갖춰야 할 몇 가지 속성에 대한 제 생각을 말씀드리는 것입니다. 이는 완전한 목록이 아니며, 저의 크립토 펑크 성향이 반영되어 있고 보안과 프라이버시에 중점을 두고 있으며 사용자 경험 측면에서 불완전할 수 있습니다. 하지만 위시리스트는 단순히 피드백을 기반으로 배포하고 반복하는 것만큼 사용자 경험을 최적화하는 데 효과적이라고 생각하지 않기 때문에 보안 및 개인정보 보호 속성에 초점을 맞추는 것이 가장 가치 있다고 생각합니다.

L2 트랜잭션 전반의 사용자 경험

이제 L2 전반의 사용자 경험을 개선하기 위한 로드맵이 단기적인 부분과 장기적인 부분으로 점점 더 세분화되고 있습니다. 여기서는 단기적인 부분, 즉 오늘날에도 이론적으로 구현 가능한 아이디어에 대해 이야기하겠습니다.

핵심 아이디어는 (i) 내장된 L2 전송과 (ii) 체인별 주소 및 결제 요청입니다. 지갑은 다음과 같이 주소를 제공할 수 있어야 합니다(이 ERC 초안 스타일에 따름):

[email protected]

언제? 누군가(또는 일부 애플리케이션)가 이 형식의 주소를 제공하면 지갑의 받는 사람 필드에 붙여넣고 보내기를 클릭할 수 있어야 합니다. 지갑은 가능한 모든 방법으로 전송된 데이터를 자동으로 처리해야 합니다.

• 대상 체인에 필요한 유형의 토큰을 이미 충분히 보유하고 있다면 직접 전송합니다.

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

• 같은 체인이나 다른 체인에 다른 유형의 토큰이 있는 경우 탈중앙화 거래소를 사용하여 올바른 체인에 올바른 유형의 토큰으로 변환하여 전송합니다. 토큰으로 변환하여 보내세요. 이를 위해서는 사용자의 명시적인 허가가 필요합니다. 사용자는 자신이 지불한 금액과 수신자가 받은 금액을 확인할 수 있습니다.

크로스체인 주소를 지원하는 가능한 지갑 인터페이스 모델

위 내용은 "다른 사람이 내게 결제할 수 있도록 주소(또는 ENS, 예: [email protected])를 복사하여 붙여넣는" 사용 사례에 적용됩니다. 디앱이 입금을 요청하는 경우(예: 폴리마켓 예시 참조), 이상적인 흐름은 웹3 API를 확장하고 디앱이 체인별 결제 요청을 할 수 있도록 허용하는 것입니다. 그러면 지갑은 필요한 방식으로 해당 요청을 처리할 수 있습니다. 좋은 사용자 경험을 위해서는 getAvailableBalance 요청도 표준화해야 하며, 지갑은 보안과 전송 편의성을 극대화하기 위해 사용자 자산을 기본적으로 어떤 체인에 저장할지 신중하게 고려해야 합니다.

체인별 결제 요청은 모바일 지갑에서 스캔할 수 있는 QR 코드에 넣을 수도 있습니다. 대면(또는 온라인) 소비자 결제 시나리오에서 수취인은 "참조 ID 또는 콜백 W와 함께 체인 Z의 X 단위 토큰 Y를 원합니다"라는 내용의 QR코드 또는 웹3 API 호출을 발행하면 지갑은 가능한 모든 방식으로 요청을 이행할 수 있습니다. 또 다른 옵션은 클레임 링크 프로토콜로, 사용자의 지갑이 온체인 콘트랙트에서 특정 금액의 자금을 청구할 수 있는 권한이 포함된 QR코드 또는 URL을 생성하고, 해당 자금을 자신의 계정으로 전송하는 방법을 알아내는 것은 수신자의 몫입니다.

또 다른 관련 주제는 가스 결제입니다. 아직 이더가 없는 L2에서 자산을 받고 해당 L2에서 트랜잭션을 전송해야 하는 경우, 지갑은 자동으로 프로토콜(예: RIP-7755)을 사용해 이더가 있는 체인에서 가스를 지불할 수 있어야 합니다. 지갑이 향후 L2에서 더 많은 트랜잭션을 만들려면 DEX만 사용하여 트랜잭션을 전송해야 합니다. 향후 트랜잭션에서 직접 가스를 사용할 수 있도록 몇 백만 가스의 가치가 있는 이더리움을 보유해야 합니다(더 저렴하기 때문이죠).

계정 보안

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

왼쪽의 '오류'는 의도하지 않은 것입니다. 하지만 막상 보고 나니 문맥에 딱 들어맞는다는 것을 깨달았기 때문에 그대로 두기로 했습니다.

10년 이상 제가 선호하는 솔루션은 계층적 접근 제어 기능을 갖춘 소셜 복구와 다중 서명 지갑이었습니다. 사용자 계정에는 마스터 키와 N명의 보호자(예: N = 5)라는 두 개의 키 계층이 있습니다. 마스터 키는 낮은 가치의 비재무적 작업을 수행할 수 있습니다. 대부분의 보호자는 (i) 계정의 전체 가치를 전송하거나 (ii) 마스터 키 또는 보호자를 변경하는 등의 고가치 작업을 수행해야 합니다. 원하는 경우 마스터 키가 시간 잠금을 통해 고가치 작업을 수행하도록 허용할 수 있습니다.

위 내용은 기본 설계이며 확장할 수 있습니다. 세션 키 및 ERC-7715와 같은 권한 메커니즘을 사용하면 애플리케이션에 따라 편의성과 보안의 균형을 다양하게 지원할 수 있습니다. 여러 임계값에 여러 시간 잠금 기간을 설정하는 등 보다 정교한 가디언 아키텍처를 사용하면 도난 위험을 최소화하면서 합법적인 계정을 성공적으로 복구할 수 있는 가능성을 최대화할 수 있습니다.

보호자는 누구 또는 무엇을 해야 하나요?

노련한 암호화폐 사용자 커뮤니티에서 노련한 암호화폐 사용자를 위한 한 가지 실행 가능한 옵션은 친구와 가족의 열쇠입니다. 모두에게 새 주소를 알려달라고 요청하면 아무도 상대방이 누구인지 알 필요가 없으며, 사실 보호자들도 서로가 누구인지 알 필요가 없습니다. 보호자가 귀하에 대한 정보를 알려주지 않았다면 이들이 공모하고 있을 가능성은 거의 없습니다. 하지만 이 옵션은 대부분의 신규 사용자에게는 제공되지 않습니다.

두 번째 옵션은 기관 보호자: 서비스를 전문적으로 제공하는 회사로, 사용자의 요청에 따라 다른 확인을 받은 경우에만 거래를 승인합니다. 확인 코드 또는 고가치 사용자를 위한 영상 통화 등이 있습니다. 사람들은 오랫동안 이러한 서비스를 만들기 위해 노력해 왔습니다. 하지만 지금까지 이러한 유형의 회사는 그다지 성공하지 못했습니다.

세 번째 옵션은 여러 개인 기기(예: 휴대폰, 데스크톱, 하드웨어 지갑)입니다. 이 방법은 실현 가능하지만 경험이 없는 사용자가 설정하고 관리하기가 어렵습니다. 특히 디바이스가 같은 위치에 있는 경우 분실 또는 도난의 위험도 있습니다.

최근에는 키 기반 지갑이 점점 더 많아지고 있습니다. 비밀번호는 개인 디바이스 솔루션으로 디바이스에만 백업하거나 클라우드에 백업할 수 있어 암호화 보안, 기관 및 신뢰할 수 있는 하드웨어 가정이 복잡하게 혼합되어 있어 보안이 취약합니다. 실제로 키는 일반 사용자에게 유용한 보안 수단이지만, 그 자체만으로는 사용자의 소중한 자산을 보호하기에 충분하지 않습니다.

다행히도 ZK-SNARK에는 네 번째 옵션인 zk가 포함된 중앙 집중식 ID가 있습니다. 이 유형에는 zk-email, Anon Aadhaar, Myna Wallet 등이 포함됩니다. 기본적으로 여러 형태의 중앙화된 ID(기업 또는 정부)를 가져와 이더 주소로 변환할 수 있으며, 중앙화된 ID가 있음을 증명하는 ZK-SNARK를 생성해야만 트랜잭션을 전송할 수 있습니다.

이미지 src="https://img.jinse.cn/7329164_watermarknone.png" title="7329164" alt="fJVK0xvRiS2uZOdPHXlosjJrjhE0bDauO6Qtoth8.jpeg">

이번 기능 추가를 통해 이제 ZK 패키지 중앙집중식 ID에 다양한 선택권과 독특한 '초보자 친화성'을 더하게 되었습니다.

이를 위해서는 단순화된 통합 UI를 통해 "[email protected]"만 가디언으로 지정할 수 있어야 하며, 보닛 아래에 해당 zk-e-mail 이더리움 주소가 자동으로 생성되어야 합니다. 고급 사용자는 오픈 소스 타사 애플리케이션에 자신의 이메일(및 해당 이메일에 저장될 수 있는 모든 개인정보염색)을 입력하고 생성된 주소가 올바른지 확인할 수 있어야 합니다. 지원되는 다른 모든 보호자 유형도 마찬가지입니다.

가능한 보안 인터페이스 모델

현재 zk-email이 직면한 실질적인 문제 중 하나는 몇 달마다 교체되는 키를 사용하는 DKIM 서명에 의존하고 있으며 항상 사용할 수는 없다는 점입니다. 몇 달마다 교체되는 키를 사용하며 다른 기관에서 서명하지 않는 키를 사용합니다. 즉, 오늘날의 zk-email은 제공업체 자체를 넘어서는 수준의 신뢰 요구 사항을 가지고 있으며, 신뢰할 수 있는 하드웨어 내에서 TLSNotary를 사용하여 업데이트된 키를 검증하면 이 문제를 줄일 수 있지만 이는 이상적이지 않습니다. 이메일 제공업체가 DKIM 키에 직접 서명하기 시작하길 바랍니다. 현재로서는 한 명의 보호자에게만 zk-email을 권장하지만, 대부분의 보호자에게는 권장하지 않습니다: zk-email이 손상되면 사용할 수 없는 설정에 자금을 저장하지 마세요.

신규 사용자와 인앱 지갑

신규 사용자는 처음 가입할 때 실제로 많은 수의 보호자를 입력하는 것을 원하지 않습니다. 따라서 지갑은 매우 간단한 옵션을 제공해야 합니다. 자연스러운 경로는 이메일 주소의 zk-메일, 사용자 기기에 로컬로 저장된 키(범용 키일 수 있음), 공급자가 보유한 백업 키를 사용하는 3가지 중 2가지를 선택하는 것입니다. 사용자의 경험이 쌓이거나 자산이 많아지면 어느 시점에 가디언을 추가하라는 메시지가 표시될 것입니다.

암호화되지 않은 사용자를 유치하려는 앱은 사용자가 동시에 두 개의 새로운 앱(앱 자체와 이더 지갑)을 다운로드하는 혼란스러운 사용자 경험을 원하지 않기 때문에 앱에 지갑을 통합하는 것은 피할 수 없는 일입니다. 하지만 여러 앱 지갑을 사용하는 사용자는 모든 지갑을 서로 연결할 수 있어야 '접근 제어 문제' 하나만 걱정할 필요가 있습니다. 이를 위한 가장 쉬운 방법은 사용자가 기본 지갑을 모든 인앱 지갑의 보호자로 설정할 수 있는 빠른 "연결" 프로세스를 통해 계층화된 접근 방식을 채택하는 것입니다. 파캐스터 클라이언트인 워프캐스트는 이미 이를 지원합니다:

기본적으로, 내 워프캐스트 계정의 복구는 은 기본적으로 워프캐스트 팀에서 관리합니다. 그러나 회원님은 자신의 워프캐스터 계정을 "인수"하여 복구 주소를 자신의 주소로 변경할 수 있습니다.

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

오늘날의 지갑은 계정 보안 외에도 가짜 주소, 피싱, 사기 및 기타 외부 위협을 식별하고 이러한 위협으로부터 사용자를 보호하기 위해 많은 일을 하고 있습니다. 동시에, 100달러를 보내든 10만 달러를 보내든 새 주소로 이더리움이나 기타 토큰을 보내려면 클릭 한 번만 해야 하는 등 많은 대응책이 여전히 상당히 원시적인 수준입니다. 여기에는 단일한 해결책이 없습니다. 다양한 범주의 위협에 대한 지속적인 수정과 개선이 느리게 진행되고 있습니다. 하지만 이러한 개선 작업을 계속하는 것에는 많은 가치가 있습니다.

프라이버시

이제 이더리움 프라이버시를 더욱 진지하게 고려해야 할 때입니다. ZK-SNARK 기술은 이제 매우 발전했고, 규제 위험을 완화하기 위해 백도어에 의존하지 않는 프라이버시 기술(예: 프라이버시 풀)은 더욱 정교해지고 있으며, Waku 및 ERC-4337 멤풀과 같은 보조 인프라는 점차 안정화되고 있습니다. 하지만 현재까지 이더리움에서 개인 송금을 하려면 사용자가 명시적으로 철도(또는 보이지 않는 주소의 경우 엄브라)와 같은 '개인 정보 지갑'을 다운로드하여 사용해야 합니다. 이는 상당한 불편을 초래하고 비공개 송금을 하려는 사람들의 수를 감소시킵니다. 해결책은 개인 송금을 지갑에 직접 통합하는 것입니다.

간단한 구현은 다음과 같습니다. 지갑은 사용자 자산의 일부를 프라이버시 풀에 '프라이빗 잔액'으로 저장할 수 있습니다. 사용자가 송금하면 자동으로 프라이버시 풀에서 빠져나옵니다. 사용자가 자금을 받아야 하는 경우 지갑은 자동으로 보이지 않는 주소를 생성할 수 있습니다.

또한, 지갑은 사용자가 참여하는 각 애플리케이션(예: 디파이 프로토콜)에 대해 새 주소를 자동으로 생성할 수 있습니다. 입금은 프라이버시 풀에서 이루어지고 출금은 프라이버시 풀로 바로 이동합니다. 이를 통해 한 앱에서의 사용자 활동을 다른 앱에서의 활동과 연결 해제할 수 있습니다.

이미지 src="https://img.jinse.cn/7329167_watermarknone.png" title="7329167" alt="hIvle2fHhsv0e8r0Mqk7wK8RH9TyAyO4lQk0rcO4.jpeg">

이 기술의 장점 중 하나는 프라이버시를 보호하는 자산 전송뿐만 아니라 프라이버시를 보호하는 신원도 자연스럽게 보호할 수 있다는 것입니다. 신원 증명 게이팅을 사용하는 모든 애플리케이션(예: 깃코인 그랜트), 토큰 게이트 채팅, 이더 추종 프로토콜 등 모든 신원은 이미 온체인에서 이루어집니다. 저희는 이 생태계가 프라이버시도 보호하기를 바랍니다. 즉, 사용자의 온체인 활동이 한 곳에 수집되어서는 안 되며, 각 프로젝트는 개별적으로 저장되어야 하고 사용자의 지갑은 모든 증명을 동시에 '글로벌 뷰'로 볼 수 있는 유일한 곳이어야 합니다. 네이티브 사용자당 다중 계정 생태계는 EAS와 주패스 같은 오프체인 사용 증명 프로토콜과 마찬가지로 이를 달성하는 데 도움이 됩니다.

이것은 중기적으로 이더리움 프라이버시에 대한 실용적인 비전을 제시합니다. 프라이버시 보호 전송을 더 효율적이고 안정적으로 만들기 위해 L1과 L2에 기능을 도입할 수 있지만, 이는 지금 당장 달성할 수 있는 목표입니다. 일부 프라이버시 옹호자들은 모든 것을 암호화하는 완전한 프라이버시만이 유일한 방법이라고 주장합니다. 이는 장기적으로 바람직한 결과일 수 있지만, 프로그래밍 모델에 대한 보다 근본적인 재고가 필요하며 현재 이더리움에 적용할 수 있는 수준의 성숙도를 갖추지 못했다고 생각합니다. 충분한 규모의 익명성 세트를 확보하려면 기본 프라이버시가 필요합니다. 그러나 (i) 계정 간 이체와 (ii) 신원 및 신원 관련 사용 사례(예: 개인 증명)에 우선 집중하는 것이 실용적인 첫 단계이며, 구현하기 쉽고, 지갑은 지금 바로 사용할 준비가 되어 있습니다.

이더리움 지갑도 데이터 지갑이 되어야 합니다

결제, 신원 확인 또는 기타 사용 사례에 사용되는 효과적인 개인정보 보호 솔루션의 결과 중 하나는 사용자가 오프체인 데이터를 저장해야 할 필요성이 생긴다는 것입니다. 이는 사용자가 0.1~100 이더리움의 예치금을 나타내는 각 '티켓'을 저장해야 하는 토네이도 캐시에서 잘 드러납니다. 최신 프라이버시 프로토콜은 암호화된 데이터를 온체인에 저장하고 단일 개인 키를 사용해 암호를 해독하기도 합니다. 이는 키가 손상되거나 양자 컴퓨터가 실용화되면 데이터가 모두 공개되기 때문에 위험합니다. 오프체인 데이터 저장소의 필요성은 EAS와 주패스 같은 오프체인 증명을 통해 더욱 분명해집니다.

지갑은 온체인 액세스뿐만 아니라 개인 데이터도 저장하는 소프트웨어여야 합니다. 예를 들어, 비암호화 세계에서도 이를 점점 더 인식하고 있습니다. 팀 버너스 리의 개인 데이터 저장에 관한 최근 연구를 참조하세요. 접근 권한 제어를 강력하게 보장하는 것과 관련하여 해결해야 할 모든 문제는 데이터 접근성 및 유출 방지를 강력하게 보장하는 것과 관련하여 해결해야 합니다. 이러한 해결책을 서로 겹쳐서 사용할 수도 있습니다. 가디언이 N명인 경우, 가디언 간에 M-of-N 비밀 공유를 사용하여 데이터를 저장할 수 있습니다. 누군가의 데이터 공유를 취소할 수 없기 때문에 데이터는 본질적으로 보호하기가 더 어렵지만, 최대한 안전한 분산형 관리 솔루션을 마련해야 합니다.

보안 체인 접근

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

• RPC 제공자는 시장 가격 등 허위 정보를 제공하여 자금을 탈취하려고 시도할 수 있습니다

< li>

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

이상적으로는 이 두 가지 취약점을 모두 해결하고자 합니다. 첫 번째 문제를 해결하려면 블록체인 합의를 직접 검증할 수 있는 L1 및 L2용 표준화된 라이트 클라이언트가 필요합니다. 헬리오스는 이미 L1에 대해 이 작업을 수행하고 있으며, 일부 특정 L2를 지원하기 위한 예비 작업을 해왔습니다. 모든 L2를 올바르게 다루기 위해서는 L2를 나타내는 구성 컨트랙트(체인별 주소에도 사용)가 ERC-3668과 유사한 방식으로 가장 가까운 상태를 가져오는 함수를 선언할 수 있는 표준이 필요합니다. ROOTS를 가져오고, 그 상태를 기반으로 STATE ROOTS 증명과 영수증을 생성하는 함수를 선언할 수 있습니다. 이렇게 하면 지갑이 L1과 L2의 모든 상태나 이벤트를 안전하게 검증할 수 있는 일반적인 라이트 클라이언트를 가질 수 있습니다.

현재 프라이버시를 위한 유일한 현실적인 접근 방식은 자체 풀 노드를 운영하는 것입니다. 하지만 이제 L2가 등장하면서 모든 것을 풀 노드로 운영하는 것이 점점 더 어려워지고 있습니다. 여기서 라이트 클라이언트에 해당하는 것이 개인 정보 검색(PIR)입니다. PIR에는 모든 데이터의 사본을 보관하는 서버와 암호화된 요청을 서버로 전송하는 클라이언트가 포함됩니다. 서버는 모든 데이터에 대한 연산을 수행하여 클라이언트가 필요로 하는 데이터를 반환하고, 클라이언트가 어떤 데이터에 액세스했는지 서버에 공개하지 않고 클라이언트의 키로 암호화합니다.

이미지 src="https://img.jinse.cn/7329168_watermarknone.png" title="7329168" alt="mVG57b7iKu8hIXwcQfybutSt9ZqmRZU5Q6UQbTCA.jpeg">

서버를 정직하게 유지하기 위해 개별 데이터베이스 항목은 그 자체로 Merkle 브랜치이므로 클라이언트는 라이트 클라이언트를 사용하여 인증할 수 있습니다.

PIR은 매우 계산 집약적입니다. 이를 해결하기 위한 몇 가지 방법이 있습니다.

• 무차별 대입: 알고리즘 또는 특수 하드웨어의 개선으로 PIR을 충분히 빠르게 실행할 수 있습니다. 이러한 기술은 서버가 각 클라이언트에 대해 암호화 및 스크램블된 데이터를 저장하고 클라이언트가 해당 데이터를 쿼리할 수 있는 전처리에 따라 달라질 수 있습니다. 이더넷 환경의 주요 과제는 이러한 기술을 국가와 같이 빠르게 변화하는 데이터 세트에 적용하는 것입니다. 이렇게 하면 실시간 연산 비용은 저렴해지지만 총 연산 및 스토리지 비용은 높아질 가능성이 높습니다.

• 개인정보 보호 요건 약화: 예를 들어, 조회당 '믹스인'은 100만 개까지만 가능하므로 서버는 클라이언트가 액세스할 수 있는 백만 개의 가능한 값을 알 수 있지만 더 세분화된 수준은 알 수 없습니다.

• 멀티 서버 PIR: 일반적으로 여러 서버를 사용하고 서버 간에 1 대 N의 정직성을 가정하는 경우 PIR 알고리즘이 더 빠릅니다.

• 비밀성보다는 익명성: 요청을 믹스넷을 통해 전송할 수 있으므로 요청의 내용보다는 요청의 발신자를 숨길 수 있습니다. 그러나 이렇게 하면 필연적으로 지연 시간이 증가하여 사용자 경험이 악화될 수 있습니다.

이더리움 환경에서 유용성을 유지하면서 프라이버시를 극대화할 수 있는 적절한 기술 조합을 찾아내는 것은 열린 연구 과제이며, 저는 암호학자들이 이를 시도하는 것을 환영합니다.

이상적인 키스토어 지갑

전송과 상태 접근 외에도, L2 컨텍스트에서 원활하게 작동해야 하는 또 다른 중요한 워크플로는 계정의 인증 구성 변경(예: 키 복구)이든, 계정 전체에 대한 더 심층적인 변경이든 간에 로직을 변경해야 합니다. 다음은 난이도가 높은 순서대로 3단계 솔루션입니다.

• 업데이트 재생: 사용자가 설정을 변경하면 사용자가 지갑을 소유하고 있음을 감지하면 변경을 승인하는 메시지가 지갑에 전송됩니다. 메시지는 지갑이 사용자가 자산을 소유하고 있음을 감지하는 모든 체인에서 재생됩니다. 메시지 형식과 유효성 검사 규칙은 체인에 독립적일 수 있으므로 가능한 한 많은 체인에서 자동으로 재생될 수 있습니다.

• L1의 키스토어: 구성 메시지는 L1에 있으며, L2의 지갑은 L1SLOAD 또는 REMOTESTATICCALL을 사용해 이를 읽습니다. 이렇게 하면 L1에서 구성만 업데이트하면 구성이 자동으로 적용됩니다.

• L2의 키스토어: 구성 정보가 L2에 존재하고 L2의 지갑은 ZK-SNARK를 사용하여 이를 읽습니다. 이는 (2)와 동일하지만 키스토어 업데이트 비용이 더 저렴할 수 있지만 반면에 읽기 비용이 더 많이 든다는 점이 다릅니다.

솔루션 (3)이 특히 강력한 이유는 개인정보 보호와 잘 작동하기 때문입니다. 일반적인 '프라이버시 솔루션'에서는 사용자가 비밀 s와 '리프 값' L을 체인에 게시하고, 사용자가 자신이 관리하는 일부 (공개되지 않은) 비밀에 대해 L = 해시(s, 1) 및 N = 해시(s, 2)임을 증명합니다. 무효화자 N은 동일한 리프에 대한 향후 지출이 L을 공개하지 않고 실패하도록 보장하기 위해 게시됩니다. 이는 사용자가 동일한 리프에 대해 동일한 목적으로 사용할 수 없도록 보안을 유지하는지에 따라 달라집니다. 복구 친화적인 프라이버시 솔루션은 다음과 같이 말합니다: s는 체인 내 위치(예: 주소 및 저장 슬롯)이며, 사용자는 상태 쿼리인 L = 해시(sload(s), 1)를 증명해야 합니다.

Dapp 보안

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

이상적으로는 생태계를 온체인 콘텐츠 버전 관리로 전환하여 사용자가 인터페이스의 IPFS 해시를 포함하는 ENS 이름으로 댑에 액세스하도록 할 것입니다. 인터페이스를 업데이트하려면 다중 서명 또는 DAO의 온체인 트랜잭션이 필요합니다. 지갑은 사용자에게 더 안전한 온체인 인터페이스와 상호작용하는지, 아니면 덜 안전한 웹 2.0 인터페이스와 상호작용하는지를 표시할 것입니다. 또한 지갑은 사용자가 안전한 체인(예: 1+ 단계, 다중 보안 감사)과 상호작용하고 있는지 여부를 사용자에게 표시할 수도 있습니다.

개인정보 보호에 민감한 사용자를 위해 지갑은 사용자가 웹3 작업뿐 아니라 HTTP 요청을 수락하기 위해 클릭해야 하는 편집증 모드를 추가할 수도 있습니다.

가능한 파라노이드 모드 인터페이스 모델

더 고급 접근 방식은 HTML + 자바스크립트를 넘어서서 디앱의 비즈니스 로직을 특수 언어(솔리디티나 바이퍼에 비교적 얇은 오버레이)로 작성하는 것입니다. 그러면 브라우저는 원하는 기능에 대한 UI를 자동으로 생성할 수 있습니다. OKContract는 이미 이를 수행하고 있습니다.

또 다른 방향은 암호경제 정보 방어입니다. 디앱 개발자, 보안 회사, 체인 배포자 등은 디앱이 해킹당하거나 매우 잘못된 방식으로 피해를 입었을 때 피해 사용자에게 지급되는 보증금을 설정할 수 있습니다. 일부 온체인 판결에 따라 DAO. 지갑은 사용자에게 채권 규모에 따라 점수를 표시할 수 있습니다.

장기적인 미래

위의 모든 것은 사물을 가리키고 클릭하고 텍스트 필드에 입력하는 전통적인 인터페이스의 맥락에서 설명한 것입니다. 그러나 우리는 또한 더 심오한 패러다임의 전환을 목전에 두고 있습니다.

• 인공 지능으로 인해 클릭 투 타입의 패러다임에서 " 하고 싶은 것을 말하면 로봇이 알아서 해준다" 패러다임;

• 시선 추적과 같은 '부드러운' 방법부터 보다 직접적이고 침습적인 기술까지 다양한 뇌-컴퓨터 인터페이스(참고: 올해 첫 Neuralink 환자);

인공지능은 클릭 투 타입 패러다임에서 ""하고 싶은 것을 말하면 로봇이 알아서 해준다" 패러다임으로 우리를 이끌 수 있습니다." 패러다임. p>

• 클라이언트 측 능동 방어: Brave Browser는 광고, 트래커 및 기타 여러 가지 원치 않는 객체로부터 사용자를 선제적으로 보호합니다. 많은 브라우저, 플러그인, 암호화폐 지갑은 다양한 보안 및 개인 정보 보호 위협으로부터 사용자를 보호하기 위해 팀 전체가 적극적으로 노력하고 있습니다. 이러한 '적극적인 보호자'는 향후 10년 동안 더욱 강력해질 것입니다.

이 세 가지 트렌드는 함께 인터페이스 작동 방식에 대한 심도 깊은 재고로 이어질 것입니다. 자연어 입력, 시선 추적 또는 궁극적으로 보다 직접적인 뇌-컴퓨터 인터페이스와 사용자의 이력(모든 데이터가 로컬에서 처리되는 한 문자 메시지 포함)을 통해 '지갑'은 사용자가 무엇을 하고 싶은지 명확하고 직관적으로 이해할 수 있습니다. 그러면 AI는 이러한 직관을 구체적인 '행동 계획', 즉 사용자가 원하는 작업을 수행하기 위한 일련의 온/오프체인 상호작용으로 변환할 수 있습니다. 이렇게 하면 타사 사용자 인터페이스의 필요성을 크게 줄일 수 있습니다. 사용자가 타사 애플리케이션(또는 다른 사용자)과 상호 작용하는 경우, AI는 사용자를 대신하여 대립적으로 사고하여 위협을 식별하고 이를 피하기 위한 행동 계획을 제안해야 합니다. 이상적으로는 이러한 AI는 다양한 편견과 인센티브 구조를 가진 다양한 그룹에 의해 생성된 개방형 생태계를 가져야 합니다.

이보다 더 급진적인 아이디어는 오늘날의 극도로 미성숙한 기술에 의존하고 있기 때문에 저는 지금 당장 이러한 기술에 의존하는 지갑에 제 자산을 넣지 않을 것입니다. 하지만 이와 유사한 것이 미래라는 것은 분명해 보이므로 그 방향으로 더 적극적으로 탐색해 볼 가치가 있습니다.