"계정 추상화"에 대한 긴 기사: 7년간의 경로 진화와 트랙 맵 - ODAILY

avatar
ODAILY
12-26
이 기사는 기계로 번역되었습니다
원문 표시

계정 추상화는 EIP-4337에 국한되지 않으며, 키리스 및 소셜 복구 기능에만 국한되지 않습니다. 이 글에서는 EIP 제안을 토대로 계정 추상화의 개발 이력과 미래 방향을 정리하고, 트랙 맵을 통해 계정 추상화의 무한한 가능성을 상상해 본다.

계정 추상화가 실제로 구현되려면 아직 어느 정도 시간이 걸리겠지만, 이는 미래에 임계값을 낮추고 새로운 사용자의 사용자 경험을 개선할 수 있는 유일한 방법이 될 것입니다.

셀프 커스터디가 필요한 지갑 주소는 온체인 세계에서는 사용자의 " 계정 " 이지만, 사용자가 Web3 에 진입하는 데 큰 장애물이기도 합니다. 계정 개선은 7 년 이상 진행된 실험입니다. Vitalik이 계정 추상화에 대한 EIP-4337을 소개하는 Twitter 스레드 를 게시한 것은 2022년 10월이 되어서였다. 계정 추상화는 11월 보고타에서 개최된 Devcon 6 의 다양한 공유 세션에서도 자주 등장하여 계정 추상화, 계약 지갑 및 4337 에 대한 광범위하고 격렬한 논의를 촉발했다.

계정 추상화는 사용자가 온라인에 접속하는 것을 지원하는 데 매우 중요합니다. "키가 아니라 코인이 아닙니다." 자체 보관은 암호화폐 베테랑들이 수없이 강조했지만, 이를 할 수 있는 사람은 극소수에 불과합니다. 계정 추상화가 가져온 매우 높은 수준의 자유는 일반 사용자에게 더 안전하고 사용자 친화적인 탈중앙화 경험을 제공할 수 있습니다. 셀프 커스터디는 더 이상 몇몇 괴짜들만 할 수 있는 일이 아닙니다. FTX 의 붕괴는 암호화폐 세계의 미래에 깊은 그림자를 드리웠지만, 탈중앙화 애플리케이션과 셀프 커스터디의 필요성이 의심할 여지 없이 확인되었습니다. 계정 추상화가 구현되면 암호화폐 산업은 중앙집권화된 악당과 황제로부터 벗어나 더 높은 차원의 탈중앙화 와 자유로 나아갈 수 있을 것입니다.

현재 많은 사람들은 EIP-4337을 계정 추상화에 대한 길잡이로 보고 있지만, 이 제안은 여전히 ​​지나치게 이상적인 초안에 불과합니다. 예를 들어, 이상적인 환경에서는 거래 패키징이 가스를 공유할 수 있지만, 현실적으로는 검증 프로세스로 인해 추가적인 가스 소비가 발생합니다. 이상적인 환경에서는 계약 지갑이 통합 아키텍처를 사용하지만, 현실적으로는 효과가 약한 자발적인 ERC 제안입니다. 이상적인 환경에서는 EIP-4337을 사용하는 계정이 더 나은 사용자 경험을 제공할 수 있지만, 현실적으로는 많은 dapp이 계약 주소의 상호작용을 금지합니다 ...

EIP-4337 과 같은 적당한 솔루션은 계정 추상화의 진화에 따른 변화이며, 부족한 개발 리소스와 직접적인 코드 변경으로 인한 불균형적인 영향과 같은 다양한 현실에 대한 타협입니다. 이러한 타협적 솔루션은 계정 추상화 개념을 미리 퍼뜨리고 향후 추상화를 위한 합의 기반을 마련하는 데 도움이 되지만, 이것이 계정 추상화의 종말은 아닙니다. 궁극적으로, 이더 이더 우리 모두가 갈망하는 유토피아에 도달하기 위해 코드 수준에서 계정 추상화를 실제로 구현해야 합니다.

계정 추상화란 무엇인가? 주판에서 스마트 계산기로

계정 추상화의 구체적인 의미를 논의하기 전에 먼저 이를 분석하여 "계정"과 "추상화"가 각각 무엇인지 이해할 수 있습니다.

간단히 말해서, 이더 의 기반은 두 가지 유형의 계정을 기반으로 구축됩니다. 하나는 사용자 지갑을 보관하는 계정이고 다른 하나는 스마트 계약의 논리를 보관하는 계정입니다. 두 지갑의 기능은 대부분 호환되지 않습니다. 즉, 사용자의 지갑은 논리적인 판단을 수행할 수 없고, 스마트 계약을 호스팅하는 계정은 논리를 넘어서는 어떤 작업도 수행할 수 없습니다. 상상할 수 있듯이 그런 계정 시스템은 최적화되어 있지 않습니다. 계정 추상화의 목표는 이러한 비호환성을 제거하고 차이점을 " 일반화"하는 것입니다. 즉, 특이성을 제거하고 공통점을 찾는 것입니다.

계정

이더 에는 두 가지 기본 계정 유형이 있습니다. 외부 소유 계정(EOA )과 계약 계정( CA )입니다.

EOA 는 일반 사용자가 가장 자주 접하는 계정 유형으로, MetaMask 지갑의 주소와 같이 사용자가 개인 키를 통해 제어합니다. 반면 CA 는 이더 네트워크에 배포된 스마트 계약으로, 코드로 제어되며 개인 키가 없습니다. 두 가지 계정 유형의 유사점과 차이점은 다음과 같습니다.

"계정 추상화"에 대한 긴 기사: 7년간의 경로 진화 및 트랙 맵

추상적인

추상화는 구체적인 문제에서 공통적인 패턴을 클레임 다음 일반적인 솔루션을 사용하여 해당 문제를 해결하는 것을 말합니다. 다시 말해, 추상화는 특수성을 제거하고 공통점을 찾는 '일반화' 과정입니다.

추상화를 이해하기 위해 더 구체적인 예를 들어보겠습니다. 장난감 자동차와 레고 블록입니다. 장난감 자동차의 구조는 4개의 바퀴와 차체 등 일련의 특수한 부품으로 구성되어 있어 특수하고 구체적입니다. 작은 트럭 장난감이나 비행기 장난감을 원한다면 새 장난감을 사야 합니다. 레고 블록은 더 추상적이고 일반적입니다. 그들은 장난감을 큐브와 구와 같은 일반적인 빌딩 블록 모듈 로 매우 추상화합니다. 플레이어는 이러한 빌딩 블록을 사용하여 모든 장난감 모양을 만들 수 있습니다.

블록체인의 개발에 있어서 비트코인에서 이더 으로의 전환은 실제로 추상화 과정입니다. 비트코인 네트워크의 원래 목적은 구체적이고 명확한 목적을 가진 P2P 지불 시스템을 실현하는 것이었습니다. 이더 블록체인을 보다 일반적인 시스템으로 전환하여 P2P 지불에 대한 특수성을 제거하고 블록체인 기술의 공통점을 클레임 새로운 네트워크를 구축했으며, 이더 가상 머신을 통해 다양한 프로토콜과 애플리케이션을 온체인 자유롭게 구축하여 블록체인 생태계를 확장할 수 있습니다.

계정 추상화

계정 추상화는 이더 계정을 일반화하고 구체성을 제거하는 것을 의미합니다. 이전 기사에서 언급했듯이, 이더 에는 EOACA라는 두 가지 계정 유형이 있으며, 각각 고유한 특성이 있습니다. EOA는" 최상위 " 계정입니다. 모든 거래는 EOA 에만 의존하여 ETH를 가스 로 시작하고 지불할 수 있습니다. EOA는 특정 Secp 256 k 1 타원 암호화 알고리즘으로 구현된 ECDSA 서명 체계만 사용할 수 있습니다. 하지만 EOA는 코드 논리를 직접적으로 지원하지 않습니다. 코드 로직을 지원하는 CA가 배포되어야 하고 EOA 가 거래를 시작해야 합니다.

이 모든 것은 기본 이더 의 특별하고 필수적인 설계입니다. 계정 추상화의 목적은 이더 계정을 일반화하고, 더 높은 수준의 자유도를 부여하며, 계정의 가능성을 확장하는 것입니다. 계정의 특수성을 일반화하면 다음과 같은 계정 추상화의 핵심 요점을 클레임 할 수 있습니다.

  1. 암호화 추상화: 계정 서명 검증은 더 이상 특정 암호화 알고리즘에 국한되지 않습니다. 사용자는 보안 메커니즘으로 다양한 암호화 알고리즘을 사용자 지정하고 선택할 수 있습니다.

  2. 계정 기능 추상화: 코드 논리 지원 및 사용자 정의 기능 구현

  3. 거래 추상화: 모든 계정에서 거래를 시작할 수 있으며 가스 지불은 사용자 정의가 가능합니다.

간단히 말해, 개발자에게는 계정 추상화가 더 큰 자유와 더 많은 가능성을 의미하고, 사용자에게는 계정 추상화가 보안, 사용 편의성, 기능성 등 여러 측면에서 더 나은 사용자 경험을 제공할 수 있습니다. 계정 추상화 이전에는 사용자의 지갑 주소가 단지 덧셈과 뺄셈에 사용할 수 있는 셈판에 불과하다고 할 수 있습니다. 계산 추상화가 실현되면 셈판은 논리적 판단 기능을 갖게 되고 칩이 장착된 지능형 계산기가 됩니다.

계정 추상화의 발전 : 급진적에서 온건한 상태로, 그리고 최종 상태로

추상화에 대한 논의는 2015년 이더 네트워크가 공식 출시된 후 몇 달 만에 시작되었으며, 올해 10월 현재까지도 새로운 제안이 제시되고 있었습니다. 계정 추상화와 관련된 EIP를 시간순으로 정리하여 계정 추상화의 다양한 솔루션과 개발 내용을 살펴보겠습니다.

여기서 계정 추상화 계획의 개발은 단계로 나뉩니다.

"계정 추상화"에 대한 긴 기사: 7년간의 경로 진화 및 트랙 맵

2015년 이더 출시되었을 때 처음으로 계정 추상화를 제안한 EIP-86은 이상주의로 가득 찬 5 년간의 급진적인 개혁의 시작이었습니다. 이더 의 기본 코드를 직접 변경하는 이러한 계정 추상화 제안은 검토 단계로 진출하지 못했지만, 일부 보조 제안은 통과되어 계정 추상화를 위한 일정한 기반을 마련했습니다. 예를 들어, EIP-1014는 계약을 배포하지 않고 사전에 계약 주소를 계산하는 기능을 구현하고, EIP-1271은 계약 계정을 통해 서명 솔루션을 구현합니다.

급진적인 개혁으로 인해 좌절을 겪은 후, 계정 추상화는 더 온건한 타협안을 모색하기 시작했습니다. 이 단계에서는 기본 이더 코드를 직접 변경하려는 시도는 없지만, 대신 개발자가 자발적으로 채택할 ERC 표준을 출시하는 데 중점을 둡니다. EIP-4337 의 탄생으로 계정 추상화가 점진적으로 발전하는 시대가 열렸습니다. 최근 EIP-5189는 4337 의 아이디어를 기반으로 한 추가적인 최적화 계획을 제안했습니다.

ERC 표준 계정 추상화 솔루션은 기본 코드의 느린 변화, 큰 영향 및 낮은 호환성에 대한 타협안입니다. 이처럼 온화한 접근 방식은 계정 추상화 개념을 확산하는 데 도움이 되며, 이상적인 논의에서 실제 현실로 계정 추상화를 구현하고 기존 솔루션의 단점을 점진적으로 개선하고 완벽하게 만드는 데 도움이 됩니다.

앞으로 점진적인 진화를 거쳐 일정한 합의에 도달하면 EIP-30745003 과 같은 제안을 적용하여 EOA를 계약 계정으로 업그레이드하는 것이 가능할 수도 있습니다. 이더 결국 본래의 이상을 실현하고 기반 프로토콜을 근본적으로 변경하며 계정을 프로그래밍 가능하고 사용자 정의 가능한 계정으로 통합할 것입니다.

"계정 추상화"에 대한 긴 기사: 7년간의 경로 진화 및 트랙 맵

과거 - 급진적 개혁

해당 제안이 처음 제시된 이래로, 계정 추상화에 대한 해결책은 항상 컨센서스 레이어 직접 변경하는 무차별 대입 개혁 계획이었으며, 이 단계 동안 제안에서 지속적으로 개선되었습니다.

이아이피-101

프로그램 소개:

2015 년 말, 이더 창시자 비탈릭이 EIP-101 에서 처음으로 추상화를 제안했습니다. 이 제안에서 Vitalik은 Serenity 에서 계정 시스템의 추상 설계를 논의하여 계정을 4개 필드에서 코드스토리지 라는 두 필드로 단순화했습니다. 모든 ETH 는 토큰 계약에 저장되어 사용자 잔액 매핑하는 주소 목록을 유지합니다. 거래는 8개 필드에서 4개 필드로 단순화되어 계정과 거래를 크게 추상화합니다.

장점:

  • 다른 암호화 알고리즘을 사용하여 계정 보안을 보호하는 사용자 정의 보안 모드

  • ETH 와 기타 ERC 20 토큰은 동등하게 취급될 수 있습니다.

  • 사용자 정의 계정 기능(다중 서명 등)의 간접성이 감소했습니다.

문제점과 현재 상황:

이 제안은 계정 시스템에 큰 변화를 가져왔고, 이로 인해 호환성 문제와 보안 위험이 발생했습니다. 따라서 샤딩 이후까지 일시적으로 보류되었고 현재는 정체된 상태입니다.

이피에이피-86

프로그램 소개:

2017년비탈릭은 거래의 소스와 서명을 추상화하고 기본 코드를 다시 근본적으로 변경하는 EIP-86을 제안했습니다. 이 제안은 사용자가 서명 및 논스 확인 메커니즘을 사용할 수 있는 계정 계약을 생성할 수 있도록 허용합니다. 이 계획에는 누구나 거래를 보낼 수 있는 진입점 계약이 있습니다. 계정 계약은 진입점 에서 데이터를 수신하고 서명을 확인합니다. 정확하면 가스가 채굴자에게 지불됩니다. 이 솔루션은 계정 추상화를 위한 준비 과정으로, 사용자가 서명 알고리즘을 사용자 정의하고 더 이상 이더 하드코딩된 ECDSA 및 기본 nonce 메커니즘을 사용할 필요가 없습니다. 동시에, 서명이 올바른 것으로 검증된 후에만 계약 계정에서 가스가 지불됩니다.

장점:

  • 다중 서명: 각 다중 서명자는 ETH를 소유할 필요가 없습니다. 다중 서명 정보가 포함된 거래는 다중 서명 계정으로 직접 전송되고 다중 서명 계정에서 직접 지불할 수 있습니다.

  • 링 시그니처 코인 믹싱: 링 시그니처는 시그니처가 시작부터 끝까지 연결되어 링을 형성하므로 시작점을 결정할 수 없습니다. n 명의 사용자가 같은 수의 토큰을 계약에 보낸 다음 링 서명을 사용하여 같은 수의 토큰을 인출합니다. 하지만 토큰을 클레임가스를 준비해야 하므로 이 단계에서는 노출 리스크 있습니다. 따라서 이 제안을 통해 클레임 토큰에서 직접 가스를 지불할 수 있어 이 시나리오에서 개인 정보 보호가 보장됩니다.

  • 사용자 지정 암호화: 사용자는 Lamport 와 같은 양자 안전 서명 방법을 사용하여 계정 보안을 보장할 수 있습니다.

  • 사용자 정의 비암호화 기능: 거래 만료 시간 설정 등

문제점과 현재 상황:

  • 새로운 거래 유형에는 거래 발신자(모든 진입점 )가 없으므로 해시의 고유성이 파괴됩니다. 해시 기반 고유성 프로토콜 작업과 호환되지 않습니다.

  • 가스 없는 지불은 필요 없습니다. 현재는 프록시 계약을 통해 달성할 수 있지만 비용은 약간 더 높을 것입니다.

  • 광부들의 채굴 전략이 크게 영향을 받을 것입니다.

  • 새로운 거래 유형은 nonce , gasprice , value 와 같은 필드를 유지하고 이를 0 으로 설정하는데, 이는 코드의 우아함이 부족합니다.

  • 따라서 이러한 문제를 고려하여 해당 제안은 결국 연기되었고 현재는 침체된 상태에 있습니다.

EIP-859

프로그램 소개:

이 제안에서는 새로운 거래 유형과 새로운 명령어를 도입하고, 거래 해시의 고유성을 유지하기 위해 거래에서 nonce 필드를 강제로 유지합니다. paygas 명령어는 가스 결제를 위해 도입되었으며 일부 거래를 검증하고 일부 거래를 실행하는 사이의 논리적 경계 역할을 합니다.

장점:

  • 맞춤형 서명 방식

  • 거래 해시 고유성을 유지합니다.

  • 더 복잡한 검증 시나리오를 지원하고 가스를 절약할 수 있습니다. 예를 들어, 토큰 ICO 동안 10,000개의 거래가 동시에 참여하지만 토큰은 처음 5,000개의 거래만 지원하기 위해 출시됩니다. 기존 로직에 따르면 모든 10,000개의 거래가 패키징되어 체인에 업로드됩니다. 이 제안에 따라 마지막 5,000개의 거래가 블록체인에 포함되지 않도록 계약을 설정하여 가스 소비를 절약하고 잘못된 정크 거래를 줄일 수 있습니다.

문제점과 현재 상황:

  • ERC-20 토큰을 사용하여 가스 비용을 지불할 수 없습니다.

  • ERC 20을 사용하여 가스 비용을 지불할 수 없습니다.

실제로 이 제안은 확정된 초안을 형성하지 못했고 단지 논의 단계에만 머물러 있습니다. 이 제안은 또한 몇몇 이더 개발자 회의에서 논의되었지만, 미성숙한 점과 당시 업그레이드에 이미 많은 콘텐츠가 포함되어 있었기 때문에 제안은 영구적으로 보류되었습니다.

EIP-1014

프로그램 소개:

이 제안은 계정 추상화를 직접적으로 언급하지는 않지만, 계정 추상화 개발과 밀접한 관련이 있습니다. 이 제안에서는 실제로 배포하기 전에 계약 주소를 미리 계산하고, 배포하기 전에 자산을 해당 주소로 보내고, 계약 주소를 사용하여 첫 번째 거래가 이루어질 때 해당 자산을 배포하는 방법을 소개합니다.

장점:

  • 비용 절감: 사용자는 계약을 배포하기 위해 가스 비용을 지불하기 전에 계약 주소를 미리 계산할 수 있습니다.

  • 멀티체인 계약 주소 일관성: 계약 주소는 존재하기 전에 배포되어야 하므로 멀티체인 일관성을 직접 달성할 수 있는 EOA 와 같지 않습니다. 이 명령어의 salt 매개변수를 통해서도 계약 주소는 멀티체인 일관성을 달성할 수 있습니다.

현상 유지:

결국 이 제안은 통과되어 스마트 계약 지갑 개발을 위한 중요한 기반을 마련했습니다.

EIP-1271

프로그램 소개:

이 제안에서는 계약 계정을 나타내는 서명이 유효한지 확인하기 위한 일련의 기준을 제공합니다. 이를 통해 계약 계정은 EOA 와 마찬가지로 서명 검증을 수행할 수 있습니다.

장점:

이 제안은 개발자들이 자발적으로 채택할 수 있는 확정된 ERC 표준입니다. 이는 향후 계약 계정의 홍보 및 대중화를 위한 좋은 토대를 마련합니다. dapp이 계약 주소 서명을 지원할 의향이 있는 한, 프로토콜에 EIP-1271 코드를 추가하기만 하면 됩니다.

현상 유지:

이 제안은 마침내 통과되어 실제 사용에 들어갔습니다. 예를 들어 OpenSea에서 서명 로그인을 위한 인증 계약 지갑을 지원하는 경우가 있습니다.

EIP-2938

프로그램 소개:

2020년Vitalik은 많은 다른 사람들과 힘을 합쳐 더욱 완전한 계정 추상화 솔루션을 제안했습니다. 여러 계정 유형을 하나 의 계약 계정으로 통합하려는 이전 계정 추상화 목표와 비교했을 때, EIP-2938 제안은 기존의 두 가지 유형의 EOA 와 계약 계정을 그대로 유지하면서도 계약을 최상위 계정으로 허용하여 해당 계정에서 거래 가스를 지불하고 거래 실행 프로세스를 시작할 수 있도록 허용합니다.

이 제안은 새로운 유형의 거래 , 즉 계정 추상화 거래 를 정의하고 NoncePAYGAS라는 두 가지 명령어를 도입합니다. 이러한 개선 사항에는 여전히 이더 의 기본 코드에 대한 변경이 필요합니다.

또한 EIP-2938은 솔루션 구현을 계획하고 구체적인 응용 프로그램 시나리오를 설명합니다. 계정 추상화는 두 수준으로 나뉩니다. 먼저 단일 테넌트 계정 추상화를 구현한 다음 다중 테넌트 계정 추상화로 확장합니다.

장점 및 시나리오:

단일 세입자

  • ECDSA 외의 서명 검증 방법( BLS , 포스트퀀텀 등)을 사용자 정의

  • 다중서명 검증, 소셜 복구 등 계약 지갑 기능 추가

  • ERC-20 토큰을 사용하여 가스 비용을 지불하세요.

다중 테넌트

  • 개인정보 보호: Tornado Cash 와 같은 개인정보 보호 시나리오에서는 계정에서 더 이상 가스 요금을 준비하거나 개인정보를 노출할 필요가 없습니다.

  • 가스 절약: 예를 들어, 중재 기회가 발생하면 대량 중재자가 동시에 중재 거래를 시작합니다. 첫 번째 거래가 성공한 후 다른 중재 거래는 실패하지만 여전히 블록에 패키지됩니다. 계정이 추상화된 후 중재자는 더 이상 실패한 중재 행동에 대해 가스를 지불할 필요가 없으므로 온체인 쓰레기 거래의 수가 줄어듭니다.

문제점과 현재 상황:

계획은 더 구체적이지만 멀티테넌트 단계에 대한 기술적 솔루션은 아직 형성되지 않았습니다. 이 계획은 기술적, 경제적으로 효율적이지 않다고 간주되어 최종 단계에 들어가지 못했습니다.

이 시점에서 계정 추상화의 첫 번째 단계, 즉 기본 이더 프로토콜을 급진적이고 폭력적으로 변경하려는 계획은 거의 모두 보류되었습니다. 계정 추상화의 우선순위, 필요성, 경제성, 호환성은 아직 더욱 최적화되어야 합니다.

지금 - 적당한 변화

이더 개발자들은 이더 의 합병과 샤딩에 집중하고 있다. 기본 프로토콜을 직접 변경하는 계획을 추진하기는 어렵다. 비탈릭이 대표하는 개발자들은 타협해야 하고 비교적 온건하고 간접적인 대안을 제안해야 한다.

영어: EIP 4337 (영어)

프로그램 소개:

이 제안은 이더 기본 코드를 변경할 필요가 없는 최초의 계정 추상화 제안입니다. ERC-4337 에서는 UserOperation 객체가 도입되었습니다. 사용자는 UserOperation 객체를 별도의 메모리 풀로 보냅니다. Bundler는 이러한 객체를 트랜잭션으로 패키징하고, Entry Point 계약을 호출한 다음, 트랜잭션을 블록에 포함합니다.

장점:

  • 사용자 정의 서명 알고리즘: ECDSA 이외의 서명 알고리즘 지원

  • 기능 커스터마이징 : 가스 결제, 소셜 복구 등의 기능을 계약코드를 통해 구현 가능

문제점과 현재 상황:

  • 업그레이드 불가: 사용자는 표준을 지원하기 위해 자산과 활동을 새 주소로 이동해야 합니다.

  • 가스 비용 증가: 도입된 사용자 운영으로 인해 가스 소비량이 증가하게 됩니다.

  • 호환성 문제: 일부 기존 dapp 또는 프로토콜은 계약 계정과의 상호 작용을 금지할 수 있습니다.

많은 실질적인 문제에도 불구하고, Vitalik은 단기적으로 ERC-4337을 강력히 지원하고, 실제로 더 나은 솔루션을 연구하고, 지속적으로 개선하고 완성하기를 바라고 있습니다. 대규모 홍보 후 합의와 규모 효과가 형성되어 기존 애플리케이션에서 계약 계정과 ERC-1271 계약 서명 표준의 상호작용을 지원하기 위한 변경을 촉진하는 데 도움이 될 것입니다. 현재 EIP 4337은 아직 초안 상태로, 다음 단계로 진행되기를 기다리고 있습니다.

EIP-5189

프로그램 소개:

이 제안은 거래 패키징 프로세스를 변환하기 위한 ERC 제안이며, 기본 코드를 변경할 필요가 없습니다. 제안은 지지자 역할을 도입합니다. 계약 지갑 개발자는 제출된 메타 거래의 품질을 확인하고 들러가 거래가 mempool 에 남아야 하는지 여부를 결정하는 데 도움이 되는 지지자 계약을 정의합니다. 이 제안은 번들러로 계정을 추상화하는 데 따른 리스크지갑 개발자에게 전가하여, 개발자가 보증인 계약을 코딩하고 배포하는 책임을 지기를 기대합니다.

장점:

번들러가 메타 거래를 검토하는 임계값과 리스크 줄입니다.

문제점과 현재 상황:

해당 제안은 현재 초안 형태이며 아직 초기 단계에 있습니다.

이 단계에서 계정 추상화 계획은 초기의 폭력적 혁명에서 평화로운 진화로 전환되었습니다. 힘은 약하지만 구현이 쉽고 스마트 계약 지갑 개발을 촉진하고 특정 사용자 그룹을 유치하고 축적할 수 있습니다.

미래 - 시행

비탈릭은 ERC - 4337 을 홍보하는 동안 EOA를 계약 주소로 업그레이드하고 가스 요금을 최적화하는 등 ERC-4337의 단점을 개선하기 위한 새로운 제안을 지속적으로 도입하기를 희망한다고 언급했습니다. 가능한 경로는 자발적인 채택을 거쳐 광범위한 대중화로 이어지고, 이후 의무적 변환을 최종적으로 구현하여 이더 계정 유형을 하나로 통합하는 궁극적인 목표를 달성하는 것입니다.

EIP-3074

프로그램 소개:

EIP 3074는 실제로 EIP 4337 보다 일찍 제안되었습니다. 새로운 거래 유형을 도입하지 않았지만 대신 AUTHAUTHCALL이라는 두 개의 명령어를 도입했습니다. 이를 통해 EOA 의 제어를 스마트 계약에 위임하여 모든 EOA가 스마트 계약 지갑의 기능을 가질 수 있습니다.

장점:

  • 다른 사람을 대신하여 가스 요금 지불: 가스 요금은 다른 계정으로 지불할 수 있으며, ETH를 보유하지 않은 주소에서도 토큰을 보낼 수 있습니다.

  • 일괄 거래: 단일 통화로 여러 거래를 보내 거래 수수료를 절감합니다.

문제점과 현재 상황:

이 제안은 이더 코드의 변경을 요구하며 이더리움 Shapella 업그레이드 단계에서 구현될 예정입니다. 다양한 보안 불확실성으로 인해 아직 검토 중입니다.

EIP-5003

프로그램 소개:

이 제안은 EIP 3074 의 확장으로서, 권한 주소가 권한 주소의 코드를 설정하고 EOA를 계약 계정으로 업그레이드할 수 있도록 하는 새로운 명령어 AUTHUSURP를 도입합니다.

장점:

EOA 에서 계약 계정으로 업그레이드를 실현합니다.

현상 유지:

이 제안은 EIP-3074를 기반으로 하며 아직 초안 단계에 있습니다. 그 진행은 EIP-3074 의 진행에 영향을 받을 것입니다.

2번째 레이어 ?

위의 EIP 개발 이력을 보면 계정 추상화가 이더 듀얼 계정 시스템의 레거시 문제를 해결하기 위한 것이라는 것을 알 수 있습니다. 그러나 프로토콜을 직접 변경하는 솔루션이 더 직접적이기는 하지만 더 많은 개발자를 동원해야 하며 계정 추상화의 시급성이 높지 않아 많은 장애물에 부딪혔습니다. 이에 비해 코드를 직접 바꾸는 솔루션은 생태계가 막 시작 단계에 있는 새로운 레이어 2 퍼블릭 체인에 더 적합할 수 있습니다. 예를 들어, Starknet 은 계정 추상화를 기본적으로 지원하는 체인입니다. 프로그래밍, 거래 전송, 자산 수신 및 전송 등이 가능한 통합 계정 유형이 하나뿐입니다. 10월zksync 2.0 메인넷이 출시되었고, 계정 추상화라는 새로운 기능도 도입되었습니다. 계정은 거래를 시작하고 배포된 코드 로직을 실행할 수 있습니다.

또한, 레이어 2는 종종 이더 메인넷보다 가스 요금이 낮습니다. 배포를 위해 가스를 지불해야 하는 스마트 계약 계정의 경우 사용자 경험이 더 좋고 비용이 낮아집니다.

따라서 계정 추상화가 이더 메인넷에 최종적으로 구현되기 전에, 레이어 2가 계정 추상화 및 계약 지갑 개발의 최전선에 설 수 있습니다.

계정 추상 추적 맵

계정 추상화는 모든 향후 계정이 계약 계정과 유사한 기능을 갖게 됨을 의미합니다. 계정 추상화가 합의 및 기반 코드에서 완전히 구현되기 전에도, 계약 계정의 장점을 파악하고 EOA 계정 시스템 외에 사용자에게 옵션을 제공하는 일부 스마트 계약 지갑 제품( 스마트 계약 지갑-SCW )이 이미 존재합니다.

여기서 스마트 계약 지갑과 관련 스마트 계약 플랫폼의 제품 리뷰를 통해 SCW 의 현재 개발 방향을 이해하고, 이를 통해 ERC-4337 또는 계정 추상화가 완전히 실현된 후 지갑의 가능한 응용 시나리오를 상상할 수 있습니다.

"계정 추상화"에 대한 긴 기사: 7년간의 경로 진화 및 트랙 맵

"계정 추상화"에 대한 긴 기사: 7년간의 경로 진화 및 트랙 맵

계정 추상 개념 프로젝트 비교

SCW 의 개발 이력에서, 그것은 몇 단계로 나눌 수 있습니다. 처음에는 Safe 가 대표하는 제품 이었으며, 이는 계정과 자산의 보안 문제를 해결하기 위해 Defi 의 번영을 통해 Argent , Pillar, Enters , and the Worlder 의 초점을 높이고 있습니다 이더 에서의 계정 추상화에 대한 직접적인 폭력 개혁의 가능성은 감소했으며, 이더 메인 네트워크의 높은 가스 수수료는 레이어 2를 기반 으로 한 새로운 기회를 제공했으며, Argent 의 개발 초점은 ZksyncUnipass 를 기반으로 한 Soul- Wallet 을 기반으로 한 Soul -Wallet 기반으로합니다 계정 추상화 및 계약 계정의 시간은 A3S 프로토콜에 의한 계정의 Nftization 과 같은 더 많은 활력과 잠재력을 갖습니다. Defisaver 의 모듈 기능은 일반 사용자에게 계약 지갑 기능을 사용자 정의하고 계정 로직을 설정할 수 있는 가능성을 제공합니다.

계정 추상화가 필요한가?

MetaMask 와 같은 전통적인 EOA 지갑은 사용자 경험이 좋지 않다는 비판을 받아왔습니다. 사용자는 개인 키나 니모닉 단어 적절히 관리하고 개인 키 유출 리스크 감수해야 합니다. 이로 인해 웹 3 세계로 진출하는 첫 걸음이 매우 높은 문턱을 가지게 됩니다.

최근, 대량 사용자와 트래픽을 보유한 많은 웹2 회사들이 웹3 으로 확장하려고 시도하고 있습니다. 예를 들어, Reddit은 사용자에게 Reddit NFT를 발행하여 Opensea의 기존 사용자 기반을 훨씬 초과하는 새로운 사용자를 쉽게 유치했습니다. Reddit은 NFT 민트 과정을 안내하면서 사용자의 이해 한계를 낮추고 주소, 개인 키, NFT 와 같은 복잡한 개념을 모호하게 만드는 데 최선을 다하고 있습니다.

개인 키리스 계약 지갑을 사용하면 임계값을 근본적으로 없앨 수 있으며, 많은 수의 web2 사용자가 web3 에 진입할 수 있는 더 나은 채널을 제공합니다.

하지만 안전하고, 열쇠가 필요 없는 경험을 계정 추상화나 계약 주소를 통해서만 실현할 수 있을까요?

아니요.

첫 번째 옵션은 현재 대부분 거래소 에서 사용하는 보관형 지갑입니다. 즉, 개인 키가 사용자의 손에 있지 않고 거래소 사용자를 대신하여 자산을 보관하고 관리하며 사용자는 자신의 자금을 완전히 통제할 수 없습니다. 이러한 보관형 지갑은 사용자 임계값을 크게 낮출 수 있지만, 그에 상응하는 신뢰 리스크 있습니다. 최근 FTX가 갑자기 붕괴되면서 사용자들은 보관 중인 자산이 횡령되었을 수 있고, 강력해 보이는 기관도 붕괴될 수 있다는 사실을 깨닫게 되었습니다. 가장 안전한 선택은 자신의 자산을 완전히 스스로 통제하는 것입니다. 열쇠도 아니고 동전도 아니야 .

MPC(Multi-Party Compution )라는 기술을 사용하는 또 다른 유형의 지갑도 있는데, 이 역시 일부 계약 지갑이 달성하고자 하는 보안과 키리스 사용자 경험을 달성할 수 있습니다.

일반적으로 MPC는 대부분 임계값 서명( TSS-Threshold Signature Scheme ) 방식을 사용합니다. 간단히 말해서, 개인 키를 조각내어 탈중앙화 넘겨 계산 및 암호화를 수행합니다. 개인 키 서명이 필요한 경우 조각을 모아 완전한 개인 키를 형성하고, 이를 통해 제어를 분산시켜 단일 지점 장애로 인한 보안 문제를 방지합니다. 이 방법은 셀프 커스터디와 커스터디 사이에 있으며 반 커스터디형 지갑이라고 할 수 있습니다.

이 논리는 다중 서명 지갑의 논리와 다소 비슷하지만, 다중 서명 지갑의 차이점은 각 다중 서명자가 계약 계정을 제어하기 위해 완전한 개인 키 서명을 제공하는 반면, TSS 검증 프로세스에는 오프체인이며 스마트 계약과 직접적인 관련이 없는 하나의 개인 키만 포함된다는 것입니다.

현재 B 버전용 Safeheron , C 버전용 Bitizen 등 우수한 MPC 지갑 제품도 많이 있습니다.

"계정 추상화"에 대한 긴 기사: 7년간의 경로 진화 및 트랙 맵

MPC는 개인 키 없이도 기능을 실현할 수 있으며, MPC는 EOA를 기반으로 할 수 있는데, EOA는 사용 비용이 저렴하고 호환성이 더 좋은 것으로 보입니다. MPC 기술은 EVM 체인에만 적용 가능한 것이 아니라 다른 비 EVM 계정에 대해서도 적용 가능합니다. 그렇다면 개인 키가 필요 없는 목적에 기반한 계약 지갑이나 계정 추상화가 정말 필요한가요?

그런 논쟁은 실제로 존재합니다. 올해 5월, Coinbase는 계약 지갑의 비싼 가스 와 사용자가 신뢰할 수 있는 보호자를 찾을 수 없을 가능성에 대해 자체 MPC 지갑에 대한 홍보 트윗에서 의문을 제기했습니다.

비탈릭은 또한 트위터 에서 자신의 태도를 다음과 같이 표현했습니다.

"계정 추상화"에 대한 긴 기사: 7년간의 경로 진화 및 트랙 맵

Vitalik은 계정 서명 알고리즘을 사용자 정의하는 목표를 달성하기 위해 프로토콜 수준에서 계정 추상화를 수행하려고 하는 것을 알 수 있습니다. 현재 이더 에서 시행하는 ECDSA 서명 알고리즘은 최상의 선택이 아닙니다. MPC는 ECDSA를 기반으로 하는 로컬 보안 솔루션일 뿐입니다. 계정 추상화를 달성한 후에는 기술 개발에 따라 더욱 진보적이고 안전한 서명 알고리즘(양자 저항 알고리즘 등)을 바로 사용할 수 있습니다.

따라서 보다 안전한 서명 알고리즘, 더 나은 사용자 경험, 보다 완벽한 자산 제어의 관점에서 계정 추상화는 여전히 매우 필요합니다.

궁극적인 형태의 계정 추상화 지갑

계정 추상화가 대중화되고 합의가 이루어지면 계약 계정의 호환성과 경제성이 향상될 것입니다. 여기서 우리는 또한 그러한 제품의 최종 상태, 제공할 수 있는 기능 및 적용 가능한 시나리오에 대한 낙관적인 예측이나 기대를 합니다. 우리는 다음과 같은 기능과 응용 시나리오가 포함될 수 있다고 믿습니다.

  1. 개인키 불필요: 사용자는 더 이상 니모닉 단어 이나 개인키를 보관할 필요가 없으며 생체인증, 기기인증 등 다양한 검증방법을 활용할 수 있다.

  2. 계정 복구: 계정 복구는 생체 인식, 사회적 검증 등을 통해 수행될 수 있습니다.

  3. 가스 상호작용 없음: 사용자는 거래에 관련된 ERC-20 토큰을 사용하여 가스 비용을 지불하거나, 사전에 ETH를 가스 로 준비하지 않고도 지불을 위한 고정 계정을 직접 지정할 수 있습니다. 또는 거래가 실패할 경우 가스 요금이 필요하지 않습니다.

  4. 사용자 지정 보안 메커니즘: 암호화가 발전함에 따라 더 나은 보안 메커니즘을 선택할 수 있습니다.

  5. 개인정보 보호: 링 서명과 같은 방법을 통해 보다 효과적인 온체인 개인정보 보호

  6. 임시 계좌 수탁: 사용자는 관리자, 기간, 상호작용 등의 요구 사항을 설정하고, 관리를 위해 자신의 계정을 다른 사람에게 위탁할 수 있으며, 이는 시간 또는 요구 사항이 충족되면 자동으로 회수됩니다.

  7. 계정 담보 / 거래: 계정에는 자산과 누적된 온체인 신용 기록이 포함됩니다. 계정 자체는 온체인 시장에서 직접 담보되고 거래될 수 있습니다.

  8. 계정 권한 제한 및 세분화: 계정에서 NFT 만 사용할 수 있고 토큰은 사용할 수 없도록 하는 등 다른 사람에게 일부 계정 권한을 부여할 수 있습니다.

  9. 사용자 정의 가능한 워크플로: 자동화된 트리거 및 프로세스를 설정합니다. 예를 들어, 계정 A 의 잔액1 Eth를 0.5 ETH 만큼 초과하면 초과 0.5 ETH가 자동으로 계정 B 로 전송됩니다. 특정 토큰이 특정 가격에 도달하면 계정 B는 자동으로 ETH를 특정 토큰으로 스왑합니다...

  10. 거래 제한: 거래 시간과 금액을 설정할 수 있습니다. 시간이나 금액을 초과하는 거래는 성공하지 못합니다.

  11. 허용 목록 / 차단 목록: 블랙리스트에 있는 주소와의 상호 작용을 제한합니다. 예를 들어, 블랙리스트에 있는 주소에서 보낸 자산은 Tornado Cash가 제재를 받고 다른 주소가 " 독살 " 되어 다른 프로토콜 프런트 엔드에서 실수로 주소가 금지되는 상황을 피하기 위해 자동으로 반환됩니다.

  12. 계정 분류 관리 시스템: 사용자는 다양한 시나리오에서 전용 계정을 사용하고, 보다 합리적인 계정 관리 시스템을 갖추고 있습니다. 예를 들어, 계정은 ETH 만 저장하는 가스 계정으로 사용되고 다른 계정과의 모든 상호작용은 가스 계정으로 지불됩니다. 계정은 블루칩 NFT 만 저장하며 쉽게 사용되지 않습니다. 계정은 게임별 계정으로 사용됩니다.

  13. 모듈 식 코드 기능: 사용자에게 다양한 기능 모듈 제공합니다. 사용자는 코드를 이해할 필요가 없습니다. 사용자는 자신의 필요에 따라 기능 모듈 결합하여 습관과 필요에 맞는 계정을 사용자 정의하기만 하면 됩니다.

결론:

계정 추상화의 구현은 모든 사람의 기대에 부응할 만한 가치가 있습니다. 이를 통해 온체인 사용자 수가 대폭상승 뿐만 아니라, 계정 추상화가 개발자에게 제공하는 높은 수준의 자유도를 통해 현재 계정 시스템의 문제점을 해결하고 새로운 애플리케이션, 게임 플레이, 상상의 공간이 탄생할 것입니다.

코드 수준에서 계정 추상화를 실현하는 것은 장애물과 불확실성으로 가득 차 있습니다. EIP-4337 과 같은 타협 솔루션은 여전히 ​​높은 가스 가격과 낮은 호환성과 같은 실질적인 문제가 있지만, EIP-4337을 적극적으로 홍보하는 것도 개념을 홍보하고 합의를 강화하는 선택입니다. 이 개념이 대중화됨에 따라 계정 추상화와 계약 지갑은 틈새 시장에서 주류 시장으로 이동하면서 사용자 요구에 따른 프로토콜 호환성을 확대하고 새로운 계정 패러다임을 형성할 것입니다. 마지막으로, 광범위한 합의를 통해 이더 기본 코드를 직접 변경하여 계정 추상화를 달성할 수 있는 조건을 갖추게 되었습니다.

최종 계정 추상화가 구현되면 현재 계정 시스템의 높은 한계와 복잡한 사용자 경험은 더 이상 당연하게 여겨지지 않을 것입니다. 이 새로운 계정 시스템은 웹3에 새로운 사용자와 트래픽을 유치하는 데 더욱 도움이 될 것이며, 생태계의 활발한 발전을 촉진하여 긍정적인 순환을 형성할 것입니다.

출처
면책조항: 상기 내용은 작자의 개인적인 의견입니다. 따라서 이는 Followin의 입장과 무관하며 Followin과 관련된 어떠한 투자 제안도 구성하지 않습니다.
라이크
즐겨찾기에 추가
코멘트