계정 추상화가 구현되려면 시간이 좀 걸리겠지만, 앞으로 신규 사용자에 대한 문턱을 낮추고 사용자 경험을 개선할 수 있는 유일한 방법이 될 것입니다.
계정 추상화가 구현되려면 시간이 좀 걸리겠지만, 앞으로 신규 사용자에 대한 문턱을 낮추고 사용자 경험을 개선할 수 있는 유일한 방법이 될 것입니다.
자체 호스팅해야 하는 지갑 주소는 체인 세계에서 사용자의 "계정"이지만 사용자가 Web3에 들어가는 것을 방해하는 주요 장애물이기도 합니다. 계정 개선을 위해 7년 이상 지속된 실험입니다. 2022년 10월까지 Vitalik은 계정 추상화에 대한 EIP-4337을 소개하는 스레드를 트윗했습니다. 계정 추상화는 11월 보고타에서 열린 devcon 6의 다양한 공유 세션에 자주 등장하여 계정 추상화에 대한 토론을 촉발했습니다. .
계정 추상화는 온체인 사용자를 지원하는 데 매우 중요합니다. "당신의 열쇠도, 당신의 코인도 아닙니다." 암호화폐 베테랑들이 셀프호스팅을 몇 번이나 강조했는지는 모르겠지만, 아직 할 수 있는 사람은 거의 없습니다. 계정 추상화로 인한 매우 높은 자유도는 일반 사용자에게 진정으로 더 안전하고 사용하기 쉬운 탈중앙화 경험을 제공할 수 있습니다. FTX의 폭발적인 성장은 암호화된 세계의 미래에 깊은 그림자를 드리웠지만, 탈중앙화 애플리케이션과 자체 호스팅의 필요성을 분명히 확인했습니다. 계정 추상화의 구현으로 암호화 산업은 중앙 집중식 악당과 황제로부터 스스로를 더 자유롭게 할 수 있고 더 높은 차원의 탈중앙화와 자유를 향해 나아갈 수 있습니다.
현재 EIP-4337은 많은 사람들에게 계정 추상화의 방향 지표로 간주되지만 제안은 여전히 이상적인 초안일 뿐입니다. 예를 들어 이상적으로 트랜잭션 패키징은 가스를 공유할 수 있지만 실제로는 검증 과정에서 가스 소비가 증가합니다. 예를 들어 EIP-4337을 사용하는 이상적인 계정은 더 나은 사용자 경험을 제공할 수 있지만 실제로는 많은 dapp이 계약 주소 상호 작용을 금지하는 당혹스러운 상황입니다...
첫 번째 레벨 제목
텍스트
계정 추상화의 구체적인 의미를 논의하기 전에 "계정"과 "추상화"가 무엇인지 이해하기 위해 먼저 분해할 수 있습니다.
보조 제목
계정 계정
Ethereum에는 외부 소유 계정(EOA)과 계약 계정(계약 계정 - CA)의 두 가지 기본 계정 유형이 있습니다.
보조 제목
추상적인
추상화는 특정 문제에서 공통 패턴을 추출한 다음 일반적인 솔루션을 사용하여 이를 처리하는 것을 말합니다. 즉, 추상화는 특수성을 제거하고 공통성을 찾는 "일반화"의 과정입니다.
보다 현실적이고 구체적인 예인 장난감 자동차와 레고 블록으로 추상화를 이해해 봅시다. 작은 자동차 장난감의 구조는 특별하고 구체적이며 네 개의 바퀴와 몸체와 같은 일련의 특수 부품으로 구성됩니다. 작은 트럭 장난감이나 비행기 장난감을 갖고 싶다면 새 장난감을 사야 합니다. 레고 빌딩 블록은 더 추상적이고 더 일반적입니다. 그는 장난감을 정육면체 및 구체와 같은 일반 빌딩 블록 모듈로 추상화합니다. 플레이어는 이러한 빌딩 블록을 사용하여 장난감 모양을 만들 수 있습니다.
보조 제목
계정 추상화
계정 추상화는 이더리움 계정의 일반화와 특이성의 제거를 의미합니다. 우리는 또한 이전 기사에서 이더리움에 두 가지 유형의 계정이 있다고 언급했습니다. EOA와 CA는 각각 고유한 특성을 가지고 있으며, 그 중 EOA는 보다 "최상위" 계정이며 모든 거래는 EOA에 의존하여 ETH를 시작하고 지불할 수 있습니다. 가스 및 EOA는 특정 Secp 256 k 1 타원 암호화 알고리즘에 의해 구현되는 ECDSA 서명 체계만 사용할 수 있습니다. 그러나 EOA는 코드 로직을 직접 지원하지 않습니다. 코드 논리를 지원하는 CA는 EOA에 의해 트랜잭션을 배포하고 시작해야 합니다.
이 모든 것은 이더리움 최하층의 특별한 필수 설계입니다. 계정 추상화의 목적은 이더리움 계정을 일반화하여 더 높은 자유도를 갖고 계정의 가능성을 확장하는 것입니다. 계정의 특수성을 일반화하면 다음과 같은 계정의 추상 키를 추출할 수 있습니다.
암호화 추상화: 즉, 계정 서명 확인은 더 이상 특정 암호화 알고리즘에 제한되지 않으며 사용자는 보안 메커니즘으로 다른 암호화 알고리즘을 사용자 정의하고 선택할 수 있습니다.
계정 기능 추상화: 코드 로직 지원 및 맞춤형 기능 실현
트랜잭션 추상화: 계정이 트랜잭션을 시작할 수 있음, 가스 결제 사용자 정의
첫 번째 레벨 제목
계정 추상화의 개발 과정 - 급진적인 것에서 온건한 것, 최종 상태로의 전환
추상화에 대한 논의는 2015년 이더리움 네트워크가 공식적으로 출시된 지 몇 달 후에 시작되었으며 올해 10월까지 새로운 제안이 계속 제시되었습니다. 계정 추상화의 다양한 솔루션과 개발을 엿볼 수 있도록 계정 추상화와 관련된 EIP를 연대순으로 정렬합니다.
여기에서 계정 추상화 체계의 개발은 세 단계로 나뉩니다.
2015년 이더리움 출시 이후 EIP-86은 처음으로 계정 추상화를 제안했고 이상주의로 가득 찬 5년 간의 급진적 개혁을 시작했습니다. 이더리움의 기본 코드를 직접 변경한 이러한 계정 추상화 제안은 검토 단계로 진출하지 못했지만 일부 보조 제안은 통과되어 계정 추상화를 위한 일정한 기반을 마련했습니다. 예를 들어, EIP-1014는 컨트랙트를 배포하지 않고도 컨트랙트 주소를 미리 계산할 수 있음을 인식하고 EIP-1271은 컨트랙트 계정을 통해 서명하는 방식을 구현합니다.
급진적인 개혁에 좌절한 계정 추상화는 좀 더 겸손한 타협을 찾기 시작했습니다. 이 단계에서는 더 이상 Ethereum의 기본 코드를 직접 변경하려는 시도가 아니라 주로 개발자가 자발적으로 채택한 ERC 표준을 시작하는 것입니다. EIP-4337이 탄생하여 계정 추상화의 완만한 발전 시대를 열었습니다. 최근 EIP-5189는 4337의 아이디어를 기반으로 한 추가 최적화 방안을 제안했습니다.
ERC 표준의 계정 추상화 체계는 기본 코드의 느린 변경, 큰 영향 및 낮은 호환성에 대한 절충안입니다. 이러한 부드러운 접근 방식은 계정 추상화 개념의 보급에 도움이 되므로 계정 추상화는 먼저 이상적인 논의에서 실제 현실에 이르기까지 단계별로 구현되고 기존 솔루션의 단점을 지속적으로 개선하고 개선할 수 있습니다.
보조 제목
과거 - 급진적 개혁
관련 제안이 처음 제안된 이후 계정 추상화에 대한 해결책은 항상 합의 계층을 직접 변경하는 폭력적인 개혁 계획이었으며 현재 단계 제안에서 지속적으로 개선되었습니다.
EIP-101
프로그램 소개:
2015년 말, 이더리움 설립자 Vitalik은 EIP-101에서 처음으로 추상화를 제안했습니다. 이 제안에서 Vitalik은 Serenity에서 계정 시스템의 추상적인 설계에 대해 논의하여 계정을 4개 필드에서 코드 및 저장소의 2개 필드로 단순화했습니다.ETH는 토큰 계약에 저장되며 사용자 잔액을 매핑하는 주소는 예약됩니다. ; 트랜잭션이 8개 필드에서 4개 필드로 단순화되어 계정 및 트랜잭션이 크게 추상화됩니다.
이점:
다른 암호화 알고리즘을 사용하여 계정 보안을 보호하는 사용자 정의 보안 모드
ETH 및 기타 ERC 20 토큰은 동등하게 취급될 수 있습니다.
다중 서명과 같은 사용자 정의 계정 기능의 간접 감소.
문제 및 현상 유지:
이 제안은 계정 시스템을 대폭 변경했으며 호환성 문제 및 보안 위험이 있으므로 샤딩 후 일시적으로 보류되었으며 현재 정체 상태입니다.
EIP-86
프로그램 소개:
2017년에 Vitalik은 트랜잭션 소스와 서명을 추상화하고 기본 코드를 다시 급진적으로 변경하는 EIP-86을 제안했습니다. 이 제안을 통해 사용자는 모든 서명 및 논스 확인 메커니즘을 사용할 수 있는 계정 계약을 만들 수 있습니다. 이 방식에는 진입점 계약이 있습니다.이 계약을 통해 누구나 트랜잭션을 보낼 수 있습니다.계정 계약은 진입점에서 데이터를 수신하고 서명을 확인하고 맞으면 광부에게 가스를 지불합니다. 이 솔루션은 계정 추상화를 위한 준비로, 사용자가 서명 알고리즘을 사용자 정의할 수 있으며 더 이상 이더리움의 하드 코딩된 ECDSA 및 기본 논스 메커니즘을 사용할 필요가 없으며 동시에 서명이 확인된 후 계약 계정에서 가스를 지불합니다. 바르게.
이점:
다중 서명: 모든 다중 서명자는 ETH를 소유할 필요가 없으며, 다중 서명 정보가 포함된 거래는 다중 서명 계정으로 직접 전송될 수 있으며 다중 서명 계정은 다중 서명 계정에서 직접 지불됩니다.
링 서명 혼합 통화: 링 서명은 서명을 연결하여 링을 형성하는 것을 말하므로 시작점을 판단할 수 없습니다. n 사용자는 계약에 동일한 수의 토큰을 보낸 다음 링 서명 방법을 사용하여 동일한 수의 토큰을 인출합니다. 그러나 토큰 출금을 위한 가스를 준비해야 하기 때문에 이 단계에서 노출 위험이 있습니다. 따라서 이 제안을 통해 추출된 토큰에서 가스를 직접 지불할 수 있으므로 이 시나리오에서 프라이버시가 보장됩니다.
맞춤형 암호화: 사용자는 Lamport와 같은 양자 안전 서명 방법을 사용하여 계정 보안을 보장할 수 있습니다.
비암호화 기능 사용자 지정: 트랜잭션 만료 시간 설정 등
문제 및 현상 유지:
새 거래 유형에는 거래 발신자(모든 진입점)가 없으므로 해시의 고유성이 파괴됩니다. 해시 고유성에 기반한 프로토콜 작업과 호환되지 않음
Gas-free 결제의 필요성이 미흡하고, 현재 대리점 계약을 통해서도 실현이 가능하나, 비용은 다소 높아질 예정입니다.
채굴자들의 채굴 전략이 크게 영향을 받을 것입니다.
새로운 트랜잭션 유형은 nonce, gasprice, value 및 기타 필드를 유지하고 코드 우아함이 부족한 0으로 설정됩니다.
따라서 이러한 문제점을 바탕으로 제안이 결국 유보되어 현재 정체되어 있다.
EIP-859
프로그램 소개:
이 제안은 새로운 트랜잭션 유형과 새로운 opcode를 도입하고 트랜잭션 해시의 고유성을 유지하기 위해 트랜잭션에서 nonce 필드는 여전히 필수입니다. 가스 결제를 위한 Paygas 연산 코드를 도입하고 거래의 검증 부분과 거래의 실행 부분 사이의 논리적 경계 역할을 합니다.
이점:
맞춤형 서명 체계 맞춤형 서명 체계
트랜잭션 해시 고유성 유지
더 복잡한 검증 시나리오를 지원하고 가스를 절약할 수 있습니다.예를 들어 토큰 ICO 중에 10,000개의 트랜잭션이 동시에 참여하지만 토큰은 온라인으로만 처음 5,000개의 트랜잭션을 지원합니다.기존 논리에 따르면 10,000개 모두 이 제안에 따라 계약은 마지막 5,000개의 트랜잭션을 블록체인에 포함하지 않도록 설정할 수 있으므로 가스 소비를 줄이고 유효하지 않은 스팸 트랜잭션을 줄일 수 있습니다.
문제 및 현상 유지:
ERC-20 토큰으로 가스 지불을 지원하지 않습니다.
Cannot use ERC 20 s to pay for gas
사실 이 제안은 아직 최종 초안을 작성하지 않았으며 논의 단계에 불과합니다. 이 제안은 여러 Ethereum 개발자 회의에서도 논의되었지만 충분히 성숙하지 않았고 당시 업그레이드에 많은 콘텐츠가 포함되어 있었기 때문에 제안도 영구적으로 보류되었습니다.
EIP-1014
프로그램 소개:
제안은 계정 추상화를 직접적으로 언급하지는 않지만 계정 추상화의 발전과 밀접한 관련이 있습니다. 본 제안은 컨트랙트 주소를 실제로 배포하기 전에 컨트랙트 주소를 미리 계산하고 컨트랙트 주소를 배포하기 전에 해당 주소로 자산을 전송하는 방법을 소개합니다.
이점:
비용 절감: 사용자는 계약을 배포하기 위해 가스를 지불하기 전에 사전에 계약 주소를 계산할 수 있습니다.
다중 체인 계약 주소 일관성: 계약 주소는 존재하기 전에 배포해야 하므로 EOA와 달리 다중 체인 일관성을 직접 달성할 수 있습니다.
현상 유지:
이 제안은 마침내 통과되어 스마트 계약 지갑 개발을 위한 중요한 토대를 마련했습니다.
EIP-1271
프로그램 소개:
이 제안은 계약 계정을 나타내는 서명이 유효한지 확인하기 위한 일련의 기준을 제공합니다. 이를 통해 계약 계정은 EOA와 같은 서명 확인을 수행할 수 있습니다.
이점:
이 제안은 개발자가 자발적으로 채택할 수 있는 확립된 ERC 표준입니다. 이것은 향후 계약 계정의 홍보 및 대중화를 위한 좋은 기반을 마련했습니다.dapp이 계약 주소 서명을 지원하는 한 계약에 EIP-1271 코드를 추가하기만 하면 됩니다.
현상 유지:
제안이 마침내 통과되었으며 서명 로그인을 위한 authereum 계약 지갑을 지원하는 opensea와 같은 실용적인 응용 프로그램이 이미 있습니다.
EIP-2938
프로그램 소개:
2020년 Vitalik은 더 완벽한 계정 추상화 솔루션을 제안하기 위해 많은 사람들과 협력했습니다. 계정 유형을 하나의 계약 계정으로 통합한 이전 계정 추상화 목표와 비교하여 EIP-2938 제안은 여전히 기존 EOA 및 계약 계정을 유지하지만 거래 가스를 지불할 수 있도록 계약을 최상위 계정으로 수락합니다. 트랜잭션 실행 프로세스를 시작합니다.
이 제안은 새로운 유형의 트랜잭션인 계정 추상화 트랜잭션을 정의하고 Nonce 및 PAYGAS라는 두 가지 opcode를 도입합니다. 이 개선 사항은 여전히 이더리움의 기본 코드에 대한 변경이 필요했습니다.
EIP-2938은 또한 이 솔루션 구현을 계획하고 특정 애플리케이션 시나리오를 설명합니다. 계정 추상화는 두 가지 수준으로 나뉩니다. 첫 번째는 단일 테넌트 계정 추상화를 구현한 다음 다중 테넌트 계정 추상화로 확장하는 것입니다.
이점 및 시나리오:
단일 테넌트 단일 테넌트
ECDSA 이외의 서명 확인 방법(예: BLS, 사후 양자)의 사용을 사용자 지정합니다.
다중 서명 검증 및 소셜 복구와 같은 계약 지갑 기능 추가
ERC-20 토큰으로 가스 비용을 지불하세요.
멀티 테넌트 멀티 테넌트
프라이버시: 토네이도 현금과 같은 프라이버시 보호 시나리오에서 계정은 더 이상 프라이버시를 노출하기 위해 가스 수수료를 준비할 필요가 없습니다.
Save gas: 예를 들어 차익거래 기회가 발생하면 많은 차익거래자들이 동시에 차익거래를 시작하고 첫 번째 차익거래가 성공한 후 다른 차익거래는 실패하지만 여전히 블록에 패키징된다. 더 이상 실패에 대한 비용을 지불할 필요가 없습니다 차익 거래를 위한 지불 가스는 체인의 스팸 트랜잭션 수를 줄입니다.
문제 및 현재 상황:
계획은 더 상세하지만 멀티 테넌트 단계에 대한 기술 계획은 아직 미정입니다. 그리고 이 솔루션은 기술적으로나 경제적으로 충분히 효율적인 것으로 간주되지 않았기 때문에 최종 단계에 진입하지 못했습니다.
보조 제목
나우 - 젠틀 체인지
이더리움 개발자들은 이더리움의 병합과 샤딩에 초점을 맞추고 있으며, 기반 프로토콜을 직접 변경하는 계획을 진행하기는 어려우므로 Vitalik으로 대표되는 개발자들은 타협하여 상대적으로 온화하고 간접적인 대안을 제시해야 합니다.
EIP 4337
프로그램 소개:
이 제안은 Ethereum의 기본 코드를 변경할 필요가 없는 최초의 계정 추상화 제안입니다. ERC-4337에서 UserOperation 개체가 도입되었습니다. 사용자는 UserOperation 개체를 별도의 메모리 풀로 보냅니다. 번들러는 이러한 개체를 트랜잭션으로 패키징하고 진입점 계약을 호출한 다음 트랜잭션이 블록에 포함됩니다.
이점:
맞춤형 서명 알고리즘: ECDSA 이외의 서명 알고리즘 지원
기능 커스터마이제이션: 계약 코드를 통해 가스 결제 및 소셜 복구와 같은 기능을 실현할 수 있습니다.
문제 및 현재 상황:
업그레이드 불가능: 사용자는 표준을 지원하기 위해 자산 및 활동을 새 주소로 이전해야 합니다.
가스 오버헤드가 더 높음: 도입된 사용자 작업으로 인해 더 높은 가스 소비가 발생합니다.
호환성 문제: 일부 기존 dapp 또는 프로토콜은 계약 계정과의 상호 작용을 금지할 수 있습니다.
현실적인 문제가 많지만 비탈릭은 단기적으로 ERC-4337을 강력하게 지원하고 실습 과정에서 더 나은 솔루션을 연구하고 지속적으로 개선하고 개선하기를 희망합니다. 대규모 프로모션을 달성한 후 합의 및 규모 효과의 형성은 기존 애플리케이션의 변경을 촉진하고 계약 계정의 상호 작용을 지원하며 ERC-1271의 계약 서명 표준을 지원하는 데 도움이 될 것입니다. 현재 EIP 4337은 아직 초안 상태이며 다음 단계로 계속 진행되기를 기다리고 있습니다.
EIP-5189
프로그램 소개:
이 제안은 트랜잭션 패키징 프로세스를 변환하기 위한 ERC 제안이며 기본 코드를 변경할 필요도 없습니다. 이 제안은 보증인의 역할을 소개합니다.계약 지갑의 개발자는 제출된 메타 트랜잭션의 품질을 확인하고 번들러가 트랜잭션이 mempool에 남아 있어야 하는지 여부를 결정하는 데 도움이 되도록 보증인 계약을 정의합니다. 이 제안은 계정을 번들러로 추상화하는 위험을 지갑 개발자에게 이전하고 개발자가 보증서 계약 코딩 및 배포를 담당할 것으로 기대합니다.
이점:
번들러가 메타 트랜잭션을 가리기 위한 임계값과 위험을 줄였습니다.
문제 및 현재 상황:
이 제안은 현재 초안 형식이며 아직 초기 단계에 있습니다.
보조 제목
미래 - 필수
Vitalik은 ERC-4337을 구현하는 과정에서 EOA를 계약 주소로 업그레이드하고 가스 비용을 최적화하는 등 ERC-4337의 단점을 개선하기 위한 새로운 제안을 계속해서 소개할 것이라고 언급했습니다. 가능한 경로는 자발적 채택에서 광범위한 대중화로 이어지고 이더리움 계정 유형을 하나로 통합하는 궁극적인 목표를 달성하기 위한 필수 변환의 최종 구현이 될 것입니다.
EIP-3074
프로그램 소개:
EIP 3074의 제안은 실제로 EIP 4337보다 이전입니다. 새로운 트랜잭션 유형을 도입하지 않았지만 EOA 제어를 스마트 계약에 위임할 수 있는 AUTH 및 AUTHCALL의 두 가지 작업 코드를 도입하여 모든 EOA가 스마트 계약을 가질 수 있도록 합니다. 지갑 기능.
이점:
가스 지불: 다른 계정에서 가스 수수료를 지불할 수 있으며 ETH를 보유하지 않은 주소도 토큰을 보낼 수 있습니다.
일괄 거래: 한 번의 호출로 여러 거래를 보내 거래 수수료를 줄입니다.
문제 및 현재 상황:
이 제안은 이더리움 코드에 대한 변경이 필요하며 상하이 업그레이드 단계에서 이를 구현할 계획이며 다양한 보안 불확실성으로 인해 아직 검토 단계에서 검토 중입니다.
EIP-5003
프로그램 소개:
이 제안은 EIP 3074에 대한 확장 제안이며, 승인된 주소가 승인된 주소의 코드를 설정할 수 있도록 하는 새로운 작업 코드 AUTHUSURP를 도입하여 계약 계정에 대한 EOA 업그레이드를 실현합니다.
이점:
EOA를 계약 계정으로 업그레이드 실현
현상 유지:
보조 제목
Layer 2 ？
위의 EIP 개발 이력에서 계정 추상화는 이더리움 이중 계정 시스템의 레거시 문제를 해결하기 위한 것임을 알 수 있으며, 성은 아직 높지 않아 많은 장애물에 직면했습니다. 이에 비해 코드를 직접 변경하는 솔루션은 생태계가 막 시작된 새로운 레이어 2 퍼블릭 체인에 더 적합할 수 있습니다. 예를 들어, Starknet은 기본적으로 계정 추상화를 지원하는 체인으로, 프로그래밍할 수 있는 통합 계정 유형이 하나만 있으며 트랜잭션을 보내고 자산을 보내고 받는 등의 작업을 수행할 수 있습니다. 10월에 zksync 2.0 메인넷이 출시되었고 계정 추상화의 새로운 기능도 도입되었습니다.계정은 트랜잭션을 시작하고 그들에 배포된 코드 로직을 실행할 수 있습니다.
또한 이더리움 메인넷과 비교하여 Layer 2는 종종 가스 요금이 낮습니다. 배포를 위해 가스를 지불해야 하는 스마트 계약 계정의 경우 사용자 경험이 더 좋고 비용이 더 낮을 것입니다.
첫 번째 레벨 제목
계정 요약 트랙 맵
계정 추상화는 향후 계정이 계약 계정과 유사한 기능을 갖게 됨을 의미합니다. 컨센서스 및 기본 코드에서 계정 추상화가 완전히 실현되기 전에 이미 일부 스마트 계약 지갑 제품(Smart Contract Wallet-SCW)이 있으며 계약 계정의 이점을 보고 사용자에게 EOA 계정 시스템 이외의 옵션을 제공하고 있습니다.
이미지 설명
계정 추상 개념 프로젝트 비교
보조 제목
계정 추상화가 필요합니까?
MetaMask와 같은 전통적인 EOA 지갑은 사용자 경험이 좋지 않다는 비판을 받아 왔으며 사용자는 개인 키 또는 니모닉 단어를 적절하게 관리하고 개인 키 유출 위험을 감수해야 합니다. 이것은 또한 웹3 세계로의 첫 걸음이 매우 높은 문턱을 갖게 합니다.
최근 사용자와 트래픽이 많은 많은 web2 회사들이 web3로의 확장을 시도하고 있는데, 예를 들어 Reddit은 사용자에게 reddit NFT를 발행하여 Opensea의 기존 사용자 수를 훨씬 초과하는 신규 사용자를 쉽게 유치했습니다. NFT 캐스팅 프로세스를 안내하면서 reddit은 사용자가 이해할 수 있는 임계값을 낮추고 주소, 개인 키 및 NFT와 같은 복잡한 개념을 흐리게 하기 위해 최선을 다했습니다.
개인키가 없는 컨트랙트 지갑을 사용한다면 근본적으로 문턱을 없앨 수 있고 많은 web2 사용자들이 web3에 진입할 수 있는 더 나은 채널이 제공될 것입니다.
그러나 계정 추상화 또는 계약 주소를 통해 보안 및 개인 키 없는 경험을 실현해야 합니까?
아니다.
첫 번째 유형의 옵션은 현재 대부분의 거래소에서 사용하는 수탁 지갑입니다. 즉, 개인 키는 사용자의 손에 있지 않지만 거래소는 사용자를 대신하여 자산을 보유하고 관리하며 사용자는 완전히 제어할 수 없습니다. 그들 자신의 자금. 이러한 관리형 지갑은 사용자의 문턱을 크게 줄일 수 있지만 그에 상응하는 신뢰 위험도 있습니다. 최근 FTX의 갑작스러운 폭발로 인해 사용자는 보관 중인 자산이 남용될 수 있고 겉보기에 강력한 기관도 무너질 수 있음을 깨달았습니다. 가장 안전한 옵션은 자신의 자산을 완전히 통제하는 것입니다. 당신의 열쇠도, 당신의 코인도 아닙니다.
또 다른 유형의 지갑은 MPC(Multi-Party Computation)라는 기술을 적용하여 일부 계약 지갑이 달성하고자 하는 보안 및 개인 키 없는 사용자 경험을 달성할 수도 있습니다.
일반적으로 MPC는 주로 임계값 서명(TSS-Threshold Signature Scheme) 방식을 사용합니다. 이는 단순히 개인 키를 조각화하고 계산 및 암호화를 위해 조각을 분산 네트워크에 제출하는 것을 의미합니다. 개인 키 서명이 필요한 경우 조각이 함께 접합되어 완전한 개인 키를 형성하며 제어 권한을 분산시켜 단일 실패 지점의 보안 문제를 방지합니다. 이 방식은 자기 수탁과 수탁 사이에 있으며 준수탁 지갑이라고 할 수 있습니다.
이 논리는 다중 서명 지갑과 유사하지만 다중 서명 지갑의 각 다중 서명자는 계약 계정을 제어하기 위해 완전한 개인 키 서명을 제공하는 반면 TSS의 검증 프로세스에는 개인 키만 포함된다는 점에서 차이점이 있습니다. 그리고 체인입니다. 다음은 스마트 계약과 직접적인 관련이 없습니다.
To B의 Safeheron 및 To C의 Bitizen과 같은 우수한 MPC 지갑 제품도 많이 있습니다.
MPC는 개인 키 없음과 같은 기능도 구현할 수 있으며 MPC는 EOA를 기반으로 할 수 있으므로 사용 비용이 저렴하고 호환성이 더 좋아 보입니다. MPC 기술은 EVM 체인뿐만 아니라 다른 비 EVM 계정에도 적용할 수 있습니다. 그렇다면 프라이빗 키가 없는 것을 목적으로 하는 컨트랙트 월렛일까, 아니면 계정 추상화가 정말 필요한 것일까?
올해 5월 코인베이스는 컨트랙트 월렛의 값비싼 가스와 사용자가 MPC 월렛 프로모션 트위터에서 신뢰할 수 있는 보호자를 충분히 찾지 못할 수 있다는 사실과 같은 문제에 의문을 제기했습니다.
그리고 Vitalik도 이 트위터에서 자신의 태도를 표현했습니다.
Vitalik은 계정 서명 알고리즘을 사용자 정의할 수 있다는 목표를 달성하기 위해 프로토콜 수준에서 계정을 추상화하기를 희망합니다. 현재 Ethereum에 의해 시행되는 ECDSA 서명 알고리즘은 최적의 선택이 아니며 MPC는 ECDSA를 기반으로 하는 부분적인 보안 체계일 뿐입니다. 계정 추상화가 구현된 후 기술 발전에 따라 더 발전되고 안전한 서명 알고리즘(양자 저항 등)을 직접 사용할 수 있습니다.
보조 제목
계정 추상 지갑의 궁극적인 형태
계정 추상화가 대중화되고 합의에 도달하면 계약 계정의 호환성과 경제성이 향상됩니다. 여기에서 우리는 또한 이러한 유형의 제품의 최종 상태, 제공할 수 있는 기능 및 적용 가능한 시나리오를 낙관적으로 예측하거나 기대하며 다음과 같은 기능 및 애플리케이션 시나리오를 포함할 수 있다고 생각합니다.
개인 키 없음: 사용자는 더 이상 니모닉 단어 또는 개인 키를 보관할 필요가 없으며 생체 인증 및 장치 인증과 같은 여러 인증 방법을 통과할 수 있습니다.
계정 복구: 생체 인식, 소셜 인증 등을 통해 계정 복구를 수행할 수 있습니다.
Gas-free 상호 작용: 사용자는 거래에 포함된 ERC-20 토큰을 가스 지불에 사용하거나 미리 ETH를 가스로 준비하지 않고 또는 거래 실패 시 가스 수수료를 지불하지 않고 지불을 위한 고정 계정을 직접 지정할 수 있습니다.
맞춤형 보안 메커니즘: 암호화 기술의 발전으로 더 나은 보안 메커니즘을 선택할 수 있습니다.
프라이버시: 링 서명 및 기타 방법을 기반으로 한 보다 효과적인 온체인 프라이버시
임시 계정 보관: 사용자는 관리 당사자, 시간, 상호 작용 및 기타 요구 사항을 설정하고 관리를 위해 계정을 다른 사람에게 위탁하고 시간 또는 요구 사항에 도달하면 자동으로 철회할 수 있습니다.
계정 담보/거래: 계정에는 체인에 자산과 누적된 신용 이력이 포함되어 있으며 계정 자체는 체인 시장에서 직접 담보 및 거래가 가능합니다.
계정 권한 제한 및 분할: 계정에서 NFT만 사용하고 토큰은 사용하지 않는 등 일부 계정 권한을 타인에게 라이선스할 수 있습니다.
맞춤형 워크플로: 자동화된 트리거 및 프로세스를 설정합니다. 예를 들어 A계좌의 잔액이 1Eth보다 0.5ETH가 많다면 자동으로 초과된 0.5ETH를 B계좌로 이체하고, B계좌는 특정 토큰이 일정 가격에 도달하면 자동으로 ETH를 특정 토큰으로 스왑한다. .
거래 제한: 거래 시간 및 할당량을 설정할 수 있으며, 시간을 초과하거나 할당량을 초과하는 거래는 성공하지 못합니다.
화이트리스트/블랙리스트: 블랙리스트 주소와의 상호 작용을 제한합니다.예를 들어 블랙리스트 주소로 보낸 자산은 이전에 토네이도 현금이 제재된 후 다른 주소를 "중독"하여 다른 프로토콜 프런트 엔드에서 주소를 차단하는 것을 방지하기 위해 자동으로 반환됩니다. 거짓 금지.
계정 분류 관리 시스템: 사용자는 다양한 시나리오에서 전용 계정을 사용하고 보다 합리적인 계정 관리 시스템을 갖습니다. 예를 들어 어떤 계정은 Gas 계정으로 ETH만 저장하고 다른 모든 계정의 상호작용은 Gas 계정으로 지불하고, 어떤 계정은 쉽게 사용되지 않는 블루칩 NFT만 저장하고, 특정 계정은 사용됩니다. 게임 전용 계정으로
첫 번째 레벨 제목
결론:
계정 추상화의 상륙은 모두가 기대할 만한 가치가 있습니다. 이는 체인의 사용자 수가 크게 증가하는 데 도움이 될 뿐만 아니라 계정 추상화가 개발자에게 제공하는 높은 수준의 자유도가 현재 계정 시스템의 문제점을 해결하고 새로운 애플리케이션, 게임 플레이 및 상상력을 생성할 것이기 때문입니다.
코드 수준에서 계정 추상화 구현은 장애물과 불확실성으로 가득 차 있습니다.EIP-4337과 같은 타협 솔루션은 여전히 높은 가스와 낮은 호환성과 같은 실질적인 문제가 있지만 EIP-4337을 적극적으로 홍보하는 것도 개념을 홍보하고 향상시키는 선택입니다. 합의.. 개념의 대중화와 함께 계정 추상화 및 계약 지갑은 틈새에서 주류로 이동하고 사용자 요구에서 프로토콜 호환성을 촉진하며 새로운 계정 패러다임을 형성합니다. 결국 광범위한 합의하에 이더리움은 계정 추상화를 달성하기 위해 기본 코드를 직접 변경할 수 있는 조건을 갖습니다.
최종 계정 추상화가 구현된 후 현재 계정 시스템의 높은 임계값과 복잡한 사용자 경험은 더 이상 당연한 것으로 간주되지 않습니다. 이 새로운 계정 시스템은 web3에 대한 새로운 사용자와 트래픽을 유치하는 데 더 도움이 될 것이며 생태계의 활발한 발전을 자극하여 긍정적인 순환을 형성할 것입니다.
IOS
Android