작성자: Davide Rezzoli( @DavideRezzoli ) 및 Barnabé Monnot( @barnabe )
문제를 소개해 준 Yoav Weiss( @yoavw )와 초안에 대한 유익한 의견을 제공해 준 Dror Tirosh( @drortirosh )와 지원해 준 4337 팀에 진심으로 감사드립니다. 리뷰 ≠ 추천; 모든 오류는 저자의 것입니다.
이 작업은 ROP-7을 위해 수행되었습니다.
소개
이전 게시물 에서 우리는 이더리움 요청 사항(ERC)-4337 모델을 소개했습니다. 이 모델은 번들러의 수수료 시장 구조를 개략적으로 설명하고 번들의 온체인 퍼블리싱 비용과 오프체인(집계 비용)과 관련된 비용 함수를 자세히 설명합니다.
또한 " 번들러 게임 "이라는 개념을 소개했습니다. 이 게임은 두 번째 부분의 주요 초점이 될 것입니다. 거래 집합이 주어지면 번들러는 번들에 포함할 거래를 선택할 수 있습니다. 이는 정보의 비대칭성을 만듭니다. 번들러와 사용자, 사용자는 번들에 포함될 거래 수를 알 수 없기 때문입니다. 이는 사용자가 분명히 불리한 위치에 있는 제로섬 게임으로 이어집니다.
이 연구는 사용자가 다음 번들에 포함하기 위해 과도하게 지불할 필요가 없도록 함으로써 UX를 개선하는 방법을 탐구하는 것을 목표로 합니다. 대신 사용자는 포함에 대한 실제 시장 수요에 따라 요금을 지불할 수 있어야 합니다.
이더리움 요청 사항(ERC)-4337의 현재 상태
오늘날의 시장에서 P2P mempool은 메인넷에서 라이브가 아니며 Sepolia 테스트넷에서 테스트 중입니다. 이더리움 요청 사항(ERC)-4337을 기반으로 하는 회사는 현재 개인 모드로 운영 중이며, 사용자는 RPC를 통해 개인 번들러에 연결한 다음 작동하게 됩니다. 사용자 작업을 온체인에 게시하는 빌더. Kofi가 개발한 Bundle Bear 앱은 이더리움 요청 사항(ERC)-4337의 현재 상태에 대한 흥미로운 통계를 제공합니다.
주간 % 다중 사용자 운영 번들 메트릭에서 우리는 번들러가 다중 사용자 운영을 포함하는 번들을 만드는 비율을 관찰합니다. 2024년 초부터 2024년 6월까지 이 비율은 6.6%를 넘지 않았습니다. 이 데이터는 많은 번들러는 사용자를 대신하여 거래를 후원하는 자체 지불자를 운영합니다. 특히, 사용자 운영 측면에서 지불자로도 운영되는 가장 큰 번들러 두 곳은 서비스를 사용하여 사용자 운영의 97%를 후원했습니다 . 지불자는 다음을 지불합니다. 일부 부분은 사용자가 운영하고 나머지는 디앱(DApp) 나 다른 엔티티 가 지불합니다.
발생하는 질문은 paymasters, 디앱(DApp) 이더리움 클래식(ETC) 사용자 운영에 대해 비용을 지불하는 이유입니다. 사용자는 미래에 그들에게 돈을 갚을까요? 무슨 일이 일어날지 확신할 수 없지만, 제 개인적인 추측은 현재 디앱(DApp) 가 앱 사용 및 채택을 늘리기 위해 수수료를 충당합니다. 채택률이 높아지면 사용자는 거래 비용을 직접 지불해야 할 가능성이 높습니다. 현재 모델에서 사용자가 사용자 운영 비용을 지불하는 것이 최선의 선택이 아니라는 점을 언급할 가치가 있습니다. 기본 이더리움 요청 사항(ERC)-4337 작업에는 ~42,000가스 비용이 들고, 일반적인 거래에는 ~21,000가스 비용이 듭니다.
이더리움 요청 사항(ERC)-4337의 변형
이더리움 요청 사항(ERC)-4337 개요
mempool은 아직 Sepolia에서 테스트 단계에 있으며 메인넷에서 라이브로 제공되지 않습니다. mempool이 없으면 사용자는 계정 추상화를 사용하는 데 제한적인 옵션을 사용할 수 있습니다. 사용자는 UserOps를 번들로 제공하는 번들러에서 제공될 수 있는 RPC와 상호 작용하거나 Alchemy나 Infura와 비슷한, 번들링하지 않는 RPC 서비스로, 다른 번들러에 트랜잭션을 수신하여 전파합니다.
mempool이 활성화되면 트랜잭션 흐름은 아래 다이어그램과 유사하며, 이는 현재 트랜잭션 흐름과 유사합니다. mempool은 RPC 모델과 달리 트랜잭션이 제외될 가능성을 줄여 사용자의 검열 저항성을 향상시킵니다. 그러나 메모풀을 사용하더라도 RPC 공급자가 트랜잭션을 전달하지 않을 위험이 여전히 있습니다. 하지만 메모풀 모델은 이러한 위험을 완화해주므로 자체 노드를 운영하는 것을 선호하는 사용자에게 특히 유용합니다.
번들러는 빌더 역할을 할 수 있는 잠재력이 있지만, 경쟁적인 환경으로 인해 우리는 그 역할을 분리하는 것을 선호합니다. 번들러는 기존의 정교한 빌더와 상당한 경쟁에 직면하게 되어 빌딩이 덜 매력적이고 잠재적으로 덜 수익성이 있게 됩니다. 그 결과 번들러는 더 독립적으로 건설을 하여 손실을 감수하기보다는 기존 건설업체와 협력하는 것을 더 선호합니다.
번들러와 빌더의 역할을 단일 엔티티로 결합하는 것은 현재 시스템에 상당한 변화를 의미합니다. 번들러는 기존의 정교한 빌더 와 경쟁해야 하거나, 아니면 현재 빌더는 수평적으로 통합하여 번들러 역할도 맡아야 합니다. 후자의 시나리오 더 그럴듯해 보이지만, 시장 집중과 검열 저항에 대한 잠재적인 부정적 영향에 대한 우려를 불러일으킵니다.
번들러와 빌더는 서로 다른 두 개체입니다.
사용자가 RPC에 직접 연결하면 모든 것이 더 개인적인 환경에서 실행되므로 시장 경쟁에 도움이 되지 않습니다. 가까운 미래에 mempool이 메인넷에 올라 경쟁이 치열해질 것입니다.
userops가 다른 번들러에 공개되는 mempool을 사용하면 경쟁이 증가합니다. 기본 계정 추상화가 아닌 경우 번들러와 빌더를 분리해야 하지만 기본 계정 추상화의 경우 빌더가 가능하기 때문에 분리가 필요하지 않을 수 있습니다. userops를 일반 트랜잭션으로 해석합니다.
우리 모델의 경우 번들러와 빌더를 분리하는 것이 경쟁과 검열 저항 측면에서 특히 몇 가지 이점을 제공한다고 생각합니다. 모든 번들러가 포함되는 데 비용 \textbf{v} v를 제공하는 시나리오를 상상해 보세요. 번들. 더 많은 사용자를 유치하여 더 높은 수익을 얻고자 하는 번들러가 있을 것이므로 비용 \textbf{v'} v' 를 제공할 것입니다. 여기서 \textbf{v'} < \textbf{v} v' < v 번들러 간의 경쟁이 충분하다면, \textbf{v'} v'는 번들의 집계 비용인 \omega ω 에 가까워질 것입니다. 이 경우, 더 효율적으로 검색할 수 있고 더 나은 하드웨어를 갖춘 번들러는 더 많은 거래를 번들에 포함할 수 있습니다. 번들은 더 높은 수수료를 얻게 되고 그 대가로 사용자의 운영 비용이 더 저렴해집니다.
이는 다음과 같은 결과를 초래할 수 있습니다. 경쟁적인 환경 에서 번들러는 사용자가 선택할 수 있도록 가격을 낮추고, 사용자는 번들에 사용자 운영을 포함하는 데 대한 가장 낮은 가격을 추구합니다. 이 경쟁은 가장 좋은 가격을 제공하는 번들러가 더 작은 번들을 만들어 이익을 극대화하려는 번들러보다 더 자주 선택되는 시스템입니다. 번들러와 빌더의 역할을 분리하면 검열 저항도 강화할 수 있습니다. 번들러는 번들을 만들 수 있습니다. 집계된 사용자 작업의 집합을 생성하여 다른 빌더로 전송합니다. 번들에 검열될 수 있는 작업이 포함된 경우 검열하지 않는 빌더가 이를 수락하고 건설을 진행할 수 있습니다. 그러나 사용자 관점에서 볼 때 이러한 설정은 비용을 증가시킬 수 있다는 점에 유의해야 합니다. 번들러를 도입하면 추가적인 당사자가 생겨 비용이 증가하게 됩니다.
RIP-7560
네이티브 계정 추상화는 새로운 개념이 아니며 수년간 연구되어 왔습니다. 이더리움 요청 사항(ERC)-4337이 인기를 얻고 있지만 프로토콜 외부에서 구현하면 트레이드오프와 함께 뚜렷한 이점이 있습니다. 특히 기존 EOA는 SCW로 원활하게 전환할 수 없습니다. 그리고 다양한 유형의 검열 방지 목록은 활용하기 어렵습니다. 앞서 언급했듯이, userOp 비용의 가스 오버헤드는 일반 거래에 비해 상당히 증가합니다. RIP-7560은 오프체인 비용과 관련된 지속적인 문제를 본질적으로 해결하지 못하지만 거래 비용을 상당히 줄일 수 있습니다. 초기 ~42000가스에서 ~20000가스 까지 비용을 줄일 수 있습니다.
Layer2s 계정 추상화
계정 추상화는 레이어 2(L2) 솔루션에서 활용할 수 있습니다. 일부 L2는 이미 기본적으로 구현하고 있는 반면, 다른 L2는 L1 접근 방식을 따르고 RIP-7560과 유사한 새로운 제안을 기다리고 있습니다. L2에서 L1은 데이터 가용성에 사용됩니다. 보안을 계승하는 반면 대부분의 계산은 L2에서 오프체인으로 수행되어 거래 비용이 저렴하고 확장성이 뛰어납니다.
L2에서의 계산이 메인체인에서 데이터 가용성(DA)을 위한 콜데이터 비용보다 상당히 저렴한 시나리오에서 서명 집계를 사용하면 매우 유익합니다. 예를 들어, 메인넷에서 BLS를 위한 페어링은 0x08 사전 컴파일을 통해 용이해집니다. 이더리움 가상 머신(EVM) 약 ~45000k 가스가 듭니다. 결과적으로 L1에서 BLS를 사용하는 것은 기존 거래보다 비쌉니다.
L2의 압축 기술은 이미 사용되고 있으며, 예를 들어 0바이트 압축은 ERC20 전송에 대한 비용을 ~188바이트에서 ~154바이트로 줄여줍니다. 서명 집계를 사용하면 단일 서명을 사용하여 압축 효율성을 더욱 향상시킬 수 있습니다. 크기를 ~128바이트로 줄입니다.
레이어 2에서 서명 집계는 거래 효율성과 비용 효율성을 모두 향상시키는 중요한 혁신입니다. 여러 서명을 하나로 결합하면 전체 데이터 페이로드가 크게 줄어들어 레이어 1에서 데이터 가용성과 관련된 비용이 낮아집니다. 발전으로 인해 확장성이 향상될 뿐만 아니라 사용자의 거래 비용도 줄어들어 시스템이 더 경제적이고 효율적으로 작동합니다.
Layer2에서의 Signature Aggregation 경제학
L2 서비스를 사용할 경우 사용자는 L2 운영자 요금, 네트워크 혼잡에 따른 비용, L1의 데이터 가용성 비용 등 여러 가지 비용을 부담하게 됩니다.
" 첫 번째 원칙에서 롤업 경제 이해 "에 대한 이전 연구에서 L2 서비스를 사용할 때 사용자가 직면하는 비용을 다음과 같이 설명할 수 있습니다.
사용자가 2계층과 상호작용할 때 발생하는 비용은 다음과 같이 정의할 수 있습니다.
- 이용료 = L1 데이터 공개료 + L2 운영자료 + L2 혼잡료
- 운영자 비용 = L2 운영자 비용 + L1 데이터 게시 비용
- 운영자 수익 = 사용자 요금 + MEV
- 운영자 이익 = 운영자 수익 - 운영자 비용 = L2 혼잡 요금 + MEV
기본 계정 추상화가 아닌 경우 번들러라는 추가 엔터티가 userops 번들을 생성하는 데 대한 수수료를 부과할 수 있습니다.
번들러를 고려할 때 비용과 이익은 다음과 같이 확장됩니다.
- 사용자 수수료 = L1 데이터 공개 수수료 + L2 운영자 수수료 + L2 혼잡 수수료 + 번들러 수수료
- 번들러 비용 = 견적(L1 데이터 게시 수수료 + L2 운영자 수수료 + L2 혼잡 수수료)
- 번들러 수익 = 사용자 수수료
- 번들러 이익 = 번들러 수익 - 번들러 비용 = L1 및 L2 비용과 번들러의 견적 가격의 차이 + 번들러 수수료
- 운영자 비용 = L1 데이터 공개 수수료 + L2 운영자 수수료
- 운영자 이익 = 운영자 수익 - 운영자 비용 = L2 혼잡 요금 + MEV
번들러는 사용자로부터 서비스에 대한 수수료를 받는 반면, 사용자가 지불한 나머지 금액은 L2 운영자의 비용을 충당합니다. 사용자가 번들 크기를 알지 못하는 경우, userops를 보내는 실제 비용을 추정하는 것이 어려워져 번들러가 운영자 비용을 충당하는 데 필요한 금액보다 높은 수수료를 청구합니다.
L2에서의 인센티브 정렬
번들러와 L2 간의 상호작용은 이 문제를 해결하는 데 도움이 됩니다. L2는 경쟁으로 인해 사용자 비용을 낮게 유지하려는 인센티브를 받기 때문입니다. 사용자에게 과도한 요금을 부과하면 더 공정한 가격을 제공하는 다른 L2로 전환하게 됩니다.
연산자를 도입하여 모델을 재정의해 보겠습니다. 사용자는 번들러에게 다음 L2 블록 에 포함되도록 V V 값을 입찰하여 입찰합니다. 사용자는 데이터 게시 수수료를 최소화하는 것을 목표로 하는 반면 번들러는 수수료를 최대화하거나 L2 상호작용 비용과 사용자 수수료에서 발생하는 잉여금입니다.
번들을 만들고 체인에 게시하는 데 관련된 비용은 두 부분으로 나눌 수 있습니다.
온체인 비용 함수: 기본 수수료가 r r 일 때 번들 \mathbf{B} B를 발행하는 번들러는 비용을 지출합니다.
집계 비용 함수: 번들러는 기본 수수료 r r 을 사용하여 n n 개의 거래를 단일 번들 B B 로 집계하기 위한 비용 함수를 갖습니다.
S' < S S ′ < S 이면 거래 크기가 줄어들고 사전 검증 가스 사용은 F' > F F ′ > F 이며 여기에는 단일 온체인 집계 서명의 게시 및 검증이 포함됩니다.
사용자가 n n 에 대한 신뢰할 수 있는 추정치를 얻을 수 있다면, 대부분 L2 솔루션에서 사용 가능한 estimateGas 함수를 사용하여 비용을 계산할 수 있습니다. 좋은 추정치를 가지고 있으면 사용자는 포함에 대한 입찰을 과대평가하지 않고도 그에 따라 입찰할 수 있습니다. 이 함수는 다음을 결정합니다. 포함을 보장하기 위한 필요한 비용. n n 과 estimateGas 함수에 대한 좋은 추정치를 가지면 사용자가 더 높은 preVerificationGas 에 대해 비용을 지불하는 것을 피할 수 있습니다. 다음 섹션에서는 n n 의 신뢰할 수 있는 추정치를 보장하기 위한 다양한 메커니즘을 살펴보겠습니다.
Layer2는 오라클을 운영합니다
오라클의 역할은 mempool을 모니터링하고 현재 거래 수를 추정하는 것입니다. 프로세스는 다음과 같이 작동합니다. 레이어 2는 mempool을 확인하기 위해 오라클을 배포한 다음 mempool의 거래 수를 사용자에게 알립니다. 이를 통해 사용자는 번들에 포함하기 위한 입찰을 추정합니다. 레이어 2는 번들러에게 번들에 지정된 수의 거래( n n ) 이상을 포함하도록 요청할 수 있으며, 그렇지 않으면 번들이 거부됩니다. 번들러가 충분한 거래를 수집하여 번들을 형성하면 번들을 2계층으로 전송하고, 이를 메인넷에 콜데이터로 전달하여 데이터 가용성을 높입니다.
공유 시퀀서가 있는 Layer2
흥미로운 접근 방식은 공유 시퀀서를 실행하는 여러 레이어 2(L2) 네트워크를 갖는 것입니다. 이 설정은 공유 시퀀서가 용이하게 하는 합의 통해 시퀀서가 합의에 도달함에 따라 mempool에 대한 보다 정확한 추정치를 제공할 수 있습니다.
이 구성에서 서로 다른 L2 네트워크는 독립적으로 작동하지만 공통 시퀀서를 공유합니다. 이러한 네트워크는 정기적으로 공유 mempool에서 사용자 작업(userops) 수를 확인합니다. 공유 시퀀서는 이러한 네트워크의 데이터를 동기화하고 집계하는 데 도움이 됩니다. 도달하면 계약을 통해 사용자에게 정보가 전달되고, 사용자는 현재 사용자 운영 수에 따라 입찰할 수 있습니다.
이 접근 방식은 여러 가지 장점을 제공합니다. 첫째, mempool에서 userops 수를 결정하는 분산된 방법을 제공하여 공모에 대한 저항력을 강화합니다. 둘째, 하나의 시스템만 통신을 관리하는 경우 발생할 수 있는 단일 장애 지점을 제거합니다. 사용자와 mempool. 셋째, 공유 시퀀서는 일관성을 보장하고 다양한 L2 솔루션 간의 불일치를 줄입니다.
이 방법은 공유 시퀀서를 활용하여 메모리 풀의 상태를 추정하고 사용자에게 전달하는 강력하고 안정적인 시스템을 보장하며, 이를 통해 프로세스의 전반적인 효율성과 보안을 향상시킵니다.
오라클을 사용하여 설명된 두 가지 접근 방식에서, 적대자가 mempool에서 여러 사용자 작업을 생성할 수 있는 잠재적인 공격 벡터가 있으며, 이를 함께 집계하면 되돌아갈 것임을 알고 있습니다. 결과적으로 오라클은 n n 개의 트랜잭션이 있음을 확인합니다. 그리고 큰 번들을 필요로 하지만 번들러가 번들을 생성할 수 없습니다. 이 문제는 네트워크를 여러 블록 동안 멈출 수 있습니다.
Layer2는 자체 번들러를 운영합니다.
이 제안에서 레이어 2 자체는 번들러의 역할을 맡고 다른 엔터티는 서명의 집계를 처리합니다(현재 번들러 서비스일 수 있음). 프로세스는 다음과 같이 작동합니다. 레이어 2는 자체 번들러를 작동시키고 사용자는 작업(userops)을 mempool로 전송합니다. 레이어 2는 mempool에서 이러한 userops 중 일부를 선택하여 집계자에게 "원시"로 전송하여 서명을 집계한 집계자에게 보상합니다. 집계자가 번들을 생성하면 번들러로 전송합니다. 그러면 데이터 가용성을 위해 이를 콜데이터로 메인넷에 전달합니다.
주요 아이디어는 레이어 2가 userops 수집을 처리한 다음 집계를 다른 엔터티에 아웃소싱한다는 것입니다. 레이어 2는 집계 비용을 지불하고 사용자에게 서비스 요금을 청구합니다.
두 가지 다른 옵션이 있습니다.
정액 수수료 모델: 번들러(시퀀서)는 일부 거래를 선택하여 사용자에게 정액 수수료를 청구합니다. 이 정액 수수료는 현재 레이어 2 거래와 유사하게 계산되어 L1 데이터 게시의 미래 비용을 예측합니다. 또는 레이어 2는 사용자에게 요금을 청구할 수 있습니다. n n 통합된 userops의 번들링 비용에 기반한 일정 수수료, 계층 2는 여전히 번들에 존재할 거래 수를 예측해야 하며 사용자를 올바르게 견적하기 위해 이를 구성할 수 있습니다. 이는 현재와 같은 방식으로 수행될 수 있습니다. . 현재 L2가 사용자에게 가장 경쟁력 있는 가격을 청구하고 있으므로 Layer 2에서는 사용자에게 가능한 한 경쟁력 있는 가격을 제공하는 것이 최선의 이익이 됩니다.
정액요금 671×702 22.1 KB환불 요청: 레이어 2가 신뢰성을 높이고자 하는 경우 자동 환불을 활성화할 수 있습니다. 여기에는 단일 블록 에 얼마나 많은 userops가 게시되었는지와 트랜잭션이 집계되었을 수 있는지 확인하는 메커니즘이 포함됩니다. 집계되지 않았고 자동 환불이 이루어지지 않은 경우 사용자는 환불을 요청할 수 있습니다. 이 시나리오에서 레이어 2는 일부 자산을 예치(stake) 수 있으며 환불이 제공되지 않으면 사용자는 환불을 강제하여 공정성을 보장할 수 있습니다. 그리고 책임감.
환불 요청 671×702 22.8 KB
결론
이 두 가지 다른 게시물에서 우리는 사용자가 다음 번들에 포함되도록 입찰할 때 겪는 어려움을 설명합니다. 첫 번째 부분에서는 이더리움 요청 사항(ERC) 들러가 체인에 번들을 게시할 때 발생하는 비용과 연관된 오프체인 비용. 또한 번들러의 수수료 시장을 개략적으로 설명하고 번들러 포맷팅 문제에 대한 논의를 시작했습니다. 사용자는 번들링 시점에 mempool에 존재하는 거래 수에 대한 지식이 부족하여 입찰에 어려움을 겪습니다.
두 번째 부분에서는 이더리움 요청 사항(ERC)-4337과 RIP-7560을 설명했습니다. 그런 다음 서명 집계가 Layer 1에서 직접 발생하는 것보다 Layer 2 솔루션에서 발생할 가능성이 더 높은 이유를 논의했습니다. Layer 2 솔루션이 사용자가 비대칭 지식을 어떻게 처리할 수 있는지 보여주었습니다. 다양한 방식으로 경험을 제공합니다. 첫 번째는 오라클을 사용하여 사용자에게 mempool에 얼마나 많은 거래가 있는지 알리는 것입니다. 이 접근 방식을 사용하면 사용자는 얼마를 입찰해야 하는지 알고 번들러가 더 큰 번들을 만들도록 강제할 수 있습니다. 세 번째 접근 방식 가장 간단한 것은 L2가 번들러 역할을 하여 집계를 제3자에게 아웃소싱하고 사용자가 이에 대해 요금을 지불하도록 하는 것입니다.
