ERC-677이란 무엇인가요: 스마트 계약 상호작용을 더 쉽게 만들기

스마트 계약은 토큰 스왑, 스테이킹, 자산 브리징, 오라클 업데이트 트리거 등 EVM 체인에서 거의 모든 의미 있는 상호작용을 지원합니다. 하지만 기본 ERC-20 토큰 표준은 종종 "승인" 후 "호출"과 같은 여러 단계의 사용자 경험 패턴을 요구하며, 이는 마찰을 증가시키고, 더 많은 가스를 소비하며, 사용자 오류 가능성을 높입니다. ERC-677은 토큰 전송과 즉각적인 계약 호출을 결합하여 이러한 흐름을 간소화하는 실용적인 ERC-20 확장 기능입니다.

이 글에서는 ERC-677이 무엇인지, 어떻게 작동하는지, 어디에 유용한지, 그리고 2025년에 개발자와 사용자가 무엇을 주목해야 하는지에 대해 설명합니다.

ERC-20만으로는 문제가 되는 이유

ERC-20은 대체 가능한 토큰을 위한 간단한 인터페이스(전송, 승인, 전송_from)를 정의합니다. 이러한 단순성은 ERC-20이 DeFi와 스테이블코인의 기반이 되도록 도왔지만, 일반적인 워크플로우를 두 개의 트랜잭션으로 강제합니다.

• 지출자 승인
• 프로토콜 계약 호출(이후 전송_from 실행)

이 두 단계 패턴은 다음과 같은 단점이 있습니다.

• 트랜잭션 수와 가스 비용 증가
• 사용자 경험의 마찰 및 혼란 야기
• 승인 경쟁 조건 및 잔여 허용량 발생 가능성. OpenZeppelin의 허용량 조정 가이드를 참조하여 승인 의미론 관련 문제를 완화하세요. OpenZeppelin ERC-20 허용량 권장 사항

ERC-20 자체에 대한 배경 정보는 Ethereum.org 문서를 참조하세요. ERC-20 표준 개요

ERC-677의 추가 기능

ERC-677은 transferAndCall이라는 단 하나의 핵심 함수로 ERC-20을 확장합니다. 이 함수를 통해 단일 트랜잭션으로 토큰이 수신자 계약으로 이동하고, 임의의 데이터와 함께 해당 수신자에게 미리 정의된 콜백(일반적으로 onTokenTransfer)을 즉시 호출합니다.

고수준 흐름:

1. 사용자가 ERC-677 토큰에 대한 transferAndCall을 서명합니다.
2. 토큰 계약이 수신자에게 토큰을 전송합니다.
3. 토큰 계약이 recipient.onTokenTransfer(sender, amount, data)를 호출합니다.
4. 수신자 계약은 예금, 스테이킹, 스왑 또는 오라클 트리거와 같은 로직을 실행합니다.

이 패턴은 별도의 승인 단계의 필요성을 제거하고 계약이 토큰 수신에 즉시 반응할 수 있도록 합니다.

Chainlink의 LINK 토큰은 잘 알려진 ERC-677 구현으로, 계약이 오라클 서비스 및 관련 상호작용 비용을 지불하기 위해 LINK 전송에 즉시 반응할 수 있도록 설계되었습니다. Chainlink LINK 토큰 및 ERC-677

일반적인 사용 사례

• 스테이킹 및 예치금 입금: 사용자는 단일 트랜잭션으로 입금하고, 예치금 계약은 콜백에서 해당 입금 내역을 처리합니다.
• DEX 및 유동성 흐름: 프로토콜은 토큰을 직접 수신하고 스왑 또는 유동성 추가 로직을 실행할 수 있습니다.
• 오라클 및 서비스 결제: 서비스 계약으로 토큰을 전송하고 동일한 호출에서 사용 또는 청구를 트리거합니다. LINK ERC-677이 원활한 오라클 결제를 지원하는 방식입니다. Chainlink LINK 토큰 및 ERC-677
• 브리지 및 크로스체인 프로토콜: 토큰 전달과 브리징 또는 메시징을 위한 지침 페이로드를 결합합니다.
• 크로스체인 상호 운용성: 크로스체인 사용이 증가함에 따라 가치 전송과 실행을 결합하는 것이 유용합니다. Chainlink CCIP의 설계는 네트워크 간 프로그래밍 가능한 토큰 흐름에 대한 수요 증가를 보여줍니다. CCIP란 무엇인가

ERC-677과 대안 비교

• ERC-1363 (transferAndCall-유사 "지불 가능 토큰"): 유사한 목표 - 계약이 토큰 수신 시 반응하도록 허용 - 지불 및 승인 흐름에 대한 표준화된 콜백 제공. 지불과 유사한 경험에 적합합니다. ERC-1363 사양

• ERC-777 (후크 기반 토큰): 더 풍부한 토큰 의미론 및 수신자 후크 제공. 강력하지만 역사적으로 더 많은 복잡성과 수신자가 신중하게 설계되지 않은 경우 재진입 위험을 수반했습니다. ERC-777 사양

• EIP-2612 (permit) 및 Permit2: 서명된 메시지를 통한 가스 없는 승인에 중점을 두어 approve 트랜잭션의 필요성을 줄입니다. DEX 및 지갑에 유용하지만, 종종 후속 계약 호출이 필요합니다. ERC-677은 전송과 실행을 번들링하여 사용자 단계를 줄입니다. EIP-2612 permit, Uniswap Permit2

• 계정 추상화 (EIP-4337): 지갑과 지불자가 여러 작업을 번들링하고 가스를 후원할 수 있도록 하여 사용자 경험을 개선합니다. ERC-677은 프로토콜 측 단계를 더욱 줄여 AA를 보완합니다. EIP-4337 계정 추상화

요약: permit과 AA는 지갑 측의 마찰을 줄이고, ERC-677은 토큰 전송 자체가 스마트 계약 로직을 트리거하도록 함으로써 마찰을 줄입니다.

개발자 고려 사항 및 보안

토큰 수신 시 콜백이 있으므로 주의가 필수적입니다.

• 재진입 (Reentrancy): 토큰 계약은 수신자 로직을 호출합니다. 수신자가 토큰 또는 다른 외부 계약을 다시 호출하는 경우 재진입 취약점을 도입할 수 있습니다. 필요한 경우 검사-효과-상호작용 또는 가드 패턴을 사용하세요. SWC-107 Reentrancy, OpenZeppelin ReentrancyGuard

• 발신자 및 토큰 검증: 수신자 계약이 msg.sender가 신뢰할 수 있는 토큰 계약과 일치하는지 확인하고, 여러 토큰을 지원하는 경우 토큰 주소를 검증해야 합니다.

• 화이트리스팅: 콜백이 민감한 작업을 수행할 수 있는 토큰의 경우 허용된 수신자 계약(또는 인터페이스 검증)을 화이트리스팅하는 것을 고려하세요.

• 이벤트 설계: 풍부한 이벤트를 방출하면 인덱싱 및 분석에 도움이 됩니다. 도구 호환성을 위해 가능한 경우 ERC-677별 데이터와 함께 ERC-20 호환 Transfer 이벤트를 유지합니다.

• 폴백 안전성: 수신자가 예상된 콜백을 구현하지 않으면, 기능의 "사일런트" 손실을 피하기 위해 전송은 되돌려지거나 명확하고 안전한 실패 경로를 따라야 합니다.

• 가스 및 실패 모드: 콜백은 되돌려질 수 있습니다. 명확한 오류 메시지로 실패를 처리하고, 전송이 성공했는지 또는 전체 트랜잭션이 되돌려졌는지 사용자가 이해하도록 해야 합니다.

일반적인 스마트 계약 안전성에 대해, Solidity의 보안 고려 사항 문서는 계속해서 필수적으로 읽어야 할 자료입니다. Solidity 보안 고려 사항

지갑 UX: 사용자에게 왜 중요한가

"승인 후 호출" 시퀀스를 제거함으로써 ERC-677은 복잡한 상호작용을 단일하고 목적 있는 작업처럼 느끼게 할 수 있습니다. 이는 서명 피로를 줄이고, 인지 부하를 낮추며, 종종 가스를 절약합니다. 그러나 단일 트랜잭션은 더 복잡합니다. 토큰을 전송하고 계약 로직을 동시에 실행하는 것이기 때문입니다. 이를 위해서는 지갑에서 명확한 미리보기, 시뮬레이션 및 읽기 쉬운 호출 데이터가 필요합니다.

ERC-677을 사용하는 프로토콜과 상호작용하는 보안 의식이 있는 사용자라면, 사람이 읽을 수 있는 함수 이름, 매개변수 및 예상 가치 변화를 표시하는 하드웨어 지갑을 사용하면 자신 있게 서명하는 데 도움이 될 수 있습니다.

2025년 맥락: 채택 및 조합성

2025년에는 가치 전송과 의도 실행을 번들링하는 추세가 계속될 것입니다.

• 더 많은 프로토콜이 승인 번거로움을 줄이고 네이티브처럼 느껴지는 "원클릭" 예금, 스왑 또는 서비스 결제를 선호합니다.
• 크로스체인 프레임워크는 프로그래밍 가능한 토큰 이동 및 메시지 페이로드를 강조합니다. ERC-677과 유사한 의미론은 이러한 아키텍처에 잘 맞습니다. CCIP가 크로스체인 사용 사례를 위해 토큰 전송과 함께 프로그래밍 가능한 메시지를 어떻게 형식화하는지 살펴보세요. CCIP란 무엇인가

콜백 흐름 시뮬레이션, 위험 노출, 이해하기 쉬운 프롬프트를 제공하여 결합된 전송 및 실행 작업을 더 안전하게 만드는 지갑 및 미들웨어 지원이 증가할 것으로 예상됩니다.

최소 인터페이스 개요

개념적으로 ERC-677은 다음과 같이 보입니다 (구현은 약간 다를 수 있습니다).

interface IERC677 {
    function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool);
    event Transfer([address](https://onekey.so/blog/ko/ecosystem/what-is-a-crypto-wallet-address/) indexed from, [address](https://onekey.so/blog/ko/ecosystem/what-is-a-crypto-wallet-address/) indexed to, uint256 value, bytes data);
}

interface IERC677Receiver {
    function onTokenTransfer([address](https://onekey.so/blog/ko/ecosystem/what-is-a-crypto-wallet-address/) sender, uint256 value, bytes calldata data) external;
}

토큰 계약은 가치를 전송한 직후 수신자에게 onTokenTransfer를 호출하여 수신자가 단일 트랜잭션 내에서 반응할 수 있도록 합니다.

실용적인 팁

• 프로토콜 개발자를 위해: 예상되는 콜백 인터페이스와 되돌림 이유를 명확하게 문서화하세요. 해당되는 경우, 통합자가 동작을 검증할 수 있도록 허용 목록 또는 인터페이스 검사를 게시하세요.
• 통합자를 위해: transferAndCall을 시뮬레이션하여 콜백 후 상태 변경을 미리 확인하세요. 사용자에게 위험한 수신자 또는 알 수 없는 콜백을 표시하세요.
• 사용자를 위해: 신뢰할 수 있는 프로토콜을 선호하고 트랜잭션 미리보기를 검사하세요. 지갑이 읽기 쉬운 디코딩을 지원하는 경우, 콜백에 전달된 매개변수를 검토하는 데 시간을 할애하세요.

ERC-677을 사용해야 할까요?

ERC-677은 다음과 같은 경우에 사용하세요.

• 핵심 사용자 흐름에 대해 "승인 + 호출" 패턴을 제거하고 싶을 때.
• 프로토콜이 토큰 수신에 대한 즉각적이고 원자적인 반응으로부터 이점을 얻을 때.
• 재진입에 대해 수신자 콜백을 강화하고 토큰 소스를 철저히 검증할 수 있을 때.

사용 사례가 순전히 승인 중심이라면 (예: DEX가 나중에 토큰을 지출하도록 허용), EIP-2612 또는 Permit2로 충분할 수 있습니다. 여러 수신자에 걸쳐 더 풍부한 후크 의미론이 필요한 경우 ERC-777을 평가하되, 복잡성을 염두에 두세요.

OneKey 사용자 참고 사항

ERC-677 트랜잭션은 토큰 전송과 계약 호출을 결합합니다. 서명할 때 어떤 함수가 어떤 매개변수로 실행될지 정확히 확인하는 것이 도움이 됩니다. OneKey의 오픈 소스 접근 방식과 EVM 지원은 transferAndCall과 같은 고급 상호작용에 대한 투명한 호출 미리보기 및 안정적인 서명을 제공하는 것을 목표로 하므로, 파워 유저는 간소화된 UX를 즐기면서 강력한 보안을 유지할 수 있습니다.

ERC-677을 이해하고 트랜잭션 세부 정보를 명확하게 표시하는 지갑을 사용함으로써, 더 간단하고 단일 트랜잭션으로 이루어지는 스마트 계약 상호작용의 이점을 안전하게 누릴 수 있습니다.