ERC-223 내부 살펴보기: 토큰 오전송을 방지하는 방법

ERC-20 토큰을 수신 방법을 알지 못하는 스마트 계약으로 전송할 때, 프로토콜 수준에서는 전송이 성공하지만 토큰이 영구적으로 묶일 수 있습니다. 이러한 사용자 경험(UX) 함정은 DeFi 및 NFT 워크플로 전반에 걸쳐 수많은 사용자를 가두었습니다. ERC-223은 바로 이러한 문제를 해결하기 위해 제안되었습니다. 수신자 훅을 도입하여 계약 수신자가 들어오는 토큰을 명시적으로 수락(또는 거부)할 수 있도록 하여, 조용한 오전송을 방지합니다.

이 글에서는 ERC-223이 어떻게 작동하는지, 애초에 토큰 오전송이 발생하는 이유, 2025년에 존재하는 절충점은 무엇인지, 그리고 지갑과 dApp 개발자가 오송신을 과거의 유물로 만들 수 있는 방법을 자세히 살펴보겠습니다.

ERC-20이 토큰이 묶이게 하는 이유

ERC-20은 설계상 최소한의 기능을 갖추고 있습니다. 사양은 전송 및 승인을 정의하지만, 토큰 계약이 수신 계약과 어떻게 상호 작용해야 하는지는 정의하지 않습니다. transfer를 사용하여 ERC-20 토큰을 계약 주소로 전송하면, 토큰 계약은 단순히 잔액을 업데이트하고 이벤트를 발생시킵니다. 수신 계약이 자체적인 인출 또는 복구 로직을 구현하지 않으면 토큰은 다시 사용할 수 없게 될 수 있습니다. 이는 ERC-20의 버그가 아니라 수신자 동작을 정의되지 않은 상태로 둔 결과입니다. 이 표준의 범위 및 기능에 대한 자세한 내용은 이더리움 EIP 사이트의 ERC-20 공식 참조에서 확인할 수 있습니다: EIP-20.

이러한 “조용한 수락” 모델은 주소 독극물과 같은 사기 행위로 인한 혼란에 더해져 사용자의 꾸준한 손실에 기여했습니다. 공격자는 사용자를 속여 잘못된 대상 주소로 전송하도록 유인하기 위해 유사한 주소를 만듭니다. MetaMask의 지침은 이러한 사기가 어떻게 확산되는지, 그리고 이를 피하는 방법을 강조합니다: 주소 독극물 설명.

ERC-223 개요

ERC-223은 토큰 전송에 수신자 훅을 추가하여 계약 간 전송을 명시적으로 만듭니다. 수신자가 계약인 경우, 토큰 계약은 수신자에게 콜백(일반적으로 tokenFallback 또는 tokenReceived)을 호출합니다. 수신자가 이 함수를 구현하지 않으면 전송이 롤백됩니다. 이 단일 규칙은 토큰이 처리할 수 없는 계약에 조용히 전달되는 것을 방지합니다. ERC-223 사양에서 제안 및 목표를 검토할 수 있습니다: EIP-223.

핵심 아이디어:

• 통합된 전송 의미론: 별도의 approve + transferFrom 흐름에 의존하지 않고 단일 트랜잭션으로 토큰을 전송합니다.
• 수신자 검증: 계약은 알려진 함수를 통해 토큰 수신을 명시적으로 선택해야 합니다.
• 이전 버전과의 호환성 의도: 외부 소유 계정(EOA)으로의 코인 전송은 표준 ERC-20 전송과 동일하게 작동합니다.

ERC-223이 오전송을 방지하는 방법

일반적인 ERC-223 전송은 다음을 수행합니다:

1. to가 계약인지 EOA인지 확인합니다. 최신 Solidity에서 관용적인 확인 방법은 to.code.length > 0 (Solidity 0.8에서 도입)이며, Solidity 주소 유틸리티 설명서에 설명되어 있습니다: Solidity 주소 관련 전역 변수.
2. to가 계약인 경우, 금액과 선택적 데이터를 사용하여 계약의 수신자 훅을 호출합니다.
3. 훅이 존재하고 성공적으로 반환되면, 토큰은 잔액을 업데이트하고 Transfer 이벤트를 발생시킵니다.
4. 훅이 없거나 롤백되면, 토큰 전송 자체가 롤백됩니다. 따라서 송신자는 호환되지 않는 수신자에게 자금을 잃지 않습니다.

이 흐름은 ERC-20의 “조용한 수락” 격차를 해소합니다. 지갑과 dApp은 결정론적인 신호를 얻습니다. 즉, 계약이 토큰을 처리할 수 있거나 트랜잭션이 안전하게 실패합니다.

ERC-223 vs. ERC-20 vs. ERC-777

• ERC-20: 수신자 훅 없음; 계약이 토큰을 인지하지 못하더라도 계약으로의 전송이 성공할 수 있습니다. 참조: EIP-20.
• ERC-223: 수신자 훅과 선택적 메타데이터를 포함한 단일 단계 전송 추가; EOA에 대한 이전 버전과의 호환성을 목표로 합니다.
• ERC-777: 연산자 및 수신 계약의 tokensReceived 훅을 도입하는 보다 야심찬 재설계로, 더 풍부한 기능과 호환성 경로를 제공합니다. 참조: EIP-777.

실제로는 ERC-777이 더 많은 공식화 및 라이브러리 지원을 받았으며, ERC-223은 주로 우발적인 오송신 방지에 중점을 둔 더 간단한 안전 업그레이드로 남아 있습니다.

채택 및 2025년 맥락

• ERC-223은 EIPs 리포지토리에서 수신자 훅 개념에 중점을 두고 논의 및 문서화되었습니다. 그러나 ERC-20에 비해 주요 토큰 생태계 전반의 채택은 제한적입니다. 많은 프로젝트는 기존 ERC-20 패턴과 보안을 통합 계층에서 추가하는 개발자 라이브러리에 의존하고 있습니다.
• 지갑 측 및 dApp 측 완화 조치가 성숙했습니다. OpenZeppelin의 SafeERC20과 같은 안전한 래퍼는 일반적인 실패 모드(예: 비표준 ERC-20 구현)를 방지하며, 맹목적인 토큰 전송 대신 명시적인 계약 상호 작용을 장려합니다: OpenZeppelin SafeERC20.
• 사용자 보안 문제는 신원 수준 위험(주소 독극물 및 서명 기반 사기) 및 승인 관리로 이동했습니다. EIP-2612 (permit)와 같은 표준은 승인 관련 마찰 및 선행 거래 위험을 줄이며, 지갑 UX는 의심스러운 대상을 점점 더 경고합니다.

채택률이 고르지 않음에도 불구하고, 수신자 훅 아이디어는 지속적인 것으로 입증되었습니다. ERC-223 또는 ERC-777을 통해서든, 수신자 측의 명시적인 수락은 이제 일반적으로 모범 사례로 간주됩니다.

개발자 지침: ERC-223 안전하게 통합하기

• 수신자 훅 구현: ERC-223 토큰을 수신해야 하는 모든 계약에 tokenFallback 스타일 함수를 추가합니다. 스푸핑된 콜백을 방지하기 위해 msg.sender와 토큰 계약 주소를 검증합니다.
• EOA와 계약 인식: 레거시 extcodesize 어셈블리 대신 [address](https://onekey.so/blog/ko/ecosystem/what-is-a-crypto-wallet-address/)(code).length를 사용합니다. 최신 패턴은 Solidity 문서를 참조하십시오: Solidity 주소 유틸리티.
• ERC-20 호환성 유지: Transfer 이벤트를 발생시키고, 소수점 자릿수를 일관되게 유지하며, 읽기 메서드가 지갑 및 인덱서에 문제가 발생하지 않도록 합니다.
• 실패 모드 테스트: 수신자가 훅을 가지고 있지 않거나 비즈니스 규칙이 들어오는 토큰을 거부하는 경우 전송이 롤백되는지 확인합니다.
• 보안 코딩 모범 사례 따르기: 콜백, 재진입, 외부 호출에 대한 위협 모델링을 수행합니다. ConsenSys의 표준 지침을 검토하십시오: 스마트 계약 모범 사례.

지갑 UX 및 사용자 안전

ERC-223을 사용하더라도 사용자에게는 명확한 신호가 필요합니다:

• 전송이 거부될 수 있는 계약으로 토큰을 보낼 때 인간이 읽을 수 있는 경고.
• 수신자 훅의 존재 여부와 전송이 성공할 것으로 예상되는지 보여주는 시뮬레이션 또는 사전 검사.
• 주소 관리: EIP-55에 따라 체크섬 주소를 표시하고 확인하며, 시각적 유사성 및 독극물 사기에 대해 사용자 교육: 주소 독극물에 대한 MetaMask.

ERC-223이 스택에서 차지하는 위치

• 많은 계약과 상호 작용할 토큰을 구축하는 경우, ERC-223 스타일의 수신자 훅을 추가하면 오송신으로 인한 우발적인 손실을 크게 줄일 수 있습니다.
• 수신 계약(DEX, 금고, DAO)을 유지 관리하는 경우, 훅을 구현하고 허용되는 토큰과 실패 이유를 명확하게 문서화하십시오.
• 지갑 또는 집계기를 운영하는 경우, ERC-223 메커니즘을 눈에 띄게 표시하십시오. 수신자 훅의 존재/부재를 표시하고, 서명 전에 전송을 시뮬레이션하십시오.

OneKey 사용자 참고 사항

하드웨어 지갑은 진실의 순간, 즉 서명하려는 내용을 검토하고 확인할 때 도움이 됩니다. OneKey는 명확한 트랜잭션 프롬프트와 투명한 호출 데이터에 중점을 두어 토큰 계약 및 dApp과 상호 작용할 때 오류를 줄일 수 있습니다. 스마트 계약으로 토큰을 자주 이동하는 경우, ERC-223을 인식하는 dApp과 하드웨어 지갑을 페어링하여 온디바이스 검토를 강제하면 안전성이 향상됩니다. 강력한 오프라인 키 저장소와 명시적인 트랜잭션 확인은 오전송하거나 예상치 못한 것을 서명할 가능성을 줄여줍니다.

최종 생각

ERC-223은 수신자가 들어오는 토큰을 명시적으로 수락하도록 요구함으로써 오래 지속된 사용성 격차를 해결합니다. 보편적으로 채택되지는 않았지만, 핵심 아이디어인 수신자 훅은 이더리움 전반에 걸쳐 더 안전한 토큰 디자인과 지갑 UX에 영향을 미쳤습니다. 개발자라면 사용자를 보호하기 위해 이러한 훅을 구현하는 것을 고려하십시오. 사용자라면 서명하기 전에 전송을 시뮬레이션하고 무엇이 일어나고 있는지 설명하는 dApp과 지갑을 선호하십시오. 이러한 관행을 함께 사용하면 2025년의 점점 더 복잡해지는 온체인 환경에서 오송신 가능성이 훨씬 줄어들 것입니다.