ERC-621 이해하기: 토큰 발행 및 소각 표준

토큰 공급의 탄력성—새로운 토큰을 발행하거나 기존 토큰을 소각할 수 있는 능력—은 스테이블코인, RWA 프로그램, 로열티 포인트 및 많은 게임 자산의 작동 방식에 핵심적입니다. ERC-621은 ERC-20 토큰이 공급을 증가하거나 감소시키는 방법을 공식화하려는 초기 시도로, 도구 및 지갑 상호 운용성 개선을 위해 발행 및 소각 의미론을 표준화했습니다. 핵심 ERC-20만큼 널리 채택되지는 않았지만, ERC-621을 이해하는 것은 토큰 수명 주기를 설계하는 팀과 토큰이 제공하는 보증을 평가하는 사용자에게 여전히 가치가 있습니다.

이 글에서는 ERC-621이 무엇을 하는지, 현재 생태계에서 일반적인 ERC-20 확장과 어떻게 비교되는지, 그리고 특히 이더리움의 Dencun 업그레이드 이후 발행/소각 작업이 저비용 레이어 2 네트워크로 점점 더 많이 이동함에 따라 빌더와 재무 담당자가 무엇을 주시해야 하는지 설명합니다.

• ERC-20 참고 자료: 잔액, 총 공급량 및 이벤트에 대한 배경은 Ethereum.org의 표준 토큰을 참조하세요. 참고: Ethereum.org의 ERC-20.
• Dencun 컨텍스트: 메인넷 활성화로 롤업의 데이터 가용성 비용이 절감되어 L2에서 높은 빈도의 토큰 작업이 더 저렴해졌습니다. 참고: 이더리움 재단의 Dencun 발표.

링크:

• ERC-20: https://ethereum.org/en/developers/docs/standards/tokens/erc-20/
• Dencun: https://blog.ethereum.org/2024/03/13/dencun-mainnet

ERC-621이란 무엇인가?

ERC-621은 토큰 계약에서 표준화된 함수 및 이벤트 의미론을 통해 총 공급량을 늘리거나 줄일 수 있도록 하는 ERC-20의 확장 기능을 제안합니다. 본질적으로 발행(공급 증가) 및 소각(공급 감소)이 도구 전반에서 인식될 수 있는 합의된 방법을 제공합니다.

주요 아이디어:

• 발행은 totalSupply를 증가시키고 주소에 토큰을 적립하며, 0 주소(address(0))에서 수신자로 Transfer 이벤트를 발생시킵니다.
• 소각은 totalSupply를 감소시키고 주소에서 토큰을 차감하며, 보유자에서 0 주소로 Transfer 이벤트를 발생시킵니다.
• 이러한 의미론은 ERC-20 호환 토큰이 이벤트 계층에서 발행/소각을 나타낼 것으로 예상되는 방식과 일치하여 탐색기 및 인덱서와의 호환성을 향상시킵니다.

참고: eips.ethereum.org의 EIP-621.

링크:

• ERC-621: https://eips.ethereum.org/EIPS/eip-621

상태 참고: ERC-621은 생태계 초기에 제안되었으며, 오늘날 실용적인 ERC-20 "발행 가능/소각 가능" 패턴보다 덜 참조됩니다. 그럼에도 불구하고 이벤트 수준의 규칙은 발행/소각을 지원하는 제대로 구현된 ERC-20에서 광범위하게 따릅니다.

2024-2025년에 공급 탄력성이 중요한 이유

• 스테이블코인 및 RWA: 발행자는 새로운 담보가 온보딩될 때 정기적으로 발행하고 상환이 발생할 때 소각합니다. 명확하고 감사 가능한 이벤트 의미론은 투명성을 위해 필수적입니다.
• Dencun 이후 L2 운영: 롤업의 저렴한 배치 작업은 가스비 부담 없이 애플리케이션별 토큰에 대한 더 빈번한 발행/소각 주기를 의미합니다. 참고: 이더리움의 Dencun 로드맵 페이지.
• 규정 준수 및 수명 주기 제어: 재무 팀은 종종 역할 기반 발행, 상환 시 소각 또는 사고 발생 시 일시 중지할 수 있는 예약 발행이 필요합니다.

링크:

• Dencun 로드맵: https://ethereum.org/en/roadmap/dencun/

ERC-621 대 오늘날의 일반적인 ERC-20 패턴

ERC-621은 공식적인 발행/소각 확장을 정의하지만, 많은 프로덕션 프로젝트는 널리 감사된 ERC-20 라이브러리 및 액세스 제어를 사용하여 발행 및 소각을 구현합니다.

• OpenZeppelin의 ERC-20 확장:
  • Burnable 확장은 토큰 보유자(또는 승인된 지출자)가 토큰을 파괴할 수 있도록 합니다. 참고: OpenZeppelin ERC20Burnable.
  • 역할 기반 액세스 제어는 일반적으로 발행을 MINTER_ROLE 또는 소유자로 제한하는 데 사용됩니다. 참고: OpenZeppelin AccessControl.

링크:

• OpenZeppelin ERC20Burnable: https://docs.openzeppelin.com/contracts/5.x/api/token/erc20#ERC20Burnable
• OpenZeppelin AccessControl: https://docs.openzeppelin.com/contracts/5.x/api/access#AccessControl

일반적인 OZ 패턴의 장점:

• 광범위한 감사 및 커뮤니티 사용을 통한 성숙한 코드
• 유연한 역할 분리(예: MINTER_ROLE, PAUSER_ROLE)
• 일시 중지 가능 또는 허용(EIP-2612) 기능과의 쉬운 통합

엄격한 ERC-621과의 절충점:

• ERC-621은 공급 변경에 대한 표준 함수 이름 및 의미론을 목표로 합니다. 많은 토큰이 정확한 함수 시그니처를 노출하지는 않지만, 인덱서가 의존하는 이벤트 의미론(0 주소 발행/소각)은 준수합니다.
• 오늘날 도구 지원은 명시적인 ERC-621 인터페이스가 없더라도 ERC-20 발행/소각 이벤트에 대해 이미 강력합니다.

허용 흐름에 대한 참고 자료: EIP-2612.

링크:

• EIP-2612: https://eips.ethereum.org/EIPS/eip-2612

중요한 이벤트 의미론

토큰이 ERC-621의 정확한 인터페이스를 구현하지 않더라도, 투명한 공급 변경에는 두 가지 ERC-20 호환 패턴이 중요합니다.

• 발행: Transfer(address(0), to, amount) 발생
• 소각: Transfer(from, address(0), amount) 발생

인덱서, 지갑 및 탐색기는 이러한 이벤트를 사용하여 맞춤형 파싱 로직 없이 공급 변경을 이해합니다. 이것이 바로 ERC-621이 규범화하고자 했던 것입니다. 참고: ERC-20 토큰 표준.

링크:

• ERC-20 표준: https://ethereum.org/en/developers/docs/standards/tokens/erc-20/

최소한의 현대적인 구현 패턴

다음은 인기 있는 도구를 사용하면서 ERC-621 의미론과 일치하는 간단한 예입니다. ERC-621의 실제 함수 시그니처를 구현하지는 않지만, 예상되는 0 주소 Transfer 이벤트를 발생시키고 안전을 위해 역할을 사용합니다.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.[sol](https://onekey.so/blog/ko/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import {ERC20Burnable} from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.[sol](https://onekey.so/blog/ko/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import {AccessControl} from "@openzeppelin/contracts/access/AccessControl.[sol](https://onekey.so/blog/ko/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";

[contract](https://onekey.so/blog/ko/ecosystem/what-is-a-smart-contract/) ElasticToken is ERC20, ERC20Burnable, AccessControl {
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");

    constructor(string memory name_, string memory symbol_, [address](https://onekey.so/blog/ko/ecosystem/what-is-a-crypto-wallet-address/) admin) ERC20(name_, symbol_) {
        _grantRole(DEFAULT_ADMIN_ROLE, admin);
        _grantRole(MINTER_ROLE, admin);
    }

    function mint([address](https://onekey.so/blog/ko/ecosystem/what-is-a-crypto-wallet-address/) to, uint256 amount) external onlyRole(MINTER_ROLE) {
        _mint(to, amount); // Transfer([address](https://onekey.so/blog/ko/ecosystem/what-is-a-crypto-wallet-address/)(0), to, amount) 발생
    }
    // ERC20Burnable에서 상속된 소각 함수 (보유자 주도)
}

• 발행은 역할 기반으로 제어되며 0 주소 Transfer 이벤트를 발생시킵니다.
• 소각은 보유자 또는 승인된 지출자가 선택적으로 수행할 수 있으며, 0 주소로의 Transfer를 발생시킵니다.

OpenZeppelin 참고 자료:

• ERC20Burnable: https://docs.openzeppelin.com/contracts/5.x/api/token/erc20#ERC20Burnable
• AccessControl: https://docs.openzeppelin.com/contracts/5.x/api/access#AccessControl

보안 및 거버넌스 고려 사항

• 액세스 제어 및 직무 분리
  • MINTER, PAUSER 및 DEFAULT_ADMIN에 대해 별도의 역할을 사용합니다. 모든 권한에 대해 단일 EOA를 피합니다.
  • 단일 키 위험을 줄이기 위해 다중 서명 또는 모듈 기반 관리를 선호합니다. 잘 알려진 접근 방식은 관리 역할을 전용 다중 서명 뒤에 배치하는 것입니다. 참고: Safe의 Safe란 무엇인가에 대한 설명서.
• 일시 중지 및 회로 차단기
  • 일시 중지 가능한 계약은 사고 또는 오라클 오류에 대응하는 데 도움이 됩니다.
• 감사 및 모범 사례
  • 업그레이드 가능성, 초기화 및 역할 취소에 대한 확립된 보안 지침을 따릅니다. 참고: ConsenSys Diligence의 이더리움 스마트 계약 모범 사례.

링크:

• Safe 개요: https://docs.safe.global/learn/what-is-safe
• 스마트 계약 모범 사례: https://consensys.github.io/smart-contract-best-practices/

L2 및 브릿징 미묘한 차이

• 표준 토큰 대 브릿징된 토큰
  • L2의 표준 토큰인 경우, 발행은 종종 해당 L2에서 직접 발생합니다. 그런 다음 브릿지가 다른 네트워크의 공급을 반영합니다.
  • L1의 표준인 경우, L2 표현에서 발행할 권한이 있는 사람과 브릿지 계약이 해당 권한을 어떻게 제어하는지 고려합니다.
• 배치 작업
  • 롤업의 비용을 최소화하고 회계 명확성을 개선하기 위해 배치 발행/상환을 고려합니다. 롤업은 Dencun 이후 훨씬 저렴합니다. 참고: 이더리움의 Dencun 개요.

링크:

• Dencun 개요: https://ethereum.org/en/roadmap/dencun/

발행 또는 소각 가능한 토큰 평가 방법

사용자 및 통합자를 위한:

• 코드 또는 검증된 소스 읽기
  • 발행이 역할 기반인지 확인합니다. 컨트롤러(EOA, 다중 서명, DAO)를 식별합니다.
• 이벤트 의미론 확인
  • 공급 변경을 위해 0 주소와의 표준 Transfer 이벤트를 찾습니다.
• 업그레이드 가능성 검토
  • 업그레이드 가능한 경우, 누가 어떤 절차에 따라 업그레이드할 수 있는지 이해합니다.

탐색기 및 설명서 참고 자료가 여기에 도움이 됩니다.

• ERC-20 표준 개요: https://ethereum.org/en/developers/docs/standards/tokens/erc-20/
• ERC-621 제안 세부 정보: https://eips.ethereum.org/EIPS/eip-621

ERC-621을 오늘 채택해야 할까?

• 지갑이나 미들웨어가 대상 지정할 수 있는 명시적인 공급 관리 함수 시그니처를 원하는 경우, ERC-621은 명확하게 명명된 인터페이스를 제공합니다.
• 이미 OpenZeppelin 패턴에 의존하고 있다면, 감사된 라이브러리와 유연한 역할 설계를 활용하면서 ERC-621 정신의 중요한 부분—표준 0 주소 Transfer 이벤트—을 충족했을 가능성이 높습니다.
• 어떤 것을 선택하든, 발행/소각 정책(누가, 언제, 상한선, 감사 절차)을 문서화하고 통합자가 읽을 수 있도록 하십시오.

맺음말 및 실용적인 권장 사항

발행 및 소각은 엄격한 거버넌스가 필요한 강력한 레버입니다. ERC-621의 명시적인 인터페이스를 채택하든 널리 사용되는 ERC-20 확장을 고수하든, 가장 중요한 측면은 표준화된 이벤트 의미론, 명확한 역할 설계 및 안전한 키 관리입니다. 특히 2025년에 L2에서 발행 및 상환 활동이 가속화됨에 따라 더욱 그렇습니다.

운영 보안을 위해 발행 및 관리 키를 전용 콜드 스토리지에 보관하고 민감한 작업에 대한 다중 서명 승인을 요구하십시오. OneKey 하드웨어 지갑은 EVM 네트워크 전반의 재무 및 관리 역할에 대한 안전한 서명자로 사용할 수 있으며, 인기 있는 다중 서명 설정 및 dApp과 통합됩니다. 하드웨어 지갑을 사용하여 발행/소각 및 역할 관리 트랜잭션에 공동 서명하면 단일 실패 지점 위험을 줄이는 동시에 토큰 운영을 위한 효율적인 워크플로를 유지하는 데 도움이 됩니다.