크로스체인 솔루션은 어떻게 크로스체인 토큰을 대체 가능한 토큰으로 만들까요?

알렉스 후크, 엠마누엘 아워시카 작성

글렌든, 테크큐브 뉴스 편집

편집. 왼쪽;">이 보고서는 두 부분으로 나뉘며, 1부에서는 크로스체인 토큰의 대체 불가능성 문제 등 크로스체인 영역이 직면한 과제에 대한 개요를 제공하고 현재의 주요 솔루션을 분석하며, 2부에서는 소버린 크로스체인 토큰 표준 ERC-7281을 살펴보고 사용자, 개발자, 인프라 공급자 등을 위한 ERC-7281 구현의 장점과 잠재적 단점을 분석합니다. 사용자, 개발자, 인프라 제공자 및 기타 이더 생태계의 참여자들을 위한 이점과 잠재적 단점을 분석합니다.

현재 크로스체인 운영은 크로스체인 브리지와 같은 블록체인 상호운용성 접근 방식에 내재된 한계로 인해 계속해서 많은 문제에 직면하고 있습니다. 예를 들어 크로스 체인 브리지는 보안 위험이 있거나(해커의 크로스 체인 공격으로 25억 달러 이상의 손실이 발생함), 느리고 비싼 속도와 제한된 기능에 직면할 수 있습니다. 더 심각한 문제는 이러한 문제가 동일한 크로스 체인 브리지에서 동시에 존재할 수 있다는 것입니다.

또한, 대체 가능한 토큰(예: ERC-20 표준 토큰)이 다른 크로스 체인 프로토콜을 통해 다른 체인으로 교차 체인될 때 대체 불가능해져 양도 가능한 자산으로서의 기능을 잃는다는 점도 크로스 체인 공간의 핵심 과제입니다. 이 백서에서는 토큰의 원래 계약이 어디에 있든 상관없이 토큰을 여러 체인에서 대체할 수 있도록 하는 솔루션인 소버린 크로스체인 토큰 표준 ERC-7281을 살펴보겠습니다.

ERC-7281(xERC-20이라고도 함)은 이더에서 대체 가능한 토큰을 만들기 위한 표준인 ERC-20의 확장입니다.ERC-7281은 토큰 발행자가 여러 개의 브리지를 승인할 수 있도록 허용합니다. ERC-7281은 토큰 발행자가 승인한 여러 개의 브리지가 원격 체인에서 표준 토큰 버전의 ERC-20 토큰을 발행하고 파기할 수 있도록 허용하여, ERC-20 토큰을 브리징하는 사용자가 다른 경로/브리지를 통해 토큰을 체인으로 전송하더라도 목적지에서 대체 가능한 버전의 토큰(즉, 두 토큰이 1:1 교환 가능)을 받을 수 있도록 보장합니다.

중요한 점은 ERC-7281을 사용하는 프로토콜은 크로스 체인 토큰에 대한 통제권을 유지하며(현재 브리지가 크로스 체인 토큰을 제어하는 것과는 대조적으로) 발행 작업 속도를 제한할 수 있어 크로스 체인 브리지 장애 발생 시 위험을 줄일 수 있다는 점입니다.

USDC를 예로 들면, 서로 다른 체인에 있는 이론적으로 동일한 ERC-20 토큰 간에 대체 불가능한 토큰을 찾을 수 있습니다. 이더리움 L2 네트워크(예: Arbitrum, Base, Optimism)에서 캐노니컬 브리지는 종종 이더리움 L1에서 이러한 체인으로 인기 있는 ERC-20 토큰을 전송하는 데 사용됩니다. L1에서 시작된 이러한 L2 토큰은 종종 "크로스 체인 [토큰 이름 삽입]"이라고 불립니다.

USDC의 경우 일반적인 토큰 심볼은 USDC.e, USDC.b 등입니다. 두 토큰은 동일한 주체가 발행하고 가격은 동일하지만 기술적으로 서로 다른, 상호 교환이 불가능한 토큰이므로 '상호 운용'이 불가능합니다. 기본 USDC는 Circle의 크로스 체인 전송 프로토콜(CCTP)을 통해 크로스 체인할 수 있지만, 크로스 체인된 USDC는 표준 브리지를 통해서만 L1으로 다시 크로스 체인할 수 있습니다.

ERC-7281은 토큰 배포자가 다양한 크로스 체인 소스를 할당하고 매개변수화할 수 있는 ERC-20 확장을 도입하여 이 문제를 해결합니다. 위의 예에서 Circle은 표준 크로스 체인 브리지(예: Circle Mint, Circle CCTP 및 기타 승인된 크로스 체인 브리지)가 로직에 따라 토큰을 발행할 수 있도록 지정된 모든 L2에 일반 USDC 토큰을 배포할 수 있습니다. 민트가 해킹당할 위험을 최소화하기 위해 배포자는 각 민트가 주어진 기간 동안 발행하고 소멸할 수 있는 토큰 수를 제한할 수 있으며, 더 안정적인 크로스 체인 브리지(예: 표준 L2 크로스 체인 브리지)에는 더 높은 한도를 설정하고 중앙화된 합의를 가진 브리지에는 더 낮은 한도를 설정할 수 있습니다. 제한.

ERC-7281은 대체 가능한 크로스체인 토큰을 위한 솔루션을 처음 시도한 것은 아니지만, 공급자 종속, 토큰 발행자의 주권 상실, 크로스체인 토큰의 높은 부트스트랩 유동성 비용, 인프라 오버헤드 증가, 크로스체인 실패 위험 증가 등의 크로스체인 문제를 해결할 수 있을 것으로 기대됩니다. 증가 등입니다.

크로스체인 브리지 메커니즘 개요

대체 불가능한 크로스체인 토큰 문제를 살펴보기 전에 크로스체인 토큰이 존재하는 이유와 크로스체인 브리지와 그 운영의 동기를 이해하는 것이 중요합니다. 크로스 체인 브리지 제공자는 크로스 체인 토큰의 버전을 생성하는 당사자이므로, 크로스 체인 브리지 메커니즘을 이해하는 것이 중요합니다.

크로스체인 메커니즘은 블록체인 간에 정보를 전송하는 수단입니다. 크로스 체인 브리지는 순수한 암호화폐 정보 외에도 토큰 환율, 다른 체인의 스마트 콘트랙트 상태 등 기타 유용한 정보를 전달할 수 있습니다. 그러나 한 체인에서 다른 체인으로 자산(토큰)을 전송하는 것이 현재 사용자와 상호작용하는 브리지의 가장 일반적인 사용 사례입니다.

체인 간 자산 전송을 촉진하는 방법은 다양하지만, 토큰 크로스체인 워크플로는 일반적으로 세 가지 높은 수준의 패턴 중 하나를 따릅니다.

잠금 및 발행된 브리지

• 사용자는 네이티브 또는 '소스'(원래 발행된) 체인에서 다른 체인으로 토큰을 교차 연결하고자 합니다. 각 체인은 서로 다른 아키텍처와 프로토콜 설계를 구현하기 때문에 두 블록체인은 호환되지 않으므로 사용자가 A 체인의 지갑 주소에서 B 체인의 지갑 주소로 토큰을 직접 전송할 수 없습니다.

• 사용자는 자신의 홈 체인에서 다른 체인으로 토큰을 전송하고자 할 수 있습니다.

• 크로스 체인 브리지 제공자는 스마트 콘트랙트에서 원본 체인에 저장된 사용자의 토큰을 호스팅하고 대상 체인에 배포된 토큰 콘트랙트를 통해 원본 토큰의 '랩드' 토큰 버전을 생성합니다.

• 사용자가 크로스 체인(타겟 체인 → 네이티브 체인)을 되돌리고자 할 때, 랩드 토큰을 타겟 체인의 크로스 체인 브리지로 반환하면 크로스 체인 브리지의 로직(예: 영지식 증명 또는 외부 중재)에 따라 이를 검증하고 네이티브 체인의 에스크로 계정에서 네이티브 토큰을 릴리스합니다. .

소멸 및 채굴 브리지

• 이 방법은 토큰을 에스크로에 잠그는 대신 소스 체인에서 토큰을 소멸시킵니다.

• 이 크로스 체인 브리지는 대상 체인에서 동일한 수의 토큰을 발행합니다.

• 역방향 전송의 경우, 크로스 체인 토큰이 대상 체인에서 소멸된 다음 새 토큰이 소스 체인에서 발행됩니다.

• 이를 통해 총 토큰 공급량을 유지하면서 크로스 체인 전송이 가능합니다.

아토믹 스왑

• 아토믹 스왑은 동일한 개인 가치를 지닌 자금을 서로에게 잠그는 방식으로, 한쪽의 비밀이 유출되면 다른 쪽의 비밀도 손상됩니다. 이것이 거래소에 원자성의 속성을 부여합니다.

• 원자성은 거래가 양쪽 모두에서 완전히 완료되거나 전혀 완료되지 않아 사기나 부분/실패 전송을 방지할 수 있다는 의미입니다.

위 방법 중 첫 번째 방법(잠금 및 발행)이 가장 일반적입니다. 네이티브 토큰과 브릿지에서 발행한 랩드 토큰의 가치가 동일하기 때문에 사용자는 자산을 '체인 간에' '전송'하고 토큰이 원래 발행된 체인과 다른 체인에서 토큰을 사용할 수 있습니다.

그러나 인텐트 기반 크로스체인 브리지와 같은 새로운 디자인이 인기를 끌고 있습니다. "인텐트를 사용하면 사용자는 결과를 달성하기 위한 구체적인 단계를 설명하는 대신 거래의 원하는 결과(100 USDC를 100 DAI로 변환)를 표현할 수 있습니다. 인텐트는 온체인 경험을 크게 단순화하고 특히 체인 추상화 솔루션과 함께 사용할 때 암호화폐를 더 쉽게 사용할 수 있게 해주기 때문에 사용자 경험을 향상시키는 강력한 도구가 되었습니다."라고 말했습니다.

크로스체인 인텐트를 사용하면 사용자는 크로스체인 브리지의 근본적인 복잡성에 대한 걱정 없이 체인 간에 토큰을 전송할 수 있습니다. 인텐트 기반 크로스 체인 브리지에서 사용자는 소스 체인에 자금을 예치하고 대상 체인에 기대하는 결과(즉, '인텐트')를 지정합니다. '필러'(필러) 또는 '솔버'(솔버)라고 불리는 전문 운영자는 요청된 토큰을 타겟 체인의 사용자에게 미리 전송하여 이 의도를 이행할 수 있습니다. 그런 다음 운영자는 소스 체인에 잠긴 자금을 보상으로 청구하기 위해 전송이 이루어졌음을 증명합니다.

일부 인텐트 기반 크로스체인 브리지는 내부적으로 잠금 메커니즘을 활용합니다. 이 경우, 크로스 체인 브리지는 사용자의 의도를 충족하는 필러에게 전송되거나 필러가 관여하지 않는 경우 사용자에게 직접 전송되는 패키지 토큰을 채굴합니다. 그러나 인텐트 기반 교차 체인 브리지는 솔버 네트워크를 통해 효율성을 추가하지만, 본질적으로 기존의 락앤민트 브리지와 동일한 원리에 의존합니다.

랩드 토큰을 각각 배치할 수 있습니다. (전통적인 크로스 체인 브리지를 통해 생성되었든 의도적인 크로스 체인 브리지를 통해 생성되었든)을 크로스 체인 브리지 제공자가 에스크로 계약에서 특정 수의 네이티브 토큰을 릴리스할 것을 약속하는 'IOU'로 배치할 수 있습니다. 이러한 패키지 자산의 가치는 네이티브 체인에서 에스크로 토큰 보유자의 출금 요청을 처리하는 크로스 체인 브리지 제공자의 (인식된) 능력과 직접적으로 관련이 있습니다.

소스 체인에서 네이티브 토큰을 락업하고 타겟 체인에서 랩드 토큰을 발행할 권한이 있는 크로스 체인 브리지는 토큰의 총 공급량을 일정하게 유지합니다. 기본 토큰 한 단위에 대해 정확히 한 단위의 해당 포장 토큰이 발행되며, 그 반대의 경우도 마찬가지입니다. 앱이 패키징 토큰을 교환 수단으로 받아들이거나 패키징 자산을 통화로 사용하는 경우, 앱의 개발자와 사용자는 패키징 토큰의 '실제' 자산의 보안을 지원하는 크로스체인 브리지 제공자를 전적으로 신뢰하게 됩니다.

크로스체인 브리지가 필요한 이유는 무엇인가요?

크로스체인 브리지는 크로스체인 토큰을 생성함으로써 원격 체인에 있는 합성 버전의 자산과 거래할 수 있으며, 이는 개발자와 사용자 모두가 크로스체인 상호운용성의 이점을 누릴 수 있는 강력한 기능입니다. 이러한 이점에는 더 많은 유동성 확보, 신규 사용자 유치, 사용자에게 유연성 제공(다른 체인의 앱과 방해 없이 상호 작용할 수 있음) 등이 있습니다.

이것이 실제로 어떻게 작동하는지, 그리고 이것이 개발자와 사용자 모두에게 중요한 이유를 더 잘 이해하기 위해 가상의 탈중앙화 거래소인 '밥덱스'를 예로 들어보겠습니다. 이 예시는 토큰 패키징이 어떻게 크로스체인 확장을 가능하게 하는지를 보여줌과 동시에 발생할 수 있는 이점과 잠재적인 복잡성을 강조합니다.

BobDEX는 Bob이 이더에서 만든 자동화된 시장 메이커(AMM) 거래소로, 다양한 자산을 신뢰 없이 교환할 수 있도록 설계되었습니다.BobDEX에는 기본 토큰인 거버넌스 토큰이자 유동성 공급자(LP) 보상 토큰인 BOB 토큰을 보유하고 있습니다. 후자의 경우, 밥덱스는 풀에 유동성을 공급하는 사용자에게 풀에 예치된 자산을 교환하기 위해 DEX 사용자가 지불한 수수료의 일부(비율 기준)를 받을 수 있는 권한을 부여하는 BOB 토큰을 LP에게 발행합니다.

그러나 밥덱스의 시장 점유율이 크게 성장함에 따라 이더 L1의 한계로 인해 더 이상 성장하지 못했습니다. 예를 들어, 일부 사용자는 높은 가스 수수료와 거래 지연으로 인해 이더리움에서 밥덱스를 사용하기를 원하지 않으며, 마찬가지로 다른 사용자는 BOB 토큰에 액세스하고 싶지만 이더리움에서 네이티브 BOB 토큰을 보유하기를 원하지 않습니다.

이 문제를 해결하기 위해 Bob은 낮은 수수료, 높은 처리량의 레이어 2 롤업인 BobDEX 버전을 Arbitrum에 배포하고 Arbitrum-에테리움 브리지를 통해 L2에 BOB 토큰의 랩드 토큰 버전( wBOB). 아리트럼의 밥덱스는 이더의 밥덱스와 동일하지만, LP 보상 및 거버넌스 토큰으로 네이티브 BOB 토큰 대신 wBOB를 사용합니다.

아비트럼에서 BobDEX와 상호작용하는 사용자(예: 유동성 공급자)의 경우, 애플리케이션 토큰(래핑된 BOB와 네이티브 BOB)의 차이는 중요하지 않습니다. 이는 wBOB 토큰이 Arbitrum- 이더리움 브릿지에 보관된 실제 BOB 토큰으로 뒷받침되기 때문에 wBOB 토큰 보유자는 브릿지 컨트랙트와 상호 작용하여 이더에서 네이티브 BOB ERC-20 토큰을 쉽게 교환할 수 있기 때문입니다.

이 상황은 Bob과 사용자 모두에게 윈윈이라는 것을 알 수 있습니다.

1. Bob은 더 많은 사용자, 특히 낮은 가스 수수료로 BobDEX에서 거래하고자 하는 사용자를 유치할 수 있습니다. LP는 이더리움의 높은 가스 비용과 긴 확인 시간을 처리할 필요 없이 밥덱스에 유동성을 제공함으로써 보상을 얻을 수 있습니다.

3. 투자자는 다음과 같은 이점을 누릴 수 있습니다. 마켓플레이스에서 wBOB 토큰을 구매하여 이더리움의 BOB ERC-20 계약과 상호작용할 필요 없이 BOB 토큰 가격 변동에 따른 수익을 얻을 수 있습니다.

그 외에도 크로스 체인 브릿지의 장점은 의 장점은 컴포저블 혁신을 강화하고 브리지 토큰의 유동성을 활용하는 새로운 사용 사례를 발굴하는 데 있습니다. 예를 들어, 앨리스는 아리트럼에서 대출자의 wBOB를 담보로 받아들이는 "AliceLend"라는 대출 계약을 생성하여 wBOB의 효용을 확장하고 새로운 대출 시장을 창출할 수 있습니다.

알리스렌드에 유동성을 제공하는 대출자는 예치금을 안전하게 확보할 수 있으며, 사용자가 채무 불이행 시 알리스렌드는 담보로 맡긴 wBOB 토큰을 자동으로 경매하여 대출자에게 상환합니다. 이 경우 wBOB 담보를 청산하는 구매자는 BobDEX에서 LP의 역할을 맡게 되며, wBOB 토큰을 1:1 비율로 기존 BOB 토큰으로 교환할 수 있습니다.

현재 크로스 체인 브리지는 (이전에 고립된) 이더 L2 간의 상호 운용성을 보장하고 크로스 체인 대출 및 크로스 체인 DEX와 같은 새로운 애플리케이션을 촉진하기 위한 실행 가능한 솔루션을 제공합니다. 그러나 크로스 체인 브리지 생태계는 크로스 체인 토큰의 대체 불가능성 문제와 같이 더 큰 성장을 방해하는 한계에 직면해 있습니다.

왜 크로스 체인 토큰은 대체 불가능한 토큰이 되었나요?

위에서 언급한 브리지 잠금과 발행을 위한 크로스 체인 워크플로는 간단해 보이지만, 실제로는 제대로 작동하려면 많은 엔지니어링과 메커니즘 설계 작업이 필요합니다.

첫 번째 과제는 크로스체인 토큰의 랩퍼 토큰 버전이 항상 소스 체인에 잠긴 네이티브 토큰에 의해 뒷받침되도록 하는 것입니다. 공격자가 소스 체인에 네이티브 토큰을 예치하지 않고 원격 체인에서 크로스 체인 토큰을 발행하는 경우, 공격자는 (부정하게 발행된) 래퍼 토큰을 메인 체인의 네이티브 토큰과 교환하여 크로스 체인 브리지 프로토콜을 파산시키고 합법적인 사용자(래퍼 토큰을 발행하기 전에 크로스 체인 브리지 계약에 예치한)가 예치금을 인출하지 못하도록 할 수 있습니다.

두 번째 문제는 더 미묘하며 크로스 체인 토큰의 특성에서 비롯된 것으로, 동일한 원격 체인에서 크로스 체인 브리지 제공자가 발행한 동일한 토큰의 두 가지 버전은 1:1 비율로 서로 교환할 수 없습니다. 이와 관련하여 서로 다른 경로를 통해 체인 간 토큰을 교환하려는 두 사용자의 예를 통해 체인 간 토큰 이동과 관련된 문제를 설명할 수 있습니다.

• 표준 Arbitrum 브리지를 통해 앨리스가 는 이더에서 아비트럼으로 USDC를 연결하고 아비트럼에서 200 USDC.e를 받고, 밥은 악셀라를 통해 USDC를 아비트럼으로 교차 연결하고 아비트럼에서 200 axlUSDC를 받습니다. 앨리스와 밥은 합의에 도달하여 앨리스가 밥에게 200 USDC를 보냅니다. (앨리스와 밥은 밥이 400 USDC를 이더로 인출할 수 있도록 앨리스가 밥에게 200 USDC를 보내고 밥은 200 USDT와 교환하는 합의에 도달합니다.

• 밥은 axlUSDC를 통해 400 USDC를 인출하려고 하지만 200 USDC만 받고, 크로스체인 브리지 프로토콜이 밥에게 200 USDC만 제공할 수 있다는 메시지도 받습니다. 밥은 패키지화된 ERC-20 토큰이 '대체 가능'해야 하기 때문에 이에 대해 혼란스러워합니다. 패키지화된 ERC-20 토큰은 "대체 가능"해야 하고, 어떤 애플리케이션에서든 1:1 비율로 교환할 수 있어야 하므로 밥은 혼란스러워합니다.

• 밥은 크로스체인 브리지를 통해 '대체 가능한 ERC-20 토큰'이 항상 '다른 앱에서 다른 ERC-20 토큰과 1:1 비율로 교환할 수 있다'는 의미는 아니라는 어려운 교훈을 얻었습니다. 따라서 밥이 앨리스와 위험한 거래를 시도한 것은 (앨리스가 토큰을 돌려주지 않을 수도 있기 때문에) 비참하게 실패한 것입니다.

밥이 400 USDC를 출금할 수 없는 이유는 위에서 언급한 것처럼 대상 체인에서 동일한 기초 자산의 다른 패키지 버전을 앨리스와 받았기 때문이며, 다른 체인에서 발행된 토큰은 호환되지 않으므로 네이티브가 아닌 체인에서 발행된 토큰은 실제로 크로스 패키징되어 있습니다. 토큰 버전은 사실상 크로스 체인 브리징 프로토콜을 위한 IOU로, 사용자가 토큰의 네이티브 체인으로 다시 브리징을 원할 경우 잔여 수량에 따라 적절한 양의 네이티브 토큰을 지급하겠다고 약속하는 것입니다.

따라서 각 크로스 체인 토큰의 가치는 기본 체인에 예치금을 보관하고 대상 체인에서 랩드 토큰을 발행하는 크로스 체인 브리지 제공자에게 묶여 있으며, 밥의 크로스 체인 브리지 제공자는 예치금에서 지불할 수 있는 금액이 200 USDC이므로 밥에게 200 USDC만 지불할 수 있습니다. USDC는 밥의 크로스체인 브리지 제공자가 예치금을 받거나 앨리스에게 "어음"을 발행한 적이 없기 때문에 밥의 크로스체인 브리지 제공자를 통해 인출할 수 없으며, 앨리스는 이더리움의 Arbitrum에서 잠긴 USDC를 인출하여 밥의 크로스체인 브리지 제공자를 통해 연결해야 나머지 토큰에 액세스할 수 있습니다.

밥과 앨리스의 딜레마는 여러 경쟁하는 크로스체인 브리지 제공자가 동일한 기초 자산에 대해 대체 불가능한 버전의 토큰을 여러 개 발행하는 크로스체인 브리징의 문제를 지적합니다. 또한 동일한 자산에 대해 서로 다른 ERC-20 토큰을 단일 유동성 풀에서 거래할 수 없다는 문제도 있습니다.

위 예시를 사용하더라도, 체인에 axlUSDC와 USDC.e가 있고 이를 ETH로 교환하려면 두 개의 유동성 풀, 즉 ETH/axlUSDC와 ETH/USDC.e로, 동일한 유동성 풀에 있을 수 있는 쌍이 다른 풀로 분할되는 '유동성 파편화' 문제가 발생합니다.

이 문제에 대한 해결책은 대상 체인에 '표준' 버전의 토큰을 유통시켜 밥과 앨리스가 각각 소스 체인의 브리지에서 돈을 인출할 필요 없이 토큰을 교환할 수 있도록 하는 것입니다. 각 체인에 표준 토큰이 있으면 사용자가 토큰 유동성과 관련된 문제를 처리할 필요 없이 생태계 사이를 빠르게 이동할 수 있으므로 개발자에게도 이점이 있습니다.

그렇다면 토큰이 사용되거나 전송될 각 체인에서 표준 버전의 토큰을 어떻게 구현할 수 있을까요?

여러 체인에서 표준 토큰 구현

각 체인에 표준 토큰을 생성하는 것은 쉬운 일이 아니며, 각각 장단점이 있는 여러 가지 옵션이 있습니다. 각 체인에 대한 표준 토큰을 만들 때 일반적으로 특정 토큰의 가치를 뒷받침하는 IOU(약속어음)의 존재를 확인하기 위해 누구를 신뢰해야 할지 고민해야 합니다. 여러분이 토큰을 생성하고 해당 토큰이 대체성 문제 없이 여러 체인에서 사용되고 전송되기를 원한다고 가정하면, 다음과 같은 4가지 선택지가 있습니다.

1. 표준 롤업/사이드체인 브리지를 통해 표준 토큰을 발행

타사 크로스체인 브리지 공급자를 통해 표준 토큰 발행

3. 토큰 발행자 브리지를 통해 표준 토큰 발행

4. 아토믹 스왑을 사용하여 직접 멀티체인 발행

4. 직접 멀티체인 발행

처음 세 가지 옵션은 다양한 크로스체인 브리지 메커니즘을 사용하여 토큰이 체인에서 쉽게 이동할 수 있도록 합니다. 그러나 토큰 생성자는 크로스 체인 브리지를 완전히 우회하고 지원되는 각 체인에서 토큰을 직접 발행하도록 선택할 수도 있습니다. 이 접근 방식에서는 토큰 패키징이나 크로스 체인 브리지 인프라에 의존하는 대신 각 체인에 독립적이면서도 조정된 토큰 배포를 유지하며, 아토믹 스왑을 통해 체인 간 신뢰 없는 교환을 가능하게 합니다.

그러나 이 접근 방식은 크로스 체인 유동성을 유지하고 아토믹 스왑을 촉진하기 위해 복잡한 인프라가 필요합니다. 과거 경험에 따르면, 여러 네이티브 배포를 관리해야 하는 복잡성으로 인해 이 접근법은 주로 상당한 기술 리소스가 필요한 대규모 프로토콜에 적합하며 그 범위가 제한됩니다.

표준 롤업/사이드체인 브리지를 통한 표준 토큰 발행

체인에 표준 브리지가 있는 경우, 해당 프로토콜의 체인에서 토큰을 발행할 수 있는 권한을 네이티브 체인에서 크로스체인하려는 이들에게 부여할 수 있습니다. 권한. 체인의 표준 브리지를 통해 이루어지는 거래(입금 및 출금)는 일반적으로 체인의 검증자 세트에 의해 검증되며, 이는 기본 체인에 예치된 예금이 모든 발행된 토큰 버전을 안정적으로 지원한다는 강력한 보증을 제공합니다.

표준 브리지는 표준 토큰 버전을 발행하지만, 표준 브리지는 종종 사용자에게 최상의 경험을 제공하지 못하는 한계가 있기 때문에 다른 토큰 버전이 여전히 존재할 것입니다. 예를 들어, 롤업의 결제 레이어(이더)가 거래 배치를 정산하기 전에 검증자가 거래를 검증해야 하기 때문에(유효하지 않은 경우 사기 증명을 통해 이의를 제기할 수도 있음) Arbitrum/Optimism 브리지에서 롤업의 표준 브리지를 통해 이더로 이동하는 데 7일이 지연될 수 있습니다.

효율성을 추구하는 롤업 사용자는 보류 중인 롤업 종료의 소유권을 인수하고 사용자가 원하는 대상 체인에 즉각적인 유동성을 제공할 수 있는 다른 크로스체인 브리지 공급자를 사용해야 합니다. 이러한 브리지가 기존의 락앤민트 모델을 사용하는 경우, 서로 다른 프로토콜에서 발행한 여러 개의 랩드 토큰을 사용하게 되며 앞서 설명한 것과 동일한 문제에 직면하게 됩니다.

독립적인 검증자 세트가 있는 사이드체인은 사이드체인의 합의 프로토콜이 출금 거래를 포함하는 블록을 확인하면 출금이 실행되므로 지연 시간이 짧으며, 폴리곤 PoS 브리지는 이더 롤업과 이더 메인넷을 포함한 여러 도메인에 사이드체인을 연결하는 표준 브리지의 예입니다.

주: 이더를 사용해 결제될 예정인 밸리디움 체인이 아닌 원래의 폴리곤 PoS 체인을 의미합니다. 폴리곤은 외부 검증자에 의해 보호되는 사이드체인에서 이더컨센서스에 의해 보호되는 밸리디움 체인으로 전환되면 L2가 될 것입니다.

유감스럽게도 사이드체인 브리지는 롤업 표준 브리지와 약점을 공유합니다. 한 쌍의 연결된 체인 사이에만 연결할 수 있습니다. 표준 브리지를 사용해 다른 블록체인으로 이동할 수는 없습니다. 즉, 현재 Arbitrum 크로스 체인 브리지를 사용해 Arbitrum과 Optimism을 연결할 수 없으며, Polygon PoS 크로스 체인 브리지를 사용해 Polygon과 Avalanche를 연결할 수 없습니다.

유동성 브리지를 사용하여 표준 토큰을 발행

롤업의 기본 브리지에 의존하여 표준 토큰을 표준 토큰을 전송하려면 유동성 부족과 자산 전송 지연 등 여러 가지 문제가 발생할 수 있습니다. 이러한 문제를 해결하기 위해 일부 프로토콜은 유동성 브리지와 함께 작동하여 체인 전체에서 빠른 인출과 짧은 지연 시간을 지원합니다.

이 방식에서는 공인 유동성 브리지가 원본 체인에서 프로토콜의 토큰을 위한 랩퍼 토큰을 발행하고, 이후 프로토콜이 소유한 유동성 풀을 통해 랩퍼 토큰을 대상 체인에서 해당 원본 토큰의 표준 토큰으로 교환하는 방식입니다.

대상 체인의 표준 토큰은 일반적으로 표준 사이드체인/롤업 브리지에서 발행한 토큰의 버전이지만, 예외도 있습니다(자세한 내용은 나중에 설명). 예를 들어, 옵티미즘에서 USDT의 표준 토큰은 옵티미즘 브리지에서 발행한 opUSDT입니다.

각 유동성 브리지는 자동화된 시장 메이커(AMM)가 있는 DEX와 유사하게 작동하며, 서로 다른 유동성 풀에 보관된 자산 쌍 간의 교환을 수행하는 데 사용됩니다. 서로 다른 유동성 풀에 보관된 자산 쌍 간의 교환을 수행합니다. 유동성 공급을 장려하기 위해 AMM 풀은 풀 계약에 고정된 표준 토큰 보유자에게 교환 수수료의 일부를 할당합니다.

유니스왑의 모델과 유사하지만, 주목할 만한 차이점은 자산 쌍이 일반적으로 크로스체인 토큰과 표준 토큰 간에 교환되는 유동성 브리지 쌍이라는 점입니다. 예를 들어, 홉을 통해 USDT를 옵티미즘으로 크로스체인하는 사용자는 huSDT:opUSDT 풀을 통해 옵티미즘에서 hUSDT를 교환해야 합니다.

유동성 브리지를 통한 크로스체인 워크플로우는 다음과 같습니다.

1. 원본 토큰을 소스 체인에 잠그기

2. 대상 체인에서 네이티브 토큰의 크로스체인 토큰 발행

3. AMM 풀을 통해 크로스체인 토큰을 대상 체인에서 표준 토큰으로 변환

4. 표준 토큰 전송

이 과정은 모든 유동성 브리지(Across, Celer, Hop, Stargate 등)에서 비슷하지만 최종 사용자 입장에서는 많은 부분이 복잡하게 얽혀있음에도 불구하고 간단한 거래처럼 느껴질 수 있습니다.

사용자는 소스 체인으로 다시 이동할 때 표준 토큰을 소멸하거나 AMM을 통해 표준 토큰을 크로스 체인 토큰과 교환한 다음 토큰을 소멸하고 소멸 증명 영수증을 제출합니다. 확인이 완료되면 사용자는 처음에 잠긴 오리진 토큰을 출금할 수 있습니다. (이전 작업과 마찬가지로 토큰을 원래 체인으로 다시 이동하는 지루한 세부 사항은 사용자에게 숨겨지며 전적으로 솔버가 관리합니다).

유동성 브리지의 장점은 롤업의 크로스 체인 브리지의 지연 문제를 해결한다는 것입니다. 예를 들어, Hop은 '본더'라는 전문 기관이 L2에서 사용자의 인출 거래의 유효성을 증명하고 롤업의 L1 브리지에서 인출하는 비용을 부담할 수 있도록 허용합니다. 각 본더는 L2 체인의 풀 노드를 운영하며 사용자의 출금 거래가 최종적으로 L1에서 확인될지 여부를 결정할 수 있으므로 사용자가 사기 출금을 시도하여 본더에게 손실을 입힐 위험을 줄일 수 있습니다.

표준 브리지와 달리 유동성 브리지는 사용자가 더 많은 체인 사이를 이동할 수 있게 해줍니다. 예를 들어, 홉은 사용자가 이더로 먼저 인출하지 않고도 아리트럼과 옵티미즘 사이의 체인을 교차할 수 있게 해줍니다. 빠른 L2에서 L1으로의 브리징과 마찬가지로, 빠른 L2에서 L2로의 브리징은 본더가 소스 L2 체인에 대한 전체 노드를 실행하여 인출을 확인한 후 대상 L2 체인에서 사용자의 토큰 발행을 위해 선결제해야 하므로 롤업 간의 구성성을 높이고 사용자 경험을 크게 개선할 수 있습니다.

물론 유동성 브리지에는 몇 가지 단점이 있으며, 이는 L2/L1 체인에서 표준 토큰을 발행하기 위해 체인의 표준 브리지를 사용하는 실용성에 영향을 미칩니다.

유동성 브리지의 단점

슬라피지

슬라피지는 AMM과의 상호작용에서 예상 토큰 수와 실제로 받은 토큰 수 사이의 차이입니다. 받은 토큰 수와 실제 받은 토큰 수의 차이입니다. 크로스 체인 자산의 유동성이 부족하면 슬리피지가 증가할 수 있으며, 풀에 리밸런싱할 유동성이 충분하지 않으면 대규모 거래로 인해 가격이 급변하여 사용자가 더 높은 가격에 스왑 거래를 체결하게 될 수 있습니다. 이론상 차익거래자는 거래 활동을 통해 서로 다른 자산 풀 간의 가격 차이를 보정해야 하지만, 거래 활동이 적거나 가치가 낮은 토큰이 차익거래에 포함되면 이 메커니즘이 방해받을 수 있습니다.

또한, 이는 크로스 체인 앱을 구축하는 개발자에게도 영향을 미칠 수 있는데, 이는 슬리피지가 발생하는 에지 케이스를 고려해야 하므로 사용자가 하나 이상의 대상 체인에서 받은 토큰 수가 적어 크로스 체인 작업을 완료하지 못할 수 있습니다.

이를 방지하기 위해 유동성 브리지가 슬리피지를 발생시키지 않고 대상 체인에서 거래소를 커버하기에 충분한 유동성을 가지고 있는지 알 방법이 없는 크로스 체인 애그리게이터와 같은 앱은 최대 슬리피지 허용 범위를 지정하는 전략을 채택하여 사용자에게 미리 정해진 최대 슬리피지 허용 범위를 제공하는 방법을 채택했습니다. 견적. 이는 트랜잭션 롤백을 방지하지만, 사용자는 브리지 AMM 풀의 유동성에 관계없이 항상 크로스체인 토큰의 일정 비율을 잃게 됩니다.

유동성 제한

유동성 브리지가 직면한 근본적인 문제 중 하나는 대상 체인에 충분한 유동성이 있어야 한다는 것입니다. 기존의 락앤민트(토큰 발행이 고정 자산으로 직접 지원되는 방식)와 달리 유동성 브리지는 AMM 풀에서 사용 가능한 토큰에 의존해 체인 간 전송을 완료합니다. 유동성이 임계값 아래로 떨어지면 전체 크로스 체인 메커니즘이 사실상 작동을 멈출 수 있습니다.

• 유동성이 너무 낮으면 크로스 체인 작업이 완전히 중단되어 사용자가 의도한 전송을 완료하지 못할 수 있습니다.

• 사용자는 풀 유동성 고갈을 피하기 위해 대규모 이체를 소규모 거래로 분할해야 할 수 있습니다.

• 유동성 공급자는 크로스 체인 브리지 기능이 가장 필요한 시장 변동성이 높거나 스트레스가 심한 기간 동안 풀에서 자금을 인출할 수 있습니다.

• 새로운 토큰 쌍을 출시하는 것은 크로스 체인 브리지를 작동시키는 데 필요한 초기 유동성이 많기 때문에 특히 더 어렵습니다.

유동성 요건은 순환적 의존성을 야기합니다. 브리지가 안정적으로 작동하려면 많은 유동성이 필요하지만, 유동성 공급자를 유치하려면 브리지의 지속적인 사용과 수수료 발생을 입증해야 합니다. 이러한 '닭이 먼저냐 달걀이 먼저냐'의 문제는 특히 신규 토큰이나 거래 빈도가 낮은 토큰의 경우 여러 체인에서 충분한 유동성을 유지하는 데 어려움을 겪을 수 있습니다.

불일치하는 인센티브

유동성 브리지는 사용자 입장에서는 크로스 체인 토큰에서 목표 체인의 표준 토큰으로 토큰을 교환하는 데 큰 부담 없이 사용할 수 있다는 점에서 유용하지만, 사용자 입장에서는 브리지와 상호작용하는 데 드는 비용 가스 비용에 따라 유동성 브리지의 가치도 결정됩니다. 따라서 크로스체인 어그리게이터와 토큰을 발행하는 프로젝트 팀은 유동성과 거래 비용을 기준으로 크로스체인 브리지의 우선순위를 정합니다.

이러한 방식은 크로스 체인 프로젝트 토큰이나 크로스 체인 애그리게이터를 사용해 토큰을 체인으로 전송하는 사용자에게 더 나은 사용자 경험을 보장하지만, 유동성을 기준으로 크로스 체인 브리지를 선택하면 LP 인센티브에 지출할 수 없는 크로스 체인 브리지는 불리한 상황에 처하게 됩니다. 또한 거래 수수료만을 기준으로 하면 중앙화된 접근 방식을 사용해 운영 비용을 절감하고 크로스 체인 거래에 더 낮은 수수료를 부과할 수 있는 크로스 체인 브리지에게 유리하게 경쟁이 편향될 수 있습니다. 두 경우 모두, 크로스체인 브리지는 가장 중요한 지표인 보안을 두고 경쟁하지 않습니다.

또한 유동성 브리지는 거래 활동이 적은 롱테일 자산(유동성 공급자를 유치할 가능성이 낮은)에 불리하게 작용합니다. 롱테일 토큰(또는 크로스체인 거래량이 적은 신규 토큰) 발행자는 유동성 브리지를 통해 체인을 가로지르는 오리지널 토큰과 발행자 토큰의 표준 토큰 간의 스왑을 충당하기 위해 AMM 풀을 구축하고 유동성을 공급하거나, 크로스체인 브리지 공급자와 협력하여 LP가 해당 자산에 유동성을 제공할 수 있는 금융 인센티브를 늘려야 합니다.

열악한 크로스체인 사용자 경험

유동성 브리지는 표준 크로스체인 브리지를 개선한 것이지만, 사용자 경험 문제가 없는 것은 아닙니다. 크로스 체인 스왑의 슬리피지 외에도 브릿지가 대상 체인의 표준 토큰으로 거래를 처리하기에 충분한 유동성이 없기 때문에 사용자가 대상 체인에서 크로스 체인 거래를 즉시 완료하지 못할 수 있습니다. 사용자의 토큰 스왑 메시지가 대상 체인에 도달할 때까지 브릿지는 자산 쌍의 유동성을 알 방법이 없으므로 이러한 상황은 대부분 피할 수 없습니다.

이 경우 사용자는 다음과 같은 선택지를 갖게 됩니다. 두 가지 옵션(어느 쪽도 이상적이지 않음):

• 브릿지가 교환을 완료하고 표준 토큰을 인출하기에 충분한 유동성을 확보할 때까지 기다립니다. 이는 크로스 체인 거래가 지연되고 풀 유동성이 단기간에 임의로 변경될 수 있기 때문에 사용자가 처음에 호가된 것과 동일한 수의 토큰을 받을 수 있는지 알 방법이 없기 때문에 이상적이지 않습니다.

• 크로스체인 브리지(예: Hop Bridge의 hUSDT)에서 독점 토큰을 받습니다. 대부분의 앱은 네이티브 토큰의 표준 토큰(예: 옵티미즘 브리지에서 발행한 opUSDT)과 통합하는 것을 선호하고 사용자의 패키지 자산을 받지 않을 수 있으므로 이는 최적이 아닙니다.

타사 크로스체인 브리지를 통해 표준 토큰 발행

멀티체인 DApp은 DApp이 배포된 각 체인에서 해당 DApp의 토큰을 발행하는 단일 크로스체인 브리지를 선택하여 크로스체인 토큰의 상호 호환성 문제를 해결할 수 있습니다. 디앱 토큰의 표준 토큰은 디앱이 배포된 각 체인에서 발행됩니다. 프로젝트 토큰의 표준 브리지 발행과 마찬가지로, 이 접근 방식은 일관된 글로벌 토큰 공급을 보장하기 위해 원격 체인에서 발행된 토큰을 프로젝트의 메인 체인에 배포된 토큰 콘트랙트에 매핑해야 합니다. 크로스 체인 브리지 제공자는 토큰의 발행과 소멸을 추적하고 이러한 작업이 메인 체인의 토큰 공급과 동기화된 상태를 유지해야 합니다.

이를 기반으로 크로스 체인 토큰의 대체 불가능성 문제가 해결되며, 사용자가 승인된 크로스 체인 브리지 제공자를 통해 체인을 건너는 한, 다른 크로스 체인 토큰과 항상 1:1 비율로 교환할 수 있습니다. 또한 이 접근 방식은 표준 브리지 모델의 유동성 기반 크로스 체인 문제를 해결합니다.

• 사용자는 크로스 체인 브리지 제공자가 크로스 체인에 필요한 토큰을 AMM을 통해 표준 토큰으로 변환할 필요가 없으므로 크로스 체인 거래에서 슬리피지 손실이 발생하지 않습니다. 크로스 체인 브리지 제공자가 지원하는 토큰은 각 체인에 있는 토큰의 표준 토큰 버전입니다. 이러한 표준 토큰의 가치는 원래 체인에 공급자가 락인한 토큰의 가치에 연동됩니다.

• 크로스체인 브리지 공급자는 mint() 메시지를 수신하는 즉시 대상 체인에서 랩드 토큰을 발행하기 시작할 수 있으므로 사용자는 체인 간 이동 시 지연을 거의 또는 전혀 경험하지 않습니다.

• 개발자는 AMM 유동성 또는 유동성 공급 인센티브 프로그램을 시작할 필요 없이 멀티체인 토큰 배포 관리를 크로스체인 브리지 제공자에게 아웃소싱할 수 있습니다.

현재 단일 크로스체인 브리지 공급자가 제공하는 토큰의 표준 예시로는 LayerZero의 올체인 유니버설 토큰(OFT), Axelar의 인터체인 토큰 서비스(ITS), Celer의 xAsset, Multichain의 anyAsset 등이 있습니다. 이러한 예시들은 모두 본질적으로 독점 토큰이며 다른 크로스체인 브리지를 통해 전송되는 토큰과 동일하지 않다는 점에 유의할 필요가 있습니다. 공급자는 다른 크로스 체인 브리지를 통해 전송된 동일한 토큰의 크로스 체인 토큰과 호환되지 않으므로, 이 세부 사항은 다음과 같이 크로스 체인 토큰 처리에 대한 이러한 접근 방식의 몇 가지 문제를 강조합니다.

• 공급자 잠금

• 프로토콜 주권 상실

• 브리지 실패 위험이 높음

• 대상 체인에 있음. 토큰 커스터마이징 손실

• 공급자가 지원하는 체인으로 제한

• 필요한 모든 체인에서 동일한 토큰 주소를 유지할 수 없어 사용자 보안이 손상될 수 있음 또는 피싱 공격에 취약할 수 있음

표준 타사 크로스체인 브리지 사용의 단점

공급자 종속

. 왼쪽;">하나 이상의 체인에서 표준 토큰을 생성하기 위해 단일 크로스체인 브리지 공급자를 선택하면 개발자는 공급자 종속의 위험에 노출될 수 있습니다. 각 크로스체인 브리지 제공자는 자사 인프라(및 통합 생태계 프로젝트)와만 호환되는 독점 토큰을 생성하므로, 단일 크로스체인 브리지 제공자는 향후 다른 크로스체인 브리지로 마음대로 전환할 수 없이 토큰 발행자를 특정 크로스체인 브리지 서비스에 효과적으로 묶어두게 됩니다.

크로스체인 브리지 공급자를 변경할 수는 있지만, 비용이 많이 들기 때문에 대부분의 프로젝트는 이 방법을 선택하지 않습니다.

예를 들어 한 개발자(Bob이라고 부릅니다)가 이더에서 토큰(BobToken)을 발행하고 옵티미즘, 아비트럼, 베이스에서 표준 버전의 BobToken을 발행하기 위해 레이어제로 OFT를 선택한다고 가정해 봅시다. 밥토큰의 고정 공급량은 1,000,000개이며, 레이어제로를 통해 발행된 크로스체인 토큰은 유통되는 밥토큰 총 공급량의 50%를 차지합니다.

처음에는 Bob이 Axelar와 같은 경쟁 크로스체인 서비스를 통해 BobToken을 연결하기로 결정하기 전까지 사업이 순조로웠지만, Bob은 단순히 "Optimism, Base, Arbitrum에서 BobToken을 발행하기 위해 Axelar ITS로 전환할 것입니다. 아비트럼"이라고 말할 수 없습니다. OFT 토큰과 ITS 토큰의 비호환성으로 인해 밥은 두 개의 밥 토큰을 상호 교환할 수 없기 때문에 신규 사용자와 기존 사용자 모두에게 문제를 일으킬 수 있습니다(앞서 설명한 문제를 여기서 다시 소개합니다). 동시에 레이어제로 버전의 밥토큰과 통합된 애플리케이션은 액셀라 버전의 밥토큰을 대체로 받아들이지 못할 수 있으며, 경쟁하는 밥토큰 토큰이 공존하는 L2 체인에서 유동성 파편화로 이어질 수 있습니다.

그렇다면 밥이 전환을 해야 한다면 어떻게 해야 할까요?

먼저, 밥은 사용자가 레이어제로를 통해 발행된 밥토큰 랩드 토큰의 잠금을 해제하는 트랜잭션을 보내도록 설득해야 하며, 이는 체인 전반의 OFT 토큰을 소멸시키고 이더에서 밥토큰을 잠금 해제할 수 있습니다. 그런 다음 사용자는 이더에서 Axelar를 사용하여 토큰을 잠그고 대상 체인에서 밥토큰(이더의 토큰 컨트랙트 공급에 매핑된) 형태의 새로운 표준 토큰을 받을 수 있습니다. 이 프로세스는 DAO 프로젝트 관리 팀에게 비용이 많이 들고 상당한 조정 및 운영 오버헤드가 발생하므로 초기 공급자를 고수하는 것이 가장 안전한 옵션인 경우가 많습니다.

반면, 크로스체인 브리지 공급자가 계약 조건을 준수하지 않거나, 기능 세트가 제한적이거나, 광범위한 생태계 통합이 부족하거나, 사용자 경험이 좋지 않은 경우 공급자 종속으로 인해 개발자가 전환할 수 없으므로 밥과 같은 개발자는 곤경에 처할 수 있습니다. 한편, 크로스체인 브리지 제공자는 크로스체인 밥토큰의 사용자 비율을 제한하거나 크로스체인 수수료를 인상하거나 명확한 근거 없이 크로스체인 운영을 검열하는 등 자의적인 행위를 할 수도 있습니다.

프로토콜 주권 상실

위에서 공급자 종속에 대해 설명한 부분은 표준 제3자 크로스체인 브리지 사용의 또 다른 문제점으로 토큰 발행자가 편의성과 사용자 경험 개선을 위해 표준 크로스체인 토큰의 통제권을 희생했다는 점을 강조합니다. 표준 크로스체인 토큰에 대한 통제권을 포기했습니다. 예를 들어 이더리움의 밥토큰은 기본 ERC-20 토큰 컨트랙트를 제어하기 때문에 밥이 전적으로 통제하지만 옵티미즘, 아비트럼, 베이스의 밥토큰은 해당 블록체인에서 밥토큰 표준 토큰을 발행하는 OFT 컨트랙트를 보유한 레이어제로가 통제합니다.

밥은 레이어제로가 표준 토큰을 네이티브 토큰의 원래 설계와 일치시킬 것으로 기대했을지 모르지만, 항상 그런 것은 아니었습니다. 최악의 경우, 크로스체인 브리지 제공자가 매우 다른 버전의 토큰 컨트랙트를 구현하기 때문에 이더리움에서 밥토큰의 동작이 옵티미즘에서 밥토큰의 동작과 매우 다를 수 있으며, 이는 프로토콜 개발자와 크로스체인 브리지 제공자의 목표와 이해관계가 달라 프로토콜 사용자에게도 문제가 발생할 수 있습니다. 제공자의 목표와 이해관계가 다를 수 있기 때문입니다.

크로스체인 브리지 실패 위험 높음

첫 번째 솔루션에서는 토큰이 각 체인의 표준 브리지를 통해 체인을 건너며, 토큰 발행자는 하나의 크로스체인 브리지에 영향을 미치는 취약성에 노출되어도 해당 브리지로만 제한됩니다. 예를 들어 해커가 유동성 브리지를 손상시켜 담보를 예치하지 않고 패키지 토큰을 무제한으로 채굴한다고 가정해 보겠습니다. 이 경우 유동성 풀에서 패키지 자산의 최대 가용 유동성만 추출할 수 있습니다(예: 옵티미즘에서 cUSDT를 발행 → 표준 opUSDT로 교환 → 빠른 크로스체인을 통해 이더로 opUSDT를 추출 → 이더에서 네이티브 USDT로 교환).

그리고 타사 크로스체인 브리지 모델에서 파트너의 크로스체인 브리지에 영향을 미치는 취약점으로 인한 위험은 토큰 발행자의 경우 영향을 받는 브리지가 배포한 원격 체인에서 공격자가 발행한 총 토큰 수와 동일합니다. 이는 다음 예시와 같이 체인 중 하나의 표준 토큰을 다른 체인에서 발행된 표준 토큰과 1:1로 교환할 수 있기 때문에 전적으로 가능합니다.

공격자가 체인 B의 제3자 크로스 체인 브리지를 손상시키고 담보 없이 토큰 1,000개(처음에 체인 A에서 발행한 토큰)를 발행한다고 가정해 보겠습니다. (토큰은 원래 체인 A에서 발행된 토큰입니다). 체인 B에 있는 공격자의 토큰은 메인체인 컨트랙트에 매핑되지 않으므로 체인 A에서 인출할 수 없습니다. 체인 B에 있는 공격자의 토큰은 메인체인 컨트랙트에 매핑되지 않습니다. 그러나 체인 C로 교차 체인화하여 체인 B 토큰 1000개를 체인 C 토큰 1000개로 교환할 수 있습니다. 이러한 표준 교차 체인 토큰은 동일한 교차 체인 브리지 서비스에서 제공되므로 모두 호환되고 상호 교환이 가능하다는 점을 기억하세요. 체인 C 토큰은 체인 A(토큰의 홈 체인)에서 토큰을 잠근 사용자가 합법적으로 발행했기 때문에 메인 체인 컨트랙트에 매핑되며, 공격자는 체인 C의 토큰을 파괴하고 체인 A의 기본 토큰을 추출할 수 있으며, 마지막으로 공격자는 CEX를 통해 토큰을 거래하여 공격을 완료할 수 있습니다.

타깃 체인에서 토큰 사용자 지정하기 기능 손실

타사 크로스체인 브리지를 사용할 때 토큰 발행자는 일반적으로 투표 프록시(ZK), 리베이싱 메커니즘(stETH, USDM), 전송 수수료 기능, 블랙리스트 및 화이트리스트 기능( USDT, USDC), 일시 중지 가능한 전송, 특별 발행 규칙 또는 권한 등. 이러한 일반적인 토큰 기능은 크로스체인 브리지 제공자가 표준화된 ERC-20 구현 계약을 사용하는 경향이 있기 때문에 원래 토큰 구현에 존재했던 특수 기능을 지원하지 않을 수 있기 때문에 제거되는 경우가 많습니다.

이러한 기능이 없으면 체인 간 토큰 운영이 일관되지 않을 수 있으며, 이는 특정 사용자 지정 기능에 의존하는 통합 애플리케이션에 피해를 줄 수 있습니다. 크로스 체인 토큰을 표준화하려는 움직임은 크로스 체인 브리지 제공자의 입장에서는 운영을 단순화하는 것처럼 보일 수 있지만, 실제로는 토큰의 원래 기능을 약화시키고 발행자가 애플리케이션이 다루는 전체 멀티 체인 생태계에서 토큰의 동작에 일관성을 유지하지 못할 수 있습니다.

지원되는 체인 제한

토큰 발행자는 선택한 크로스체인 브리지 제공자의 네트워크 범위와 확장 계획에 따라 달라집니다. 크로스체인 브리지 공급자가 토큰 발행자가 확장하고자 하는 특정 블록체인 네트워크를 지원하지 않는 경우, 토큰 발행자는 두 가지 덜 이상적인 옵션에 직면하게 됩니다.

• 크로스체인 브리지 공급자가 원하는 체인에 대한 지원을 추가할 때까지 기다립니다. 시간이 오래 걸리고 높은 통합 비용으로 인해 발생하지 않을 수도 있습니다(예: ZKsync 시대의 EVM 불평등으로 인해 많은 디앱이 해당 체인에 배포되지 않음);

• 특정 체인에 다른 크로스체인 브리지 공급자를 사용하지만 이는 상호 교환 불가능한 토큰과 유동성 조각화를 다시 도입하게 됩니다. 대체 가능한 토큰과 유동성 조각화.

이러한 제한은 프로토콜의 성장 전략과 신흥 체인에서 새로운 사용자를 유치하는 능력에 심각한 영향을 미칠 수 있습니다. 크로스체인 브리지 제공자는 토큰 발행자에게 전략적으로 중요할 수 있는 소규모 또는 신생 네트워크를 희생시키면서 인기 있는 체인에 대한 지원을 우선시할 수 있다는 점에 유의해야 합니다.

일관되지 않는 크로스체인 토큰 주소

기술 스택의 특성(예: CREATE2 미지원)으로 인해 타사 크로스체인 브리지 제공자는 각 체인에서 다른 주소를 사용해 크로스체인 토큰을 배포할 수 있으며, 주소 일관성이 부족해 여러 문제가 발생하고 있습니다. 주소 일관성의 부족은 여러 가지 사용자 경험 문제로 이어집니다.

• 보안 위험: 사용자는 각 체인의 토큰에 대해 다른 주소를 검증해야 하므로 사기성 토큰과 상호작용할 위험이 증가합니다.

• 통합 복잡성: 개발자는 각 네트워크에 대해 유효한 토큰 주소 목록을 유지해야 합니다.

• 피싱 위험 증가: 확인할 일관된 주소가 없기 때문에 악의적인 공격자가 가짜 토큰을 사용하여 사용자를 더 쉽게 속일 수 있습니다.

토큰 발행자 브리지를 통한 표준 토큰 발행

위에서 언급한 솔루션 외에도 개발자가 프로젝트 토큰의 크로스체인 배포를 최대한 통제하고자 하는 경우, 토큰의 표준 토큰을 원격 체인에서 관리할 수 있습니다. 원격 체인에서 표준 토큰 버전의 토큰 발행을 관리할 수 있으며, 각 크로스 체인 토큰 버전의 가치는 소스 체인에서 토큰의 원래 버전을 발행하는 프로토콜에 의해 잠긴 토큰의 가치와 밀접하게 연결되어 있기 때문에 '신뢰할 수 있는 토큰 발행자'로 설명됩니다.

이 접근 방식이 작동하려면 토큰 발행자는 표준 매핑을 통해 글로벌 공급이 동기화되도록 보장하면서 크로스 체인 토큰의 발행과 소멸을 관리할 수 있는 인프라를 갖추고 있어야 합니다.

토큰 제작자가 발행한 (네이티브 토큰) 표준 토큰의 유명한 예로는 메이커다오의 텔레포트와 서클의 크로스체인 전송 프로토콜(CCTP)이 있습니다. 텔레포트를 사용하면 표준 DAI 토큰을 이더와 다양한 이더 사이에서 이동할 수 있습니다. 텔레포트를 통해 사용자는 이더와 다양한 이더 롤업 간에 표준 다이를 이동할 수 있습니다. 한 체인에서 다이를 소멸하고 동시에 대상 체인에서 다이를 발행할 수 있습니다. cCTP는 비슷한 기능을 하며 소멸 및 발행 메커니즘을 통해 기본 USDC(서클에서 발행)의 교차 체인 전송을 가능하게 합니다. 두 경우 모두 발행자가 표준 토큰의 발행과 소멸을 통제합니다.

이 접근 방식은 프로토콜에 크로스 체인 토큰에 대한 완전한 제어권을 제공합니다. 이는 가능한 가장 효율적인 방법으로 동일한 토큰의 대체 불가능 문제를 해결합니다. 토큰의 표준 버전(발행자가 대상 체인에서 발행)이 하나만 존재하므로 사용자는 토큰 발행자가 지원하는 각 생태계에서 토큰을 사용할 때 동일한 경험을 할 수 있습니다.

이 접근 방식을 사용하면 앱은 동일한 생태계에서 비공식적인 크로스체인 토큰으로 인한 유동성 파편화를 제거할 수도 있습니다. 또한 개발자는 표준 토큰 발행자 브리지를 통해 체인 간 자본을 효율적이고 원활하며 안전하게 토큰 전송할 수 있으므로 더욱 강력한 크로스체인 앱(예: 크로스체인 거래소 및 크로스체인 대출)을 구축할 수 있습니다.

물론 이러한 유형의 솔루션에는 몇 가지 단점이 있으며, 이 모델은 체인 간에 표준 토큰을 배포하기에 충분한 자본과 크로스 체인 발행 및 소멸을 수행하는 데 필요한 인프라(전구체, 가디언 등)를 유지하는 데 드는 오버헤드가 있는 프로젝트에만 적용할 수 있습니다. 동시에 크로스 체인 자산의 보안을 프로토콜의 보안 모델과 긴밀하게 결합하는 덜 바람직한 효과도 있습니다.

객관적으로 이러한 관계(프로토콜 토큰의 크로스체인 버전과 프로토콜 보안 사이)는 우호적인데, 표준 토큰 버전을 지원하는 네이티브 토큰의 보안은 이미 프로토콜의 보안에 의존하기 때문에 사용자와 외부 개발자는 새로운 신뢰 가정을 하지 않아도 되기 때문입니다. 이는 특히 Circle이나 Maker(현 Sky)와 같은 발행자가 운영하는 스테이블코인 브릿지에 적용됩니다. 사용자는 스테이블코인 발행자가 법정화폐를 스테이블코인으로 교환하는 비용을 충당하기에 충분한 자산을 보유하고 있다고 이미 신뢰하기 때문에 스테이블코인 브릿지의 보안을 신뢰하는 것은 어렵지 않습니다.

결론

크로스체인 자산 대체 가능성은 의심할 여지 없이 롤업의 상호운용성에서 중요한 부분이며, 체인 간 자산 전송의 사용자 경험에 영향을 미칩니다. 동시에, 특정 사용 사례가 이 기능에 의존하기 때문에 토큰이 여러 체인에서 원격 체인으로 대체 가능한 상태를 유지하는 능력은 개발자 행동에도 영향을 미칠 수 있습니다.

대체 불가능한 크로스체인 토큰 문제를 해결하기 위해 업계에서는 네이티브(구현된) 브리지를 통한 표준 토큰 발행, 전용 타사 브리지를 사용해 여러 체인에서 표준 토큰 발행, 프로토콜 소유 브리지를 사용해 토큰 이동을 촉진하고 대체 가능성을 유지하는 등 다양한 솔루션을 제시해왔습니다.

이러한 접근 방식은 많은 특정 문제를 해결하지만, 모든 문제를 해결하지는 못하며, 크로스체인 자산 대체 가능성을 달성하기 위해서는 다소 이상적인 트레이드오프가 필요합니다. 그렇다면 더 나은 방법을 찾을 수 있을까요? 답은 '그렇다'입니다.

우리는 ERC-7281이 프로토콜이 보안, 주권 또는 사용자 경험을 희생하지 않고도 여러 체인에 걸쳐 표준 토큰을 효율적으로 배포할 수 있는 새로운 크로스체인 자산 대체 솔루션이라고 믿습니다.

ERC-7281의 독특한 설계는 여러 개의 (화이트리스트에 등록된) 크로스체인 브리지가 지원되는 각 체인에서 프로토콜 토큰의 표준 버전을 발행하는 동시에 프로토콜 개발자가 크로스체인 브리지별로 발행 제한을 동적으로 조정할 수 있도록 합니다. 이 기능은 유동성 파편화, 인센티브 조정, 사용자 경험 문제, 크로스 체인 브리지 보안, 크로스 체인 토큰의 사용자 지정 가능성 등 과거 멀티 체인 표준 토큰 제안과 관련된 많은 문제를 해결합니다.

따라서 크로스체인 자산 상호교환성 보고서의 다음 섹션에서는 ERC-7281(xERC-20이라고도 함)을 자세히 살펴보고, 다른 멀티체인 표준 토큰 설계와 비교하여 멀티체인 표준 토큰에 대한 xERC-20의 접근 방식을 분석하고, xERC-20 토큰 표준을 다른 멀티체인 표준 토큰 디자인과 비교하고 xERC-20 토큰 표준이 개발자와 사용자에게 어떻게 도움이 될 수 있는지에 대한 인사이트를 제공합니다.

Continued.