DAOrayaki DAO 리서치 보너스 풀:

DAOrayaki DAO 리서치 보너스 풀:

투표 진행: DAO 위원회 3/7 통과

펀딩 주소: DAOrayaki.eth

투표 진행: DAO 위원회 3/7 통과

총 현상금: 80USDC

연구 유형: DAO, ERC4337, 계정 추상화, 스마트 지갑

원작자: 비탈릭 부테린

기여자: Dewei, DAOctor @DAOrayaki

원문: ERC 4337: 이더리움 프로토콜 변경 없이 계정 추상화

계정 추상화는 오랫동안 이더리움 개발자 커뮤니티의 꿈이었습니다. EVM 코드는 애플리케이션의 논리를 구현하는 데 사용될 뿐만 아니라 개별 사용자 지갑(nonce, 서명...)의 논리적 검증을 구현하는 데에도 사용됩니다. 이것은 지갑 디자인의 혁신에 대한 많은 아이디어를 제공할 것이며 지갑은 다음과 같은 몇 가지 중요한 기능을 제공할 수 있습니다.

1. 멀티시그와 소셜 복구

2. 보다 효율적이고 간단한 서명 알고리즘(예: Schnorr, BLS)

3. 포스트 퀀텀 보안 서명 알고리즘(예: Lamport, Winternitz)

이러한 모든 작업은 오늘날 스마트 계약 지갑으로 수행할 수 있지만, 이더리움 프로토콜 자체는 스마트 계약 지갑이 달성하기 어려운 ECDSA 보안 외부 계정(EOA)에서 발생하는 트랜잭션에 모든 것을 패키징해야 합니다. 모든 사용자 작업은 EOA의 트랜잭션으로 래핑되어야 하며 21000 가스 오버헤드가 추가됩니다. 사용자는 별도의 EOA에서 ETH를 소유하여 가스 비용을 지불하고 두 계정의 잔액을 관리하거나 종종 중앙 집중식인 릴레이 시스템에 의존해야 합니다.

EIP 2938은 최상위 이더리움 트랜잭션이 EOA 대신 계약으로 시작할 수 있도록 일부 이더리움 프로토콜을 변경하여 이 문제를 해결하는 방법입니다. 계약 자체에는 확인 및 수수료 지불 논리가 있으며 채굴자가 확인합니다. 그러나 프로토콜 개발자가 병합 및 확장성에 세심한 주의를 기울이면 프로토콜을 크게 변경해야 합니다. 새로운 제안(ERC 4337)에서는 합의 계층 프로토콜을 변경하지 않고도 동일한 이점을 얻을 수 있는 방법을 제공합니다.

보조 제목

이 제안은 어떻게 작동합니까?

우리가 수정하는 것은 합의 레이어 자체의 로직이 아니라 상위 시스템에서 트랜잭션 멤풀을 복제하는 기능입니다. 사용자는 확인을 위해 사용자의 의도를 서명 및 기타 데이터와 함께 패키징하여 UserOperation 개체를 보냅니다. Flashbots와 같은 서비스를 사용하는 광부와 번들러 모두 UserOperation 개체 집합을 "번들 트랜잭션"으로 묶을 수 있으며, 이는 Ethereum 블록에 포함됩니다.

번들러는 ETH의 번들 트랜잭션에 대해 지불되며 실행된 모든 개별 사용자 작업의 일부로 지불된 수수료를 통해 보상됩니다. 번들러는 광부가 기존 트랜잭션 mempool에서 작동하는 방식과 유사한 수수료 우선 순위 논리를 기반으로 포함할 UserOperation 개체를 선택합니다. UserOperation은 트랜잭션처럼 보이며 다음 필드를 포함하는 ABI 인코딩 구조입니다.

1. 발신인 : 운영을 위한 지갑

2. nonce 및 서명: 지갑이 작동을 검증할 수 있도록 지갑 검증 기능에 전달되는 매개변수

4. callData: 실제 실행 단계에서 지갑을 호출하는 데 사용되는 데이터

나머지 필드는 가스 및 수수료 관리와 관련이 있으며 전체 필드 목록은 ERC 4337 사양에서 찾을 수 있습니다.

보조 제목

지갑은 두 가지 기능이 필요한 스마트 계약입니다.

2. op는 함수를 실행하고 calldata를 지갑이 조치를 취하라는 지시로 해석합니다. 이 함수가 calldata와 그 결과를 해석하는 방법은 완전히 공개되어 있지만 가장 일반적인 동작은 calldata를 지갑에서 하나 이상의 호출을 수행하기 위한 지침으로 구문 분석하는 것입니다.

지갑의 논리를 단순화하기 위해 보안을 보장하는 데 필요한 대부분의 복잡한 스마트 계약 트릭은 지갑 자체가 아니라 진입점이라는 글로벌 계약에서 수행됩니다. validateUserOp 및 실행 기능은 require(msg.sender == ENTRY_POINT)로 제어되므로 신뢰할 수 있는 진입점만 지갑에서 작업을 수행하거나 수수료를 지불할 수 있습니다. 진입점은 validationUserOp 이후에 지갑에 임의의 호출을 하고 해당 호출의 데이터를 전달하는 UserOperation이 성공했으므로 이 정도면 공격으로부터 지갑을 보호하기에 충분합니다. 진입점은 지갑이 존재하지 않는 경우 제공된 initCode를 사용하여 지갑을 생성하는 역할도 합니다.

보조 제목

런타임 진입점 제어 흐름

UserOperation의 유효성 검사가 성공적으로 조롱되면 UserOperation은 발신자 계정에서 다른 내부 상태 변경이 발생할 때까지 포함 가능하도록 보장됩니다(다른 UserOperation에 동일한 발신자가 있거나 발신자를 호출하는 다른 계약이 있기 때문입니다. 어떤 경우든 , 계정에 대해 이 조건을 트리거하려면 체인에 7500+가스를 지출해야 합니다.

또한 사용자 작업은 validationUser 단계에 대한 가스 한도를 지정하며, 이 가스 한도가 매우 작지 않은 한(예: 200000 미만) mempool 노드와 번들러는 이를 거부합니다. 이러한 제한은 기존 이더리움 트랜잭션의 주요 속성을 복제하여 mempool이 DoS 공격에 면역이 되도록 합니다. 번들러 및 mempool 노드는 오늘날의 이더리움 트랜잭션과 유사한 논리를 사용하여 UserOperation을 포함할지 또는 전달할지 여부를 결정할 수 있습니다.

보조 제목

이 설계는 일반 이더리움 트랜잭션 멤풀과 비교하여 어떤 속성을 추가, 유지 및 희생합니까?

속성 유지:

1. 중앙 집중식 참여자가 없으며 모든 것이 P2P 멤풀을 통해 이루어집니다.

2. DoS 안전(가장 검사를 통과한 사용자 작업은 발신자가 또 다른 상태 변경이 있을 때까지 억제 가능하도록 보장되며, 공격자는 발신자당 7500+ 가스를 지불해야 합니다.)

3. 클라이언트 측 지갑 설정 복잡성 없음: 사용자는 지갑 계약이 "게시"되었는지 여부를 신경 쓸 필요가 없습니다. 지갑은 결정론적 CREATE2 주소에 존재하며 지갑이 아직 존재하지 않는 경우 첫 번째 UserOperation은 자동으로 생성

4. 수수료 설정을 포함한 전체 EIP 1559 지원(사용자는 고정 수수료 프리미엄 및 최고 총 수수료를 설정할 수 있으며 빠른 포함 및 공정한 수수료를 기대할 수 있음)

5. 이전 작업보다 더 높은 프리미엄으로 새 사용자 작업을 전송하여 작업을 교체하거나 유료 교체로 더 빠르게 포함하는 기능

새로운 혜택:

1. 검증 논리 유연성: validateUserOp 함수는 임의 서명 및 nonce 검증 논리(새로운 서명 체계, 다중 서명...)를 추가할 수 있습니다.

3. 지갑 업그레이드 가능성: 지갑 확인 논리는 상태 저장이 가능하므로 지갑에서 공개 키를 변경하거나 (DELEGATECALL을 사용하여 발급된 경우) 코드를 완전히 업그레이드할 수 있습니다.

결점

4. 실행 논리 유연성: 지갑은 실행 단계에 대한 사용자 지정 논리를 추가할 수 있습니다. Atomic multi-ops 수행(EIP 3074의 핵심 목표)

결점

1. 프로토콜의 최선의 노력에도 불구하고 허용된 확인 논리가 단일 ECDSA 확인을 사용하는 현상 유지보다 더 복잡하기 때문에 DoS 취약성이 약간 증가했습니다.

2. 가스 오버헤드: 일반 트랜잭션보다 가스 오버헤드가 약간 더 많습니다(일부 사용 사례에서는 다중 작업 지원으로 상쇄됨).

3. 한 번에 하나의 거래: 계정은 대기할 수 없으며 여러 거래를 mempool에 보낼 수 없습니다. 그러나 원자적 다중 작업을 수행할 수 있는 기능으로 인해 이 기능이 훨씬 덜 필요합니다.

지급인과의 후원:

스폰서 십 거래에는 여러 가지 주요 사용 사례가 있습니다. 가장 일반적으로 인용되는 바람직한 사용 사례는 다음과 같습니다.

2. 사용자가 ERC20 토큰으로 수수료를 지불할 수 있도록 하고 계약은 ERC20을 청구하고 ETH로 지불하는 중개자 역할을 합니다.

제안은 내장된 지불 관리자 메커니즘을 통해 이 기능을 지원할 수 있습니다. UserOperation은 다른 주소를 지불인으로 설정할 수 있습니다. 지불 관리자가 설정된 경우(즉, 0이 아님) 확인 단계 중에 진입점은 지불 관리자를 호출하여 지불 관리자가 UserOperation에 대해 기꺼이 지불하는지 확인합니다. 그렇다면 수수료는 지갑이 아닌 진입점(보안을 위해 출금 지연)에 스테이킹한 결제담당자의 ETH에서 차감된다. 실행 단계에서 지갑은 평소와 같이 UserOperation에서 calldata로 호출하지만 이후 postOp로 paymaster를 호출합니다.

보조 제목

위의 두 가지 사용 사례에 대한 예제 워크플로는 다음과 같습니다.

2. 결제 관리자는 송금인의 지갑에 UserOperation을 결제하기에 충분한 ERC20 잔액이 있는지 확인합니다. 그렇다면 paymaster는 ETH 수수료를 수락하고 지불한 다음 postOp의 ERC20 토큰을 보상으로 청구합니다(UserOperation이 ERC20 잔액을 소모하여 postOp가 실패하면 실행이 재개되고 postOp가 다시 호출되므로 paymaster는 항상 지급됩니다). 현재 ERC20이 결제 관리자가 관리하는 래핑된 토큰인 경우에만 가능합니다.

특히 두 번째 경우에는 지불 감독자가 완전히 반응할 수 있으며 때때로 매개변수를 재조정하고 재설정할 수 있습니다. 이것은 개별 거래를 능동적으로 처리하기 위해 지불자가 항상 온라인 상태여야 하는 기존 후원 시도에 비해 크게 개선된 것입니다.

보조 제목

이 제안은 어떻게 진행되고 있습니까?