비탈릭 부테린: 이더리움은 세 가지 전환 L2, 지갑, 프라이버시를 완료해야 한다

원문 제목：《The Three Transitions》

저자：Vitalik Buterin

번역：MK，MarsBit

이더리움이 일반 사용자에게 개방적이고 글로벌하며 허가가 필요 없는 경험을 제공할 수 있는 성숙한 기술 스택으로 전환될 때, 이 스택은 대체로 동시에 진행되는 세 가지 주요 기술 전환을 겪어야 합니다:

1. L2 확장 전환 - 모든 사람이 롤업으로 이동
2. 지갑 보안 전환 - 모든 사람이 스마트 계약 지갑으로 이동
3. 프라이버시 전환 - 프라이버시 보호 자금 이체를 보장하고, 개발 중인 모든 다른 도구(소셜 복구, 신원, 평판)가 프라이버시를 보호하도록 보장

이것은 생태계 전환의 삼각 관계입니다. 당신은 3개 중 3개를 선택할 수 있습니다.

첫 번째가 없다면, 이더리움은 실패할 것입니다. 왜냐하면 모든 거래가 3.75달러의 비용이 들기 때문입니다(다시 한 번 황소장이 온다면 가격은 82.48달러가 될 것입니다). 대중 시장을 겨냥한 모든 제품은 결국 체인을 잊고 모든 것을 중앙 집중화된 솔루션으로 취할 것입니다.

두 번째가 없다면, 이더리움은 실패할 것입니다. 왜냐하면 사용자가 자금(및 비금융 자산)을 저장하려 하지 않기 때문입니다. 모든 사람이 중앙 집중식 거래소로 이동할 것입니다.

세 번째가 없다면, 이더리움은 실패할 것입니다. 왜냐하면 모든 거래(및 POAPs 등)가 누구에게나 공개되기 때문입니다. 이는 많은 사용자에게 프라이버시의 과도한 희생이며, 모든 사람이 최소한 일부 숨겨진 데이터가 있는 중앙 집중화된 솔루션으로 이동할 것입니다.

이러한 이유로 이 세 가지 전환은 매우 중요합니다. 그러나 이러한 문제를 해결하기 위해서는 강력한 조정이 필요하므로 도전적이기도 합니다. 단순히 프로토콜의 기능을 개선하는 것뿐만 아니라, 경우에 따라 이더리움과 상호작용하는 방식을 상당히 근본적으로 변화시켜야 하며, 애플리케이션과 지갑에 대한 깊은 변화가 필요합니다.

이 세 가지 전환은 사용자와 주소 간의 관계를 근본적으로 변화시킬 것입니다

L2 확장 세계에서 사용자는 여러 L2에 존재하게 됩니다. 당신은 Optimism에 위치한 ExampleDAO의 회원인가요? 그렇다면 당신은 Optimism에 계좌가 있습니다! ZkSync의 스테이블코인 시스템에서 CDP를 보유하고 있나요? 그렇다면 당신은 ZkSync에 계좌가 있습니다! Kakarot에 위치한 애플리케이션을 시도해 본 적이 있나요? 그렇다면 당신은 Kakarot에 계좌가 있습니다! 사용자가 단 하나의 주소만 가지던 시대는 사라질 것입니다.

저는 네 곳에서 ETH를 보유하고 있습니다. 제 Brave Wallet 뷰에 따르면, Arbitrum과 Arbitrum Nova는 다릅니다. 걱정하지 마세요, 시간이 지남에 따라 이것은 더욱 복잡해질 것입니다!

스마트 계약 지갑은 더 많은 복잡성을 추가하여 L1과 다양한 L2에서 동일한 주소를 소유하는 것을 더욱 어렵게 만듭니다. 오늘날 대부분의 사용자는 외부 소유 계좌를 사용하고 있으며, 그 주소는 실제로 서명을 검증하는 공개 키의 해시입니다 - 따라서 L1과 L2 간에는 아무런 변화가 없습니다. 그러나 스마트 계약 지갑의 경우, 주소를 유지하는 것이 더욱 어려워집니다. 이미 CREATE2와 ERC-2470 단일 공장과 같은 네트워크 간 동등한 코드 해시를 만들기 위해 많은 작업이 이루어졌지만, 이를 완벽하게 구현하는 것은 매우 어렵습니다. 일부 L2(예: "type 4 ZK-EVMs")는 EVM과 완전히 동일하지 않으며, 일반적으로 Solidity 또는 중간 어셈블리를 대신 사용하여 해시 동등성을 방해합니다. 해시 동등성을 가질 수 있다고 하더라도, 지갑이 키 변경을 통해 소유권을 변경할 가능성은 다른 비직관적인 결과를 초래할 수 있습니다.

프라이버시는 각 사용자에게 더 많은 주소를 보유하게 하고, 우리가 처리하는 주소 유형을 변경할 수도 있습니다. 프라이버시 주소 제안이 널리 사용된다면, 각 사용자는 더 이상 몇 개의 주소만 가지지 않거나 각 L2에서 하나의 주소만 가지지 않고, 아마도 각 거래에서 하나의 주소를 가질 수 있습니다. 다른 프라이버시 솔루션, 심지어 Tornado Cash와 같은 기존 솔루션은 자산 저장 방식을 다르게 변화시킬 것입니다: 많은 사용자의 자금이 동일한 스마트 계약(따라서 동일한 주소) 내에 저장됩니다. 특정 사용자에게 자금을 보내기 위해 사용자는 프라이버시 솔루션의 내부 주소 시스템에 의존해야 합니다.

우리가 보았듯이, 이 세 가지 전환은 "하나의 사용자 ~= 하나의 주소"라는 심리 모델을 다양한 방식으로 약화시키며, 그 중 일부 효과는 전환을 실행하는 복잡성에 피드백됩니다. 두 가지 특별한 복잡성 포인트는 다음과 같습니다:

1. 누군가에게 지불하고 싶다면, 그들에게 지불할 정보를 어떻게 얻을 수 있을까요?

2. 사용자가 서로 다른 체인에서 여러 자산을 저장하고 있다면, 그들은 어떻게 키 변경 및 소셜 복구를 수행할 수 있을까요?

세 가지 전환은 온체인 지불(및 신원)과 관련이 있습니다

저는 Scroll에서 동전을 보유하고 있으며, 커피를 지불하고 싶습니다(만약 "저"가 이 글의 저자를 의미한다면, "커피"는 물론 "녹차"의 환유입니다). 당신은 저에게 커피를 팔고 있지만, 당신은 Taiko에서만 동전을 받을 준비가 되어 있습니다. 저는 어떻게 해야 할까요?

기본적으로 두 가지 해결책이 있습니다:

1. 수신 지갑(상인일 수도 있고, 단순한 개인일 수도 있음)이 각 L2를 지원하기 위해 노력하고, 일부 비동기적으로 자금을 통합하는 자동 기능을 갖추는 것입니다.

2. 수신자가 그들의 L2와 주소를 제공하고, 발신자의 지갑이 어떤 형태의 크로스 L2 브리징 시스템을 통해 자금을 목표 L2로 자동으로 라우팅하는 것입니다.

물론, 이러한 해결책은 조합될 수 있습니다: 수신자가 그들이 수용할 수 있는 L2 목록을 제공하고, 발신자의 지갑이 지불을 계산하며, 이는 직접 전송(운이 좋다면)하거나 크로스 L2 브리징 경로를 통해 이루어질 수 있습니다.

하지만 이것은 세 가지 전환이 도입한 주요 도전 과제의 한 예일 뿐입니다: 누군가에게 지불하는 것과 같은 간단한 행동이 이제는 단순히 20바이트 주소에 대한 정보보다 더 많은 것을 요구하게 됩니다.

스마트 계약 지갑의 전환은 다행히도 주소 시스템에 대한 부담이 크지 않지만, 애플리케이션 스택의 다른 부분에서는 여전히 해결해야 할 기술적 문제가 있습니다. 지갑은 업데이트되어야 하며, 거래에서 21000 gas를 전송하는 것뿐만 아니라, 더 중요한 것은 지갑의 지불 수신 측이 EOA의 ETH 전송을 추적할 뿐만 아니라 스마트 계약 코드에서 전송된 ETH도 추적하도록 보장해야 합니다. 주소 소유권이 변하지 않는다는 가정에 의존하는 애플리케이션(예: 강제 로열티를 위한 NFT)은 그들의 목표를 달성하기 위해 다른 방법을 찾아야 할 것입니다. 스마트 계약 지갑은 또한 일부 작업을 더 쉽게 만들 것입니다 - 특히 누군가가 비 ETH ERC20 토큰만 수신하는 경우, 그들은 ERC-4337 지불인을 사용하여 그 토큰으로 gas 비용을 지불할 수 있을 것입니다.

반면에, 프라이버시는 다시 우리가 아직 제대로 해결하지 못한 주요 도전 과제를 제기합니다. 초기 Tornado Cash는 내부 전송을 지원하지 않았기 때문에 이러한 문제를 도입하지 않았습니다: 사용자는 시스템에 자금을 입금하고 인출할 수만 있었습니다. 내부 전송을 수행할 수 있게 되면, 사용자는 프라이버시 시스템의 내부 주소 계획을 사용해야 합니다. 실제로 사용자의 "지불 정보"는 (i) 수신자가 사용할 수 있는 비밀의 약속인 어떤 형태의 "지출 공개 키"와 (ii) 발신자가 수신자가 지불을 발견하는 데 도움이 되는 암호화된 정보를 전송하는 방법을 포함해야 합니다.

프라이버시 주소 프로토콜은 메타 주소의 개념에 의존하며, 그 작동 방식은 다음과 같습니다: 메타 주소의 일부는 발신자의 지출 키의 블라인드 버전이고, 다른 부분은 발신자의 암호화 키입니다(최소 구현에서는 이 두 키가 동일하게 설정될 수 있습니다).

여기서 핵심 교훈은 프라이버시를 중시하는 생태계에서 사용자가 지출 공개 키와 암호화 공개 키를 보유하게 되며, 사용자의 "지불 정보"는 이 두 가지 키를 포함해야 한다는 것입니다. 지불 외에도 이 방향으로 확장할 몇 가지 좋은 이유가 있습니다. 예를 들어, 우리가 이더리움 기반의 암호화 이메일을 원한다면, 사용자는 어떤 형태의 암호화 키를 공개적으로 제공해야 할 것입니다. "EOA 세계"에서는 계좌 키를 재사용하여 이 목표를 달성할 수 있지만, 안전한 스마트 계약 지갑 세계에서는 이 목표를 달성하기 위해 더 명확한 기능이 필요할 수 있습니다. 이는 또한 이더리움 기반 신원이 비이더리움 분산 프라이버시 생태계와 더 호환되도록 도와줄 것입니다. 가장 두드러진 예는 PGP 키입니다.

세 가지 전환과 키 복구

사용자가 여러 주소를 가질 수 있는 세계에서, 키 변경 및 소셜 복구를 구현하는 기본 방법은 사용자가 각 주소에 대해 개별적으로 복구 프로세스를 수행하도록 하는 것입니다. 이는 한 번의 클릭으로 완료될 수 있습니다: 지갑은 모든 사용자의 주소에서 동시에 복구 프로세스를 실행할 수 있는 소프트웨어를 포함할 수 있습니다. 그러나 이러한 사용자 경험 단순화가 있더라도, 순진한 다중 주소 복구에는 세 가지 문제가 있습니다:

1. 가스 비용의 비현실성: 이 점은 자명합니다.
2. 반사실 주소: 스마트 계약이 아직 발행되지 않은 주소(실제로 이는 해당 계좌에서 자금을 전송한 적이 없는 계좌를 의미합니다). 사용자는 무한한 수의 반사실 주소를 가질 수 있습니다: 각 L2에서 하나 이상의 주소가 있으며, 존재하지 않는 L2도 포함됩니다. 또한, 비밀 주소 계획에서 유래된 완전히 다른 무한한 반사실 주소 집합이 있습니다.
3. 프라이버시: 사용자가 의도적으로 많은 주소를 가지고 이를 연결하지 않으려 한다면, 그들은 확실히 동시에 또는 거의 동시에 복구하여 모든 주소를 공개적으로 연결하고 싶지 않을 것입니다!

이 문제를 해결하는 것은 어렵습니다. 다행히도, 상당히 우아한 해결책이 있으며, 이는 상당히 잘 작동합니다: 검증 논리와 자산 보유를 분리하는 아키텍처입니다.

각 사용자에게는 키 저장소 계약이 있으며, 이는 한 위치(주 네트워크 또는 특정 L2)에 존재합니다. 그런 다음 사용자는 서로 다른 L2에서 주소를 가지며, 각 주소의 검증 논리는 키 저장소 계약을 가리키는 포인터입니다. 이러한 주소에서 자금을 지출하려면 키 저장소 계약에 대한 증명이 필요하며, 이는 현재(또는 더 실질적으로 최근의) 지출 공개 키를 보여줍니다.

증명은 여러 가지 방법으로 구현할 수 있습니다:

1. L2에서 읽기 전용 L1 접근 권한을 직접 읽습니다. L2를 수정하여 L1 상태를 직접 읽을 수 있는 방법을 제공할 수 있습니다. 키 저장소 계약이 L1에 있다면, 이는 L2 내의 계약이 "무료"로 키 저장소에 접근할 수 있음을 의미합니다.

2. 머클 브랜치. 머클 브랜치는 L1 상태를 L2로, 또는 L2 상태를 L1으로 증명할 수 있으며, 두 가지를 결합하여 L2의 상태의 일부를 다른 L2에 증명할 수 있습니다. 머클 증명의 주요 약점은 증명 길이에 따른 높은 가스 비용입니다: 하나의 증명은 5 kB가 필요할 수 있으며, Verkle 트리 덕분에 이는 미래에 1 kB 미만으로 줄어들 것입니다.

3. ZK-SNARKs. 머클 브랜치 대신 머클 브랜치를 사용하는 ZK-SNARK를 사용하여 데이터 비용을 줄일 수 있습니다. EIP-4337 기반의 체인 외부 집계 기술을 구축하여 단일 ZK-SNARK가 블록 내에서 모든 크로스 체인 상태 증명을 검증할 수 있습니다.

4. KZG 약속. L2 또는 그 위에 구축된 솔루션은 순차 주소 지정 시스템을 도입하여 이 시스템 내부의 상태 증명이 48바이트 길이만 필요하도록 할 수 있습니다. ZK-SNARKs와 마찬가지로, 다중 증명 솔루션은 모든 증명을 각 블록의 단일 증명으로 통합할 수 있습니다.

우리가 매 거래마다 증명을 피하고 싶다면, 우리는 복구 시에만 크로스 L2 증명을 수행하는 더 경량화된 솔루션을 구현할 수 있습니다. 하나의 계좌에서 자금을 지출하는 것은 지출 키에 따라 달라지며, 해당 공개 키는 그 계좌에 저장됩니다. 그러나 복구는 키 저장소 내의 현재 지출 공개 키를 복사하는 거래가 필요합니다. 반사실 주소 내의 자금은 이전 키가 안전하지 않더라도 안전합니다: 반사실 주소를 "활성화"하고 이를 작동 계약으로 전환하려면 크로스 L2 증명을 수행하여 현재의 지출 공개 키를 복사해야 합니다. Safe 포럼의 이 주제는 유사한 아키텍처가 어떻게 작동할 수 있는지를 설명합니다.

이러한 솔루션에 프라이버시를 추가하기 위해, 우리는 단순히 포인터를 암호화한 다음 ZK-SNARKs 내에서 모든 증명을 수행하면 됩니다:

더 많은 작업을 통해(예: 이 작업을 시작점으로 삼아) 우리는 ZK-SNARKs의 복잡성의 대부분을 제거하고 KZG 기반의 더 간단한 솔루션을 만들 수 있습니다.

이러한 솔루션은 복잡해질 수 있습니다. 그러나 이러한 솔루션 간에는 많은 잠재적인 시너지 효과가 있습니다. 예를 들어, "키 저장소 계약" 개념은 이전 섹션에서 언급한 "주소" 문제의 해결책이 될 수 있습니다: 사용자가 지속적인 주소를 가지기를 원한다면, 이러한 주소는 사용자가 키를 업데이트할 때 변경되지 않아야 하며, 우리는 비밀 메타 주소, 암호화 키 및 기타 정보를 키 저장소 계약에 넣고, 키 저장소 계약의 주소를 사용자의 "주소"로 사용할 수 있습니다.

많은 L2 인프라가 업데이트가 필요합니다

ENS 사용은 비쌉니다. 오늘날, 2023년 6월, 상황은 그리 나쁘지 않습니다: 거래 수수료는 높지만 ENS 도메인 비용과 비교할 수 있습니다. zuzalu.eth 등록은 약 27달러가 들었으며, 그 중 11달러는 거래 수수료입니다. 그러나 만약 우리가 또 다른 황소장이 온다면, 비용은 급증할 것입니다. ETH 가격이 오르지 않더라도, 가스 비용이 200 gwei로 돌아가면 도메인 등록의 거래 수수료는 104달러로 증가할 것입니다. 따라서 사람들이 실제로 ENS를 사용하기를 원한다면, 특히 분산형 소셜 미디어와 같은 애플리케이션 시나리오에서, 사용자는 거의 무료 등록을 요구해야 하며(ENS 도메인 비용은 문제가 되지 않습니다. 왜냐하면 이러한 플랫폼은 사용자에게 서브도메인을 제공하기 때문입니다), 우리는 ENS가 L2에서 작동하도록 해야 합니다.

다행히도, ENS 팀은 이미 행동을 시작했으며, ENS는 L2에서 실제로 발생하고 있습니다! ERC-3668(일명 "CCIP 표준")는 ENSIP-10과 함께 모든 L2에서 ENS 서브도메인을 자동으로 검증하는 방법을 제공합니다. CCIP 표준은 L2 데이터 증명을 검증하는 방법을 설명하는 스마트 계약을 설정하도록 요구하며, 도메인 이름(예: Optinames는 ecc.eth 사용)은 이러한 계약의 제어 하에 놓일 수 있습니다. CCIP 계약이 L1에서 ecc.eth를 제어하게 되면, some subdomain.ecc.eth에 접근하는 것은 자동으로 L2 상태를 찾아보고 검증하는 것(예: 머클 브랜치)을 포함하게 되며, 실제로 해당 특정 서브도메인을 저장합니다.

실제 증명을 얻는 것은 계약에 저장된 일련의 URL에 접근하는 것을 포함하며, 이는 사실상 중앙 집중화된 느낌이지만, 저는 그것이 실제로는 그렇지 않다고 주장할 것입니다: 이는 1-of-N 신뢰 모델입니다(무효 증명은 CCIP 계약의 콜백 함수 내의 검증 논리에 의해 포착되며, 하나의 URL이 유효한 증명을 반환하기만 하면 문제가 없습니다). 이 URL 목록은 수십 개의 URL을 포함할 수 있습니다.

ENS CCIP의 작업은 성공적인 사례로, 우리가 필요로 하는 그러한 급진적 개혁이 가능하다는 신호로 간주되어야 합니다. 그러나 애플리케이션 레이어에서 더 많은 개혁이 필요합니다. 몇 가지 예는 다음과 같습니다:

많은 dapp이 사용자가 제공하는 오프체인 서명에 의존합니다. 외부 소유 계좌(EOA)의 경우, 이는 간단합니다. ERC-1271은 스마트 계약 지갑에 이를 구현하기 위한 표준화된 방법을 제공합니다. 그러나 많은 dapp은 여전히 ERC-1271을 지원하지 않으며, 그들은 이를 지원해야 합니다.

"이것이 EOA인가?"를 사용하여 사용자와 계약을 구분하는 Dapp(예: 전송을 방지하거나 로열티를 실행하기 위해)은 무너질 것입니다. 일반적으로, 저는 순수 기술적 해결책을 찾으려 하지 말 것을 권장합니다; 특정 암호화 제어권 이전이 유익한 권리 이전 문제인지 파악하는 것은 어려운 문제이며, 일부 오프체인 커뮤니티 주도 메커니즘의 도움 없이 해결할 수 없을 것입니다. 가장 가능성이 높은 것은 애플리케이션이 이전보다 더 적게 전송을 방지하고, Harberger 세금과 같은 기술에 더 많이 의존해야 할 것입니다.

지갑이 지출 및 암호화 키와 상호작용하는 방식은 개선이 필요합니다. 현재 지갑은 일반적으로 결정론적 서명을 사용하여 애플리케이션 특정 키를 생성합니다: EOA의 개인 키로 표준 난수(예: 애플리케이션 이름의 해시)에 서명하여 개인 키 없이 생성할 수 없는 결정론적 값을 생성하므로 기술적으로 안전합니다. 그러나 이러한 기술은 지갑에 대해 "불투명한" 것이며, 지갑이 사용자 인터페이스 수준의 보안 검사를 구현하는 것을 방해합니다. 더 성숙한 생태계에서는 서명, 암호화 및 관련 기능이 지갑에 의해 더 명확하게 처리되어야 합니다.

경량 클라이언트(예: Helios)는 L1뿐만 아니라 L2를 검증해야 합니다. 오늘날 경량 클라이언트는 L1 헤더의 유효성을 검사하는 데 집중하고 있으며(경량 클라이언트 동기화 프로토콜을 사용), L1 헤더에서 유래한 L1 상태 및 거래의 머클 브랜치를 검증합니다. 내일 그들은 L1에 저장된 상태 루트에서 유래한 L2 상태의 증명도 검증해야 합니다(이 더 발전된 버전은 실제로 L2의 사전 확인을 확인할 것입니다).

지갑은 자산과 데이터를 보호해야 합니다

현재 지갑의 업무는 자산을 보호하는 것입니다. 모든 것이 체인에 존재하므로, 지갑이 보호해야 할 유일한 것은 현재 이러한 자산을 보호하는 개인 키입니다. 키를 변경하면, 다음 날 안전하게 인터넷에 이전 개인 키를 게시할 수 있습니다. 그러나 제로 지식 증명 세계에서는 상황이 더 이상 그렇지 않습니다: 지갑은 인증 자격 증명만 보호하는 것이 아니라, 당신의 데이터를 보호하고 있습니다.

우리는 Zupass에서 이러한 세계의 첫 번째 징후를 보았습니다. Zupass는 Zuzalu에서 사용되는 ZK-SNARK 기반의 신원 시스템입니다. 사용자는 개인 키를 가지고 있으며, 이를 사용하여 시스템을 인증하고, "나는 Zuzalu의 주민임을 증명하지만, 어떤 주민인지 밝히지 않는다"와 같은 기본적인 증명을 수행할 수 있습니다. 그러나 Zupass 시스템은 또한 그 위에 구축된 다른 애플리케이션을 가지고 있으며, 가장 유명한 것은 스탬프(즉, Zupass의 POAPs 버전)입니다.

저는 Team Cat의 자랑스러운 구성원임을 증명하는 Zupass 스탬프 중 하나를 가지고 있습니다.

스탬프는 POAPs가 제공하는 주요 특징은 비공식적입니다: 당신은 데이터를 로컬로 보유하고 있으며, 당신이 그들에게 당신의 정보를 제공하고 싶을 때만 스탬프(또는 스탬프의 일부 계산)를 증명합니다. 그러나 이는 위험을 증가시킵니다: 만약 당신이 이 정보를 잃어버린다면, 당신은 당신의 스탬프를 잃게 됩니다.

물론, 데이터를 보유하는 문제는 암호화 키를 보유하는 문제로 귀결됩니다: 제3자(심지어 체인)도 데이터의 암호화된 복사본을 보유할 수 있습니다. 이는 당신이 취하는 행동이 암호화 키를 변경하지 않기 때문에 암호화 키를 안전하게 유지하는 시스템과의 상호작용이 필요 없다는 편리한 장점이 있습니다. 그러나 그럼에도 불구하고, 만약 당신이 암호화 키를 잃어버린다면, 당신은 모든 것을 잃게 됩니다. 반대로, 누군가가 당신의 암호화 키를 보게 된다면, 그들은 그 키로 암호화된 모든 것을 볼 수 있습니다.

Zupass의 사실상의 해결책은 사람들이 여러 장치(예: 노트북과 휴대폰)에 키를 저장하도록 장려하는 것입니다. 모든 장치를 동시에 잃어버릴 확률은 낮기 때문입니다. 우리는 더 나아가 비밀 공유를 사용하여 키를 저장하고, 여러 수호자 간에 키를 분할할 수 있습니다.

이러한 MPC를 통한 소셜 복구는 지갑에 대한 충분한 해결책이 아닙니다. 이는 현재의 수호자뿐만 아니라 이전의 수호자가 공모하여 당신의 자산을 훔칠 수 있는 높은 위험을 의미하기 때문입니다. 그러나 프라이버시 유출은 일반적으로 자산을 완전히 잃는 위험보다 작으며, 누군가가 높은 프라이버시 보호가 필요한 경우, 그는 프라이버시 보호 행동에 필요한 관련 키를 백업하지 않음으로써 더 높은 손실 위험을 감수할 수 있습니다.

복잡한 다중 복구 경로 시스템으로 사용자를 압도하지 않기 위해, 소셜 복구를 지원하는 지갑은 자산 복구와 암호화 키 복구를 동시에 관리해야 할 수 있습니다.

신원 문제로 돌아가기

이러한 변화의 공통 주제는, 당신이 체인에서 사용하는 "당신"을 대표하는 암호화 식별자의 "주소" 개념이 근본적으로 변화해야 한다는 것입니다. "나와 상호작용하는 지침"은 더 이상 단순한 ETH 주소가 아닙니다; 그들은 어떤 형태로든 여러 L2에 있는 여러 주소, 비밀 메타 주소, 암호화 키 및 기타 데이터의 조합을 포함해야 합니다.

이를 구현하는 한 가지 방법은 ENS를 당신의 신원으로 만드는 것입니다: 당신의 ENS 기록은 이러한 모든 정보를 포함할 수 있으며, 만약 당신이 누군가에게 bob.eth(또는 bob.ecc.eth, 또는…)를 보낸다면, 그들은 이를 조회하고 지불 및 상호작용하는 모든 방법을 이해할 수 있습니다. 이는 더 복잡한 크로스 도메인 및 프라이버시 보호 방식으로도 가능합니다.

그러나 이러한 ENS 중심 접근 방식에는 두 가지 약점이 있습니다:

• 너무 많은 것을 당신의 이름에 묶습니다. 당신의 이름은 당신이 아닙니다. 당신의 이름은 당신의 많은 속성 중 하나일 뿐입니다. 당신은 당신의 이름을 변경할 수 있어야 하며, 이를 위해 전체 신원 프로필을 이동하고 많은 애플리케이션에서 기록을 업데이트할 필요는 없습니다.
• 신뢰 없는 반사실 실명 이름을 가질 수 없습니다. 모든 블록체인의 주요 UX 특성 중 하나는 아직 체인과 상호작용하지 않은 사람에게 코인을 보낼 수 있는 능력입니다. 이러한 기능이 없다면, 닭과 계란 문제에 직면하게 됩니다: 체인과 상호작용하려면 거래 수수료를 지불해야 하며, 수수료를 지불하려면… 이미 코인을 소유해야 합니다. ETH 주소는 CREATE2가 있는 스마트 계약 주소를 포함하여 이 특성을 가지고 있습니다. ENS 이름은 그렇지 않습니다. 두 Bob이 체인 외부에서 bob.ecc.eth라고 결정하면, 어느 쪽이 이 이름을 얻는지 선택할 방법이 없습니다.

하나의 가능한 해결책은 이 글 앞부분의 아키텍처에서 언급된 키 저장소 계약에 더 많은 것을 넣는 것입니다. 키 저장소 계약은 당신과 당신과의 상호작용 방법에 대한 다양한 정보를 포함할 수 있으며(이를 통해 CCIP를 사용하여 일부 정보는 오프체인에서 처리될 수 있음), 사용자는 그들의 키 저장소 계약을 주요 식별자로 사용할 수 있습니다. 그러나 그들이 수신하는 실제 자산은 다양한 장소에 저장될 것입니다. 키 저장소 계약은 이름에 묶이지 않으며, 반사실 친화적입니다: 특정 고정 초기 매개변수를 가진 키 저장소 계약으로만 초기화할 수 있는 주소를 생성할 수 있습니다.

또 다른 해결책 범주는 사용자 지향 주소 개념을 포기하는 것과 관련이 있으며, 이는 비트코인 지불 프로토콜의 정신과 유사합니다. 한 가지 아이디어는 발신자와 수신자 간의 직접적인 통신 채널에 더 많이 의존하는 것입니다; 예를 들어, 발신자는 요청 링크(명시적인 URL 또는 QR 코드로)를 보내고, 수신자는 해당 링크를 사용하여 원하는 방식으로 지불을 수락할 수 있습니다.

발신자나 수신자 중 누가 먼저 행동하든, 지갑이 직접 실시간으로 최신 지불 정보를 생성하는 데 더 많이 의존하는 것은 마찰을 줄일 수 있습니다. 그럼에도 불구하고, 지속적인 식별자는 편리하며(특히 ENS와 함께), 실제로 발신자와 수신자 간의 직접적인 통신이 존재한다는 가정은 매우 까다로운 문제이므로, 우리는 다양한 기술의 조합을 볼 수 있을 것입니다.

이 모든 설계에서, 사물을 탈중앙화하면서도 사용자에게 이해하기 쉽게 유지하는 것이 중요합니다. 우리는 사용자가 현재 자산의 최신 뷰와 그들에게 게시된 정보를 쉽게 접근할 수 있도록 해야 합니다. 이러한 뷰는 독점 솔루션이 아닌 개방형 도구에 의존해야 합니다. 더 복잡한 지불 인프라가 개발자가 발생하는 일을 이해하기 어려운 불투명한 "추상 타워"로 변하지 않도록 하려면 노력해야 합니다. 도전이 있겠지만, 이더리움의 확장성, 지갑 보안 및 일반 사용자의 프라이버시를 실현하는 것은 매우 중요합니다. 이는 단순히 기술적 실행 가능성에 관한 것이 아니라, 일반 사용자의 실제 접근 가능성에 관한 것입니다. 우리는 이 도전에 맞서야 합니다.

특별히 Dan Finlay, Karl Floersch, David Hoffman 및 Scroll과 SoulWallet 팀의 피드백, 검토 및 제안에 감사드립니다.