이더넷 계정 추상화 트랙의 과거와 미래를 4337에서 7702로 해독하기

서문

이 백서는 두 개의 모듈로 나뉩니다.

전반부는 2015년의 첫 AA 제안부터 시작됩니다. 전반부에서는 2015년의 첫 번째 AA 제안부터 시작하여 지금까지의 EIP 제안의 주요 내용을 체계적으로 정리하여 역대 AA 제안의 역사를 발굴하고, 각 프로그램의 장단점을 종합적으로 평가할 예정입니다.

하반기에는 EIP4337이 제안된 후 부진했던 시장 피드백을 중점적으로 비교하고, 다음 버전의 이더리움 업그레이드에 포함될 예정이며 통합되면 모든 측면에서 온체인 애플리케이션의 형태를 변화시킬 EIP7702를 심층적으로 분석할 것입니다.

EIP-7702는 획기적인 변화를 가져올 것이며, 이에 대해 준 XIV의 이야기를 들어보겠습니다

1, 계정 추상화의 배경

1.1 계정 추상화의 의미있는 포지셔닝

2023년 말 이더리움 창립자 비탈릭은 다시 이더리움 개발 로드맵을 업데이트했지만 계정 추상화 설정에 대해서는 변경하지 않았습니다. 를 변경하지 않았습니다. 오늘날의 지배적인 모델도 정확히 EIP-4337에서 나온 것으로, 다음 단계인 자발적EOA 전환(자발적 EOA 계정 전환)으로 나아가고 있습니다.

https://x.com/VitalikButerin/status/1741190491578810445

EIP4337 출시 후 1년이 넘었습니다. 2023.3.1 덴버에서 열린 월렛콘에서 이더리움 재단 개발자들이 설계하고 구현한 ERC-4337의 핵심 계약이 오픈제플린의 감사를 통과하여 공식 출시를 위한 역사적인 노드로 간주된다고 공식적으로 발표되었습니다).

사용자들에게 널리 알려졌을 뿐 널리 사용되지는 않는 모순적인 시장 환경 덕분에 EIP-7702는 다음 업그레이드에서 통합될 것이 이미 확정될 정도로 크게 발전할 수 있었습니다.

1.2 계정 추상화 시장 현황

더 이상 설명할 필요 없이 데이터를 보시면 됩니다.

1년 반의 개발 기간 끝에 EIP4337은 주류 체인 계정 모음에서 1,200W 주소만 가지고 있으며, 가장 놀라운 점은 이더 메인 네트워크에서 활성 주소 수가 6,764개에 불과하다는 것인데, 이는 통계적 차원에서는 문제가 될 수 있지만 적어도 EOA 및 CA의 주소 수와는 차이가 있다는 것입니다. 메인 이더리움 네트워크의 고유 주소 수는 2억 7천만 개에 달합니다(출처: https://etherscan.io/chart/address).

EIP4337은 메인넷에서 아무데도 가지 않는다고 해도 과언이 아닙니다.

(차트 데이터 출처: https://dune.com/niftytable/account-abstraction)

그러나 이는 AA의 본질적인 가치에 영향을 미치지 않습니다. EIP4337의 설계 초기부터 그는 주 네트워크에서 심각한 순방향 호환성 문제에 직면하여 잘 할 수 없으므로 기본 AA의 일반적인 임베딩의 모든 종류의 L2 계층 체인과 함께 7 월 월간 활성 사용자의 기본 및 다각형 체인의 폭발을 얻기 위해 L2의 EIP4337 주소 번호는 각각 100W 및 300W이지만 상당히 상당합니다.

따라서 EIP4337이 잘못 설계된 것이 아니라 잠시 후에 체계적으로 요약 할 많은 장점이 있으며, 오늘날의 상황은 메인넷과 L2의 차이에서 비롯되며, 이는 자신의 적절한 솔루션과 함께 사용해야합니다.

2. 계정 추상화란 무엇인가요?

계정 추상화는 매우 혼란스럽게 들리지만 사실 이 솔루션의 본질은 재산권을 분리하는 것입니다.

EVM 아키텍처(즉, 이더넷 가상 머신)에는 두 가지 유형의 계정, 즉 외부 계정(EOA)과 계약 계정이 있는데, 소유권과 서명이 동일한 주체에 의해 보유되는 경우입니다. 실제로는 동일한 물리적 단위가 보유하고 있습니다. 개인키를 보유한 사람은 계정의 소유권뿐만 아니라 모든 이체에 대해 서명할 수 있는 권한도 갖습니다.

이것은 이더넷 계정 거래 구조에 따라 결정됩니다

아래 이미지의 구조에서 볼 수 있듯이 실제로 이더넷에서는 표준 거래에 대한 From 쪽이 없기 때문에 자금 이체를 했는데, 정확히 무엇을 썼나요? 주소에 자금을 보냈을까요? 실제로는 VRS 매개변수(즉, 사용자의 서명)를 통해 역파싱되는 것은 발신자 주소입니다.

여기에는 ECDSA, 단방향 임계값 함수 및 기타 개념과 같은 비대칭 암호화가 포함되며, 간단히 말해서 보안을 보장하기 위한 암호화는 물론 오늘날의 재산권으로 이어져 EOA 주소 딜레마를 병합하는 데까지 이르렀습니다.

그리고 EIP4337의 핵심 효과는 트랜잭션 필드에 발신자 주소 필드를 추가하여 개인 키를 조작되는 주소와 분리할 수 있도록 하는 것입니다.

제목 분리가 중요한 이유는 무엇일까요? 왜 그렇게 중요한가요?

외부 계정(EOA) 설계로 인해 더 많은 문제가 발생할 수 있기 때문입니다:

1. 개인 키 보호하기 어려움: 사용자의 개인키를 분실하거나 해킹당하거나 암호가 손상되면 모든 자산이 손실됩니다.

2. 서명 알고리즘이 거의 없음: 네이티브 프로토콜은 트랜잭션 확인을 위해 ECDSA 서명과 서명 확인 알고리즘만 사용할 수 있습니다.

3. 높은 서명 권한: 네이티브 다중 서명(다중 서명은 스마트 컨트랙트를 통해서만 협업을 달성할 수 있음)이 없으며, 단일 서명으로 모든 작업을 수행할 수 있습니다.

4. 거래 수수료는 이더리움을 통해서만 지불할 수 있으며, 일괄 거래는 지원하지 않습니다.

5. 거래 개인정보 보호: 일대일 거래를 통해 계정 소유자의 개인 정보를 쉽게 분석할 수 있습니다.

앱 제약으로 인해 일반 사용자가 이더를 사용하기 어렵습니다:

우선, 이더에서 앱을 사용하려면 사용자가 이더를 보유해야 하고 이더 가격 변동에 따른 위험을 감수해야 합니다.

둘째, 사용자는 복잡한 수수료 로직을 처리해야 하며, 가스 가격, 가스 한도, 거래 차단(논스 순서)의 개념이 너무 복잡하여 사용자가 이해하기 어렵습니다.

마지막으로, 많은 블록체인 지갑이나 앱이 제품 최적화를 통해 사용자 경험을 개선하려고 노력했지만 실질적인 효과는 거의 없었습니다.

이러한 문제를 해결하기 위해서는 계정 추상화를 통해 소유자와 서명자를 분리하여 각각의 문제를 해결하는 것이 해결책이 될 수 있습니다.

실제로 많은 기록 제안이 있으며, 결국 두 가지 경로로 수렴합니다

3, AA 기록 제안 펄스 콤빙

문제에 대한 해결책은 많은 EIP 제안이 있는 것 같지만 최종 분석에서 두 가지 핵심이 있습니다. 아이디어이므로 과거에 채택되지 않은 모든 EIP에 대해 고려 사항이 현재 제안의 문제 해결 방안으로 수렴되었습니다.

3.1 첫 번째 경로는 EOA 주소를 CA 주소로 만드는 것입니다

2015년 11월 15일, EIP-101 즈음에 비탈릭은 컨트랙트를 계정으로 사용하는 새로운 구조를 제안했습니다. 주소를 코드와 저장소만으로 변경하고, 수수료 지원을 ERC20으로 지불하도록 변경하고, 잔액을 보유하기 위해 컨트랙트를 미리 컴파일하여 네이티브 토큰을 ERC20처럼 변경하고(승인 보류와 같은 기능을 가질 수 있음), 거래 필드를 to, startgas, 데이터 및 코드로 간소화했습니다.

이제 각 계정 주소에 고유한 "코드" 로직을 갖도록 기본 설계를 대폭 변경하는 것은 큰 도약처럼 보입니다(현재 EIP-7702가 시도하고 있는 것과 정확히 일치합니다).

다른 기능으로는 다음과 같은 것들이 파생될 수 있습니다.

1. 각 주소의 내부에서 지정할 수 있는 더 많은 암호화 알고리즘을 거래에 사용할 수 있도록 하는 것. 서명 확인 인증 방법을 지정하는 코드

2. 코드 업그레이드로 인해 양자 공격에 대한 내성 강화.

3. 이더리움에 원천징수 승인이라는 핵심 효과와 함께 ERC20 계약과 동일한 기능을 제공하므로 네이티브 코인 손실이 필요 없음

4. 계정의 사용자 정의 공간 향상 사용자 정의 공간, 소셜 복구, sbt 지원, 키 검색 등과 호환

전진하지 않는 이유도 매우 간단하며, 분명히 현재 거래 해시 충돌 문제에 비해 속도가 너무 크고 보안 위험이 잘 고려되지 않아 보류되었지만 아이디어의 각 장점은 다음과 같이되었습니다. EIP4337과 EIP7702의 핵심 기능 중 하나입니다.

이 로직을 개선하려는 일련의 후속 EIP가 있었습니다

EIP-859: 마스터 체인 계정 추상화 - 2018-01-30

style="text-align: left;">코드의 배포 문제를 해결하기 위해 거래에 첨부된 코드 파라미터를 사용하여 거래 상대방 계약이 배포되지 않은 경우 계약 지갑 배포를 실행하는 것이 핵심 역할이며, 두 번째로 가스 지불과 더불어 거래 파라미터의 유효성 검사 부분이 실행 부분이 되는 새로운 PAYGAS 옵코드를 제안하고 있습니다. 새로운 PAYGAS 옵코드도 제안됩니다.

당시에는 끝이 보이지 않았지만, 이것은 현재 EIP7702의 핵심 로직 중 하나가 되었고, 특별한 거래 구조와 결합된 EIP7702의 각 거래에는 일정량의 코드가 수반되어 EOA 주소가 이 거래에서 계약 기능을 가질 수 있게 됩니다.

EIP-7702: EOA 계정 코드 설정 2024-05-07

이 메커니즘의 핵심 EIP는 이 글의 뒷부분에서 설명할 것입니다. 비탈릭은 EIP-3074(2024-05-07)의 대안으로 EIP-7702를 발표했습니다. 그 결과 EIP-3074는 폐기되었고, EIP-7702가 곧 있을 이더리움 프라하/일렉트라(펙트라) 하드포크에 포함될 것으로 확정되었으며, 자세한 내용은 아래에서 자세히 설명해드리겠습니다.

3.2 두 번째 경로는 EOA 주소가 CA 주소를 구동하도록 하는 것입니다

EIP-3074: 추가AUTH 및AUTHCALL Opcode - 2020-10-15

EVM에 두 개의 새로운 옵코드를 추가합니다. AUTH 및 AUTHCALL; EOA가 대신 이 두 옵코드를 통해 계약을 승인할 수 있도록 다른 컨트랙트를 호출하기 위한 EOA의 신원.

아래 다이어그램과 함께 요약하면, EOA는 서명된 메시지(트랜잭션)를 신뢰하는 컨트랙트(Invoker라고 함)에 보낼 수 있으며, Invoker는 다른 컨트랙트에 호출을 위해 인보커 컨트랙트를 사용할 수 있다는 뜻이죠. >컨트랙트는 이 EOA 대신 이 트랜잭션을 전송하기 위해 AUTH 및 &authcall 옵코드를 사용할 수 있습니다.

EIP-4337: 트랜잭션 메모리 풀을 사용한 계정 추상화 - 2021-09-29

요약하자면, 그는 MEV에서 영감을 받아 설계했으며, 그의 핵심 가치는 합의 계층 프로토콜 변경을 완전히 피할 수 있는 기능입니다.

eip4337은 사용자가 메모리 풀로 전송하는 새로운 트랜잭션 객체, UserOperation를 제안하며, 여기서 번들러는 채굴자 차원에서 컨트랙트를 일괄 패키징하고 전달하여 트랜잭션을 실행합니다. 이는 기본적으로 기본 트랜잭션과 계정 작업을 실행을 위해 컨트랙트 수준으로 끌어내립니다.

EIP-5189: 보증인이 운영하는 추상 계정-2022-06-29

이것은 일종의 최적화입니다. EIP4337의 로직은 악의적인 <코드>번들러에 직면했을 때 페널티 보증 보증인에게 자금을 지원하는 메커니즘을 만들어 Dos 차단 공격을 방지하는 것입니다.

3.3 AA 지원을 위한 기타 제안

EIP-2718: 새로운 거래 유형을 위한 패키징 봉투 - 2020-. 06-13

이 제안은 향후 추가될 봉투로 사용할 새로운 트랜잭션 유형을 정의하는 최종 제안입니다.

그 결과 새로운 트랜잭션 유형이 도입될 때 특정 인코딩을 사용하여 어떤 트랜잭션인지 구분함으로써 이전 버전과의 호환성만 허용하고 이전 버전과의 호환성은 허용하지 않습니다. 가장 일반적인 예는 거래 수수료를 구분하고 원래 레거시 거래 유형에 영향을 주지 않고 새로운 거래 유형 인코딩을 사용하는 EIP1559입니다.

EIP-3607: 만들기EOA배포할 수 없는 컨트랙트 주소 지정 - 2021-06-10

컨트랙트 배포 주소가 EOA 주소와 충돌하는 문제를 방지하기 위해 AA 경로에서 보완하는 솔루션입니다. 시스템이 이미 EOA 주소인 주소에 코드를 배포할 수 없도록 컨트랙트 생성 방법을 제어합니다. 이더리움 주소는 160비트 길이이고, 주어진 컨트랙트 주소에 대해 개인 키와 개인 키를 충돌시키는 방법이 있긴 하지만, 비트코인 컴퓨팅 성능이 최대로 발휘되기까지는 아직 1년이 걸릴 것으로 예상되기 때문에 이러한 위험은 실제로 매우 작습니다.

3.4 계정 추상화 개발 이력을 어떻게 이해하나요?

가장 먼저 이해해야 할 것은 CA로의 전환의 가치입니다

기본적으로 EIP-4337이 실제로 하는 일이 바로 그 일입니다

그러나 EIP-4337의 가장 큰 단점은 인간의 동기 부여 원칙에 어긋난다는 점입니다.

그는 더 좋아 보이지만 시장 발전의 일종의 데드 서클에 갇혀 있고, Dapp은 여전히 호환되지 않는 경우가 많으며, 사용자는 CA 주소를 사용하는 것을 좋아하지 않으며, CA를 사용하더라도 거래 비용이 더 높고(일반적인 전송 시나리오, 거래 비용도 두 배가 됨), Dapp 자체의 호환성에 너무 의존적입니다.

이러한 이유로 지금까지 메인 이더리움 네트워크에서 인기를 끌지 못했습니다.

비용은 사용자에게 가장 중요한 지표이며, 이를 낮춰야 합니다.

그러나 진정으로 GAS를 줄이기 위해서는 이더 자체가 소프트포크 업그레이드를 하거나 GAS 계산을 수정하거나 옵코드의 GAS 소비량과 같은 모듈을 수정해야 하는데, 소프트포크를 해야 하므로 EIP-7702를 고려해보시는 건 어떨까요?

4. EIP-7702에 대한 종합 분석

4.1 EIP-7702란

새로운 EVM opCode를 도입하지 않고도 단일 트랜잭션에서 일시적으로 스마트 컨트랙트 기능을 가질 수 있는 새로운 거래 유형으로 배치 거래, 가스 프리 거래, 사용자 지정 권한 관리 등의 업무를 지원하는 것이 차별화됩니다(하위 호환성에 영향을 미침).

스마트 컨트랙트를 배포하지 않고도 대부분의 AA 기능에 액세스할 수 있으며, 사용자가 개인 키를 제공하지 않고도 제3자가 사용자 대신 거래를 개시할 수 있는 기능을 제공하여 승인 정보에 서명하는 것만으로도 가능합니다.

4.2 데이터 구조

새 트랜잭션 유형 0x04를 정의하며, 트랜잭션 페이로드는 다음과 같습니다. 콘텐츠의 RLP 인코딩된 직렬화 결과

중요하게는 서명자가 실행하고자 하는 코드를 EOA에 저장하고 사용자가 실행할 계약의 코드와 함께 트랜잭션에 서명하는 새로운 authorization_list 객체가 있으며, 이는 2차원 목록으로 존재하여 일괄 처리할 수 있다는 것을 나타냅니다. 그는 2차원 목록으로 존재하며, 여러 작업에 대한 정보를 일괄 저장하고 일괄 작업을 수행할 수 있음을 나타냅니다.

4.3 트랜잭션 수명 주기

4.3.1 유효성 검사 단계

트랜잭션 실행이 시작될 때, authorisation_list의 각 [chain_id, address, nonce, y_parity, r, s] 튜플에 대해:

1. ecrecover를 사용하여 서명 r, s에서 서명자의 주소를 복구합니다(이는 이더 자체의 메커니즘이므로 이 EIP는 서명 알고리즘을 변경하지 않습니다). authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s] (앞서 서명을 복호화하여 FROM 주소를 도출한 것과 유사하며, 여기서는 이 목록의 로컬 서명 주소입니다). )

2. 체인 ID를 확인합니다(포크 체인 리플레이를 방지하기 위해).

3. 권한 서명자의 코드가 비어 있거나 위임되었는지 확인합니다(트랜잭션이 유효한 7702 트랜잭션인지 확인하면 위임 메커니즘이 에이전트를 대신하여 트랜잭션을 실행할 것입니다).

4. <코드>권한 서명자의 논스를 확인합니다(<코드>권한 서명의 재연출을 방지하기 위해).

5. authority 서명자의 코드를 0xef0100 || 주소로 설정합니다(EIP3607 충돌 정책 우회용)

6. authority 서명자의 논스를 검증합니다(authority 서명의 재생 방지용). li>

   authority 서명자 논스를 추가합니다(로컬 서명 재생 방지).

7. 방문 주소 목록에 권한 서명자 계정 추가(주소의 열을 높이고, 스토어 조회 시 가스 요금 절감)

4.3.2 운영 실행 단계

실행할 계약 코드와 운영 지침은 어디에 있나요?

"새" 버전은 코드 배포 측면의 동작만 변경합니다.

더 이상 계정 코드를 contract_code로 설정하지 않고 대신 authorisation_list에서 address 코드를 검색하여 해당 코드를 계정 코드로 설정합니다.

따라서 인증 코드를 실행해야 할 때 authorization_list의 address 필드에 지정된 주소에서 코드가 로드되고 서명자 계정의 컨텍스트에서 실행됩니다.

이것은 사용자의 컨트랙트 코드가 트랜잭션에 직접 포함되지 않고 실제로 체인의 특정 주소에 저장된다는 것을 의미합니다.

작업 지시와 관련 파라미터는 트랜잭션 로드의 데이터 필드에 저장됩니다.

4.4 EIP-7702의 값은 무엇인가요?

웹3 지갑의 전체 체인에 변화를 가져올 것이며, 결과적으로 사용자 경험은 크게 달라질 것입니다. EOA에 의해 시작된 일반 거래도 일괄 전송과 같은 다양한 로직을 수행하도록 유사하게 계약될 수 있기 때문입니다. CeFi 시나리오의 경우 거래 인증에 영향을 주고 플러시 출금에도 영향을 미칩니다. 풀링 수수료

풀링 수수료의 등장으로 인해 다음과 같은 고정관념이 많이 깨졌습니다:

1. 계좌 잔액은 해당 계좌에서 발생한 거래에서만 해당 계정에서 발생한 거래에 의해서만 감소할 수 있다는 규칙을 위반합니다.

2. 거래 체결 시작 후 EOA 논스가 1씩 증가한다는 불변성을 위반합니다(동시에 1 이상 증가할 수 있음).

3. tx.origin과 msg.sender의 두 비교의 가딩 로직을 깨뜨리고 많은 과거 계약이 위험에 처하게 됩니다.

4. EOA 자체가 이벤트를 전송할 수 없으며 일부 온체인 이벤트 인식 리스너에 주의를 기울여야 할 수 있는 현 상황을 깨뜨립니다.

5. ERC20, 721, 1155 등과 같은 자산을 받아들이는 EOA 주소는 성공할 수밖에 없는(콜백 메커니즘으로 인해 실패할 수 있는) 현 상황을 깨뜨립니다.

< strong>4.5 EIP-7702와 EIP-4337의 비교

1. EIP-7702의 장점

엔트리포인트 모듈을 거칠 필요가 없으므로 온체인 작업이 줄어들어 가스가 더 적게 발생합니다.

사용자 마이그레이션 비용 절감, 온체인 컨트랙트를 미리 메인으로 배포할 필요가 없음

Eip4337과 비교해 실행 코드 위임은 동일하며 다시 두 가지 방식으로 수행됩니다."

전체 위임

전체 위임은 특정 주소에 작업에 대한 전체 액세스 권한을 위임하는 것을 의미합니다. 예를 들어, 사용자가 모든 ERC-20 토큰의 관리를 스마트 콘트랙트 주소에 위임하면 스마트 콘트랙트가 사용자를 대신하여 모든 관련 작업을 수행할 수 있습니다.

보호 위임

보호 위임은 위임된 작업의 보안을 보장하기 위해 제한과 보호를 추가하여 위임하는 과정을 말합니다. 위임된 작업의 안전과 제어 가능성을 보장하기 위해 보호 기능을 추가하는 것을 말합니다.

예를 들어, 사용자는 하나의 스마트 컨트랙트에 ERC-20 토큰의 일부만 위임하거나 일부 제한(예: 하루 총 잔액의 1%까지만 사용)을 설정할 수 있습니다.

2. EIP-7702의 단점

EIP-7702의 핵심 단점은 모두의 합의로 추진해야 하는 소프트포크 업그레이드에 속하며, 변경 사항이 커서 체인 생태계에 미치는 영향이 너무 크다는 점입니다. 14명의 신사에 대한 예비 평가는 다음과 같은 도전이 있지만 도전은 시장 기회이기도 합니다 :

1. 자유도가 매우 높고 감사를 받기가 어렵고 사용자는 보안 보호를 맡기 위해 신뢰할 수있는 지갑을 더 많이 필요로하게 될 것입니다.

2. 자유도가 매우 높고 감사하기 어려우며, 사용자는 보안을 책임질 수 있는 신뢰할 수 있는 지갑을 더 많이 요구할 것입니다.

3. 원래 아키텍처에 대한 변경이 너무 급격했고, 다양한 거래 유형을 구분하기 위해 사용되었지만 많은 인프라, 특히 온체인 불변 계약은 직접 적용될 수 없었습니다.

4. EOA 주소에 대한 컨트랙트 기능은 제공되지만 해당 저장 공간은 유지할 수 없습니다.

5. 별도 트랜잭션의 비용은 콜 데이터 부분이 크게 증가하기 때문에 약간 더 높으며, 예상 총 비용은 16(가스) * 15(바이트) = 240 (가스) 콜 데이터 비용에 더하여 다음과 같습니다. EIP-3860 비용 <코드>2 * 15 = 30와 대략적인 런타임 비용 <코드>150가 더해집니다. 따라서 아무것도 하지 않도록 계정을 준비하는 것만으로도 500기가가 추가됩니다.

6. "수신자가 수신 기능이 없는 코드에 서명하면 발신자가 자산을 보내려고 할 때 DoS에 직면할 수 있습니다." 사례 보기. 문제는 실제로 EOA A가 서명해서는 안 되는 것, 즉 잘못된 구현이 설정된 재생 가능한 파일(receive() 없음)에 서명하고 있다는 것입니다.

7. 온체인 플러시 로직이 일관되지 않을 수 있는데, 예를 들어 ERC-20 토큰을 전송할 때 토큰 컨트랙트는 수신자 계정에 코드가 있는 경우 onERC20Received를 호출할 것입니다. onERC20Received가 잘못된 값을 반환하거나 되돌리면 토큰 전송이 되돌립니다.

8. 또 EOA가 이벤트를 전송할 수 있다면 문제가 있나요? 일부 인프라에는 주의가 필요할 수 있습니다.

이것은 현재 EIP7702 제안과 해당 공식 포럼 논의를 바탕으로 XIV가 요약한 단점 중 일부에 불과하며 궁극적으로 최종 구현 코드를 기반으로 분석해야 합니다.

다음 내용을 참조하세요:

5, 전체 요약

이 문서는 길어 보이지만 실제로 텍스트 내용은 6줄에 불과합니다. 이 기사는 긴 것 같지만 실제로 텍스트 내용은 6k 단어에 불과하고 중간에는 이전 EIP 해석이 많이 포함되어 있으며 텍스트 링크를 확장 할 수 있으며 추적에 들어 가지 않겠습니다.

현재, 계정 추상화는 실제로 여섯 번째 모듈, 즉 모든 것을 수리하는 것, 즉 오늘날의 EIP7702 진행의 실질적인 가속화를 구현하는 마지막, 그리고 더 많은 또는 시스템 보안의 도전, 그는 결국 달성 될 것으로 예상, 결국, 이더리움 합병, 합의 알고리즘의 수정과 같은 파괴적인 이벤트가 다시 발생할 수 있으며 EIP7702의 목적으로도 사용할 수 있으며, EIP7702는 EIP7702의 목적을 위해 사용될 수 있습니다. 파괴적인 이벤트가 발생할 수 있으며, 지구에서 새로운 유형의 거래에 대해 이야기할 수 있습니다.

그러나 이번에는 파괴적인 콘텐츠가 너무 많아서 여러 가지 불가능한 파괴적인 사슬을 깨고 대부분의 Dapp의 응용 로직도 깨지지만 가장 핵심적인 점, 즉 사용자의 비용이 더 낮다는 점을 죽였습니다! EIP4337의 거의 두 배에 가까운 트랜잭션 비용과 비교해보십시오.

사용자 자체가 여전히 EOA 주소이며, 필요할 때만 CA 로직을 구동하고 사용하기 때문에 소유 비용이 낮습니다. 작업을 수행하기 전에 온체인 CA ID에서 변환할 필요가 없으므로 사용자가 등록할 필요가 없습니다.

사용자는 승인된 원천징수, 2대1 원천징수 실행 등 여러 거래를 병렬로 쉽게 할 수 있어 사용자 거래 자체의 비용이 낮고, 특히 디앱의 경우 거래소 등 프로젝트 측의 체인 관리가 필요한데, 일괄 집계를 통해 최적화하면 이를 대체할 수 있습니다. 일괄 합산이 이루어지면 기본 교환 비용을 즉시 절반 이상 줄일 수 있으며 궁극적으로 사용자에게도 이익이 될 수 있습니다.

그러므로 그는 많이 바뀌었지만이 차원의 비용을 차지하지만 이번에는 사용자가 EIP7702의 측면에 서있을 수밖에 없기 때문에 모든 Dapp이 연구하고 적응할 가치가 있습니다.