머리말
이 문서는 두 가지 주요 모듈로 구성되어 있습니다.
상반기에는 2015년 첫 AA 제안을 시작으로 지금까지의 EIP 제안의 주요 내용을 체계적으로 정리하여 AA 역사적 제안의 이력을 발굴하고 각 방안의 장단점을 종합적으로 평가하고자 한다.
하반기에는 EIP 4337이 제안된 후 직면한 시장 침체 피드백을 비교하는 데 중점을 두고, 이 제안 이 다음 버전에 포함될 예정인 EIP 7702에 대한 심층 분석을 수행합니다. 병합되면 체인의 신청서가 완전히 변경됩니다 .
EIP-7702는 획기적인 변화를 가져왔습니다. Shishi 선생님의 자세한 설명을 들어보세요
1. 계정 추상 배경
1.1 계정의 추상적 의미
포지셔닝 이더리움 창시자 Vitalik은 2023년 말에 ETH 개발 로드맵을 다시 업데이트했지만 계정 추상화 설정은 변경되지 않았습니다. 오늘날의 주류 모델도 EIP-4337에서 다음 단계인 VoluntaryEOA Conversion(EOA 계정의 자발적 전환)으로 진입했습니다.
https://x.com/VitalikButerin/status/1741190491578810445
EIP 4337 출시 이후 1년여(2023년 3월 1일 덴버에서 열린 WalletCon에서 이더리움 재단 개발자들이 설계하고 구현한 ERC-4337의 핵심 계약이 OpenZeppelin의 감사를 통과했으며, 공식적으로 역사적인 노드를 출시합니다).
항상 사용자들에게 널리 인식되어 왔지만 널리 사용되지는 않았습니다. 이러한 모순된 시장 환경에서 EIP-7702의 발전은 크게 발전했으며 다음 업그레이드에 포함될 것이라는 사실도 확인되었습니다.
1.2 계정추출 시장현황
더 이상 고민하지 않고 데이터를 살펴보겠습니다.
1년 반의 개발 끝에 EIP 4337은 주류 체인 계정 모음에 1,200W 주소만 있습니다. 가장 놀라운 점은 이더리움 메인 네트워크에는 6,764개의 활성 주소만 있다는 것입니다. 아마도 통계적 차원이 다를 것입니다. 문제지만 적어도 EOA, CA의 주소 수와는 많이 다릅니다. 이더리움 메인넷의 독립 주소 수가 2억 7천만 개에 달했다는 사실을 아셔야 합니다(데이터 출처: https://etherscan.io/chart/ ). 주소).
메인 네트워크의 EIP 4337에는 실질적인 발전이 없다고 볼 수 있습니다.
데이터 소스: https://dune.com/niftytable/account-abstraction)
하지만 이것이 AA의 본질적인 가치를 말살하는 것은 아닙니다. EIP 4337의 설계 초기부터 메인 네트워크의 심각한 향후 호환성 문제에 직면하여 제대로 작동할 수 없도록 운명지어져 있었기 때문에 다양한 L2와 함께 레이어 체인 일반적으로 네이티브 AA에 내장된 EIP 4337의 주소 수가 L2에서 폭발적으로 증가했습니다. 7월 베이스 체인과 폴리곤 체인의 월간 활성 사용자는 각각 100W와 300W로 매우 인상적입니다.
따라서 EIP 4337의 설계가 잘못된 것은 아니며, 현재의 상황은 메인 네트워크와 L2의 차이로 인해 발생하는 것으로, 잠시 후에 체계적으로 정리하겠습니다. 솔루션.
2. 계정 추상화란 무엇입니까?
계정 추상화는 혼란스럽게 들리지만 실제로는 재산권 분리 문제를 본질적으로 해결합니다.
EVM 아키텍처에는 외부 계정(EOA)과 계약 계정(계약 계정)의 두 가지 유형의 계정이 있습니다. 외부 계정의 소유권과 서명 권한은 실제로 동일한 개인이 보유합니다. 단위. 개인 키를 보유한 사람은 계정에 대한 소유권을 가질 뿐만 아니라 모든 자산에 서명하고 양도할 수 있는 권한도 갖습니다.
이는 이더리움 계정의 거래 구조에 따라 결정됩니다.
아래 그림의 구조에서 볼 수 있듯이 실제로 이더리움의 표준 트랜잭션에는 From 당사자가 없습니다. 그렇다면 자금 이체를 수행하면 특정 주소에서 자금을 소비합니까? 실제로 보낸 사람 주소는 VRS 매개변수(예: 사용자 서명)를 통해 디코딩됩니다.
여기에는 ECDSA 및 단방향 임계값 기능과 같은 개념이 포함됩니다. 즉, 암호화는 보안을 보장하는 데 사용됩니다. 물론 이는 현재 재산권 합병의 EOA 주소 딜레마를 야기했습니다. .
EIP 4337의 핵심 효과는 트랜잭션 필드에 Sender Address 필드를 추가하여 개인 키와 운영 주소를 분리하는 것입니다.
그렇다면 재산권의 분리가 왜 그렇게 중요한가요?
외부 계정(EOA) 설계는 더 많은 문제를 야기하기 때문입니다.
개인 키는 보호하기 어렵습니다. 사용자가 개인 키를 분실(분실, 해커 공격, 암호화 크래킹)하면 모든 자산을 잃게 됩니다.
몇 가지 서명 알고리즘: 기본 프로토콜은 ECDSA 서명 및 서명 확인 알고리즘만 사용하여 트랜잭션을 확인할 수 있습니다.
높은 서명 권한: 기본 다중 서명이 없으며(다중 서명은 스마트 계약을 통해서만 협업 가능) 단일 서명으로 모든 작업을 수행할 수 있습니다.
거래 수수료는 ETH로만 지불 가능하며, 일괄 거래는 지원되지 않습니다.
거래 개인정보 유출 : 1:1 거래를 통해 계좌 보유자의 개인정보를 쉽게 분석할 수 있습니다.
항소의 제약으로 인해 일반 사용자가 이더리움을 사용하기가 어렵습니다.
첫째, 이더리움에서 애플리케이션을 사용하려면 사용자는 이더를 보유해야 합니다(그리고 이더 가격 변동 위험을 감수해야 합니다).
둘째, 사용자는 복잡한 비용 로직을 처리해야 합니다. 가스 가격, 가스 한도 및 거래 차단(Nonce 순서)의 개념은 사용자에게 너무 복잡합니다.
마지막으로 많은 블록체인 지갑이나 애플리케이션이 제품 최적화를 통해 사용자 경험을 향상시키려고 노력하지만 실제 효과는 미미합니다.
따라서 이러한 상황을 타파할 수 있는 방법은 계정 추상화를 구현하고 소유권(소유자)과 서명권(서명자)을 분리하여 위의 문제를 하나씩 해결해 나가는 것입니다. 실제로 역사적 계획은 여러 가지가 있는데, 결국 두 가지 노선으로 수렴하게 됩니다.
3. AA 제안 내역 검토
문제를 해결하기 위한 EIP 제안은 많이 있는 것 같지만, 최종적으로 분석하면 핵심 아이디어는 두 가지입니다. 따라서 과거에 통과되지 못한 모든 EIP에서 고려된 문제도 현재 솔루션의 솔루션으로 수렴되었습니다.
3.1 첫 번째 경로는 EOA 주소를 CA 주소로 변경하는 것입니다.
2015년 11월 15일 EIP-101을 둘러싸고 Vitalik은 계약을 계정으로 사용하는 새로운 구조를 제안했습니다. 코드와 저장 공간만 갖도록 주소를 변경하고, ERC 20 결제를 지원하도록 처리 수수료를 변경하고, 사전 컴파일된 계약을 통해 네이티브 토큰을 ERC 20과 유사한 매장 잔액으로 변경하고(원천징수 승인 등의 기능을 가질 수 있음), 트랜잭션 필드를 startgas, 데이터 및 코드로만 간소화합니다. 이제 이것은 단순히 Great Leap Forward 스타일의 변경인 것으로 보입니다. 이는 각 계정 주소가 고유한 코드 논리를 갖도록 기본 디자인을 크게 변경합니다(사실 이것이 바로 EIP-7702가 현재 달성하려고 하는 것입니다). ). 다음과 같은 다른 함수도 파생될 수 있습니다.
거래에서 더 많은 암호화 알고리즘을 사용할 수 있도록 하며 서명 확인 방법은 각 주소의 내부 코드로 지정할 수 있습니다.
코드에 업그레이드 특성이 있어 양자공격에 강하다.
이더리움은 ERC 20 계약과 동일한 기능적 특성을 가지며 핵심 효과에는 보류 승인이 있으므로 기본 통화를 잃을 필요가 없습니다.
소셜 복구, SBT 지원, 키 검색 등과 호환되는 계정 사용자 정의 공간을 개선합니다.
계속 진행하지 않는 이유도 매우 간단합니다. 현재 거래의 해시 충돌 문제와 보안 위험에 대해서는 각 이점에 대한 고려가 부족하여 보류되었습니다. 후속 EIP 4337 및 EIP 7702의 핵심 기능이 되었습니다.
나중에 이 논리를 개선하려는 일련의 EIP가 있었습니다.
EIP-859: 메인체인 계정 추상화--2018-01-30
Code의 배포 문제를 해결하려는 핵심 기능은 거래 당사자 계약이 배포되지 않은 경우 거래에 첨부된 코드 매개 변수를 사용하여 계약 지갑 배포를 실행하는 것입니다. 둘째, 새로운 PAYGAS 작업 코드도 제안됩니다. 가스를 지불하는 것 외에도 거래 매개변수의 검증 부분과 실행 부분을 구분하는 역할도 합니다. 당시에는 허무하게 끝났지만 지금은 EIP 7702의 핵심 로직 중 하나가 되었습니다. EIP 7702의 각 트랜잭션은 특수한 트랜잭션 구조로 결합되어 특정 코드를 동반할 수 있으므로 EOA 주소에는 계약 기능이 있습니다. 이 거래에서.
EIP-7702: EOA 계정 코드 2024-05-07 설정
이는 이 기사의 뒷부분에서 논의되는 메커니즘의 핵심 EIP이기도 합니다. EIP-7702는 EIP-3074(2024-05-07)의 대안으로 Vitalik에 의해 게시되었습니다. 따라서 EIP-3074는 폐기되었으며, EIP-7702는 다가오는 ETH 프라하/Electra(Pectra) 하드 포크에 포함되기로 결정되었습니다. 자세한 내용은 아래에서 설명하겠습니다.
3.2 두 번째 경로는 EOA 주소가 CA 주소를 구동하도록 하는 것입니다.
EIP-3074: AUTH 및 AUTHCALL opcode 추가--2020-10-15
두 개의 새로운 OpCode인 AUTH와 AUTHCALL이 EVM에 추가되어 EOA는 EOA의 ID 대신 이 두 개의 opcode 승인 계약을 통해 다른 계약을 호출할 수 있습니다. 요약하면 아래 그림과 결합하여 EOA는 신뢰하는 계약(Invoker라고 함)에 서명된 메시지(트랜잭션)를 보낼 수 있습니다. 이 호출자 계약은 AUTH 및 AUTHCALL 작업 코드를 사용하여 이 EOA를 대체하고 이 트랜잭션을 보낼 수 있습니다. 거래.
EIP-4337: 트랜잭션 메모리 풀을 사용하여 계정 추상화 구현--2021-09-29
나는 이미 그 메커니즘을 심층적으로 분석한 많은 기사를 작성했습니다.
https://research.web3caff.com/zh/archives/3212,
이더리움 계정 요약 ERC 4337(1부) 검토 계획 해석
이더리움 계정 요약 10,000 단어 연구 보고서: 10개의 관련 EIP 제안을 해체하고 수천만 명의 일일 활성 사용자의 병목 현상을 해결하기 위한 7년 여정
간단히 말해서, 그의 디자인은 합의 계층 프로토콜 변경을 완전히 피할 수 있다는 것이 핵심 가치인 MEV에서 영감을 받았습니다.
eip 4337은 새로운 트랜잭션 개체 UserOperation을 제안하고, 번들러는 트랜잭션을 실행하기 위해 번들러 패키지로 계약을 일괄 전달합니다. 실행을 위한 계약 수준.
EIP-5189: 보증인을 통한 추상 계정 운영 — 2022-06-29
이는 EIP 4337의 로직을 최적화한 것으로 볼 수 있다. 악성 Bundler에 맞서 DoS 차단 공격을 방지하기 위해 금전적 처벌 승인 보증 메커니즘을 구축한다.
3.3 AA를 지원하기 위한 기타 제안
EIP-2718: 새로운 거래 유형을 위한 봉투 포장--2020-06-13
이는 향후 새로운 거래 유형을 위한 봉투로 새로운 거래 유형을 정의하는 최종 제안입니다. 최종 효과는 새로운 트랜잭션 유형이 도입될 때 특정 인코딩을 사용하여 트랜잭션 유형을 구별하므로 이전 버전과 호환되기만 하면 되고 앞으로 호환되지는 않는다는 것입니다. 가장 일반적인 예는 EIP 1559로, 거래 수수료를 차별화하고 원래 레거시 거래 유형에 영향을 주지 않고 새로운 거래 유형 인코딩을 사용합니다.
EIP-3607: EOA가 배포 불가능한 계약 주소를 지정하도록 합니다.--2021-06-10
컨트랙트 배포 주소와 EOA 주소 간의 충돌을 방지하기 위한 AA 경로의 보완 솔루션입니다. 그는 시스템이 이미 EOA 주소인 주소에 코드를 배포하는 것을 허용하지 않도록 계약 생성 방법을 제어합니다. 이 위험은 사실 아주 작습니다. 결국 이더리움 주소는 160비트 길이입니다. 개인 키를 사용하여 지정된 계약 주소의 개인 키와 충돌하는 방법이 있지만 여전히 전체를 기준으로 1년이 걸립니다. 비트코인의 컴퓨팅 파워.
3.4 계정 추상화 개발 프로세스를 어떻게 이해합니까?
먼저 CA로 전환하는 것의 가치를 이해해야 합니다.
기본적으로 EIP-4337의 실제 효과는 다음과 같습니다.
그러나 EIP-4337의 핵심 단점은 인간의 동기 부여 원칙을 위반한다는 점이다.
더 나은 것 같지만 끝없는 시장 개발 주기에 빠졌습니다. 많은 Dapp이 호환되지 않아 사용자는 CA 주소를 사용하려고 하지 않으며 CA를 사용하더라도 거래 비용이 더 높습니다(일반적인 전송 시나리오에서는 거래 수수료도 발생합니다). double), 또한 Dapp 자체의 호환성에 너무 많이 의존합니다.
따라서 아직까지 이더리움 메인넷에서는 대중화되지 않았습니다.
비용은 사용자에게 가장 중요한 기준이므로 비용을 줄여야 합니다.
그러나 실제로 GAS를 줄이려면 이더리움 자체가 소프트 포크 업그레이드를 수행하거나 GAS 계산을 수정하거나 opcode 및 기타 모듈의 GAS 소비를 수정해야 합니다. 그러나 소프트 포크가 필요하므로 EIP-7702를 직접 고려하는 것은 어떨까요?
4. EIP-7702 종합 분석
4.1 EIP-7702란?
EOA가 단일 트랜잭션에서 일시적으로 스마트 계약의 기능을 가질 수 있도록 하는 새로운 트랜잭션 유형으로 구별됩니다. 이를 통해 비즈니스에서 도입할 필요 없이 일괄 트랜잭션, 가스 프리 트랜잭션, 사용자 정의 권한 관리 등을 지원합니다. 새로운 EVM opCode(향후 호환성에 영향을 미침)
이를 통해 사용자는 스마트 계약을 배포하지 않고도 대부분의 AA 기능을 얻을 수 있으며 사용자를 대신하여 거래를 시작할 수 있는 기능을 제3자에게 제공할 수도 있습니다. 사용자는 개인 키를 제공하지 않고 서명 인증 정보만 제공하면 됩니다.
4.2 데이터 구조
그는 TransactionPayload가 다음 콘텐츠의 RLP 인코딩 직렬화 결과인 새로운 트랜잭션 유형 0x 04를 정의합니다.
중요한 것은 서명자가 자신의 EOA에 실행하려는 코드를 저장하기 위해 Authorization_list 개체가 추가된다는 것입니다. 사용자가 트랜잭션에 서명하면 실행할 계약 코드에도 서명하게 됩니다. 여러 작업 정보를 일괄적으로 저장할 수 있음을 나타내며 일괄 작업을 수행합니다.
4.3 거래 수명주기
4.3.1 검증 단계
트랜잭션 실행 시작 시, Authorization_list의 각 [chain_id, address, nonce, y_parity, r, s] 튜플에 대해:
ecrecover를 사용하여 서명 r 및 s에서 서명자의 주소를 복구합니다(이는 Ethereum 자체의 메커니즘이므로 이 EIP는 서명 알고리즘을 변경하지 않습니다). Authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s] (from 주소를 얻기 위한 이전 서명 복호화와 유사하며 여기서 얻는 것은 로컬 서명입니다. 이 목록의 주소)
체인 ID를 확인합니다(안티포크 체인 재생).
권한 서명자의 코드가 비어 있거나 위임되었는지 확인합니다(트랜잭션이 유효한 7702 트랜잭션인지 확인하고 위임 메커니즘을 사용하여 나중에 트랜잭션을 실행합니다).
권한 서명자의 nonce를 확인합니다(권한 서명 재생을 방지하기 위해).
권한 서명자의 코드를 0x ef 0100 || 주소로 설정합니다(EIP 3607 충돌 방지 정책을 우회하는 데 사용됨)
부분 서명 재생을 방지하기 위해 권한 서명자의 nonce를 늘립니다.
방문한 주소 목록에 권한 서명자 계정 추가(쿼리 저장을 위한 가스 요금을 줄이기 위해 핫 주소 전송)
4.3.2 실행 작업 단계
계약 코드와 작업 지침은 어디에서 실행되나요?
새 버전은 코드 배포와 관련된 동작만 변경합니다.
계정 코드를 contract_code로 설정하는 대신 Authorization_list에서 코드 주소를 검색하여 해당 코드를 계정 코드로 설정합니다.
따라서 인증 코드를 실행해야 하는 경우 인증 목록의 주소 필드에 지정된 주소에서 코드가 로드되고 서명자 계정의 컨텍스트에서 실행됩니다.
이는 사용자의 계약 코드가 거래에 직접 포함되는 것이 아니라 실제로 체인의 특정 주소에 저장된다는 의미입니다.
작업 지침 및 관련 매개변수는 트랜잭션 페이로드의 데이터 필드에 저장됩니다.
4.4 EIP-7702의 가치는 무엇입니까?
Web3 지갑의 전체 링크가 변경될 것이며, EOA에 의해 시작된 일반 트랜잭션도 일괄 전송과 같은 계약과 유사한 다양한 로직을 실행할 수 있기 때문에 사용자 경험도 크게 바뀔 것입니다. CeFi 시나리오는 거래 식별 및 출금 수금 수수료에 영향을 미치며 다음과 같은 많은 이전 고정관념을 깨뜨렸습니다.
계정 잔액은 해당 계정에서 발생한 거래에 의해서만 줄어들 수 있다는 불변성을 깨뜨립니다.
트랜잭션 실행이 시작된 후 EOA nonce가 1씩 증가하는 불변성을 깨뜨립니다(동시에 여러 항목을 증가시킬 수 있음).
tx.origin과 msg.sender 간의 비교에 대한 보호 논리가 손상되어 과거의 많은 계약이 위험에 처해 있습니다.
이는 EOA 자체가 이벤트를 발행할 수 없다는 현상을 깨뜨립니다. 일부 온체인 이벤트의 식별 및 모니터링에 주의가 필요할 수 있습니다.
이는 EOA 주소가 ERC 20, 721, 1155 및 기타 자산을 성공적으로 수락해야 한다는 현상을 깨뜨립니다(콜백 메커니즘으로 인해 실패할 수 있음).
4.5 EIP-7702와 EIP-4337 비교
1. EIP-7702의 장점
진입점 모듈을 통과할 필요가 없으므로 가스가 낮아져 온체인 운영이 줄어듭니다.
사용자 마이그레이션 비용이 저렴하고 사전에 온체인 계약을 주체로 배포할 필요가 없습니다.
Eip 4337과 비교하여 코드 위임 실행도 있으며 두 가지 방법도 있습니다.
전체 위임
전체 위임이란 작업에 대한 모든 권한을 특정 주소에 위임하는 것을 의미합니다. 예를 들어, 사용자는 모든 ERC-20 토큰의 관리 권한을 스마트 계약 주소에 위임할 수 있으므로 이 스마트 계약은 사용자를 대신하여 관련된 모든 작업을 수행할 수 있습니다.
보호된 위임
보호 위임은 위임 작업의 안전과 통제 가능성을 보장하기 위해 위임 프로세스 중에 일부 제한 및 보호 조치를 추가하는 것을 의미합니다.
예를 들어, 사용자는 ERC-20 토큰의 일부만 관리를 스마트 계약에 위임하거나 일부 제한 사항(예: 총 잔액의 1%로 최대 일일 지출)을 설정할 수 있습니다.
2. EIP-7702의 단점
핵심 단점은 추진을 위해 모든 사람의 합의가 필요한 소프트 포크 업그레이드이며, 변경 사항이 거대하여 체인의 생태계에 광범위한 영향을 미칠 것이라는 점입니다 . 다음과 같은 과제가 있지만 이러한 과제는 시장 기회이기도 합니다.
자유도가 매우 높고 감사가 어렵습니다. 사용자는 보안 보호를 제공하기 위해 더욱 안정적인 지갑이 필요합니다.
원래 구조가 너무 많이 변경되었습니다. 다양한 거래 유형으로 구별되지만 많은 인프라, 특히 체인의 불변 계약은 직접 조정할 수 없습니다.
EOA 주소에 대해서는 계약 기능이 제공되지만 해당 저장 공간은 유지되지 않습니다.
Calldata 부분이 크게 증가하기 때문에 별도의 트랜잭션 비용은 약간 더 높습니다. 통화의 예상 총 비용은 16(gas) * 15(bytes) = 240(gas) 통화 데이터 비용에 EIP- 비용을 더한 금액이 됩니다. 3860 2 * 15 = 30에 대략적인 런타임 비용 150을 더한 값입니다. 따라서 계정만 준비하면 아무것도 하지 않아도 가스가 500씩 늘어납니다.
수신자가 기능을 수신하지 않고 코드에 서명하면 발신자는 자산을 보내려고 할 때 DoS에 직면할 수 있습니다. 문제는 실제로 EOA A가 서명하지 말아야 할 것에 서명했다는 것입니다. 즉, 잘못된 구현 설정(receive() 없음)이 있는 재생 가능한 파일입니다.
예를 들어, ERC-20 토큰을 전송할 때 수신자 계정에 코드가 있는 경우 온체인 출금 논리가 일관되지 않을 수 있습니다. 토큰 계약은 수신자 계정에 대해 onERC 20 수신을 호출합니다. onERC 20 수신이 잘못된 값을 되돌리거나 반환하는 경우 토큰 전송이 되돌려집니다.
또한, EOA가 이벤트를 발생시킬 수 있다면 문제가 없을까요? 일부 인프라에는 주의가 필요할 수 있습니다.
이는 현재 EIP 7702 제안 내용과 해당 공식 포럼 토론을 기반으로 Shishijun이 요약한 단점 중 일부일 뿐이며 결국 최종 구현 코드를 기반으로 완전히 분석되어야 합니다. 참고자료는 다음과 같습니다.
https://eips.ethereum.org/EIPS/eip-7702
https://ethereum-magicians.org/t/eip-set-eoa-account-code-for-one-transaction/19923
5. 전문 요약
이 기사는 길이가 엄청날 것 같지만 실제로 텍스트 내용은 약 6,000 단어에 불과합니다. 기사에 포함된 이전 EIP 해석은 기사의 링크를 통해 확장될 수 있으므로 다시 다루지 않겠습니다.
현재 계정 추상화는 모든 것을 수정하는 여섯 번째 모듈에만 배치될 수 있습니다. 즉, EIP 7702의 진행이 크게 가속화되었으므로 시스템 보안에 더 많은 문제가 발생할 것입니다. 예상할 수 있듯이 결국 그는 이더리움의 합병이나 합의 알고리즘의 수정과 같은 파괴적인 사건이 일어날 수 있는데, 그렇다면 새로운 거래 유형은 어떨까요?
그러나 이번에는 너무 많은 전복이 있어 여러 체인에서 불가능한 숨겨진 규칙을 깨뜨리고 대부분의 Dapp의 적용 논리도 깨뜨립니다. 그러나 사용자의 비용이 저렴하다는 핵심 포인트를 확고히 차지했습니다. ! 이를 EIP 4337의 거의 두 배에 달하는 거래 비용과 비교해 보세요.
사용자 자신은 여전히 EOA 주소를 갖고 있으며 필요할 때만 CA 로직을 구동하고 사용하므로 보유 비용이 저렴합니다. 작업을 수행하기 전에 체인에서 CA ID를 변환할 필요가 없습니다. 즉, 사용자가 등록할 필요가 없습니다.
사용자는 쉽게 EOA를 사용하여 원천징수를 승인하고 원천징수를 실행하는 등 여러 거래를 동시에 수행할 수 있습니다. 이는 특히 거래소와 같은 온체인 엔터프라이즈 수준 관리가 필요한 Dapp의 경우 거래 비용을 절감합니다. , 파괴적인 최적화를 수행했습니다. 원래 생태계에서 일괄 집계가 구현되면 기본 교환 비용이 즉시 절반 이상 줄어들 수 있으며 이는 궁극적으로 사용자에게 이익이 될 수 있습니다.
따라서 많이 바뀌었지만 비용적인 측면에서는 모든 Dapp에 대해 연구하고 적응할 가치가 있습니다. 이번에는 사용자가 EIP 7702의 편에 서야 하기 때문입니다.
