ERC-827 탐색: transfer 및 approval 로직 확장

이더리움 생태계는 오랫동안 대체 가능한 토큰을 위해 ERC-20에 의존해 왔습니다. 애플리케이션이 발전함에 따라 개발자들은 기존의 transfer 및 approve 패턴보다 더 풍부한 토큰 상호작용을 원했습니다. ERC-827은 토큰 계약에 "transfer-and-call" 및 "approve-and-call" 의미 체계를 직접 추가하여, 토큰 전송이 수신 계약의 로직을 즉시 트리거할 수 있도록 하는 커뮤니티 제안 확장으로 등장했습니다. 이 아이디어는 현대적인 사용성 요구를 예상했지만, 오늘날 프로토콜이 토큰 콜백을 처리하는 방식에 영향을 미친 중요한 보안 및 호환성 문제를 제기하기도 했습니다.

이 글에서는 ERC-827이 무엇을 달성하려고 했는지, 어떤 보안 절충점을 부각했는지, 주목받은 실용적인 대안들은 무엇인지, 그리고 지갑 UX와 보안(특히 하드웨어 지갑)이 안전한 토큰 승인 워크플로에 어떻게 통합되는지를 탐구합니다.

ERC-827이 해결하려 했던 문제

기존 ERC-20은 가치 이동과 의도를 분리합니다.

• transfer: 송신자에서 수신자로 토큰을 이동시킵니다.
• approve: 지출자가 송신자의 토큰을 사용할 수 있도록 한도를 설정합니다.
• transferFrom: 지출자가 해당 한도를 사용할 수 있도록 합니다.

이 모델은 작동하지만, 단일 단계의 "결제 후 실행" 흐름이 필요한 dapp에는 번거로울 수 있습니다. ERC-827은 단일 트랜잭션에서 가치를 이동시키고 대상의 코드를 호출하는 토큰 함수를 제안했습니다. 개념적으로 이는 "dapp에 토큰을 전송하고 원자적으로 해당 dapp의 receive 함수를 호출"하거나 "계약에 승인하고 즉시 해당 승인을 사용하여 호출"하는 시나리오를 가능하게 합니다.

기본 표준인 ERC-20에 대한 자세한 내용은 이더리움 EIP 사이트의 사양을 참조하세요: ERC‑20.

콜백이 매력적인 이유

콜백 스타일의 토큰 상호작용은 UX를 개선하고 마찰을 줄입니다.

• 수신자가 즉시 로직을 실행하는 단일 트랜잭션 결제
• 흐름이 잘 설계된 경우 승인 오류 및 오래된 한도 감소
• 발신자와 수신자 간의 명확한 의도 신호, 특히 온체인 서비스의 경우

이러한 동기는 사라지지 않았습니다. 개발자들은 여전히 원자적인 "결제 및 수행" 의미 체계를 원합니다. 하지만 ERC-827이 제안한 대로 토큰 계약에 직접 구현하는 것은 주목할 만한 위험을 드러냈습니다.

ERC-827을 방해한 보안 함정

임의의 외부 호출과 자산 이동을 묶는 것은 다음과 같은 문제를 야기할 수 있습니다.

• 재진입 위험: 상태가 부분적으로 업데이트된 상태에서 신뢰할 수 없는 계약을 호출하면 복잡한 제어 흐름이 발생합니다. 재진입 및 완화 패턴에 대한 ConsenSys Diligence 개요를 참조하세요: 알려진 공격: 재진입.
• 예상치 못한 부작용: 토큰 계약은 최소한의 가치 원장이라기보다는 실행 허브가 되어 버그의 노출 면적을 증가시킵니다.
• 호환성 문제: 다양한 수신자 동작 및 기본(fallback) 의미 체계는 서로 다른 dapp 및 체인 간의 구성 가능성을 복잡하게 만듭니다.

이러한 절충점 때문에 커뮤니티는 핵심 토큰 로직을 최소화하고 "transfer-and-call" 의미 체계를 잘 정의된 확장 또는 별도 프로토콜로 푸시하는 패턴으로 이동했습니다.

개발자가 오늘날 사용하는 검증된 대안

몇 가지 표준 및 패턴은 ERC-20 계약에 부담을 주지 않으면서도 사용 편의성의 이점을 포착합니다.

• ERC‑677 (transferAndCall): 단일 함수와 수신자 인터페이스를 추가하는 실용적인 확장으로, 오라클 및 브릿지에서 널리 사용됩니다. 사양: EIP‑677.
• ERC‑1363 (Payable Token): transfer 및 approval 흐름 모두에 대한 더 풍부한 콜백 인터페이스입니다. 사양: EIP‑1363.
• Permit (ERC‑2612): 승인 마찰을 줄이고 불필요한 온체인 트랜잭션을 피하는 오프체인 서명 승인입니다. 사양: EIP‑2612.
• Permit2: 선도적인 DEX에서 한도 관리를 중앙 집중화하고 승인 위험을 줄이는 데 사용되는 강화된 구성 가능한 승인 시스템입니다. 문서: Uniswap Permit2.
• Typed structured data signing (EIP‑712): 메타트랜잭션 및 Permit에 대한 서명 안전성과 UX를 향상시킵니다. 사양: EIP‑712.

이러한 접근 방식은 개발자가 "결제 및 실행" 흐름을 달성하는 동시에 관심사의 분리를 유지하고 토큰 계약의 위험을 줄일 수 있도록 합니다.

콜백 의미 체계가 필요한 경우 디자인 지침

가치 전송 또는 승인 시 즉각적인 실행의 이점을 얻는 프로토콜이 있다면:

• 토큰에 임의의 호출을 내장하는 것보다 ERC‑677 또는 ERC‑1363 수신자를 우선적으로 사용하세요.
• 외부 계약과 상호 작용할 때 재진입을 완화하기 위해 ReentrancyGuard 및 구조화된 상태 업데이트를 사용하세요. 참조: OpenZeppelin ReentrancyGuard.
• 토큰 계약을 최소한으로 유지하세요. 복잡한 로직은 전문화된 모듈 또는 수신자 계약으로 푸시하세요.
• 승인을 간소화하고 "무제한 한도" 함정을 피하기 위해 Permit (ERC‑2612) 또는 Permit2를 고려하세요.
• 지갑 및 대시보드에서 더 안전한 UX를 위해 형식화된 데이터 서명을 사용하세요.

일반적인 토큰 디자인 및 구현 세부 정보는 OpenZeppelin ERC‑20 문서를 참조하세요: OpenZeppelin ERC‑20.

2025년 빌더들이 중요하게 생각하는 것

계정 추상화가 계속 성숙함에 따라, 프로젝트들은 안전을 희생하지 않으면서 dapp를 더욱 원활하게 만들기 위해 Permit 스타일 승인, 배치 작업 및 사용자 친화적인 세션 키를 점점 더 조합하고 있습니다. 고급 흐름을 통합하는 경우, 지갑 및 도구가 오늘날 지원하는 생태계 표준과 일치시키는 것이 좋습니다. 계정 추상화 사양을 참조하세요: EIP‑4337.

지갑 UX: 승인, 의도 및 안전

어떤 확장을 채택하든, 토큰 승인 및 콜백은 명확한 사용자 의도와 강력한 서명 UX를 요구합니다.

• 서명하기 전에 메서드, 지출자, 금액 및 위험을 표시하세요.
• 가능하면 시간 제한 또는 금액 제한 승인을 선호하고, 무제한 한도는 피하세요.
• 서명 혼란을 줄이기 위해 승인에 EIP‑712 형식화된 데이터를 사용하세요.
• 광범위하고 장기적인 승인보다는 범위와 기간을 제한하는 세션 아키텍처를 고려하세요.

하드웨어 지갑은 물리적 확인을 요구하고 트랜잭션 세부 정보를 명확하게 표시함으로써 피싱 및 악의적인 승인 위험을 줄이는 데 도움이 됩니다. ERC-677, ERC-1363 또는 Permit으로 구축하는 팀의 경우, 이 추가 계층은 사용자가 의도하지 않게 알 수 없는 계약에 강력한 권한을 부여하는 것을 방지합니다.

OneKey 사용자 및 통합 담당자를 위한 참고 사항

콜백 기반 전송 또는 Permit 스타일 승인에 의존하는 제품을 사용하는 경우, 투명한 서명 경험과 페어링하는 것이 필수적입니다. OneKey는 다음을 제공합니다.

• 이더리움 및 EVM 네트워크를 위한 오프라인, 하드웨어 기반 서명
• 지출자 주소, 토큰 금액 및 메서드를 표시하는 명확한 서명 지원
• 승인 및 전송이 표시되는 방식을 감사할 수 있는 오픈 소스 펌웨어 및 도구

이러한 기능을 통해 사용자는 보안을 손상시키지 않고 "transfer-and-call" 또는 "approve-and-call" 흐름을 안전하게 승인할 수 있습니다. dapp에서 ERC-677, ERC-1363 또는 Permit을 구현하는 경우, 명확한 서명과 제한된 한도를 우선시하고 사용자가 하드웨어 지갑으로 모든 승인을 확인하도록 권장하세요.

결론

ERC-827은 실제 필요를 포착했습니다. 즉, 토큰 이동과 즉각적인 실행을 일치시키는 것입니다. 커뮤니티의 반응은 ERC-677 및 ERC-1363과 같은 더 가벼운 확장과 Permit 및 EIP-712를 통한 더 안전한 승인 흐름을 선호하며 균형 잡힌 미래를 제공합니다. 2025년에는 토큰 코어를 최소화하고, 표준화된 수신자 인터페이스를 사용하고, UX를 위해 Permit 및 형식화된 데이터에 의존하고, 신뢰할 수 있는 서명을 위해 하드웨어 지갑에 의존하는 것이 성공적인 전략입니다.

빌더의 경우, 지갑 및 보안 도구가 이미 지원하는 표준을 채택하세요. 사용자의 경우, 승인을 신중하게 관리하고 OneKey와 같은 하드웨어 지갑으로 확인하여 복잡한 토큰 워크플로에서 노출을 최소화하세요.

참조:

• ERC‑20: EIP‑20
• ERC‑677: EIP‑677
• ERC‑1363: EIP‑1363
• Permit (ERC‑2612): EIP‑2612
• Typed data signing: EIP‑712
• Account abstraction: EIP‑4337
• Reentrancy guidance: Consensys Diligence: Known Attacks
• OpenZeppelin ERC‑20 docs: OpenZeppelin Contracts
• Permit2 overview: Uniswap Docs