저자: 2077 Research
편집자: Glendon, Techub News
"크로스 체인 토큰을 다시 상호 교환 가능하게 만드는 방법" 시리즈의 첫 번째 부분을 읽지 않았다면 먼저 읽어보는 것이 좋습니다. 이 글에서는 크로스 체인 토큰의 상호 교환성 상실의 근본 원인과 이로 인해 발생하는 체계적 과제를 자세히 분석합니다. 두 번째 부분에서는 크로스 체인 토큰 전송 메커니즘을 재구축하고, 신뢰성을 높이며, 발급자에게 보다 정교한 거버넌스 권한을 제공하는 혁신적인 표준인 ERC-7281에 집중하겠습니다.
이전 기사에서는 크로스 체인 토큰 상호 교환성 문제를 해결하고 비표준 버전의 네이티브 토큰이 비네이티브 체인에서 유통됨으로써 발생하는 유동성 단편화 및 열악한 사용자 경험 문제를 해결하기 위한 다양한 기술적 경로를 체계적으로 논의했습니다. 여기에는 다음이 포함됩니다.
표준 롤업/사이드체인 브리지 프로토콜을 통해 대상 체인에서 주조된 기본 토큰의 표준 버전
타겟 체인에서 네이티브 토큰의 표준 버전을 생성하기 위해 타사 크로스체인 서비스를 활용합니다.
토큰 발행자가 독립적으로 운영하는 표준 브리징 서비스로, 대상 체인에서 표준 크로스 체인 토큰 채굴을 실현합니다.
위의 솔루션은 모두 장단점을 가지고 있습니다. 따라서 ERC-7281(xERC-20이라고도 함)의 설계 철학은 다양한 솔루션의 장점을 통합하여 크로스 체인 토큰 배포를 달성하고 보안, 주권 및 사용자 경험을 보장하면서 획기적인 균형을 이루고자 하는 프로토콜에 대한 보다 포괄적이고 효율적이며 확장 가능한 솔루션을 구축하는 것입니다.
ERC-7281이란 무엇인가요? ERC-7281: Sovereign Cross-Chain Tokens은 서로 다른 크로스 체인 프로토콜을 통해 발행된 토큰과 호환되고 상호 교환이 가능한 표준 버전의 토큰을 만드는 제안입니다. 이 표준은 ERC-20 인터페이스를 확장하여 다음과 같은 핵심 기능을 도입했습니다.
표준 ERC-20 토큰을 주조하고 파기하는 기능;
토큰 보유자의 거버넌스 권리: 1. 지정된 크로스체인 브릿지 공급자가 크로스체인 전송 중에 토큰 주조/파기 작업을 수행하도록 승인합니다. 2. 각 인증된 크로스 체인 브릿지 공급자에 대해 동적 주조/파기 한도를 설정합니다(예: 중앙 집중식 크로스 체인에는 더 작은 한도를 설정하고, 보안성이 더 높은 프로토콜에는 더 높은 한도를 설정합니다).
ERC-7281과 ERC-20 토큰 표준 간의 미묘한 기술적 차이점을 고려하여 표준 설정자는 이를 "xERC-20"이라고 명명했습니다. ERC-20 토큰 표준 인프라를 체계적으로 이해하고 싶은 독자는 OpenZeppelin에서 발표한 기술 가이드를 참조할 수 있습니다.
기본적으로 각 ERC-20 토큰 계약은 표준 인터페이스를 구현하여 글로벌 토큰 공급을 관리하고, 주소 보유량을 기록하며, 토큰 승인 관리, 전체 유통 조회, 주소 잔액 수집과 같은 기본 기능을 포함합니다.
ERC-7281 토큰 표준은 ERC-20 표준 위에 선택적 "Lockbox" 계약 모듈을 추가합니다. 래퍼 계약(기능적으로 WETH 계약과 유사)인 Lockbox 계약은 익숙한 주조 및 파괴 메커니즘을 통해 기존 ERC-20 토큰을 xERC-20 토큰 버전으로 변환할 수 있습니다. 이러한 설계는 또한 파괴/조성 인터페이스가 없고 업그레이드가 불가능한 기존 ERC-20 토큰 계약과 ERC-7281을 하위 호환되게 만듭니다.
첫 번째 부분의 분석 프레임워크에 따르면 ERC-7281은 "토큰 발급자를 신뢰하고 (승인된) 크로스 체인 브릿지 제공자를 신뢰하는" 크로스 체인 토큰 채굴 패러다임으로 분류될 수 있습니다. 핵심적인 장점은 다음과 같습니다.
크로스 체인 ERC-7281 토큰은 발행자가 완전히 제어합니다(주권 이전이 필요한 대부분의 크로스 체인 토큰 솔루션과 달리)
발급자는 여전히 승인된 크로스체인 브릿지에서 보안 사고가 발생할 위험에 직면하지만, 승인된 크로스체인 브릿지 공급자를 수동으로 선택하고 제한함으로써 이를 관리할 수 있습니다.
이 보고서에서 강조된 주요 혁신은 토큰 발행자가 지정된 크로스 체인 브릿지 제공자의 주조/파기 할당량을 동적으로 조정하여 크로스 체인 보안 사고의 위험 노출을 정확하게 보정할 수 있다는 것입니다. 또한 ERC-7281은 다수의 크로스 체인 브릿지 공급자를 위한 화이트리스트 메커니즘을 지원하여, 서로 다른 공급자가 여러 체인에서 동일한 표준 토큰을 주조할 수 있고, 발급자가 단일 공급자에 의존하는 경로 종속성을 효과적으로 줄일 수 있습니다.
이 두 가지 특징으로 인해 ERC-7281은 기존 접근 방식에 비해 상당한 개선이 이루어졌으며, 프로토콜 토큰의 크로스체인 브리징을 용이하게 하고 사용자, 상호 운용성 인프라 제공자(특히 집계자), 애플리케이션 개발자에게 긍정적인 2차 효과를 창출합니다. 다음 기사에서는 기술 사양 세부 사항을 자세히 살펴보고 ERC-7281을 구현하는 데 따른 잠재적인 장단점을 체계적으로 평가합니다.
ERC-7281 설명: Sovereign Cross-Chain 토큰
사용자 토큰 채굴 및 파기 메커니즘
ERC-7281 표준에 따르면, 이 프로젝트는 "IXERC20 인터페이스"를 준수하는 새로운 ERC20 호환 토큰 계약을 배포해야 합니다. 크로스 체인 브릿지 제공자가 소스 체인에 사용자가 예치한 토큰을 파기한 후에는 대상 체인에 동일한 양의 토큰을 주조할 수 있습니다. 주조 과정에서 시스템은 토큰 수가 브리지의 주조 한도를 초과하는지 확인합니다. 검증을 통과하면 총 토큰 공급량과 크로스 체인 브릿지 채굴 한도가 업데이트됩니다.
기존 ERC-20 토큰의 경우 Lockbox 로직을 채택해야 합니다. 크로스 체인 브릿지 제공자는 사용자가 예치한 ERC-20 토큰을 패키징을 위해 Lockbox 계약으로 전송하고 이를 xERC-20 토큰으로 변환합니다. 그러면 Lockbox는 공급자가 동일한 양의 xERC-20 토큰을 주조할 수 있는 권한을 부여합니다.
대상 체인의 브리지에서 주조된 xERC-20 토큰은 "burn() 함수"를 사용하여 소스 체인에서 파기됩니다. 이 프로세스는 파괴되는 토큰의 수가 브리지의 파괴 한도를 초과하지 않도록 보장합니다. 브리지의 전송 계층은 파괴 메시지를 대상 체인에 전달합니다. 대상 체인의 크로스 체인 브리지 계약은 메시지를 검증하고 해당 체인의 사용자 주소로 동일한 양의 xERC-20 토큰을 발행합니다.
반대로, 토큰을 소스 체인으로 다시 전송하기 위해 크로스 체인 브릿지 제공자는 대상 체인의 xERC-20 토큰을 파기하고 사용자의 주소와 토큰 수량을 제공합니다. 파기 수신은 전송 계층을 통해 소스 체인으로 전달됩니다. 파기 메시지가 검증되면, 크로스 체인 브릿지 제공자는 소스 체인의 사용자를 위해 xERC-20 토큰의 주조 및 파기 작업을 수행합니다. 토큰 계약에서 파기 인증서를 확인하면 사용자는 원래 ERC-20 토큰을 검색할 수 있습니다. 소스 체인 파괴 작업은 총 토큰 공급량과 크로스 체인 브리지 파괴 한도를 동시에 줄입니다.
요점은 xERC-20 계약이 신임장 검증 없이도 채굴 작업을 기술적으로 지원한다는 것입니다. 이 문서에서는 표준 검증 프로세스를 설명하지만 토큰 발급자는 크로스 체인 메시지 검증을 구현하지 않는 크로스 체인 브리지를 허용 목록에 추가하거나 새로운 검증 메커니즘을 채택할지 여부를 선택할 수 있습니다. 최종 의사결정권은 발행인의 위험 감수 능력에 따라 달라집니다.
토큰 주조 및 파괴 속도 제한 메커니즘
setBridgeLimits 함수는 토큰 계약 소유자만 호출할 수 있는 보호된 함수입니다. 이 기능을 사용하면 브리지 계약의 주소를 설정하고 브리지가 사용자를 위해 주조할 수 있는 최대 토큰 수(mintingLimit)와 브리지가 소각할 수 있는 최대 토큰 수(burningLimit)를 지정할 수 있습니다. 소유자는 크로스 체인 브릿지 제공자의 보안 태세 변화에 유연하게 대응하기 위해 제한을 동적으로 조정할 수 있습니다. 예를 들어:
크로스체인 브릿지 인프라에 취약점이 발견되면 mintingLimit을 낮춰 위험 노출을 제어할 수 있습니다.
반면, 크로스체인 브릿지가 보안성 업그레이드를 완료하면, 채굴 한도를 늘릴 수 있다.
xERC-20 표준에는 토큰 처리가 허용된 크로스 체인 브릿지의 파괴 및 주조 한도를 확인하는 기능도 포함되어 있습니다. "mintingMaxLimitOf"는 크로스 체인 브릿지가 주조할 수 있는 최대 토큰 수를 반환하는 반면, "burningMaxLimit"는 크로스 체인 브릿지가 지정된 시간 내에 파괴할 수 있는 최대 토큰 수를 반환합니다. 또한, 이러한 기능은 크로스체인 브릿지가 사전 설정된 한도에 도달하기 전에 파괴하고 주조할 수 있는 남은 토큰 수를 보여줍니다.
이러한 디자인은 크로스 체인 브리지 집계자에게 매우 중요합니다. 크로스 체인 브리지가 소스 체인/대상 체인의 파괴 또는 주조 한도에 도달하면 거래 지연 또는 실패가 발생합니다. 따라서 집계자는 충분한 가용 할당량을 갖추고 목표 거래량을 지원하는 크로스 체인 브리지로 요청을 라우팅하는 경향이 있습니다.
속도 제한 매개변수 분석
xERC-20 토큰 인터페이스 표준에 정의된 "Bridge" 구조에는 "burningParams"와 "mintingParams"가 포함되어 있습니다(xERC-20 토큰 비율 제한 기능의 매개변수는 브리지가 사전 정의된 시간 내에 얼마나 많은 토큰을 소각하고 주조할 수 있는지 제어합니다). "maxLimit"은 토큰 생성 및 소멸에 대한 최대 한도를 정의하며, 미리 정의된 비율(ratePerSecond)로 매초 증가합니다.
여기서 우리는 혼란스러울 수 있는 문제를 다루고자 합니다. "maxLimit"(소멸 및 주조 한도에 대해 설정됨)은 특정 시간 범위 내에서 주조 및 파괴 작업에 대한 한도입니다. 즉, 사전 설정된 시간 창 내의 사전 정의된 임계값을 기반으로 하는 주조 및 파괴에 대한 비율 한도입니다. "currentLimit"은 크로스체인 브릿지가 얼마나 많은 코인을 주조하거나 파괴할 수 있는지 정의하며, 미리 정의된 비율로 증가합니다. 이와 대조적으로 "maxLimit"은 크로스 체인 브릿지가 하루에 주조하거나 파괴할 수 있는 토큰 수를 정의합니다.
소각 및 주조 매개변수는 주로 토큰 소유자(그리고 크로스 체인 브릿지 제공자)와 관련이 있습니다. 그러나 최대 및 전류 한도 매개변수는 사용자와 크로스체인 브리지 제공자 모두에게 중요한 고려사항입니다. 예를 들어, 현재의 제한은 사용자가 대상 링크에서 xERC-20 토큰을 수신할 때 지연을 경험하지 않고 크로스 프로토콜 브리지를 자신 있게 사용할 수 있는 범위에 영향을 미칠 수 있습니다.
xERC-20 잠금장치
최초의 ERC-20 토큰은 토큰 공급을 늘리거나 줄이는 기능을 지정하지 않았습니다(초기 토큰 경제는 대부분 고정된 총 공급 모델을 채택했습니다). 따라서 모든 ERC-20 토큰이 주조 및 소각 기능을 갖추고 있는 것은 아닙니다. ERC-7281은 현재 대부분의 크로스 체인 브릿지에서 선호하는 주조 및 파괴 메커니즘을 사용하므로 Lockbox를 통해 ERC-20 토큰과의 하위 호환성을 달성해야 합니다.
원래 표준(즉, 프로젝트가 IXERC20 인터페이스를 구현하는 새로운 토큰 계약을 배포함)에서는 크로스 체인 브릿지 제공자가 소스 체인에서 예치금을 잠근 후 대상 체인의 사용자를 위해 토큰을 주조하기 위해 mint()만 호출하면 됩니다. Lockbox 계약은 WETH 래퍼 계약을 기반으로 설계되었습니다. 해당 ERC-20 토큰을 Lockbox에 예치하는 deposit() 함수를 구현하고, 원격 체인에서 래핑된 토큰을 파기한 후 크로스 체인 브릿지 제공자가 ERC-20 토큰을 잠금 해제할 수 있도록 withdrawal() 함수를 구현합니다.
이 표준에서 강조된 처음 두 가지 오류 유형("IXERC-20Lockbox_NotNative" 및 "IXERC-20Lockbox_Native")은 사용자가 잘못된 잠금 상자 계약에 토큰을 입금하려고 할 때 발생합니다. Lockbox는 지원하는 토큰 유형에 따라 기본형(또는 비기본형)일 수 있습니다.
네이티브 록박스는 검증자에게 가스 수수료를 지불하는 데 사용되는 토큰인 네이티브 토큰을 보관합니다. xERC-20 토큰으로 래핑하기 위한 네이티브 Lockbox가 있는 토큰의 일반적인 예는 ETH입니다. ETH를 xERC-20 토큰으로 래핑하려면 Lockbox의 depositNative() 함수를 호출하고 ETH를 입금하여 ERC 7281과 호환되는 버전의 ETH 토큰을 받아야 합니다.
비네이티브 Lockbox는 USDC, DAI, WETH, USDT 등과 같은 ERC-20 토큰을 저장할 수 있습니다. 예를 들어, USDC를 xERC-20 토큰으로 주조하려면 사용자는 USDC를 잠근 후 Lockbox 계약에서 deposit()를 호출해야 합니다. ETH를 사용하여 deposit()를 호출하면 해당 자금은 영구적으로 잠기게 되는데, 기본 Lockbox 계약은 ERC-20 토큰만 래핑하고 래핑을 해제할 수 있기 때문입니다. 또한, ERC-20 토큰으로 depositNative()를 호출하면 비슷한 결과가 생성됩니다. 왜냐하면 기본 Lockbox 계약은 ERC-20 토큰이 아닌 기본 토큰과 함께 작동하도록 설계되었기 때문입니다.
이런 방식으로, 표준 ERC-20 토큰을 채굴/소각을 지원하는 xERC-20 토큰으로 래핑함으로써 Lockbox는 해당 표준에 대한 중요한 호환성 계층을 제공합니다. 그러나 다른 크로스체인 솔루션을 xERC-20에 통합하는 등 어떤 경우에는 Lockbox만 사용하고 래핑된 토큰을 반환하는 것만으로는 실행 불가능합니다. 이러한 이유로 프로젝트에서는 어댑터 계약을 구현할 수 있습니다.
어댑터 계약
크로스체인 프로토콜이 xERC‑20 토큰에 내재된 작업(채굴/파기, 이벤트 로깅 등)을 인식하지 못하는 경우 애플리케이션 계층은 어댑터 계약을 빌드할 수 있습니다. 이러한 계약은 자동화된 래퍼 및 언래퍼 역할을 하며 ERC‑20 승인+호출 동작을 xERC‑20 표준에서 요구하는 보다 정교한 채굴/소각 방식으로 효과적으로 변환합니다.
이는 많은 크로스체인 프로토콜(예: Chainlink의 CCIP)이 여전히 레거시 ERC‑20 동작에 최적화되어 있기 때문에 필요합니다. 어댑터 계약은 다음 논리를 구현하여 이러한 호환성 격차를 메울 수 있습니다. 즉, 소스 체인에 xERC‑20 버전을 생성하기 위해 토큰을 Lockbox에 예치한 다음 대상 체인에서 메시지를 수신한 후 표준 자산으로 되돌리기 위한 종료 메커니즘을 트리거합니다.
이 프로세스는 사용자가 기본 xERC-20에서 지원하는 패키징 메커니즘의 영향을 받지 않고 궁극적으로 일관된 표준 토큰을 받을 수 있도록 보장합니다. 이를 통해 어댑터를 사용하면 프로토콜을 비 xERC-20 표준 크로스 체인 브리지와 원활하게 통합하고 지원하는 상호 운용 솔루션의 범위를 늘릴 수 있습니다.
왜 ERC-7281을 선택하시나요? Sovereign 크로스 체인 토큰 표준 케이스
일반적으로 ERC-7281에는 4가지 주요 목표가 있습니다.
1. 상호 교환성: 네이티브 체인에서 다른(L1/L2) 체인으로 토큰을 브리지하는 사용자는 항상 대상 체인에서 크로스 체인 토큰의 표준 버전을 받아야 합니다. 이전에 설명한 이유(예: 분산된 유동성 및 토큰 구성성 부족)로 인해 동일한 토큰의 여러 대체 불가능한 버전을 비네이티브 체인에서 유통하는 것은 문제가 있습니다. ERC-20 표준을 만드는 원래 비전은 이더리움 토큰이 애플리케이션과 이더리움 인프라 사이에서 원활하게 상호 교환되고 상호 운용될 수 있도록 하는 것이었습니다. 그러나 롤업 중심의 스케일링 로드맵을 채택한 후 원자적 구성성이 부족해지고, 여러 도메인을 생성하면서 이러한 호환성 속성이 저하되었습니다. xERC-20은 다양한 크로스 롤업 브리지의 유동성을 통합된 멀티 롤업 토큰 표준으로 집계하여 Ethereum의 원래 비전을 복원합니다.
2. 보안성: 상대방 위험을 줄이기 위해 토큰 발행자는 크로스 체인 브릿지 제공자의 보안 인프라를 평가하여 여러 제공자를 독립적으로 선택하고 연결할 권리가 있어야 합니다. 동시에 발행자는 효과적인 위험 격리 메커니즘을 구축해야 합니다. 일부 브리지 서비스 제공자가 보안 사고에 직면했을 때, 단일 공격으로 인해 프로토콜의 총 잠금 가치(TVL)가 완전히 붕괴되는 것을 방지하기 위해 영향 범위를 엄격히 제한해야 합니다.
3. 유동성 의존성이 없는 크로스 체인 토큰 콜드 스타트: 프로토콜 DAO는 멀티 체인 확장 계획의 일환으로 크로스 체인 토큰의 유동성을 부트스트래핑하는 데 상당한 (재정적) 리소스를 투자하도록 강요받아서는 안 됩니다. 유동성 기반 크로스 체인은 사용자 경험에 해로울 뿐만 아니라 지원되는 체인의 수가 급격히 증가함에 따라 프로젝트 당사자가 유동성 제공 인센티브에 지출하는 것이 실행 불가능해질 수 있습니다.
4. 토큰 발행자의 주권적 통제: 발행자는 비네이티브 체인에서 주조된 프로토콜 토큰의 표준 버전을 계속 통제해야 합니다. 대체 불가능한 크로스체인 토큰 문제를 해결한다는 것은 토큰에 대한 통제력(특히 총 공급량 제어, 주조 및 파기 메커니즘 구성 등과 같은 관리 측면)을 포기하는 대가를 치러야 하는 것은 아닙니다.
다음으로, 이러한 목표를 확장하여 ERC-7281이 프로토콜과 커뮤니티에 어떤 이점을 가져다주는지 살펴보겠습니다.
ERC-7281의 장점
사용자 경험 개선 및 유동성 분산 제거
ERC-7281은 다양한 경로 종속성 문제를 해결합니다. 경로 종속성은 체인별(예: Ethereum에서 Arbitrum을 거쳐 Optimism으로 가는 ETH는 Ethereum에서 Optimism을 거쳐 Arbitrum으로 가는 ETH와 다름)이거나 브리지별(예: Ethereum에서 Celer를 거쳐 Optimism으로 가는 ETH는 Ethereum에서 Connext를 거쳐 Optimism으로 가는 ETH와 다름)일 수 있습니다.
경로 종속성은 보안 가치가 있지만, 크로스체인 사용자 경험과 구성성을 심각하게 손상시킵니다. 크로스체인 DEX 시나리오를 예로 들면, 사용자가 Optimism과 Arbitrum의 유동성 풀에 동시에 자금을 주입해야 하는 경우, 체인 간 자산 표현의 차이(예: opETH와 arbETH)로 인해 자동화된 작업이 불가능할 것입니다.
ERC-7281은 xERC-20 토큰을 도입하여 이러한 문제를 완전히 제거합니다. xERC-20은 사용자가 체인을 교차하는 횟수나 어떤 크로스 체인 브릿지 공급자를 사용하는지와 관계없이 항상 대체 가능합니다. 예를 들어:
사용자는 Ethereum 체인으로 인출하지 않고도 Arbitrum의 래핑된 USDT를 Optimism으로 전송할 수 있습니다.
크로스 체인 브릿지 제공자가 Arbitrum 체인의 xERC-20 토큰을 파기한 후에는 Optimism에서 동일한 양의 토큰을 주조할 수 있습니다.
대상 체인 토큰의 가치는 항상 Lockbox의 기본 자산 보유액에 고정되어 1:1의 엄격한 상환이 유지됩니다.
ERC-7281은 Circle CCTP(Cross-Chain Transfer Protocol)와 유사한 표준 토큰 배포의 이점을 달성하지만, 계약 당사자가 크로스 체인 자산을 중앙에서 보관할 것을 요구하지 않는다는 점이 주목할 만합니다. 핵심 가치는 다음과 같습니다.
유동성 집계: DeFi 애플리케이션의 유용성을 개선하기 위해 프로토콜 토큰의 표준 버전을 중심으로 통합된 시장을 형성합니다.
운영 비용 절감: 동일한 자산의 다양한 버전에 대해 분산된 시장을 만드는 것을 피하세요.
토큰 발행자의 주권 통제 강화
xERC-20은 토큰 발행자가 특정 옵션을 사용하여 토큰의 표준 버전에 고정될 필요가 없고 크로스 체인 배포에서 크로스 체인 토큰의 설계 및 관리에 대한 통제권을 유지하기 때문에 "주권 크로스 체인 토큰"이라고 불립니다. ERC-7281은 "제3자 브리지를 통해 주조된 표준 토큰"과 "토큰 발행자가 제어하는 브리지를 통해 주조된 표준 토큰"의 하이브리드로, 주권, 사용자 경험 및 분산화를 결합합니다.
체인 간에 토큰을 배포하기 위해 ERC-7281을 사용하는 프로젝트는 동일한 네이티브 자산의 상호 교환이 불가능한 래핑된 버전이라는 문제 없이 여러 브리지를 통해 네이티브 토큰의 표준 버전을 주조할 수 있으며, 이는 사용자 경험을 저하시킬 수 있습니다. 이러한 프로젝트는 도메인 간에 표준 토큰의 전송을 관리하는 내부 인프라를 운영하는 토큰 발급자와 비슷한 수준의 토큰 크로스체인 배포에 대한 통제력을 유지합니다. 이는 xERC-20 토큰 계약과 Lockbox(크로스 체인 브리지가 사용자의 토큰을 잠그고, 주조하고, 파기하는 데 사용)가 프로젝트에 의해 배포되고 제어되기 때문입니다.
이 과소평가된 기능은 잘 알려진 프로젝트가 자체 메인 체인에서 네이티브 토큰을 발행하는 상황에서 매우 유용합니다. 특히 다른 생태계의 사용자가 여러 가지 이유로 토큰에 노출되기를 원하지만 자체 체인에 보관하고 싶어하지 않을 때 유용합니다.
이 경우, 해당 프로젝트는 크로스 체인 토큰 간의 1:1 호환성을 보장하기 위한 각 체인에 대한 내부 크로스 체인 인프라를 운영할 능력이나 의지가 없으며, 프로토콜과 커뮤니티와 반드시 일치하지 않는 제3자에게 토큰 통제권을 넘겨주고 싶어하지 않습니다. 이러한 상황은 네이티브 체인에서 투표를 계산하는 동시에 크로스 체인 토큰으로 투표를 허용하여 크로스 체인 거버넌스를 구현할 때 고려해야 할 사항입니다. 크로스 체인 토큰에 대한 통제권을 가진 일관성 없는 크로스 체인 브릿지 제공자는 프로토콜 거버넌스의 병목 현상이 됩니다.
위에서 언급한 이유로, 수확량 농업 프로토콜 Beefy는 xERC-20 표준을 채택했습니다. 프로젝트의 크로스 체인 브릿지 문서에 설명된 대로 ERC-7281은 프로젝트에 더 많은 크로스 체인 토큰 옵션을 제공하고(주요 크로스 체인 브릿지 파트너가 해킹당한 후 필요해짐) 크로스 체인 메커니즘의 설계에 대한 보다 세부적인 제어를 제공합니다. Beefy의 경우, ERC-7281의 화이트리스트 기능을 통해 프로토콜은 다양한 크로스체인 파트너를 선택하고 사용자에게 mooBIFI 토큰을 연결할 때 속도, 분산화, 비용 및 보안을 최적화하는 다양한 옵션을 제공할 수 있습니다.
개방 경쟁과 보안을 촉진하기 위한 인센티브 재조정
유동성 기반 브릿지는 일반적으로 유동성 인센티브를 자금 지원할 수 있는 재정적 능력이 있는 프로젝트를 선호합니다. 토큰 발행자는 유동성 공급자(LP) 인센티브에 대한 비용을 줄이고 우수한 크로스 체인 브릿지 사용자 경험을 제공하고자 하므로, 표준 L1/L2 브릿지를 사용하는 프로토콜에 있어 유동성이 가장 중요한 요소가 됩니다. 이는 또한 크로스체인 브릿지 집계자가 크로스체인 브릿지 공급자를 선택하는 데까지 확대되는데, 이로 인해 새로운 크로스체인 서비스(안전한 인프라를 갖춘 서비스도 해당)가 기존 크로스체인 프로토콜과 경쟁하기가 더 어려워질 수 있습니다.
ERC-7281은 크로스체인 유동성의 필요성을 없앰으로써 이 문제를 해결합니다. 비표준 토큰을 표준 토큰으로 주조하고 상환하는 대신, 모든 규모의 브리지가 대상 체인에서 프로젝트 토큰을 주조하도록 승인될 수 있습니다. 토큰 발행자가 크로스체인 실패 위험을 최소화하려고 할 때, 점점 더 많은 프로토콜이 유동성을 우선시하기보다는 크로스체인 브리지의 보안 설계에 더 집중하기 시작할 수 있습니다.
이는 "가장 유동성이 높은 브리지가 승리하게 하는" 것이 아니라 "가장 안전한 브리지가 승리하게 하는" 것이 되기 때문에 공개 경쟁을 장려합니다. 이러한 공개 경쟁은 유동성/보안 이외의 기능(예: 수수료, API/SDK, 앱 통합 등)을 놓고 경쟁하는 크로스 체인 브리지의 형태를 취할 수도 있습니다. 이러한 기능은 개발팀의 전문성에 주로 의존하기 때문에 처음부터 애플리케이션에 통합하기가 더 쉽습니다. 반면에 유동성과 크로스체인 거래량은 출시하기가 더 어렵고 사업 개발, 자금 조달, 업계 연결, 마케팅 등 여러 요소의 조합이 필요합니다.
토큰 발행자를 위한 더 나은 위험 관리 제공
ERC-7281은 토큰 주조 및 소각에 대해 구성 가능한 비율 제한을 도입하여 기본 토큰을 기본이 아닌 체인에서 주조하는 타사 크로스 체인 프로토콜을 사용할 때의 위험 프로필을 크게 개선합니다. 협력하는 크로스체인 브릿지 제공자가 해킹이나 침입을 당할 경우, 공격자가 입힐 수 있는 최대 피해는 손상된 브릿지의 한계와 같습니다. 토큰 발행자가 속도 제한 매개변수를 신중하게 선택하면 단일 크로스 체인 브리지에 대한 고립된 공격이 프로토콜의 지불 능력에 미치는 영향이 최소화될 수 있습니다.
또한, 각 크로스체인 브릿지에 대한 비율 한도를 구성하면 프로토콜 DAO의 위험 평가 프로세스도 개선될 수 있습니다. ERC-7281을 채택하면 위험 평가가 더욱 역동적으로 진행됩니다. 프로젝트에서는 여전히 적절한 요율 제한 속성을 선택하기 위해 크로스체인 브리지 공급자에 대한 실사를 수행해야 합니다. 하지만 위험 평가 기간은 단축될 수 있습니다. 프로젝트 당사자는 수개월에 걸쳐 여러 크로스체인 브릿지를 분석하여 하나를 선택하는 대신, 여러 크로스체인 브릿지 공급자를 선택하고 보안 평가에 따라 다양한 주조 한도를 설정할 수 있습니다. 토큰 발행자는 보안 검토를 수행하여 선택된 크로스 체인 브릿지 파트너에 대한 주조 한도를 늘리거나 줄일지, 또는 크로스 체인 브릿지에서 주조 권한을 철회할 것인지(예를 들어 해킹이나 취약성 공개에 대응하여) 결정할 수 있습니다.
ERC-7281은 또한 크로스 체인 브리지 보안 기술을 도입하고자 하지만 커뮤니티에서 전투 테스트를 거치고 엄격하게 검증될 때까지 기술을 완전히 도입하기를 꺼리는 프로젝트가 직면한 장벽을 줄입니다(즉, 혁신자의 딜레마). 크로스체인 브릿지 제공자가 보안 보장을 크게 개선한다고 주장하는 새로운 인프라를 제안한다고 가정해 보겠습니다. 이 경우, 프로토콜은 브리지에 제한된 주조권을 할당하고 제안된 시스템 설계에 대한 확신이 커짐에 따라 브리지의 주조 한도를 점진적으로 늘려 "시장을 테스트"할 수 있습니다.
유동성 관련 우려를 없애는 것과 마찬가지로, 채굴권을 할당하기 전에 크로스체인 브리지 기술 스택을 100% 신뢰해야 하는 프로토콜의 필요성을 없애면 신규 진입자와 기존 참여자 간에 동등한 경쟁 환경을 조성할 수 있습니다. 기존 참여자는 더 나은 보안 방법을 반복할 인센티브가 생기는데, 토큰 발행자가 이제 채굴권을 철회하여 소규모 프로젝트에 재할당할 수 있는 유연성을 갖게 되고, 후자는 보안과 분산화에 더 큰 의지를 보이기 때문입니다.
동시에, 이는 타사 크로스 체인 브리지와 함께 작동하는 프로토콜이 직면한 또 다른 위험 요소를 제거합니다. 크로스 체인 브리지 보안의 취약점과 문제점이 공개되고 발견되는 속도에도 불구하고, 선택된 크로스 체인 브리지 제공자는 토큰 발급자가 처벌 조치(예: 다른 크로스 체인 브리지 제공자로 신속하게 마이그레이션)를 시행할 수 없고 그러한 활동을 시행하는 것이 매우 어렵다는 것을 알고 있기 때문에 보안 혁신을 멈출 수 있습니다.
생태계 간 구성성 개선
오늘날에는 예측할 수 없는 유동성 기반 브릿지 가격 책정으로 인해, 토큰을 여러 체인을 통해 라우팅해야 하는 복잡한 애플리케이션 워크플로를 구축하는 것이 어렵습니다. 예를 들어, Ethereum → Linea → Base의 브리지 애그리게이터에는 두 가지 옵션이 있습니다.
오늘날 예측할 수 없는 유동성 기반 크로스 체인 브릿지 가격 책정으로 인해, 여러 Anthrouter 토큰을 통과해야 하는 복잡한 애플리케이션 워크플로를 구축하는 것은 어렵습니다. 예를 들어, Ethereum → Linea → Base의 크로스 체인 브리지 애그리게이터에는 두 가지 옵션이 있습니다.
슬리피지 허용 매개변수를 설정하고 각 체인에서 사용자가 받는 최소 토큰 수(크로스 체인 메시지가 각 계층에 도달할 때 사용 가능한 유동성 양에 따라 다름)를 기준으로 크로스 체인 라우팅 가격 책정을 수행합니다.
슬리피지 허용 매개변수는 설정되지 않으며, 하나 이상의 체인에서 수신된 토큰 양이 예상 금액보다 적을 경우 온체인 유동성(예: DEX를 통해)을 얻기 위한 로직이 생성됩니다.
반면, 특정 토큰의 주조를 허용하는 크로스 체인 브릿지의 mintingLimit과 burningLimit을 확인하면 브릿지 집계자는 크로스 체인 거래에서 각 도메인에 얼마나 많은 토큰이 있어야 하는지 미리 알 수 있습니다.
물론, 거래가 브로드캐스트되고 도메인에 도착하는 사이에 크로스체인 브리지가 maxLimit에 도달할 수 있습니다. 즉, 사용자는 대상 체인에서 표준 토큰을 받을 수 없습니다. 하지만 ERC-7281은 다음과 같은 이유로 이 측면에서 여전히 개선된 편입니다.
거래가 진행되는 동안 크로스체인 브릿지 제공자가 mintingLimit에 도달하면, 크로스체인 거래는 일시 중지되고 비율 제한 매개변수가 조정된 후 다시 시도됩니다. 오늘날의 유동성 브릿지와 달리 사용자는 표준 토큰의 독점적인 래핑 버전을 받지 못합니다.
크로스체인 브릿지 집계자는 크로스체인 거래가 실행되는 시점과 예상 토큰 양에 대한 더 큰 예측 가능성을 제공합니다. mintingLimit과 burningLimit은 블록을 시간 척도로 사용하도록 구성되어 있으므로(비율 제한 매개변수 섹션에 표시된 대로) 크로스 체인 브릿지가 토큰을 다시 주조하고 소각하기 시작하는 시점을 쉽게 계산할 수 있습니다. 이와 대조적으로, 크로스체인 브릿지의 유동성이 언제 증가할지 예측하는 것은 "러시안 룰렛"을 하는 것과 같습니다.
유동성의 예측 불가능한 변화는 재시도된 크로스체인 거래에 대한 가격도 예측 불가능하다는 것을 의미합니다. 크로스체인 브리지 집계자(또는 다른 애플리케이션)가 크로스체인 브리지 유동성 풀에서 토큰 쌍의 현재 가격을 기반으로 크로스체인 스왑을 견적한다고 가정해 보겠습니다(이 가격은 전체 풀 유동성을 기반으로 합니다). 그러나 풀 유동성이 급격히 떨어져 거래가 실행되지 않았습니다. 거래가 중단되었다가 나중에 다시 시도된다고 가정해 보자. 이런 경우 앱 개발자는 이전 견적이 여전히 정확한지, 유동성이 사용자가 처음 거래를 제출했을 당시와 같은 수준에 도달할지 알 수 없습니다.
크로스 체인 xERC-20 토큰은 유동성 변화에 영향을 받지 않으므로 사용자는 크로스 체인 거래가 즉시 실행되지 않더라도 슬리피지가 발생하지 않을 것이라고 확신할 수 있습니다.
크로스체인 브릿지 애그리게이터는 이러한 향상된 구성성의 혜택을 누리는 유일한 곳은 아닙니다. 모든 크로스체인 애플리케이션은 xERC-20 토큰의 대체성을 활용하여 더욱 매력적인 애플리케이션을 만들 수 있습니다.
하지만 경로 종속성 문제로 인해 현재로서는 이를 달성하는 것이 쉽지 않습니다. 개발자가 이더리움에서 ETH로 크로스 체인을 생성하고, Arbitrum DEX에서 대출 포지션을 개설한 다음 수익으로 Optimism에서 NFT를 구매한 후 다시 이더리움으로 크로스 체인을 생성하려고 한다고 가정해 보겠습니다. 이 과정에서 개발자는 사용자가 독점 버전을 쉽게 바꿀 수 없기 때문에 이러한 체인에서 크로스 체인 브릿지 제공자와의 통합을 보장해야 합니다. 하지만 프로젝트가 xERC-20을 채택하고 해당 크로스 체인 토큰이 대체 가능해지면 상황이 달라집니다.
이 워크플로는 위에 설명된 토큰 발급자 크로스 체인 브리지와 유사하며 Circle CCTP를 예로 들어 설명합니다.
Circle의 크로스 체인 전송 프로토콜을 통해 사용자는 서로 다른 체인의 생태계에 갇히지 않고도 통합된 표준 버전의 USDC 토큰을 사용할 수 있습니다. 모든 크로스체인 전송은 소각 및 주조 방식을 사용하는 프로토콜을 통해 처리됩니다.
하지만 CCTP는 중앙화된 프로토콜이고 Circle의 운영자는 USDC 토큰을 파기하고 주조할 권한이 있는 유일한 기관이지만 xERC-20은 다양한 보안 메커니즘을 갖춘 여러 기관이 크로스 체인 전송을 운영할 수 있도록 하여 신뢰 위험을 제거할 수 있습니다.
Rollup 중심의 멀티체인 미래에 대한 Ethereum의 비전을 지원하세요
ERC-7281은 또한 이더리움의 롤업 중심 로드맵을 가속화하여 프로젝트에 기존 L2 체인의 강력한 보안이 부족할 수 있는 새로운 EVM L2에 토큰을 배포할 수 있는 자신감을 제공할 수 있습니다. 예를 들어, 0단계 롤업용 표준 브리지는 Ethereum L1이 브리지의 보안을 보장하지 않기 때문에 보안성이 낮습니다. 토큰 프로젝트는 표준 브리지에 제한된 채굴 권한을 부여하고 롤업이 1단계에 진입한 후 채굴 한도를 늘리는 방식으로 이러한 체인에 점진적으로 배포할 수 있습니다.
이 프로세스는 L2가 2단계(롤업 분산화 및 보안의 가장 높은 단계)에 도달할 때까지 계속될 수 있습니다. 이 메커니즘을 통해 위험을 최소화하는 방식으로 새로 출시된 체인에 프로토콜을 배포할 수 있으며, 이를 통해 새로운 L2가 토큰 유동성과 애플리케이션을 부트스트래핑하기 쉬워지고 프로젝트가 롤업 디자인 분야에서 더 많은 혁신을 이룰 수 있으므로 이더리움 생태계에 이롭습니다.
ERC-7281 구현의 잠재적 단점
DAO 프로젝트 관리 팀의 비용 증가
ERC-7281이 프로토콜로서는 매우 매력적이지만, DAO에서는 xERC-20 토큰을 관리하는 데 드는 막대한 운영 비용으로 인해 이를 도입하는 데 주저할 수도 있습니다. DAO 프로젝트 팀은 다양한 배포에서 xERC-20 토큰을 관리하기 위해 상당한 운영 비용을 부담해야 합니다.
Gerard Persoon은 Managing Cross-Chain Tokens on a Large Number of Chains에서 ERC-20에서 xERC-20으로 마이그레이션한 후 프로토콜이 수행해야 하는 일회성 및 반복적 작업의 비철저한 목록을 제공합니다.
제안된 해결책 중 하나는 DAO가 크로스체인 xERC-20 토큰 관리와 관련된 일부 업무를 제3자 서비스에 아웃소싱하는 것입니다. 하지만 이는 단순히 인적 자원 비용과 서비스 고용 비용 간의 균형일 뿐입니다.
이전에는 내부 인프라를 사용하여 크로스 체인 토큰을 관리했던 프로토콜이 있었다고 가정해 보겠습니다(예: 각 체인에 대해 별도의 토큰 계약을 배포하고 주조와 소각을 제어). 이런 맥락에서 ERC-7281은 급진적인 변화로 보이지는 않습니다. 그러나 핵심 크로스체인 인프라 관리를 크로스체인 브릿지 개발팀에 아웃소싱하는 데 익숙한 프로젝트에서는 추가적인 업무 부담이 걱정스러울 수 있습니다.
xERC-20 토큰을 관리하면 프로토콜과 커뮤니티 구성원에게 무시할 수 없는 추가 관리 비용이 부과됩니다. 예를 들어, 크로스체인 브릿지 한도를 설정하려면 크로스체인 브릿지의 보안을 적극적으로 모니터링하고 평가하여 이 정보를 기반으로 주조 한도를 조정해야 하며, 크로스체인 브릿지 한도(또는 주조권의 취소/할당)에 대한 결정에는 DAO 투표가 필요할 수 있습니다(이러한 결정을 자주 내려야 하는 경우 DAO 구성원이 투표 피로를 경험할 수 있음).
하지만 이는 ERC-7281에 대한 가치 판단으로 여겨져서는 안 됩니다. 각 프로젝트는 서로 다른 위험 프로필, 장기 목표 및 리소스를 가지고 있습니다. 이러한 요소들은 ERC-7281을 도입하는 장기적 이점이 단기적 및 지속적 비용보다 더 큰지 여부를 결정합니다.
예를 들어, 규모가 작은 프로젝트는 xERC-20 토큰 발행을 관리하는 데 비용이 더 많이 들 수 있으며 Axelar의 ITS(Inter-chain Token Service)나 Wormhole의 NTT(Native Token Transfer)와 같은 관리형 멀티체인 토큰 크로스체인 서비스를 사용하기로 선택할 수 있습니다. 더 성숙한 프로젝트라면 xERC-20 토큰 발행에 따른 운영 비용을 관리할 수 있는 리소스가 있을 수 있으며, ERC-7281이 제공하는 제어 기능이 크로스 체인 토큰 관리에 따른 추가 오버헤드만큼 가치가 있다고 판단할 수도 있습니다.
기존 토큰을 xERC-20 표준으로 마이그레이션하는 것은 어렵습니다.
채굴/소각 인터페이스가 없거나 IERC20을 사용하도록 토큰 계약을 업그레이드할 수 없고 이미 기본 토큰의 표준 버전이 기본 체인에서 유통되고 있는 프로젝트의 경우, xERC-20 토큰으로 마이그레이션하는 것은 토큰 보유자, 거래소(DEX와 CEX), 파트너 브리지, 기존 ERC-20 토큰과 통합되는 다양한 애플리케이션 등 복잡한 참여자 네트워크가 참여하는 길고 엄격한 조정 과정입니다. 작업의 이 부분이 완료되더라도 프로토콜은 마이그레이션 프로세스를 완료하기 위해 ERC-20을 xERC-20으로 압축 해제하는 비용을 여전히 부담해야 합니다.
ERC-7281 표준 논의에서 설명한 대로, 사용자를 위해 래핑된 xERC-20을 주조하려면 기존 토큰을 Lockbox에 잠가야 합니다. 그러나 기존 ERC-20 토큰의 단계적 폐지는 머지않아 이루어질 가능성이 높으며, 이를 위해서는 새로운 (기존) ERC-20 토큰의 주조를 동결하는 일정에 관해 커뮤니티와 소통하는 또 다른 장기적인 과정이 필요합니다. 다시 말해서, 이는 프로토콜 관점에서 볼 때 가치가 있을 수 있습니다. 그러나 이러한 이득은 프로토콜 토큰과 호환되는 xERC20 버전으로 생태계 전반을 마이그레이션하는 데 드는 비용을 정당화하기에 충분하지 않을 수도 있습니다.
DAO 거버넌스는 더 위험하다
ERC-7281을 사용하여 여러 도메인에서 xERC-20 토큰을 관리하려면 프로토콜을 감독하는 DAO의 적극적인 거버넌스가 필요합니다. 여기에는 주조 한도 설정, Lockbox 계약 업그레이드, 토큰 주조 또는 소각 중단 등의 매개변수 설정이 포함됩니다. 이러한 결정은 민감하며, 비공개적으로 내려진 결정에 대한 책임을 피하기 위해 DAO에서 이를 관리해야 합니다.
ERC-7281은 제3자 크로스 체인 브리지가 아닌 프로토콜이 이러한 결정을 제어할 수 있도록 설계되었습니다. DAO가 이미 자체 체인의 토큰을 관리하고 있기 때문에 이러한 통제를 추구하는 프로토콜과 커뮤니티에게는 다른 체인의 토큰에 대한 거버넌스 확장이 합리적입니다. 그러나 일부 프로토콜은 거버넌스와 안정성에 대한 우려로 인해 이러한 추가적인 DAO 제어를 원하지 않을 수 있습니다.
예를 들어, 리도는 거버넌스 문제로 인해 조사를 받았으며, 토큰 관리에 대한 통제가 증가하면 거버넌스 인수의 위험이 커질 것입니다. 프로젝트가 모든 ERC-20 토큰을 하나의 잠금 상자로 통합하고 DAO를 통해 관리하는 경우 거버넌스 공격이 광범위한 영향을 미칠 수 있습니다. 공격자는 Lockbox를 제어하고 채굴 제한이 없는 악의적인 크로스 체인 브리지 공급자를 도입하여 다른 체인의 xERC-20 토큰을 쓸모 없게 만들 수 있습니다.
상황은 멀티체인 취약성과 비슷합니다. 멀티파티 연산(MPC) 서명 인프라의 취약성으로 인해 해커가 이더리움과 도지코인의 네이티브 토큰을 보유한 주요 멀티체인 주소를 손상시킬 수 있었습니다. 이 토큰은 Fantom과 Moonriver와 같은 네이티브가 아닌 체인에서 발행된 토큰을 지원하며, 이로 인해 "도미노 효과"가 발생하여 이더리움과 도지코인의 멀티체인 스마트 계약에 대한 공격으로 인해 다른 곳의 프로젝트가 손실을 입었습니다.
최대 분산형 프로토콜과 호환되지 않음
ERC-7281은 토큰 거버넌스가 있는 프로토콜이나 중앙화된 기관 (예: Circle의 USDC 또는 CZKC 스테이블코인)에서 토큰이 발행될 때만 요구 사항을 충족합니다. 그러나 프로토콜이 최대한 분산화되어 있고 공식적인 거버넌스가 없다면 가치가 거의 없습니다. Liquity의 LUSD 스테이블코인은 xERC-20 표준과 호환되기 어려운 토큰의 예입니다.
xERC-20 토큰을 사용하려면 기업이 주조 및 소각 한도와 같은 구체적인 매개변수를 결정하고 특정 크로스 체인 브릿지 공급자를 허용 목록에 추가할지 여부와 같은 결정을 내려야 합니다. 즉, xERC-20 토큰의 존재에는 지속적인 거버넌스가 필요하다는 의미입니다. 시간이 지남에 따라 프로토콜의 핵심 구성 요소를 분산화하려는 프로젝트의 경우(예: DAO의 토큰 계약) 이는 문제를 일으키고 분산화 계획을 복잡하게 만들 수 있습니다.
핵심 구성 요소(Lockbox 계약 및 크로스 체인 브리지 공급자)와 관련된 취약성은 더 큰 위험을 초래합니다.
우리는 이미 경로 종속성이 어떻게 작동하는지, 그리고 그것이 체인 A에 영향을 미치는 취약성이 체인 B에 영향을 미치지 않도록 보장하는 이유, 또는 체인 A의 브리지 A의 취약성이 체인 B의 브리지 B에 영향을 미치지 않도록 보장하는 이유를 언급했습니다. ERC-7281 표준은 경로 종속성을 제거하여 이점을 제공하지만 보안 측면에서 상충 관계도 발생시킵니다.
다양한 크로스체인 브릿지 제공자가 발행한 토큰은 크로스체인 간에 호환이 가능하므로, 크로스체인 브릿지에서 이용 가능한 최대 유동성은 더 이상 크로스체인 브릿지 취약성이 토큰 발행자에게 미칠 수 있는 최대 영향을 나타내지 않습니다. ERC-7281 표준 작성자는 토큰 발행자가 사기적 주조 손실을 보상하는 데 사용할 수 있는 금액을 기준으로 크로스 체인 브리지 제공자에 대한 비율 한도를 설정할 것을 제안했습니다. 그러나 회고해보면, 선택한 요금 한도가 지나치게 보수적이었을 수도 있습니다.
한도가 높은 크로스체인 브릿지가 공격을 받으면 그 영향이 상당할 수 있으며, 같은 토큰을 주조하는 다른 크로스체인 브릿지의 사용자에게도 영향을 미칠 수 있습니다. 따라서 프로토콜은 여러 개의 크로스 체인 브리지에 주조권을 분배하여 위험을 줄일 수 있습니다(크로스 체인 브리지 제공자가 주조할 수 있는 토큰의 수가 다른 크로스 체인 브리지에 비해 너무 많지 않도록 함). 하지만 이런 식으로 위험을 피하면 효율성이 떨어질 수 있습니다. 각 크로스 체인 브리지마다 DAO 팀이 독립적으로 평가를 실시하고 더 많은 크로스 체인 브리지와 조정해야 하기 때문에 위에서 언급한 관리 비용이 증가하게 됩니다.
또한 DAO가 관리하는 Lockbox 계약은 거버넌스 공격이 발생할 경우 부정적인 전염 효과를 가져올 수도 있습니다. 안전한 DAO 거버넌스를 사용하더라도 토큰 메인체인의 네이티브/비네이티브 Lockbox 계약의 버그로 인해 많은 문제가 발생할 수 있습니다. 이와 대조적으로 재무부 계약(브리지 제공자의 Lockbox 계약과 동일)은 해당 브리지를 통해 브리지된 토큰만 보유하므로 이 문제는 완화됩니다. 한 제공자의 재무부 계약의 취약성은 해당 브리지에 토큰을 예치한 사용자에게만 영향을 미치기 때문입니다.
생태계 통합 비용
ERC-7281 표준으로 인해 발생하는 추가 관리 작업은 프로젝트의 xERC-20 토큰을 사용하는 애플리케이션 개발자와 서비스 제공자에게도 영향을 미칩니다. 크로스 체인 브릿지 집계자는 스팸 토큰 및 스푸핑 공격과 같은 문제를 방지하기 위해 xERC-20 토큰과 해당 Lockbox 계약 간의 매핑 관계를 추적해야 합니다. 이러한 매핑에 대한 레지스트리가 도움이 될 수 있지만, 중앙 집중화 위험을 초래하거나 xERC-20 도입자를 위협에 노출시키지 않고 레지스트리를 구축하는 것은 어렵습니다.
위험은 공격자가 토큰 레지스트리에 악성 계약을 추가하고 사용자와 개발자를 속여 잘못된 주소로 토큰을 보내도록 할 수 있다는 사실에서 발생합니다. 이로 인해 L2 및 L1 네트워크 모두에서 토큰 도난이 발생할 수 있습니다. 거래소는 위조 토큰으로 인해 표준 감사 토큰과 달리 이상하게 작동하는 등 심각한 문제가 발생할 수 있으므로 유사한 문제에 직면합니다.
요약하다
ERC-7281 표준은 상호 교환이 불가능한 크로스 체인 토큰 문제에 대한 매력적인 솔루션을 제공하며 토큰 크로스 체인 설계에서 사용자 경험, 분산화, 보안 및 유연성을 향상시키는 기능을 제공합니다. 이러한 기능 중 일부는 롤업 중심 로드맵의 실현 가능성에 직접적인 영향을 미쳐 xERC-20 표준을 이더리움 L2 생태계의 핵심 인프라로 만듭니다.
현재 Hyperlane, Omni, Sygma, Router Protocol, Everclear 등 크로스체인 브리지 분야의 몇몇 주요 업체가 ERC-7281 표준을 채택하기로 약속하면서 이 제안이 폭넓은 관심을 받고 있음을 알 수 있습니다. 심지어 이미 토큰에 대한 크로스체인 메커니즘을 갖춘 일부 기존 토큰 발행자(예: Circle)조차도 승인되지 않은 토큰이 사용자와 개발자에게 제기하는 과제를 해결하기 위해 ERC-7281 표준에 관심을 표명했습니다. ERC-7281 표준 논의를 따르는 개발자나 xERC-20을 통합하려는 개발자에게는 Fellowship of Ethereum Magicians 와 xERC-20 웹사이트 , 그리고 xERC-20 Launchpad (xERC-20 토큰의 통합적 생성, 모니터링, 관리를 위한 도구)가 중요한 정보 및 도구 소스가 될 것입니다.
