Vitalik: Ethereum은 L2, 지갑 및 프라이버시의 세 가지 변환을 완료해야 합니다.

원래 제목: "The Three Transitions》

원본 편집: MarsBit, MK

원본 편집: MarsBit, MK

이더리움이 젊은 실험적 기술에서 일반 사용자에게 진정으로 개방적이고 글로벌하며 무허가 경험을 제공할 수 있는 성숙한 기술 스택으로 변환할 때 스택은 대략 동시에 세 가지 주요 기술 변환을 거쳐야 합니다.

1. 이더리움이 젊은 실험적 기술에서 일반 사용자에게 진정으로 개방적이고 글로벌하며 무허가 경험을 제공할 수 있는 성숙한 기술 스택으로 변환할 때 스택은 대략 동시에 세 가지 주요 기술 변환을 거쳐야 합니다.

2. L2 스케일링 전환 - 모두 롤업으로 마이그레이션됨

3. 월렛 보안 전환 - 모두 스마트 계약 월렛으로 마이그레이션

개인 정보 이동 - 개인 정보를 보호하는 송금을 보장하고 개발 중인 다른 모든 도구(사회 복구, 신원, 평판)가 개인 정보를 보호하는지 확인합니다.

첫 번째가 없으면 이더리움은 모든 거래 비용이 $3.75(또 다른 상승세가 있는 경우 $82.48)의 비용이 들기 때문에 실패하고 모든 대중 시장 제품은 결국 체인을 잊어버리고 모든 것을 위한 중앙 집중식 솔루션을 사용합니다.

두 번째가 없으면 사용자가 자금(및 비금융 자산)을 저장하기를 꺼리고 모두 중앙 집중식 거래소로 이동하기 때문에 이더리움은 실패할 것입니다.

두 번째가 없으면 사용자가 자금(및 비금융 자산)을 저장하기를 꺼리고 모두 중앙 집중식 거래소로 이동하기 때문에 이더리움은 실패할 것입니다.

세 번째가 없으면 이더리움은 실패할 것입니다. 모든 거래(및 POAP 등)가 공개되어 누구나 볼 수 있기 때문입니다. 이는 많은 사용자에게 엄청난 프라이버시 희생이 될 것이며 모든 사람이 적어도 일부 숨겨진 데이터를 중앙 집중화하도록 이동하게 될 것입니다. 해결책.

위에서 언급한 이유로 이 세 가지 전환이 중요합니다. 하지만 문제를 해결하는 데 필요한 강도 높은 조정 때문에 어려움을 겪기도 합니다. 프로토콜의 기능을 개선해야 할 뿐만 아니라 우리가 이더리움과 상호 작용하는 방식을 상당히 근본적으로 변경해야 하는 경우가 있어 애플리케이션과 지갑에 대한 심층적인 변경이 필요합니다.

이 세 가지 변화는 사용자와 주소 간의 관계에 혁명을 일으킬 것입니다.

L2 확장 세계에서 사용자는 많은 L2에 존재하게 됩니다. Optimism에 있는 ExampleDAO의 회원이십니까? 그러면 Optimism에 대한 계정이 생겼습니다! ZkSync의 스테이블 코인 시스템에서 CDP를 보유하고 있습니까? 그러면 ZkSync에 계정이 생겼습니다! 카카로트에 있는 앱을 사용해 보셨나요? 그러면 카카로트에 계정이 생깁니다! 사용자가 하나의 주소만 가지던 시대는 지났습니다.

내 Brave Wallet 보기에 따르면 네 곳에 ETH가 있습니다. 예, Arbitrum과 Arbitrum Nova는 다릅니다. 걱정하지 마십시오. 시간이 지남에 따라 더 복잡해집니다!"type 4 ZK-EVMs"스마트 계약 지갑은 복잡성을 더해 L1 및 다양한 L2에서 동일한 주소를 갖는 것을 더 어렵게 만듭니다. 오늘날 대부분의 사용자는 주소가 실제로 서명을 확인하는 데 사용되는 공개 키의 해시인 외부 소유 계정을 사용하고 있으므로 L1과 L2 간에 변경되는 사항은 없습니다. 그러나 스마트 계약 지갑을 사용하면 주소를 유지하는 것이 더 어려워집니다. 주소를 네트워크 간 등가 코드, 특히 CREATE 2 및 ERC-2470 싱글톤 팩토리의 해시로 만들기 위해 많은 작업이 수행되었지만 이를 완벽하게 달성하는 것은 매우 어려웠습니다. 일부 L2(예:

)는 EVM과 정확히 일치하지 않으며 일반적으로 Solidity 또는 중간 어셈블리가 대신 사용되어 해시 동등성을 방지합니다. 해시 등가성을 가질 수 있더라도 키 변경을 통해 지갑의 소유권이 변경될 가능성은 다른 직관적이지 않은 결과를 초래합니다.

프라이버시를 위해서는 사용자당 더 많은 주소가 필요하며 처리하는 주소 유형이 변경될 수도 있습니다. 개인 주소 제안이 널리 사용되는 경우 사용자당 몇 개의 주소 또는 L2당 하나의 주소 대신 트랜잭션당 하나의 주소가 있을 수 있습니다. Tornado Cash와 같은 기존 개인 정보 보호 체계를 비롯한 다른 개인 정보 보호 계획은 자산 저장 방식을 다르게 변경합니다. 많은 사용자의 자금이 동일한 스마트 계약(따라서 동일한 주소)에 저장됩니다. 특정 사용자에게 자금을 보내려면 사용자는 개인정보 보호 체계의 자체 내부 주소 시스템에 의존해야 합니다.

우리가 본 것처럼 세 가지 변화는 "한 명의 사용자 ~= 하나의 주소" 정신 모델을 다양한 방식으로 약화시켰고 이러한 효과 중 일부는 변화를 구현하는 복잡성으로 다시 피드백되었습니다. 두 가지 특정 합병증은 다음과 같습니다.

1. 누군가에게 돈을 지불하고 싶다면, 그 사람에게 돈을 지불하기 위한 정보를 어떻게 얻나요?

2. 사용자가 서로 다른 체인의 서로 다른 위치에 많은 자산을 저장하는 경우 키 교체 및 소셜 복구를 어떻게 수행합니까?

3교대는 온체인 결제(및 신원)에 관한 것입니다.

Scroll에 동전이 있고 커피 값을 지불하고 싶습니다("I"가 문자 그대로 나를 이 기사의 저자로 언급하는 경우 "커피"는 물론 "녹차"의 환유어입니다). 당신은 나에게 커피를 팔고 있지만 Taiko에서 동전만 받을 것입니다. 나는 무엇을 해야 합니까?

기본적으로 두 가지 솔루션이 있습니다.

1. 수신 지갑(가맹점 또는 일반 개인일 수 있음)은 자금을 비동기식으로 통합하는 일부 자동 기능을 통해 각 L2를 지원하기 위해 노력합니다.

2. 수신자는 L2와 주소를 제공하고 발신자의 지갑은 일종의 L2 간 브리징 시스템을 통해 자금을 대상 L2로 자동 라우팅합니다.

물론 이러한 솔루션을 결합할 수 있습니다. 수신자는 기꺼이 수락할 L2 목록을 제공하고 발신자의 지갑은 지불을 계산합니다. 여기에는 직접 전송(운이 좋은 경우) 또는 L2를 가로지르는 브리지 경로를 포함할 수 있습니다.

그러나 이것은 3교대 근무에 의해 도입된 주요 문제의 한 예일 뿐입니다. 누군가에게 돈을 지불하는 것과 같은 단순한 것이 20바이트 주소보다 더 많은 정보를 요구하기 시작합니다.

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

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

프라이버시 주소 프로토콜은 다음과 같은 방식으로 작동하는 메타 주소의 개념에 의존합니다. 메타 주소의 일부는 보낸 사람 지출 키의 블라인드 버전이고 다른 부분은 보낸 사람의 암호화 키입니다(최소한의 구현이지만) 이것을 설정할 수 있습니다. 두 키는 동일합니다).

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

세 가지 변환 및 키 복구

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

• 비현실적인 가스 요금: 이것은 그 자체로 말합니다.

• Counterfactual Address: 아직 스마트 컨트랙트가 공개되지 않은 주소(실제로는 아직 자금을 보내지 않은 계정을 의미함). 사용자는 잠재적으로 무한한 수의 반사실 주소를 갖게 됩니다. 즉, 아직 존재하지 않는 L2를 포함하여 모든 L2에 하나 이상, 스테가노그래피 주소 체계에서 파생된 완전히 다른 무한 반사실 주소 세트가 있습니다.

개인 정보 보호: 사용자가 서로 연결하지 않기 위해 의도적으로 많은 주소를 가지고 있는 경우, 동시에 또는 거의 동시에 복원하여 모든 주소를 공개적으로 연결하고 싶지 않을 것입니다!

이러한 문제를 해결하는 것은 어렵습니다. 다행히도 꽤 잘 작동하는 우아한 솔루션이 있습니다. 유효성 검사 논리와 자산 보유를 분리하는 아키텍처입니다.

각 사용자는 한 위치(메인넷 또는 특정 L2일 수 있음)에 존재하는 키 저장소 계약을 가지고 있습니다. 그런 다음 사용자는 서로 다른 L2에 주소를 가지며 각 주소에 대한 확인 논리는 키 저장소 계약에 대한 포인터입니다. 이러한 주소에서 지출하려면 현재(또는 더 현실적으로는 가장 최근) 지출 공개 키를 보여주는 키 저장소 계약에 대한 증거가 필요합니다.

여러 가지 방법으로 증명할 수 있습니다.

1. L2에서 직접 읽기 전용 L1 액세스. L2는 L1의 상태를 직접 읽을 수 있도록 수정될 수 있습니다. 키 저장소 계약이 L1에 있는 경우 이는 L2의 계약이 키 저장소에 "무료" 액세스할 수 있음을 의미합니다.

2. 메르켈 지사. Merkle 분기는 L1 상태를 L2에 증명하거나 L2 상태를 L1에 증명하거나 두 가지를 결합하여 한 L2 상태의 일부를 다른 L2에 증명할 수 있습니다. Merkle 증명의 주요 약점은 증명 길이로 인한 높은 가스 비용입니다. 증명에는 5kB가 필요할 수 있지만 Verkle 트리 덕분에 향후 1kB 미만으로 줄어들 것입니다.

3. ZK-SNARK. 브랜치 자체 대신 머클 브랜치의 ZK-SNARK를 사용하면 데이터 비용을 줄일 수 있습니다. 단일 ZK-SNARK가 하나의 블록에서 모든 교차 체인 상태 증명을 검증하도록 오프 체인 집계 기술(예: EIP-4337 기반)을 구축할 수 있습니다.

4. KZG 약속. L2 또는 그 위에 구축된 체계는 이 시스템 내부의 상태 증명이 48바이트 길이에 불과하도록 허용하는 순차 주소 지정 시스템을 도입할 수 있습니다. ZK-SNARK와 마찬가지로 다중 증명 체계는 이러한 모든 증명을 각 블록에 대한 단일 증명으로 결합할 수 있습니다.

각 트랜잭션에 대해 증명을 수행하지 않으려면 더 가벼운 솔루션을 구현할 수 있으며 복구할 때 교차 L2 증명만 수행하면 됩니다. 계정의 지출은 해당 공개 키가 계정에 저장된 지출 키에 따라 달라지지만 복구에는 키 저장소의 현재 지출 공개 키를 복사하는 트랜잭션이 필요합니다. 반사실 주소의 자금은 이전 키가 아닌 경우에도 안전합니다. 반사실 주소를 "활성화"하고 작동하는 계약으로 전환하려면 현재 지출 공개 키를 복제하는 교차 L2 증명을 수행해야 합니다. Safe 포럼의 이 스레드는 유사한 아키텍처가 작동하는 방식을 설명합니다.

이러한 체계에 프라이버시를 추가하려면 포인터를 암호화한 다음 ZK-SNARK에서 모든 증명을 수행하면 됩니다.

더 많은 작업을 통해(예: 이 작업을 시작점으로 사용) ZK-SNARK의 복잡성을 대부분 제거하고 더 간단한 KZG 기반 체계를 만들 수 있습니다.

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

많은 보조 인프라를 업데이트해야 함

ENS를 사용하는 것은 비용이 많이 듭니다. 2023년 6월 현재 상황은 그리 나쁘지 않습니다. 거래 수수료는 높지만 ENS 도메인 수수료와 비슷합니다. zuzalu.eth에 등록하는 데 드는 비용은 약 27달러이며 그 중 11달러는 거래 수수료입니다. 그러나 우리가 또 다른 강세장이 있다면 수수료는 치솟을 것입니다. ETH 가격 인상 없이도 가스 수수료가 200gwei로 반환되면 도메인 등록 거래 수수료는 $104로 인상됩니다. 따라서 사람들이 실제로 ENS를 사용하기를 원한다면, 특히 사용자가 거의 무료 등록을 요청하는 분산형 소셜 미디어와 같은 사용 사례의 경우(이 플랫폼은 사용자에게 하위 도메인을 제공하므로 ENS 도메인 요금은 문제가 되지 않음) L2에서 ENS 실행이 필요합니다. .

다행히도 ENS 팀은 이미 움직이고 있으며 L2의 ENS가 실제로 진행되고 있습니다! ERC-3668("CCIP 표준"이라고도 함)은 ENSIP-10과 함께 모든 L2에서 ENS 하위 도메인을 자동으로 검증하는 방법을 제공합니다. CCIP 표준은 L2 데이터의 증명을 확인하는 방법을 설명하는 스마트 계약을 설정해야 하며 도메인 이름(예: Optinames의 경우 ecc.eth)은 이러한 계약의 제어를 받을 수 있습니다. CCIP 계약이 L1에서 ecc.eth를 제어하면 일부 subdomain.ecc.eth에 액세스하면 해당 특정 하위 도메인을 실제로 저장하는 증거(예: Merkle 분기)의 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 상태 및 Merkle 분기를 확인하는 데 중점을 둡니다. 내일 그들은 또한 L1에 저장된 상태 루트에서 발생하는 L2 상태의 증명을 확인해야 합니다(이 고급 버전은 실제로 L2의 사전 확인을 봅니다).

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

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

우리는 Zuzalu에서 사용되는 ZK-SNARK 기반 신원 시스템인 Zupass로 그러한 세계의 첫 징후를 보았습니다. 사용자는 시스템을 인증하는 데 사용하는 개인 키를 가지고 있습니다. 이 키는 "내가 Zuzalu의 거주자임을 증명하지만 누구인지 밝히지 마십시오"와 같은 기본적인 증명을 수행하는 데 사용할 수 있습니다. 그러나 Zupass 시스템은 또한 그 위에 구축된 다른 응용 프로그램, 특히 Stamps(POAP의 Zupass 버전)를 갖기 시작했습니다.

내가 Team Cat의 자랑스러운 멤버임을 증명하는 많은 Zupass 우표 중 하나입니다.

스탬프가 POAP를 통해 제공하는 주요 기능은 스탬프가 비공개라는 것입니다. 즉, 데이터를 로컬에 보유하고 스탬프(또는 일부 계산)에 대한 정보를 원하는 경우에만 스탬프를 증명합니다. 그러나 이것은 위험을 증가시킵니다. 이 정보를 잃으면 스탬프를 잃게 됩니다.

물론 데이터 보유 문제는 암호화 키 보유 문제로 귀결됩니다. 제3자(또는 체인)가 암호화된 데이터 사본을 보유할 수 있습니다. 이것은 사용자가 취하는 조치가 암호화 키를 변경하지 않는다는 편리한 이점이 있으므로 암호화 키를 안전하게 유지하는 시스템과의 상호 작용이 필요하지 않습니다. 하지만 그런 경우에도 암호화 키를 분실하면 모든 것을 잃게 됩니다. 반대로 누군가가 귀하의 암호화 키를 본다면 해당 키로 암호화된 모든 것을 볼 수 있습니다.

Zupass의 사실상의 솔루션은 동시에 모든 키를 잃어버릴 가능성이 적기 때문에 사람들이 여러 장치(예: 노트북 및 전화)에 키를 저장하도록 권장하는 것입니다. 한 단계 더 나아가 비밀 공유를 사용하여 키를 저장하고 여러 보호자에게 키를 분할할 수 있습니다.

MPC를 통한 소셜 복구는 지갑에 적합한 솔루션이 아닙니다. 이는 현재 가디언뿐만 아니라 이전 가디언이 공모하여 자산을 훔칠 수 있음을 의미하며 이는 용납할 수 없는 높은 위험입니다. 그러나 개인정보 침해는 일반적으로 자산의 완전한 손실보다 위험이 적으며, 누군가가 고도의 개인정보 보호 사용 사례가 필요한 경우 개인정보가 필요한 관련 키를 백업하지 않음으로써 더 높은 손실 위험을 감수할 수 있습니다. 보존 조치.

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

정체성으로 돌아가기

이러한 변경 사항의 공통 주제는 "귀하"를 나타내는 암호화 식별자로 온체인에서 사용하는 "주소"의 개념이 근본적으로 변경되어야 한다는 것입니다. "나와 상호 작용하는 방법에 대한 지침"은 더 이상 단순한 ETH 주소가 아니며, 여러 L2의 여러 주소, 비밀 메타 주소, 암호화 키 및 어떤 형태의 기타 데이터 조합을 포함해야 합니다.

이를 수행하는 한 가지 방법은 ENS를 귀하의 신원으로 만드는 것입니다. 귀하의 ENS 레코드에는 이 모든 정보가 포함될 수 있으며 누군가에게 bob.eth(또는 bob.ecc.eth 또는...)를 보내면 보다 복잡한 교차 절단 및 개인 정보 보호 방법을 포함하여 귀하와 지불하고 상호 작용하는 모든 것.

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

• 그것은 당신의 이름에 너무 많은 것을 묶습니다. 당신의 이름은 당신이 아닙니다. 당신의 이름은 당신의 많은 속성 중 하나일 뿐입니다. 전체 ID 프로필을 이동하고 많은 앱에서 여러 레코드를 업데이트하지 않고도 이름을 변경할 수 있어야 합니다.

신뢰할 수 없는 반사실 이름을 사용할 수 없습니다. 모든 블록체인의 주요 UX 기능은 아직 체인과 상호 작용하지 않은 사람들에게 코인을 보낼 수 있는 기능입니다. 이러한 기능이 없으면 닭이 먼저냐 달걀이 먼저냐의 문제가 있습니다. 체인과 상호 작용하려면 거래 수수료를 지불해야 하고 수수료를 지불하려면 이미 코인을 소유하고 있어야 합니다. CREATE 2가 포함된 스마트 컨트랙트 주소를 포함한 ETH 주소에는 이 기능이 있습니다. ENS 이름은 그렇지 않습니다. 두 Bob이 둘 다 bob.ecc.eth 오프체인이라고 결정하면 어느 쪽이 이름을 가질지 선택할 방법이 없기 때문입니다.

한 가지 가능한 해결책은 이 게시물 앞부분의 아키텍처에서 언급한 키 저장소 계약에 더 많은 항목을 넣는 것입니다. 키 저장소 계약에는 귀하에 대한 다양한 정보와 상호 작용 방식(CCIP를 통해, 일부는 오프체인일 수 있음)이 포함될 수 있으며 사용자는 키 저장소 계약을 기본 식별자로 사용할 수 있습니다. 그러나 그들이 받는 실제 자산은 다양한 장소에 저장됩니다. 키 저장소 계약은 이름에 구속되지 않고 반사실적입니다. 고정된 초기 매개변수가 있는 키 저장소 계약으로만 초기화할 수 있는 주소를 생성할 수 있습니다.

솔루션의 또 다른 범주는 Bitcoin 지불 프로토콜과 정신이 유사한 사용자 지향 주소 개념을 포기하는 것과 관련이 있습니다. 예를 들어 발신자는 수신자가 원하는 방식으로 결제 수락을 사용할 수 있는 청구 링크(명시적 URL 또는 QR 코드)를 보낼 수 있습니다.

가장 먼저 행동하는 것이 발신자이든 수신자이든 지갑에 더 의존하여 실시간으로 최신 결제 정보를 직접 생성하면 마찰이 줄어듭니다. 그러나 영구 식별자는 편리하며(특히 ENS 사용 시) 실제로 발신자와 수신자 간의 직접 통신 가정은 매우 까다로운 문제이므로 서로 다른 기술의 조합을 살펴볼 수 있습니다.

이러한 모든 디자인에서 사물을 분산화하고 사용자가 이해할 수 있도록 유지하는 것이 중요합니다. 우리는 사용자가 자신의 현재 자산에 대한 최신 보기 및 게시된 정보에 쉽게 액세스할 수 있도록 해야 합니다. 이러한 보기는 독점 솔루션이 아닌 개방형 도구에 의존해야 합니다. 개발자가 무슨 일이 일어나고 있는지 이해하고 새로운 환경에 적응할 수 있도록 더 복잡한 결제 인프라가 불투명한 "추상화의 탑"이 되지 않도록 하려면 많은 노력이 필요할 것입니다. 어려움에도 불구하고 Ethereum의 확장성, 지갑 보안 및 일반 사용자의 개인 정보 보호를 달성하는 것이 가장 중요합니다. 기술적인 타당성에 관한 것이 아니라 일반 사용자의 실제 접근성에 관한 것입니다. 우리는 이 도전에 맞서야 합니다.