EIP-3074이 지갑과 DApp에 미치는 영향 상세 분석

2024.05.21

EIP-3074이 지갑과 DApp에 미치는 영향 상세 분석

EIP-3074은 EOA가 스마트 계약과 동일한 수준의 풍부한 실행 기능을 갖도록 하여 많은 새로운 응용 시나리오를 열어줍니다.

2024.05.21 - 07:55:04

EIP-3074

Web3 심층 보도에 집중하고 흐름을 통찰

EIP-3074은 EOA가 스마트 계약과 동일한 수준의 풍부한 실행 기능을 갖도록 하여 많은 새로운 응용 시나리오를 열어줍니다.

글 작성: Nic @ imToken Labs

EIP-3074

더 나은, 더 안전한 사용 경험

EIP-3074은 EOA가 제어권을 특정 컨트랙트에 위임함으로써, 컨트랙트와 동일한 수준의 풍부한 실행 기능을 얻을 수 있게 해줍니다.

EIP-3074 이전에는 EOA가 매번 트랜잭션을 보낼 때마다 단 하나의 작업만 수행할 수 있었습니다. 예를 들어 ERC20 토큰의 approve 또는 Uniswap에서 스왑하는 등의 작업 말이죠. 하지만 EIP-3074 이후에는 EOA가 여러 작업을 한 번에 완료하거나, 그 전까지 상상할 수 없었던 새로운 용도를 실현할 수 있습니다.

간단히 말해, EIP-3074은 사용자 경험을 크게 향상시키며 현재 익숙한 승인 방식을 재정의합니다. 사용성은 유지하면서도 보안성을 높이는 것입니다.

또한 EIP-3074을 통해 EOA는 더 이상 직접 체인에 트랜잭션을 전송할 필요가 없으며, 따라서 거래 수수료를 지불하기 위해 ETH를 미리 확보해야 하는 문제에서도 벗어날 수 있습니다.

Invoker 컨트랙트

EOA의 제어권을 획득할 수 있는 컨트랙트를 Invoker 컨트랙트라고 합니다. 물론 임의의 컨트랙트가 EOA의 제어권을 얻을 수 있는 것은 아닙니다. EOA는 자신의 개인키로 서명해야 하며, 이 서명 내용에는 어느 Invoker 컨트랙트에게 권한을 주는지, 그리고 어떤 작업을 허용하는지 명확하게 기재되어야 합니다.

EOA의 서명 내용에는 어떤 Invoker 컨트랙트(Invoker address)인지, 그리고 해당 Invoker 컨트랙트가 수행할 수 있는 작업(commit)이 명시됩니다.

실제 실행 흐름은 대략 다음과 같습니다:

앨리스(Alice)는 자신의 EOA 개인키로 서명하고, 이 서명 내용과 전자서명을 Relayer에게 전달합니다.
Relayer가 이를 체인에 올려 Invoker 컨트랙트에서 실행합니다.
Invoker는 서명을 검증한 후, EOA의 신분으로 approve USDC, Uniswap에서 자산 교환, 그리고 일부 USDC를 Relayer의 수수료로 지급하는 등의 작업을 수행할 수 있습니다.

참고 1: Relayer는 필수 요소가 아니며, 앨리스가 직접 서명 내용과 전자서명을 체인에 올릴 수도 있습니다.

Invoker가 서명을 검증하고 작업을 시작하면, 모두 앨리스의 EOA 신분으로 수행되며, 마치 해당 EOA의 (제한된) 제어권을 부여받은 것과 같습니다.

다만 주의할 점은, 작업이 완료되어도 EOA의 nonce 값이 증가하지 않기 때문에 동일한 서명이 반복적으로 사용될 수 있다는 것입니다(EOA의 nonce가 변하지 않는 한). 따라서 Invoker는 자체적으로 nonce 메커니즘을 구현하여 리플레이 공격을 방지해야 합니다.

만약 Invoker 컨트랙트가 리플레이 방지 기능을 구현하지 않았다면, 동일한 승인을 계속해서 반복 실행할 수 있습니다.

자세히 알아보기: EIP-3074의 실제 작동 메커니즘은 다음을 참고하세요. https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234

용도

Batchcall

사용자가 원래 여러 번의 트랜잭션으로 나누어 실행해야 했던 작업들을 하나로 합쳐 수행함으로써, 반복적인 승인 서명 과정과 일부 가스 비용을 절약할 수 있습니다.

참고: 이는 DApp도 Batchcall 기능을 지원해야 가능하며, 현재 커뮤니티에서 추진 중인 EIP-5792과 같은 표준이 필요합니다. 그렇지 않으면 DApp이 사용자를 일반 EOA로 간주하여 각 작업마다 개별적으로 트랜잭션 서명을 요청하게 됩니다.

EIP-5792에 대해 알아보려면 다음 링크를 브라우저에 복사하세요: https://eips.ethereum.org/EIPS/eip-5792

Session Key

사용자는 제한된 조건 하에 타인이 자신을 대신해 작업을 수행하도록 할 수 있습니다. 아래 그림에서 delegate key는 권한을 부여받은 제3자이며, access policy는 작업 제한 조건입니다. 예를 들어 Uniswap에서만 작업 가능, 하루 최대 1 ETH 송금, 유효기간 등입니다.

이러한 조건들은 Invoker 컨트랙트 내에서 설계되고 검사되며, 조건을 통과하면 제3자는 사용자의 EOA 신분으로 작업을 수행할 수 있습니다.

텔레그램 봇(Telegram Bot)도 특정 권한을 부여받아 사용자의 EOA 신분으로 작업을 수행할 수 있습니다.

Native ETH Permit

조건이 충족되면(즉 Permit 서명이 유효하면), 승인자 EOA 신분으로 ETH 송금을 수행할 수 있어 네이티브 ETH Permit 효과를 달성할 수 있습니다.

Limit Order

사용자가 지정가 주문 조건을 입력하면, 조건이 충족되었을 때 사용자의 EOA 신분으로 관련 디지털 자산을 DEX에 approve하고, DEX에서 자산 교환 등을 수행할 수 있습니다. DEX 자체에서 제공하는 Limit Order와 비교했을 때, 사용자가 사전에 DEX에 approve 트랜잭션을 보내야 할 필요가 없습니다.

앨리스가 주문을 체결할 때 동시에 Approve가 실행되므로, 사전 Approve가 필요 없습니다.

조건을 더욱 일반화하여 설계하면, 이는 일종의 Intent 컨트랙트가 됩니다. 사용자가 지정한 조건이 만족되면 누구든지 그의 EOA 신분으로 의도를 실행할 수 있습니다.

Intent 조건이 충족되면, 누구나 사용자의 EOA 신분으로 실행을 시작할 수 있습니다.

Social Recovery

사용자가 EOA 개인키를 분실했을 경우, 이전에 앨리스가 서명한 EIP-3074 승인과 함께, 그녀가 권한을 부여한 사람(남편 및 신뢰 에이전트)의 서명을 활용해 EOA의 모든 자산을 이체할 수 있습니다. 실제로 회복되는 것은 (이체 가능한) 자산이며 계정 제어권은 아닙니다. EOA 개인키를 분실했으면 해당 EOA는 더 이상 사용할 수 없습니다.

사용자가 EOA 개인키를 분실했을 때, 이전에 권한을 부여받은 다른 사람들이 서명하여 EOA 자산을 이체할 수 있습니다.

EIP-3074의 영향

자산 승인 방식의 개선, 심지어 approve/permit를 대체할 수 있을까?

현재 대부분의 DApp은 사용자가 EOA라고 가정하고 설계됩니다. 즉 사용자는 반드시 "사전에 approve"하고, "충분한 자산량을 DApp 컨트랙트에 승인"해야 하며, 이렇게 해야 DApp이 실행할 때 사용자가 항상 온라인 상태일 필요 없고, 반복적인 approve도 피할 수 있으므로 사용자 경험(UX)이 크게 향상됩니다.

예를 들어 조건 기반 애플리케이션인 지정가 주문이나 DCA(Dollar-Cost Averaging)의 경우, 조건이 충족되었을 때 사용자가 반드시 온라인 상태일 필요는 없으므로, DApp 컨트랙트가 작업을 수행할 수 있도록 충분한 자산량을 사전에 approve해야 하며, 반복 실행도 가능해야 합니다.

DApp이 사용자의 자금을 편리하게 운영할 수 있도록 하려면, 사용자는 사전에 DApp에 충분한 자산량을 approve해야 합니다.

하지만 이로 인해 사용자는 DApp을 신뢰하거나 가짜 DApp에 approve하지 않도록 주의해야 하며, 필요 시 approval을 즉시 취소할 수 있어야 합니다.

또한 이후 등장한 permit 모델, 예를 들어 EIP-2612 또는 비네이티브 Permit2는 approve 방식의 UX와 보안성을 개선하기 위한 것이었습니다. 사용자는 더 이상 각 DApp 컨트랙트에 큰 자산량을 approve할 필요가 없으며(각 자산마다 일일이 approve해야 했음), 단지 "서명 한 번"으로 DApp 컨트랙트가 "지정된 시간 내에" "지정된 자산량을 인출"할 수 있도록 허용할 수 있습니다. 이는 공격 면을 크게 줄이고 사용자 경험을 크게 향상시킵니다.

자세히 알아보기: EIP-2612 상세 정보는 아래 링크를 브라우저에 복사하세요: https://eips.ethereum.org/EIPS/eip-2612
Permit2 상세 정보는 아래 링크를 브라우저에 복사하세요: https://medium.com/taipei-ethereum-meetup/uniswap-permit2-introduction-858ae3dddf18

사용자는 체인 외부에서 서명만 하면 되며, 자산량과 유효기간을 지정할 수 있어 approve보다 더 나은 사용 경험과 보안성을 제공합니다.

그러나 사실 permit 모델은 여전히 사기 공격 수단으로 끊임없이 악용되고 있습니다. 피해자는 DApp에 제공한다고 생각했던 permit 서명이 실제로는 공격자에게 제공된 것입니다.

사용자가 permit 서명을 할 때, 오직 누군가에게 승인하는지만 확인할 수 있으며, 이것이 어떤 작업과 함께 실행될지는 알 수 없습니다.

참고: 또한 현재의 permit 설계는 DCA나 정기 결제와 같은 반복 작업 DApp과 호환되지 않습니다. permit는 리플레이 방지 메커니즘을 갖고 있기 때문에 한 번 송금 후에는 동일한 permit를 다시 사용할 수 없으며, 사용자는 미래의 모든 반복 작업마다 미리 permit를 서명해야 합니다.

자세히 알아보기: permit 모델이 사기 공격 수단으로 악용된 사례를 알고 싶다면 다음 링크를 브라우저에 복사하세요:
https://x.com/realScamSniffer/status/1783027808723435727https://x.com/realScamSniffer/status/1784932506174967970https://x.com/realScamSniffer/status/1786738218962223226

하지만 EIP-3074은 변화의 기회를 가져옵니다. DApp 개발자가 EOA가 Invoker를 통해 다양한 복잡한 작업을 수행할 수 있음을 알게 되면, 사용자 경험을 높이기 위해 보안을 희생할 필요가 없어집니다. 예를 들어 "사용자가 사전에 큰 자산량을 approve한다", "사용자가 인출 승인 메시지를 서명한다" 등의 방식이 더 이상 필요하지 않습니다.

대신 사용자는 DApp 작업과 approve를 묶어, Invoker를 통해 원자적(Atomic)으로 실행합니다. 즉 approve와 DApp 작업이 함께 성공하거나 함께 실패하며, approve만 단독으로 성공할 가능성은 없습니다. 따라서 사용자는 이번 approve가 바로 이번 작업을 위한 것임을 확신할 수 있습니다.

또한 사용자는 체인 외부에서 서명하는 방식을 사용하므로, permit과 동일한 사용자 경험을 제공합니다! 이는 곧 DApp이 더 이상 permit 모델을 필요로 하지 않는다는 의미입니다. 앞으로 지갑은 permit 서명 요청을 차단하거나 더욱 엄격한 검토를 할 수 있으며, 특정 DApp을 사용할 수 없다는 우려(대신 사기에 이용됨)를 할 필요가 없습니다.

사용자는 더 이상 단순히 특정 주소에 권한을 주는 것이 아니라, 특정 주소와 어떤 작업을 수행할지 함께 승인하며, 시뮬레이션된 실행 결과까지 볼 수 있습니다.

참고: 이는 사기를 완전히 차단할 수 있다는 의미는 아닙니다! 사용자가 여전히 사기 사이트에 유인될 수 있고, 사기 사이트 역시 approve나 송금 작업을 구성해 사용자에게 서명을 요청할 수 있습니다. 그러나 이때 사용자는 적어도 이번 서명이 어떤 작업을 위한 것인지 확인할 수 있으며, 지갑은 시뮬레이션을 통해 실행 결과를 보여주어 사용자가 누가 돈을 잃고 누가 돈을 얻는지 명확히 알 수 있게 합니다. permit처럼 어떤 작업인지 혹은 실행 결과조차 알 수 없는 것과 비교하면, 사용자는 더 많은 정보를 바탕으로 승인 여부를 결정할 수 있습니다. 완벽한 해결책은 아니지만, 현재 상황에 비해 큰 개선입니다.

지갑은 EOA nonce를 어떻게 처리할까?

현재 EIP-3074 설계는 EOA nonce 값을 서명 내용에 포함하므로, EOA가 한 번이라도 트랜잭션을 체인에 올려 nonce 값을 변경하면, 기존의 모든 EIP-3074 승인이 즉시 무효화됩니다.

사용자가 다른 사람에게 EOA 조작을 위임하는 경우, 예를 들어 앞서 언급한 Session Key나 Social Recovery 방식에서는 EOA nonce가 변경되지 않도록 해야 하며, 그렇지 않으면 모든 승인을 다시 서명하고 위탁자에게 전달해야 하므로 사용자 경험과 메커니즘의 안정성에 상당한 영향을 미칩니다.

사용자가 직접 승인 작업을 수행하는 경우에는 EOA nonce 변경을 특별히 피할 필요가 없습니다. 왜냐하면 EIP-3074 서명 역시 트랜잭션과 마찬가지로 특정 기한 내에 실행될 것으로 예상되기 때문입니다. 다만 지갑은 해당 EOA의 EIP-3074 트랜잭션도 관리해야 합니다. 만약 EIP-3074 서명이 체인에 올라가기를 기다리고 있다면, EOA가 자체적으로 올리는 트랜잭션은 기다려야 합니다.

참고: Invoker 컨트랙트는 자체적으로(또한 그렇게 해야 합니다) nonce 메커니즘을 유지관리하므로, 서명이 사용된 후에는 다시 한번 서명해야 하며, EOA nonce가 변경되었는지 여부와 무관합니다.

Session Key와 Social Recovery는 EIP-3074 규칙이 수정되어 EOA nonce를 서명 내용에서 제거하기 전까지는 대규모 채택이 어려울 가능성이 큽니다. 따라서 지갑은 "사용자가 직접 승인 작업을 수행하는" 시나리오에 집중하고, EIP-3074 서명도 트랜잭션처럼 처리한다면, EOA가 트랜잭션을 보내거나 EOA nonce가 변경되는 것을 걱정할 필요가 없습니다.

다만 주의할 점은, 사용자가 직접 자신의 EIP-3074 서명 내용을 체인에 올릴 경우 두 가지 단점이 있습니다:

사용자는 두 번 서명해야 합니다. 한 번은 EIP-3074 서명, 한 번은 체인에 올리는 트랜잭션 서명입니다.
체인에 올리는 트랜잭션은 실행 전에 이미 EOA nonce를 +1 증가시키기 때문에, 사용자의 EIP-3074 서명에 포함된 EOA nonce도 미리 +1 해야, 직접 올리는 트랜잭션으로 인해 증가한 EOA nonce와 맞춰질 수 있습니다.

자체적으로 체인에 올릴 경우 먼저 EOA nonce가 +1 되므로, EIP-3074 서명 검증 시 EOA nonce 불일치로 인해 실패합니다.

사용자가 체인에 올리기 전에 EIP-3074 서명 내 EOA nonce를 미리 +1 해두면, 검증을 성공적으로 통과할 수 있습니다.

요약 및 핵심 포인트

EIP-3074은 EOA가 컨트랙트와 동일한 수준의 풍부한 실행 능력을 얻게 하며, 많은 새로운 애플리케이션 시나리오를 열어줍니다.
이는 사용자 경험을 크게 향상시킬 뿐 아니라 기존의 승인 방식을 변화시켜, 사용성은 유지하면서 보안성을 더욱 강화할 것입니다.
또한 EIP-3074은 단순한 서명 방식이므로, 사용자가 반드시 직접 서명을 체인에 올릴 필요는 없으며, 따라서 수수료를 지불할 ETH를 미리 마련해야 하는 부담도 없습니다.
EIP-3074의 용도로는 Batch Call, Session Key, Native ETH Permit, Limit Order, Social Recovery 등이 있습니다. 이러한 기능들은 대부분 기존 EOA로는 불가능했으며, 일부는 Limit Order처럼 사전 승인 등 보안성이 낮은 방식이 필요했습니다.
EIP-3074은 기존의 승인 방식도 변화시킬 것입니다. approve는 특정 주소에 무기한 자산 인출 권한을 부여하며, 사용자의 EOA가 먼저 approve 트랜잭션을 보내야 하므로 사용성과 보안성이 모두 낮습니다. 반면 permit은 사용자 서명만으로 자산량과 유효기간을 지정할 수 있어, 사용성과 보안성이 approve보다 훨씬 높습니다.
하지만 permit도 여전히 사기에 자주 악용됩니다. 서명 시 사용자는 오직 어느 주소에, 얼마의 자산량을, 얼마나 유효한지만 알 수 있으며, 이 승인이 "어떤 목적으로 사용될 것인지"는 알 수 없습니다. "어떤 목적으로 사용될 것인지"는 또 다른 서명(또는 트랜잭션)이며, 정상적인 DApp은 사용자에게 permit과 "목적"을 함께 서명하게 하지만, 여전히 서로 다른 두 개의 서명이므로, permit 서명 요청 시 사용자와 지갑은 이 permit이 "어떤 목적으로 사용될지" 알 수 없습니다.
EIP-3074이 도입되면, 사용자는 (1) DApp에 큰 자산량을 미리 approve할 필요 없이, 작업 시에만 approve할 수 있으며, permit과 동일한 효과를 얻습니다. (2) 단순히 서명만 하면 되며, 수수료를 지불할 ETH를 마련할 필요도 없습니다. permit과 동일합니다. (3) 매번 approve는 지정된 작업과 함께 묶여 서명되므로, 사용자는 이번 approve가 "어떤 목적"인지 명확히 알 수 있으며, 이는 permit보다 더욱 안전합니다!
EIP-3074이 기존의 approve 및 permit 모드를 성공적으로 대체하여, 사용자에게 더욱 안전한 승인 방식을 제공하기를 기대합니다.