Stable블록체인은 국가다. 블록체인에서 컨센서스 알고리즘은 현실세계의 물리법칙이며, 밸리데이터는 국회의원이고,디앱은 기업이며, 네이티브 토큰은 기축 통화이다. 그렇다면 블록체인의 GDP는 어떻게 계산할 수 있을까? MV=PQ의 관점으로보면 블록체인의 GDP가 성장하기 위해선 TVL과 화폐유통속도가 커야한다.
이러한측면에서 USDT는 블록체인의 GDP 성장을 위한 핵심 동력이다. 통화량 관점에서 BTC, ETH 다음으로 세 번째로 높은 시가총액을 가지고 있으며, 화폐유통속도도 계산해보면 약 100이라는 어마어마한 수치가 나온다. 하지만 아직 USDT에 특화된 블록체인은 없으며, 대부분 느리고 비싼 이더리움, 트론에서 활용되고 있다.
스테이블은 USDT를 위한 네트워크이다. 스테이블은 이를 위해 1) USDT에 특화된 기능들과 2) 블록체인 코어 최적화를 통한 높은 확장성을 제공한다.
스테이블은 EIP-7702와 ERC-4337의 지원을 통해, 사용자들이 USDT만 보유하고 있어도 네트워크의 모든 활동을 할 수 있도록 하고, USDT 전송의 경우 무료로 가능하게 한다. 이뿐만 아니라, 스테이블은 보장된 블록공간(Guaranteed Blockspace), USDT 전송 애그리게이터(USDT Transfer Aggregator), 기밀 전송(Confidential Transfer) 등과 같은 USDT 특화 기능을 제공하여, 기업 사용자도 쉽게 스테이블코인을 활용할 수 있도록 한다.
확장성 측면에서 스테이블은 RPC부터 컨센서스, 실행, DB까지 전반적인 최적화를 도입한다. 초기에는 CometBFT 기반에 EVM 실행 레이어를 사용하지만, 추후에는 Autobahn이라는 DAG기반 BFT, Stable RPC, StableVM++, Stable DB 등 전방위적인 업그레이드를 도입하여 네트워크의 확장성을 극대화하고자 한다.
스테이블은 USDT0을 통해 기존의 거대한 USDT 유동성을 쉽게 끌어 모을 수 있으며, EVM과 100% 호환가능하기 때문에 USDT를 위한 다양한 디파이 생태계가 구축될 수 있고, USDT0 전송 수수료 무료로 인해 굉장히 빠른 속도로 USDT가 거래될 것이다. 이러한 모든 특성들을 고려해보았을 때 스테이블은 MV=PQ 관점에서 막대한 규모의 온체인 GDP를 가질 잠재력이 있으며, USDT를 위한 초거대 디지털 국가로 자리매김할 수 있을 것이다.
트럼프 행정 출범 이후로 블록체인과 암호화폐에 대한 관심도가 매우 뜨겁다. 스트래티지(Strategy)를 비롯하여 전 세계에 걸친 상장/비상장 기업들이 사내보유금 중 일부를 비트코인 혹은 비트코인 ETF로 보유하기 시작했고, 이더리움/솔라나를 매수하여 모으는 기업들도 등장하고 있으며, 주요 금융기관들은 블록체인을 기반으로한 다양한 RWA 상품들을 출시하고 있다.
이렇듯 블록체인 기술 및 암호화폐가 점점 전통금융권에 편입되면서 달라진 것은 블록체인 네트워크를 바라보는 다양한 관점이 생겼다는 것이다. 특히, 전통금융권에서 암호화폐를 바라볼 때 이를 주식과 비슷하게 취급하며, 전통 가치 평가 모델을 대입하는 경우가 많다. 물론, 디앱에는 이러한 멘탈 모델이 적용될 수 있다. 다만 나는 블록체인을 기업이 아닌 국가로 바라보아야한다고 말하고 싶다.
블록체인은 누구나 무신뢰(trustless) 환경에서 퍼미션리스(permissionless)하게 다양한 활동을 할 수 있는 국가이다. 블록체인에서 컨센서스 알고리즘은 현실세계의 물리법칙이며, 밸리데이터는 국회의원이고,디앱은 기업이며, 네이티브 토큰은 기축 통화이다.
Source: Fidelity
블록체인이 기업이 아니라 국가라면, GDP의 개념을 적용해볼 수 있지 않을까? 이미 피델리티(Fidelity)와 뱅크리스(Bankless)에서도 이러한 개념을 한 번 소개한적이 있다. GDP의 정의는 일정 기간 동안 한 국가 내에서 생산된 모든 최종 재화와 서비스의 시장 가치 총합으로, 여러 가지 계산법이 있다. 이 중 가장 대표적인 지출 기반의 계산 법은 아래와 같다:
GDP = C + I + G + (X-M)
여기서 C는 민간 소비(Consumption), I는 기업 투자(Investment), G는 정부 지출(Government), (X-M)은 순수출(Net Exports)를 의미한다. 누군가의 생산은 누군가의 지출이기 때문에, 민간, 기업, 정부의 지출과 순수출을 합한 수치는 곧 GDP인 것이다. 피델리티는 보고서에서 블록체인에서의 C, I, G, X-M를 위의 표와 같이 정의하기도 했다.
하지만 GDP를 표현하는 방법에는 위와 같은 지출 접근 이외에도 다양한 것이 존재하는데, 화폐와 총지출 간의 관계를 나타내는 회계적 항등식인 “MV=PQ”, 즉 교환 방정식이 존재한다. 여기서 M은 통화량, V는 화폐유통속도, P는 가격 수준, Q는 실질 산출량으로 P*Q는 명목 GDP를 의미한다. 즉, 이 식에 의하면 통화량과 화폐 유통속도가 커질수록 GDP는 상승할 수 있는 것이다.
MV=PQ를 블록체인에 적용하면, 블록체인이라는 디지털 국가의 GDP가 성장하기 위해선 통화량, 즉 블록체인의 TVL이 커져야하고, 화폐유통속도, 즉 블록체인 내에서 자산들이 얼마나 빨리 순환하는지가 높아야한다.
Source: Token Terminal
블록체인을 국가로 보았을 때, USDT는 GDP 성장의 핵심이다:
통화량(M) 관점: USDT는 암호화폐에서 BTC, ETH 다음으로 세 번째로 가장 큰 시가총액 가지고 있으며, 이 규모는 무려 ~$160B이다. 이더리움 네트워크의 디파이 프로토콜에 예치된 총 TVL이 ~$65B 정도 되는데, 이더리움 네트워크에 올라가 있는 USDT의 규모만 ~$74B이다. 트론의 경우 네트워크 내에 존재하는 자산들의 총 TVL이 ~$86B인데, 이 중 ~$80B가 USDT일 정도로, USDT는 사실상 블록체인 생태계에서의 기축 통화로 작용하고 있다.
화폐유통속도(V) 관점: 다른 암호화폐와 달리, 스테이블코인은 애초에 높은 활용도를 위해 가치를 법정화폐에 고정되도록 설계한 자산이다. 통계에 따르면 USDT는 전세계 443M 사용자들을 보유하고 있으며, 일평균 ~$46B의 규모를 갖는 ~21M 건의 전송이 이루어진다. 이를 기반으로 USDT의 V를 계산해보면 ~100이라는 어마어마한 수치가 나온다. 참고로 미국 M1 통화량의 V 값이 약 1.2-1.6 정도이다.
Scene from “No Country For Old Men”
Source: rwa.xyz
MV=PQ 관점에서 USDT는 1등 시민이다. 하지만 USDT를 위한 블록체인 국가는 그 어디에도 없다. USDT는 현재 대부분 트론 네트워크($78B) 및 이더리움 네트워크($71B)에 존재하며, 그 외로는 솔라나($1.9B), 아비트럼($1.3B), 아발란체($1.1B)에 조금씩 존재한다. 하지만 트론 네트워크와 이더리움 네트워크는 USDT에 적합한 네트워크가 아니다.
Source: Token Terminal
트론 네트워크는 초기에 바이낸스에서 USDT 입출금 네트워크로 사용되며 매우 빠른 속도로 USDT 채택이 성장했다. 재미있는 것은 현재 트론 네트워크에서 발생하는 트랜잭션 중 99.3%가 USDT 트랜잭션이며, 사용되는 가스 중 98.7%가 USDT 트랜잭션으로부터 나온다. 사실상 현재 트론 네트워크가 USDT 체인이라고 해도 과언이 아닌 것이다.
Source: Token Terminal
더 재미있는 것은 지난 1년동안 가장 많은 트랜잭션 수수료를 발생시킨 네트워크는 이더리움, 솔라나, 비트코인도 아닌 트론으로, 무려 $3.2B의 트랜잭션 수수료를 발생시켰다. 이 중 ~99%가 USDT 트랜잭션 수수료부터 유래한 것이다. 이는 반대로 생각했을 때 USDT 발행사는 테더이나, 전송과 관련된 막대한 규모의 수수료는 트론 생태계에서 전부 가져가고 있는 것이다.
물론, 트론은 이더리움 네트워크에 비해 높은 확장성을 가지고 있어 USDT 전송에 이점이 있다. 그럼에도 불구하고 트론 네트워크는 트랜잭션당 수수료가 약 ~$0.2 정도로 높은편이며, 디파이 TVL도 ~$5B 정도밖에 되지 않아 생태계가 활성화되어있지 않다. 즉, 트론은 단지 초기에 거래소와의 협업을 통한 입출금 네트워크 지원으로부터 시작된 관성으로 인해 USDT 전송에 많이 활용되고 있을 뿐, USDT 활용에 적합한 네트워크라고 할 수 없다.
Source: USDT
스테이블코인은 막을 수 없는 흐름이다. 미국의 GENIUS Act를 필두로 전세계의 스테이블코인 산업은 전례없는 속도로 성장할 것이며, 이는 USDT도 예외는 아니다. 만약 USDT의 성장속도가 지금과 비슷하다면 2030년 경 USDT의 시가총액은 약 $350B-$400B로 예상된다.
USDT는 블록체인 생태계에서 1등 시민이다. 블록체인 산업은 USDT를 위해 더 나은 환경을 가진 블록체인 네트워크를 필요로 할 때가 되었다. 만약 USDT 활용에 특화된 블록체인이 나타난다면, 탄탄한 USDT의 네트워크 효과를 기반으로하여 차세대 메가 디지털 국가로 군림할 수 있을 것이다.
Source: Stable
기존 블록체인 네트워크들 위에서 스테이블코인을 사용할 때에는 여러가지 불편한점들이 있었다. 사용자들은 스테이블코인과 관련된 거래를 하는데, 수수료 지불을 위해 가격 변동성이 있는 다른 토큰을 보유하고 있어야하며, 수수료 예측이 어렵고, 네트워크 위의 활동으로 인한 수수료 변동성이 크다는 점 등 다양한 단점이 있었다.
당신이 USDT를 쉽게 사용할 수 있는 블록체인들을 설계한다고 가정해보자. 어떠한 기능들을 추가할 수 있을까?
첫 번째로 당연히 높은 확장성이다. 위에서 살펴보았듯이 USDT의 화폐유통속도는 매우 높다. 즉, 굉장히 트랜잭션이 자주 일어난다는 것이다. 수 많은 트랜잭션들을 원활히 처리하기 위해서 네트워크의 높은 확장성은 필수이다.
두 번째는 USDT로만 네트워크를 안정적으로 사용할 수 있어야 된다. 사용자들은 USDT만 보유하고 있어도 네트워크에서 모든 활동을 할 수 있어야 하며, 기업의 경우 수수료를 예측할 수 있어야 블록체인을 송금/결제의 기반으로 안정적으로 사용할 수 있다.
세 번째는 낮은 수수료이다. 스테이블코인 특성상 굉장히 빈번한 송금/결제 활동이 이루어진다. 따라서, 사용자들이 USDT를 편하게 사용할 수 있도록 매우 낮은 수수료를 취하거나, 혹은 아예 수수료를 부과하지 않을 수도 있다.
스테이블은 정확히 이러한 목적의식을 가지고 탄생한 네트워크이다. 스테이블은 스테이블코인(특히 USDT)의 송금/결제에 특화된 L1 네트워크이다. 스테이블은 블록체인 코어 최적화를 통한 높은 확장성과, USDT에 특화된 다양한 기능들을 제공하며 누구나 USDT를 비롯한 스테이블코인을 송금/결제/디파이 등 다양한 활동에 쉽게 활용할 수 있도록 한다.
Source: Stable
스테이블은 비지니스적으로도 USDT를 위한 최적의 환경을 가지고 있다. 테더의 CEO인 파올로(Paolo)뿐만 아니라, 파올로가 CTO로 있는 비트피넥스(Bitfinex) 및 USDT의 크로스체인 인프라를 담당하는 USDT0도 스테이블에 투자를 진행했다. 이러한 사실은 스테이블이 USDT를 위한 블록체인이라는 것에 정당성을 부여하고, 추후 스테이블이 비지니스를 원활하게 전개할 수 있도록 할 것이다.
스테이블은 USDT를 위한 네트워크이며, 아래와 같은 기능들을 제공한다:
USDT 가스 토큰 (USDT as Gas Token)
USDT0 전송 무료 (Gas-free USDT0 Transfer)
보장된 블록공간 (Guaranteed Blockspace)
USDT 전송 애그리게이터 (USDT Transfer Aggregator)
기밀 전송 (Confidential Transfer)
Source: Stable
사용자는 스테이블에서 USDT를 기반으로 다양한 활동을 심리스하게 할 수 있다. 스테이블은 기본적으로 EIP-7702와 계정추상화를 도입하여 사용자가 USDT0만 보유하고 있어도 네트워크 위에서 모든 활동을 할 수 있도록 지원한다. 하지만 뒷단의 작동과정을 살펴보면 구체적으로 스테이블 생태계에는 두 종류의 USDT가 존재한다. 하나는 트랜잭션 수수료로 사용되는 gasUSDT이며, 다른 하나는 생태계 내에서 송금/결제/디파이 등에 사용되는 USDT0이다.
4.1.1 USDT0
USDT0은 레이어제로의 OFT (Omnichain Fungible Token) 표준을 기반으로하는 토큰으로, USDT가 유동성 파편화 문제 없이 다른 생태계에서 심리스하게 사용될 수 있도록 한다. 기존에 USDT0이 없었을 때에, USDT는 다양한 종류의 써드파티 브릿지를 통해 다른 생태계로 브릿징되며 유동성 파편화 문제를 야기했다. 이를테면, 이더리움에서 아비트럼으로 USDT를 브릿징한다고 할 때, 1) 공식 롤업 브릿지를 통해, 2) 써드 파티 브릿지를 통해 브릿징할 수 있으며, 이렇게 브릿징된 USDT는 서로 호환이 되지 않아 유동성이 파편화되는 문제가 발생했었다.
USDT0은 소각-발행 메커니즘을 통해 이러한 문제를 해결한다. USDT0은 USDT 네이티브 발행 지원이 되지 않는 네트워크로의 브릿징을 아래와 같은 메커니즘을 통해 중개한다:
자산 잠금: 이더리움 네트워크에서 다른 네트워크(A)로 USDT를 전송한다면, 이더리움 네트워크 위의 스마트 컨트랙트에 USDT를 잠금한다.
USDT0 발행: 이더리움 네트워크에서 USDT 잠금이 검증되면 동일한 양의 USDT0이 목적지 체인(A)에서 발행된다.
심리스 USDT0 크로스체인 전송: 체인 A에서 다른 체인 B로 USDT0을 전송하고 싶다면, 체인 A에서 USDT0 잠금이 일어나고 체인 B에서 발행이되는 방식이 아닌, 체인 A에서의 USDT0이 소각되고, 체인 B에서 동일한 양의 USDT0이 발행된다. 여기서 체인 B위의 USDT0은 여전히 이더리움 네트워크 위의 스마트 컨트랙트에 잠금된 USDT와 동일한 가치를 갖는다.
상환: USDT0을 다시 USDT로 상환하고 싶다면 사용자가 보유하고 있는 USDT0이 소각되고, 이더리움 네트워크에서 동일한 양의 USDT를 받아갈 수 있다.
Source: Dune(@sealaunch_team)
USDT0을 사용하면 USDT 네이티브 발행 지원을 하지 않는 네트워크에서도, 유동성 파편화 문제 없이 네이티브 USDT와 거의 유사한 사용자 환경을 제공할 수 있기 때문에, 아비트럼, 베라체인, 유니체인, 옵티미즘 등 다양한 네트워크에서 USDT0을 채택하였고, USDT0의 발행량 규모는 총 ~$1.3B에 육박한다.
스테이블도 USDT0를 채택하여, 사용자들이 네트워크 내에서 USDT와 관련된 유동성 파편화 없이 USDT를 사용할 수 있게 한다. 또한, USDT0을 채택함으로써, 기존에 존재하는 거대한 USDT의 유동성에 쉽게 접근할 수 있기에, 이는 스테이블 생태계가 빠르게 성장하는 촉매역할을 할 수 있을 것으로 기대된다.
4.1.2 gasUSDT
gasUSDT는 스테이블에서 트랜잭션 수수료로 사용되는 토큰이다. 사용자는 USDT0 이외의 토큰을 전송하거나, 디파이와 같은 스마트 컨트랙트와 상호작용할 때 gasUSDT를 수수료로 지불한다. gasUSDT는 USDT0와 동일한 가치를 갖는다.
기본적으로 사용자는 gasUSDT와 상호작용할 필요가 없다. 스테이블은 EIP-7702와 계정추상화를 지원하기 때문에, 사용자는 USDT0만 보유하고 있으면 네트워크의 모든 트랜잭션을 수행할 수 있기 때문이다. 다만 굳이 없고 싶다면, 스테이블 생태계에서 gasUSDT는 어떻게 얻을 수 있을까?
첫 번째는 무료 언랩(unwrap) 기능이다. USDT0을 gasUSDT로 언랩하는 것은 계정추상화를 통해 무료로 제공되기 때문에, 사용자들은 스테이블로 USDT0을 브릿징 한 이후에 쉽게 gasUSDT를 얻을 수 있다. 두 번째는 레이어제로 브릿징 과정에서 가스 전환(gas conversion) 기능을 활용하는 것이다. 레이어제로는 브릿징할 때 목적지 체인에서 가스 토큰을 소량 받을 수 있도록 자동 전환해주는 기능을 지원하는데, 이를 통해 사용자는 USDT나 USDT0을 브릿징하면서 동시에 gasUSDT를 소량 얻을 수 있다.
참고로 USDT0은 메커니즘 상 USDT와 거의 동일하게 취급할 수 있기에, 이더리움, 솔라나 등과 같이 USDT 네이티브 발행이 지원되는 네트워크들뿐만 아니라, 바이낸스, 바이빗 등의 거래소 USDT와도 입출금 호환이 가능하다. 하지만, gasUSDT의 경우 스테이블에서만 사용되는 가스 토큰이기에 사용자들이 이를 혼동하여 다른 네트워크나 거래소로 오입금할 가능성이 있기에, gasUSDT의 전송은 제한되어있다. 그럼에도 불구하고 사용자들은 USDT0만 있어도 무료로 언랩(unwrap)이 가능하기에 쉽게 gasUSDT를 얻을 수 있다.
스테이블은 EIP-7702와 계정추상화(Account Abstraction)을 제공하여, 사용자들이 USDT0만 보유하고 있고, gasUSDT를 보유하고 있지 않아도 생태계 내 에서 모든 활동을 할 수 있도록 지원한다. 특히 사용자의 트랜잭션이 단순히 USDT0을 전송하는 것이라면 이를 무료로할 수 있도록 한다.
4.2.1 계정 추상화
Source: Takenobu T.
이더리움 계정(account)에는 두 가지 종류가 존재한다. 하나는 EOA(Externally Owned Account)로 우리가 흔히 사용하는 메타마스크와 같이 프라이빗 키에 의에 컨트롤되는 계정이며, 다른 하나는 CA(Contract Acount)로 스마트 컨트랙트를 배포했을 때 생성되는 계정이다. CA는 스마트 컨트랙트의 로직을 담고있는 EVM 코드와 컨트랙트의 데이터를 담는 스토리지를 가지고 있다. 여기서 EOA는 직접 트랜잭션을 실행할 수 있지만, CA는 직접 트랜잭션을 실행하지 못하며, 무조건 EOA로부터 트랜잭션을 실행하라는 호출을 받아야 트랜잭션을 실행할 수 있다.
이러한 구조는 사용자의 계정과 스마트 컨트랙트의 계정을 분리함으로써 직관적인 개발자 경험을 제공하였다. 다만 사용자 경험 측면에서 EOA를 바라볼 경우, 사용자가 프라이빗키를 분실하면 지갑에 대한 소유권을 잃는다거나, EOA에서의 서명은 ECDSA 방식만 가능하여 지갑 디자인의 다양성이 저하된다거나, 사용자는 EOA를 통해 트랜잭션을 실행한다면 무조건 ETH를 보유하고 있어야하는 등 많은 불편함을 가지고 있다.
계정추상화는 EOA와 CA를 그냥 하나의 계정으로 추상화함으로써 개발자와 사용자들이 이 둘을 구별할 필요가 없이, 하나의 계정 종류만 존재하는 것과 같은 사용자/개발자 경험을 제공하는 것을 목표로 한다. 즉, EOA를 CA와 같이 다양한 기능을 활용할 수 있도록하며, CA를 EOA와 같이 자체적으로 트랜잭션을 실행할 수 있도록 이 둘의 장점을 모두 취하는 과정이라고 이해하면 쉽다.
이를 어떻게 구현할 수 있을까? 기본적으로 트랜잭션 실행은 “검증(verification)”과 “실행(execution)” 두 스텝으로 나뉘어진다. 첫 번째로 이더리움 프로토콜 단에서 프라이빗 키를 통해 트랜잭션의 실행 주체가 실제로 해당 계정이 맞는지, 해당 트랜잭션이 유효한지 검증한다. 두 번째는 이더리움 실행 레이어 단에서 트랜잭션에 담긴 데이터가 실행되고, 트랜잭션 결과에 따라 EVM의 상태가 변경된다. 따라서 CA가 트랜잭션을 실행할 수 있도록 하기 위해서는 원래 이더리움 프로토콜 단에서 이루어지던 “검증” 단계를 이더리움 실행 레이어 단에서 수행할 수 있도록 변경되어야 한다. 이것이 바로 계정추상화 구현의 핵심이다.
계정추상화는 아래와 같은 것들을 가능하게 하여 사용자경험을 대폭 향상시킬 수 있다:
가스 추상화: 가스 지급을 ETH 외 토큰으로 하거나, 디앱 혹은 다른 계정이 대납할 수 있도록 한다. 사용자는 가스 토큰을 보유하고 있지 않아도 네트워크와 상호작용할 수 있다.
서명 알고리즘 유연성: 기존에 ECDSA로만 강조되던 서명 알고리즘을 Schnorr, BLS, 양자저항 등 다양한 서명 알고리즘을 선택할 수 있다.
검증 로직 커스터마이징: 여러 계정의 프라이빗키를 통해 제어할 수 있도록 하는 멀티시그 기능, 주기적으로 프라이빗키를 변경할 수 있는 계정 등 다양한 검증 로직이 커스터마이징 가능하다.
멀티콜 기능: 기존에는 특정 토큰이 특정 스마트 컨트랙트와 상호작용하기 위해서 먼저 “approve”하는 트랜잭션과 실제 트랜잭션, 총 2개의 트랜잭션에 따로 서명했어야 했다면, 계정추상화는 여러 트랜잭션을 묶어 한 번에 보내거나, 미리 승인을 받아 반복 상호작용 가능하도록 하여 사용자 경험을 대폭 향상시킬 수 있다.
소셜 리커버리: 사용자는 지갑을 생성할 때 신뢰할 수 있는 친구, 가족, 또는 자신의 다른 디바이스 계정을 보호자로 지정하여, 만약 프라이빗 키를 잃어버린다해도, 이 보호자들이 협력하여 새로운 키로 지갑 권한을 이전할 수 있다.
4.2.2 ERC-4337
이더리움 생태계에서 계정추상화를 구현하기 위한 다양한 시도들이 있었지만, 현재 가장 많이 사용되고 있는 계정추상화 표준은 ERC-4337이다. ERC-4337은 기존 이더리움 프로토콜을 바꾸지 않으면서 EntryPoint, Bundler, Paymaster라는 기능을 추가하여 계정추상화를 쉽게 구현했기 때문이다.
ERC-4337에서 사용자들은 트랜잭션 대신 UserOp이라는 별도의 객체에 서명하며, 이를 이더리움 공식 멤풀이 아닌, 별도의 오프체인 멤풀(UserOperation mempool)에 전송한다. 원래는 멤풀의 트랜잭션을 밸리데이터가 검증했다면, ERC-4337에서는 Bundler가 사용자들의 UserOp의 유효성을 검증하고, 이를 Bundle transaction으로 하나로 모아 EntryPoint라는 스마트 컨트랙트로 전송한다.
EntryPoint는 ERC-4337의 핵심 스마트 컨트랙트로 UserOp을 검증하고, 실행하며, 가스 정산 절차를 한 번에 처리한다. 여기서 Paymaster는 선택적으로 사용될 수 있는데, Paymaster는 가스비를 대신 납부하거나 대체 토큰으로 결제할 수 있도록 하는 스마트 컨트랙트로, 만약 UserOp에 Paymaster 지정과 추가 데이터가 포함되어있다면, EntryPoint가 이를 처리하여 사용자가 가스비를 지불하지 않도록 하거나, 다른 토큰으로 가스비를 처리할 수 있도록 지원한다.
4.2.3 EIP-7702
ERC-4337은 혁신적인 계정추상화 표준을 제시했지만, 실제로 사용자가 사용하기 위해서는 여러가지 문제가 있었다. 가장 대표적인 것은 엔드유저가 계정추상화 기능을 사용하기 위해선 원래 사용하던 EOA에 있는 자금을, 새로 개설한 CA에 전송해서 사용해야한다는 것이다. 이는 사용자경험 측면에서 추가 마찰을 도입하며, 실제로 ERC-4337이 널리 도입되는 것을 저해했다.
EIP-7702는 이를 해결한다. EIP-7702는 이더리움 펙트라 업그레이드 때 도입되어있으며, EOA를 일시적으로 CA처럼 작동할 수 있도록 하는 획기적인 기능이다. 이는 사용자가 기존 EOA의 UX와 주소를 유지하면서도, ERC-4337같은 계정추상화 기능을 바로 사용할 수 있게 하는 매우 실용적인 표준이다.
이를 가능하게하기 위해 EIP-7702는 새로운 트랜잭션 타입을 도입한다. 이 새로운 트랜잭션 타입에는 일반 트랜잭션 필드에 추가적으로 “authorization_list”가 포함된다. 이는 EOA가 어떤 컨트랙트 코드를 자신의 계정 코드로 위임할지 승인을 위한 서명 정보이다. 이 서명은 “내 EOA 주소에 이 스마트 컨트랙트 주소의 코드를 잠시 적용해도 좋다”라는 동의의 표시이다. 이후 EOA에서 트랜잭션 실행시 위임된 스마트 컨트랙트의 로직이 실행되며, 트랜잭션 종료시 위임은 자동 철회되어 EOA는 다시 원래 상태로 복귀할 수 있다.
4.2.4 USDT 가스 토큰 (USDT as Gas Token)
스테이블은 EIP-7702와 ERC-4337을 도입하여 사용자들이 기존에 사용하던 메타마스크와 같은 지갑을 통해서 계정추상화 기능들을 활용할 수 있도록 한다. 스테이블의 모든 EOA는 기본적으로 EIP-7702가 도입되어있어, 트랜잭션 때 마다 따로 EIP-7702를 위한 새로운 트랜잭션 타입을 전송할 필요가 없다. 즉, 스테이블의 사용자들은 복잡한 설정 없이 스마트 지갑 기능을 바로 사용할 수 있다.
이를 활용한 스테이블의 대표 기능 중 하나는 USDT0를 가스 토큰으로 사용할 수 있게 하는 것이다. 스테이블은 사용자들이 gasUSDT 대신 USDT0으로도 가스비를 지불할 수 있게 함으로써, USDT0만 보유하고 있어도 네트워크에서 다양한 활동을 할 수 있도록 한다:
사용자가 트랜잭션을 전송할 때 USDT0을 가스 토큰으로 사용하겠다고 서명한다.
해당 트랜잭션은 UserOp의 형태로 Bundler에게 전달된다.
Bundler는 트랜잭션들을 모아 EntryPoint로 전달하고, Paymaster와 협력하여 가스 지불을 준비한다.
Paymaster는 사용자의 USDT0을 gasUSDT로 변환하여 실제 스테이블 네트워크에서 필요한 가스비를 대신 지불한다.
사용자의 EIP-7702 스마트 계정이 실제 스마트 컨트랙트를 호출함으로써 결과적으로 사용자는 gasUSDT 없이 USDT0만 보유하고 있어도 디앱과 상호작용할 수 있게 된다.
4.2.5 USDT0 전송 무료 (Gas-free USDT0 Transfer)
스테이블은 사용자들의 USDT0 전송을 무료로 처리할 수 있도록한다. 이 또한 EIP-7702와 ERC-4337의 조합으로 가능하다:
사용자는 USDT0 전송 트랜잭션을 EIP-7702가 적용된(enabled) 계정으로 서명한다.
서명된 UserOp은 Bundler 네트워크에 전송된다.
Bundler는 트랜잭션을 번들에 포함하여 EntryPoint로 전달하고, Paymaster와 협력하여 가스 지불을 준비한다.
Paymaster는 트랜잭션 실행을 위해 가스비를 대납하며, EntryPoint는 트랜잭션을 실행하여 결과적으로 사용자의 USDT0 전송은 무료로 처리된다.
개인도 그렇지만, 특히 기업의 경우 비지니스에 스테이블코인 기반 결제/송금을 도입했을 때, 이를 안정적으로 활용할 수 있어야 한다. 만약, 갑자기 네트워크가 혼잡해져 송금/결제 서비스에 문제가 생긴다면 이는 사업에 큰 악영향을 미칠 수 있다. 스테이블은 이를 해결하기 위해 보장된 블록공간(Guaranteed Blockspace) 기능을 도입할 예정이다.
보장된 블록공간은 스테이블의 블록 용량 중 일부를 보장하는 서비스로, 사용자는 구독을 통해 이를 사용할 수 있다. 따라서 아무리 스테이블 네트워크가 혼잡해져도, 이들에게는 일정량의 블록공간이 보장되어있기 때문에, 서비스를 안정적으로 사용할 수 있다는 장점이 있다.
보장된 블록공간을 통해 구독자들의 트랜잭션이 확실히 포함하기 위해선, 1) 전용 멤풀을 통해 구독자들의 트랜잭션을 따로 담아두는 전용 멤풀을 운영하고, 2) 밸리데이터들은 생성할 블록의 일부 공간을 미리 할당해두어야 하며, 3) 전용 RPC를 운영하여 구독자들이 안정적으로 트랜잭션을 전송할 수 있도록 해야한다.
스테이블은 USDT0 전송 수수료를 무료로 하는 것을 넘어서 USDT0 전송의 효율성을 더 높이기 위해 USDT 전송 애그리게이터를 도입한다. 이는 다른 종류의 트랜잭션에 영향을 끼치지 않으면서 USDT0 전송 트랜잭션을 따로 모아 처리하여, 사용자들에게 더 높은 사용자 경험을 제공하는 것을 목표로 한다.
기존 ERC-20의 처리 방식은 순차적으로 실행되므로 느렸다면, 스테이블은 프리컴파일된 컨트랙트를 활용해 계정별 잔고와 전송으로 인한 변화량(diff) 계산을 병렬로 수행하여, USDT0 전송만 따로 모아 한 번에 처리함으로써, 전송 처리 속도를 비약적으로 개선할 수 있다.
각각의 USDT0 전송은 보낸 사람(sender)와 받는 사람(recipient)로 구성된다. 이 전송들에 대해 각 어카운트 기준으로 순 변화량(diff)를 계산할 수 있다. 예를 들어 A가 B에게 100 USDT를 전송했다면 A의 diff는 -100이고, B의 diff는 +100이다.
전송과 함께 검증도 병렬적으로 이루어지는데, 모든 전송이 합쳐졌을 때 총 전송이 총 수취와 같아야 하며, 또 각 계정의 잔고가 diff와 비교하여 충분한지 개별적으로 검증된다. 예를 들어 A의 잔고가 120 USDT0인데, diff가 -150 USDT0일 수는 없다. 따라서 이 경우 어카운트 A는 플래그 처리된다.
USDT0 전송을 이렇게 따로 모아서 병렬처리 할 경우 문제가 생길 수 잇는데 바로 충돌 가능성이다. 예를 들어 여러 USDT0 전송 트랜잭션이 동일 어카운트를 공유할 수 있다. 이를 방지하기 위해 어카운트가 공유되는 트랜잭션을 미리 사전 감지 한 후에, 잔고 부족 가능성이 있는 고위험 전송의 경우 미리 플래그 처리를 한다. 특정 계정이 잔고가 부족할 경우 스테이블은 각 어카운트 단위로 전송을 격리 처리 하기 때문에, 해당 전송이 다른 전송에 영향을 미치지 않도록한다.
금융 시스템에서 프라이버시는 필수적이다. 보통 사람들은 블록체인의 장점으로 투명성을 많이 언급하지만, 투명성은 금융 시스템에서 장점이라기보단 오히려 버그에 가깝다. 스테이블은 스테이블코인 송금 및 결제에 최적화된 네트워크인 만큼, 프라이버시가 굉장히 중요하다. 따라서 스테이블은 ZK 기술을 통해 미래에 프라이버시 기능을 도입할 계획을 가지고 있다.
스테이블에서의 기밀 전송은 규제를 준수하기 위해 전송자와 수신자의 주소는 공개하는 대신, 얼만큼의 자금을 전송했는지는 숨긴다. 전송 가치의 경우 전송자, 수신자 및 인가된 규제 기관에 한해서 확인할 수 있도록 하여, 기밀 전송 기능이 도입되어도 자금이 불법적으로 사용될 수 없도록 방지할 것이다.
스테이블은 USDT를 위한 다양한 기능들을 제공할 뿐 아니라, 블록체인의 확장성을 개선하여 수 많은 USDT 트랜잭션을 효율적으로 처리할 수 있도록 한다.
사용자가 트랜잭션을 발생시키면 이는 RPC 인터페이스를 거쳐 멤풀에 추가되고, 블록에 담긴 후에, 합의 알고리즘을 통해 검증되고, 연산을 통해 블록체인의 상태(state)가 바뀌며, 마지막으로 블록체인의 데이터베이스에 저장된다. 이 과정 속에서 특정 부분만 개선된다 할지라도, 다른 부분의 성능이 떨어지면 병목으로 작용할 수 있다. 따라서 블록체인의 확장성을 개선하기 위해선 전반적인 성능 개선이 필요하다.
스테이블도 마찬가지로 트랜잭션 라이프사이클에 개입하는 컴포넌트들의 전반적인 개선을 목표로 하고 있다. 스테이블의 기술 로드맵은 아래와 같다:
컨센서스(Consensus): 초기에는 CometBFT를 최적화한 StableBFT를 사용하다가, 추후에 DAG 기반의 BFT인 Autobahn으로 업그레이드할 예정이다.
연산(Execution): 100% EVM 호환가능한 Stable EVM을 기반으로, 추후에 블록STM 기반의 병렬연산엔진 및 고성능 EVM 클라이언트를 도입할 예정이다.
데이터베이스(DB): 추후에 상태커밋과 스토리지를 디커플링하고, mmap 기능을 추가하여 데이터베이스를 최적화할 예정이다.
RPC: 추후에 읽기와 쓰기 경로를 분리하고, EVM View 호출을 최적화하고, 인덱서를 내장하는 등 RPC를 최적화할 예정이다.
각 컴포넌트 별로 스테이블이 구체적으로 어떻게 성능을 최적화하는지 아래에서 살펴보자.
5.1.1 StableBFT
스테이블은 초기에 CometBFT를 기반으로하는 StableBFT를 컨센서스 알고리즘으로 사용한다. 이는 즉각적인 완결성을 제공하기 때문에 포크가 발생하지 않고, 금융 시스템에 적합한 모델이다. StableBFT는 기존의 CometBFT의 성능을 더 최적화하기 위해 아래와 같은 개선을 도입할 예정이다:
트랜잭션 전파와 컨센서스 전파의 분리(Decoupled transaction and consensus gossiping): 기존 CometBFT에서의 노드들은 하나의 P2P 네트워크를 통해 트랜잭션 전파와 컨센서스 메세지 전파를 처리했다. StableBFT는 트랜잭션과 컨센서스 메세지의 전파 채널을 분리함으로써, 한 쪽이 혼잡하여도 다른 한 쪽에게 영향을 주지 않도록 개선할 것이다.
블록 프로포저로의 직접 트랜잭션 전파(Direct transaction broadcasting to the block proposer): 기존 CometBFT에서 트랜잭션의 전파는 노드들 사이에서 P2P로 이루어졌다. 이는 네트워크에 부담을 줄 수 있는데, StableBFT는 트랜잭션의 전파를 블록 프로포저에게 직접하여 불필요한 전파로 인한 네트워크의 부담이 적도록 개선할 것이다.
5.1.2 Autobahn
추후에 스테이블은 컨센서스 측면에서 확장성을 더 개선하기 BFT 컨센서스 중 하나인 Autobahn을 도입할 예정이다.
BFT 프로토콜은 크게 전통적인 뷰 기반 BFT(e.g., CometBFT, Hotstuff)와 DAG 기반 BFT(e.g., Narwhal-Tusk)로 나뉜다:
뷰 기반 BFT는 네트워크가 정상 동작할 때에는 지연(latency)이 낮다는 장점이 있지만, 간헐적으로 장애(blip)가 발생한다면 여기서 회복하는데 시간이 오래걸린다는 단점이 있다. 이는 장애 동안 처리되지 못한 요청들이 백로그(backlog)로 쌓이게 되고, 네트워크가 다시 정상화되더라도 백로그가 컨센서스에 지연을 유발한다.
DAG 기반 BFT는 장애가 발생해도 빠르게 회복이 가능하다는 장점이 있지만, 네트워크가 정상 동작할 때 지연이 비교적 높다는 단점이 있다. DAG 기반 BFT는 데이터 전파와 컨센서스가 분리되어 있기 때문에 컨센서스에 장애가 생겨도 데이터 전파는 계속되며, 장애가 끝난 후에는 한 번에 많은 트랜잭션에 대한 합의를 이룰 수 있기에 장애 회복에 강하다. 하지만 DAG 기반 BFT에서 합의를 이루기 위해선 노드들 사이에서 모든 트랜잭션 데이터를 동기화해야되기 때문에, 네트워크가 정상 동작하는 동안 뷰 기반 BFT에 비해 높은 지연을 갖게 된다.
Autobahn은 이 둘의 장점만을 취해서 낮은 지연시간, 높은 처리량, 장애 회복력을 모두 달성하고자 하는 DAG기반 BFT 컨센서스 프로토콜이다. Autobahn이 양쪽의 장점을 모두 취할 수 있는 비법은 아래와 같다:
낮은 지연: Autobahn은 CAR이라는 구조를 도입해서 합의에 참여하는 노드들이 반드시 모든 데이터를 동기화하지 않아도 합의를 진행할 수 있도록 설계했다. 이로 인해 합의 비용이 감소하고, 가장 최신 CAR을 검증함으로써 이전에 쌓여있던 트랜잭션들에 대한 모든 합의가 가능하기에 합의 지연을 낮출 수 있다.
장애(blip) 저항: Autobahn은 기본적으로 DAG 기반 BFT 컨센서스 프로토콜이기 때문에, 데이터 전파와 합의가 완전히 분리되었다. 따라서 합의가 멈춘다고 하여도, 모든 노드들은 지속적으로 트랜잭션 전파를 할 수 있으며, 나중에 시스템이 정상화될 때 한 번에 합의를 할 수 있어 네트워크 장애에 대한 회복력이 높다.
그렇다면 정확히 Autobahn에서 노드들이 어떠한 과정을 통해 합의에 이르는지 살펴보도록 하자.
데이터 전파 (Data Dissemination)
기본적으로 Autobahn에선 모든 노드들이 블록 프로포저의 역할을 하며, 자신들에게 들어오는 트랜잭션을 지속적으로 데이터 프로포절(data proposal)이라는 덩어리로 묶고(batching) 이를 전파한다. 보통 컨센서스 알고리즘에서는 특정 타임 프레임에서는 하나의 블록 프로포저가 선정되어 블록을 만들고 이를 전파하지만, Autobahn에선 여러 노드들이 다들 자신만의 체인을 지속적으로 만들고 있으며, 한 노드가 만들고 있는 체인은 다른 노드가 만들고 있는 체인에 영향을 주지 않는다. 이러한 체인을 레인(Lane)이라고 부른다.
각 노드들은 데이터 프로포절을 전파하게되면, 다른 노드들은 이를 수신하고 투표한다. 여기서 n=3f+1의 시스템을 가정했을 때, f+1개의 투표가 모이면 PoA(Proof of Availability)가 생성된다. 이는 네트워크에 최소 하나 이상의 노드가 해당 데이터 프로포절을 가지고 있다는 것을 보장한다.
여기서 데이터 프로포절과 PoA를 묶은 단위를 CAR(Certification of Available Request)라고 한다. 이는 데이터의 신뢰성과 전파 가용성을 보장하는 최소 단위이며, 합의를 이루기 전에 해당 데이터 프로포절이 안전하게 전파됐다는 것을 입증할 수 있다. 새 CAR은 항상 이전 CAR을 참조한다.
합의 (Consensus)
각 노드들은 서로 영향을 받지 않고 서로 다른 속도로 자신만의 데이터 체인인 레인(Lane)을 생성하기 때문에 이들 간 합의가 필요하다. 이를 위해 Autobahn은 각 노드들의 최신 CAR을 모은 “tip cut”이라는 것에 대해 한 번에 BFT 합의 과정을 거친다.
여기서 중요한 것은 CAR들은 항상 이전의 CAR을 참조하기 때문에 각 레인별로 최신 CAR에 대해 합의가 끝난다면 이전 CAR에 대해서도 전부 합의가 완료될 수 있다. 이는 네트워크에 장애(blip)이 발생해도 금방 회복할 수 있는 이유 중 하나이다.
또한 CAR의 특징으로는 f+1개 이상의 노드들로부터 투표를 받은 PoA를 포함하기 때문에, 모든 노드들이 데이터를 동기화하지 않아도 합의를 진행할 수 있다는 장점이 있다. 이는 DAG 기반 BFT 프로토콜임에도 불구하고 전통 뷰(view) 기반 BFT 프로토콜과 같이 낮은 지연을 통해 합의를 가능하게 한다.
5.2.1 Stable EVM
Stable EVM은 EVM과 호환가능한 실행 레이어로, 사용자/개발자들은 기존 이더리움 생태계의 다양한 지갑, 인프라, 코드 등을 그대로 사용할 수 있다. 스테이블은 StableBFT 컨센서스 알고리즘을 사용하며, 네트워크 코어에는 네이티브 토큰의 전송 관리나 스테이킹을 관리하는 모듈이 존재하기 때문에, Stable EVM과 이들을 연결하기 위해 Stable EVM에는 몇 가지 프리컴파일들이 추가적으로 존재한다.
5.2.2 로드맵 1: 옵티미스틱 병렬 연산 (Optimisitic Parallel Execution)
EVM 연산 레이어에서 확장성 개선을 위해 가장 많이 적용하는 방법 중 하나는 병렬 연산이다. EVM 내에서 트랜잭션은 기본적으로 직렬로 처리된다. 하지만 만약 한 블록 내에 A가 B에게 1 ETH를 보내는 트랜잭션과 C가 D에게 1 ETH를 보내는 트랜잭션이 있다고 가정하면, 이 둘은 병렬적으로 처리해도 전혀 문제가 없으며, 연산 속도를 비약적으로 향상시킬 수 있을 것이다.
Source: MegaETH
실제로 MegaETH는 이더리움 블록 20000000부터 20010000까지 시뮬레이션을 통해 블록 1개, 2개, 5개, 10개 내에서 병렬 연산을 시도해본 결과, 하나의 블록 내에서 병렬 처리를 할 경우 평균 2배의 연산 속도 향상의 결과를 얻을 수 있었다. 하지만 재미있는 것은 블록 하나가 아닌, 두 개, 5개, 10개를 묶어서 병렬처리를 하게 된다면 더 비약적인 속도 향상을 예상할 수 있겠지만, 약 2.75배 향상으로 수렴하는 것을 확인할 수 있었다. 이는 블록 내에 서로 충돌하는 트랜잭션 때문이다.
트랜잭션 병렬 연산에서 중요한 것은 트랜잭션들이 서로 같은 상태(state)를 건드리는지 확인하는 것이다. 이런 충돌이 생기면 동시에 처리할 때 결과가 달라지는 상황이 생길 수 있기 때문에 병렬 연산에 문제가 될 수 있다.
충돌 예시 1: A가 B에게 1 ETH를 전송하는 트랜잭션과 B가 C에게 3 ETH를 전송하는 트랜잭션
충돌 예시 2: A와 B가 같은 NFT 민팅 컨트랙트에서 NFT를 민팅하는 트랜잭션
충돌 예시 3: A가 디파이 컨트랙트에 “approve”를 호출하는 트랜잭션과, 그 컨트랙트에서 “transferFrom”을 실행하는 트랜잭션
병렬 연산에서 서로 충돌하는 트랜잭션을 방지하기 위해, 어떤 트랜잭션들이 서로 관련있는지 확인하는 방법은 크게 두 가지가 있다. 첫 번째는 트랜잭션을 실행하기 이전에 트랜잭션들이 어떤 상태(state)를 참조하는지 미리 판단하는 상태 접근(State Access) 방법이다. 같은 상태를 참조하는 트랜잭션의 경우 순차적으로 처리하고, 나머지 트랜잭션들은 병렬로 연산할 수 있다. 솔라나, 수이 등이 상태 접근 방법을 사용하는 대표적인 네트워크이다.
두 번째는 일단 모든 트랜잭션들을 한 번 병렬로 처리하고, 충돌이 일어나는 트랜잭션들을 따로 다시 순차적으로 처리하는 옵티미스틱 병렬 연산(OPE)이다. 대표적인 옵티미스틱 병렬 연산 기법으로는 Block-STM이 있으며, 예시로 앱토스와 모나드가 이를 사용한다. 스테이블 또한 Block-STM 기반의 옵티미스틱 병렬 연산 엔진을 도입할 계획을 가지고 있다.
스테이블에서 OPE는 아래와 같이 작동한다:
합의 레이어에서 블록 내의 트랜잭션들이 연산 레이어로 넘어온다.
병렬로 트랜잭션들을 실행하면서 ReadSet과 WriteSet을 기록한다. 여기서 ReadSet과 WriteSet이란 트랜잭션들이 실행되는 동안 각각 읽고, 수정한 모든 데이터의 버전 정보와 키를 기록한 목록이다.
스테이블은 각 트랜잭션의 ReadSet/WriteSet을 비교하여 충돌이 있는지 확인하고 결과를 반환한다.
만약 충돌이 있는 경우 해당 트랜잭션만 재실행되며, 충돌이 없는 경우 커밋 과정으로 진행한다.
트랜잭션 충돌 없이 모두 유효하다고 확인되면 최종적으로 블록을 커밋한다.
스테이블은 OPE와 별개로 블록이 네트워크에 전파되고 합의되기 전에 미리 실행하는 옵티미스틱 블록 프로세싱(OBP)까지 도입하여 연산 효율성을 극대화할 계획을 가지고 있다.
5.2.3 로드맵 2: StableVM++
스테이블은 추후에 다른 종류의 고성능 EVM 구현체를 도입할 계획을 가지고 있다. 고성능 EVM의 대표적인 예시로는 EVMONE이 있다. 기존 널리 사용되는 Go 기반 EVM은 문법이 간단하고, 오랜 기간 동안 사용되며 많은 검증을 거쳐 안정성이 높다는 장점이 있으나, Go는 C++에 비해 정밀한 메모리 제어가 어렵고, 저수준 최적화가 덜 되어있기에 Go 기반 EVM 구현체는 느리다는 단점이 있다.
반면 EVMONE은 이더리움 재단의 입실론(Ipsilon) (구 eWASM) 팀이 개발한 구현체로 C++을 기반으로 하고 있다. EVMONE은 메모리 직접 제어, 고급 최적화 등으로 속도와 효율성을 대폭 향상시킨다. 실제로 EVMONE은 Go 기반의 EVM보다 5-10배 정도의 연산 성능 향상을 가져올 수 있다.
5.3.1 기존 DB의 문제점
블록체인의 데이터베이스는 네트워크의 상태(state)를 저장하고 관리하는 저장소이다. 참고로 상태란 계정 잔고, 스마트 컨트랙트 변수, 토큰 소유권 정보 등 모든 현재 데이터를 포함한다. 블록체인에서는 블록이 실행될 때마다 상태가 바뀐다. 이 과정은 두 단계로 나눌 수 있다:
상태 확정 (State Commitment): 트랜잭션을 실행하여 새로운 상태를 도출한 후, 이 상태를 확정한다.
상태 저장 (State Storage): 미래에 검증하거나, 과거 내역을 보존하기 위해 확정된 상태를 디스크에 저장한다.
기존 블록체인 DB는 여러가지 문제를 가지고 있는데, 첫 번째는 이 두 단계가 커플링되어있다는 것이다. 즉, 상태를 확정한 뒤 디스크에 저장이 다 끝나야 다음 블록을 실행할 수 있는 것이다. 만약 디스크 저장이 느리면 그 시간 동안 시스템은 다음 블록을 실행하기 전에 기다려야한다.
두 번째는 상태 데이터를 불러오는 과정이 비효율적이라는 것이다. 상태 데이터가 저장될 때 고정된 주소에 저장되는 것이 아닌, 디스크 여기저기에 랜덤하게 저장되기 때문에, 나중에 트랜잭션이 상태를 읽어올 때 지연율이 높은 문제가 발생한다.
5.3.2 StableDB
스테이블은 이러한 문제점들을 해결하기 위해 두 종류의 개선을 도입할 예정이다.
첫 번째는 상태 확정과 상태 저장을 디커플링하는 것이다. StableDB에서 노드들은 이전 블록이 상태 확정만 완료되면 바로 다음 블록을 실행할 수 있으며, 이전 블록의 상태 저장은 병렬적으로 처리된다.
두 번째는 “mmap”을 통해 “MemDB”와 “VersionDB”를 도입하는 것이다. “mmap”은 디스크에 저장된 파일을 메모리에 복사해서 사용하는 대신, 파일 데이터를 그대로 가상 메모리에 연결(mapping)하는 기술이다. 이를 통해 프로그램은 “read()”나 “write()” 호출 없이, 그냥 메모리처럼 파일 내용을 읽고 쓸 수 있다.
“MemDB”는 빠른 임시 저장소이다. “MemDB”는 방금 업데이트된 계정 정보, 자주 거래되는 토큰 잔액 등, 최근 자주 사용되는 상태(state)를 메모리에 저장하는 역할을 한다. “mmap”을 통해 고정된 메모리 주소에 바로 접근할 수 있어서 읽고 쓰는 속도가 매우 빠르다.
“VersionDB”는 늘리지만 오래 보관하는 저장소이다. 모든 상태를 메모리에 담을 수 없기 때문에, 오래된 정보는 디스크에 저장해야한다. “VersionDB”는 자주 접근되지는 않지만, 검증이나 과거 히스토리 조회용으로 꼭 필요하다.
즉, 정리하면 StableDB는 1) 상태 저장 전에 다음 블록을 병렬로 실행하여 네트워크의 성능을 개선할 수 있으며, 2) “MemDB”와 “VersionDB” 두 가지 DB를 통해 자주 사용되는 상태의 경우 읽기/쓰기 속도를 비약적으로 개선할 수 있다. 실제로 이러한 구조는 이미 세이(Sei)와 같은 네트워크에서 사용하였으며, 이로인해 전반적으로 2배의 TPS 향상 효과를 볼 수 있었다.
5.4.1 블록체인에서 RPC란?
블록체인에서 RPC는 네트워크에 연결된 노드에게 요청을 보내고 응답을 받는 통신 방식을 의미한다. 쉽게 말해, 당신이 사용하는 웹3 월렛이 블록체인 네트워크와 상호작용할 때의 인터페이스라고 생각하면된다. 블록체인에는 다양한 노드가 존재하는데, 이 중 RPC 노드는 클라이언트와 네트워크 사이의 중개자 역할을 하여, 사용자가 서명한 트랜잭션을 네트워크에 제출하고, 스마트 컨트랙트를 호출하는 기능 등을 제공한다.
5.4.2 기존 RPC의 문제점
기존 블록체인 RPC 노드는 보통 풀노드(full node)를 복제하여 하나 띄우고, 여기에 RPC 엔드포인트를 결합한 구조이다. 즉, 블록체인 동기화, 합의 검증, RPC 요청 응답 등의 많은 역할들을 한 노드에서 동시에 처리하여 무겁고 복잡하다. 이러한 모든 역할들은 같은 CPU, 메모리, 디스크를 공유하므로 RPC 요청 응답 외의 다른 쪽에서 바빠지면, RPC 응답 처리 속도가 느려지게 된다.
또한, 기존 RPC 구조는 쓰기 작업과 읽기 작업을 동일한 경로와 자원으로 처리한다. 대부분의 경우 읽기 작업이 쓰기 작업에 비해 훨씬 많음에도 불구하고 이를 따로 처리하지 않으며, 쓰기 작업을 처리할 때 수 많은 읽기 작업으로 인해 굉장히 비효율적이라는 단점이 있다.
5.4.3 Stable RPC
스테이블은 기존의 무겁고 복잡한 RPC 구조에서 벗어나, 역할별로 쪼개고, 가볍고 빠른 엣지 노드를 배치하는 구조로 바꿀 계획이다. 즉, 하나의 복잡한 노드가 모든 요청을 처리하는 것이 아니라, 예를 들어 읽기용, 쓰기용 등의 기능으로 나누어서 각 기능에 최적화된 경량 노드를 따로 운영하는 것이다. 스테이블은 내부 테스트 기준으로 읽기 전용 RPC의 경우 10,000 RPS 이상 처리할 수 있는 것을 확인하였으며, 100ms 이하의 낮은 지연율을 기록할 수 있었다.
이외에도 스테이블은 추후에 인덱서를 RPC 노드에 통합시킴으로써, 디앱이 필요한 데이터를 쿼리할 때, RPC와 인덱서를 따로 거치는 것이 아닌, 한 번에 얻을 수 있게 함으로써, 외부 인덱서 없이도 노드 자체에서 데이터 쿼리를 처리 가능한 구조를 도입할 계획을 가지고 있다.
글을 요약하자면, 블록체인을 디지털 국가로 보았을 때 USDT는 온체인 GDP 성장을 위한 핵심 자산이며, 스테이블은 블록체인 코어 최적화를 통한 높은 확장성과 USDT에 특화된 다양한 기능들을 통해 USDT 사용에 최적화된 환경을 제공한다. 그렇다면 스테이블이 실제로 어떻게 활용되어 사용자들에게 가치를 제공할 수 있을까?
첫 번째는 USDT 송금을 위한 네트워크이다. 스테이블의 사용자들은 기본적으로 USDT0 전송을 무료로 할 수 있으며, 스테이블은 USDT0 전송을 더 효율적으로 처리하기 위해 USDT 전송 애그리게이터 (USDT Transfer Aggregator)와 같은 기능을 도입한다. 이러한 관점에서 기존에 달러에 접근하기 어려웠던 아프리카, 남미, 아시아의 국가들의 사람들이 스테이블을 USDT 전송 네트워크로 쉽게 활용할 수 있을 것이며, USDT 거래량이 높은 바이낸스와 같은 CEX들은 USDT 입출금 네트워크로 스테이블을 지원함으로써 오퍼레이션 비용을 많이 낮출 수 있을 것이다.
두 번째는 USDT 페이먼트를 위한 네트워크이다. 스테이블은 사업체가 USDT로 결제를 원활하게 받을 수 있도록 다양한 인프라를 제공한다. 예를 들어 사업체가 보장된 블록공간 (Guaranteed Blockspace)을 사용한다면 네트워크가 혼잡한 상황이 발생해도 고객들의 결제를 안정적으로 처리할 수 있을 것이다. 또한 스테이블은 높은 확장성을 가지고 있고, USDT0 무료 전송이 가능하기 때문에 페이먼트나 직불카드와 같은 서비스가 도입된다면 달러에 쉽게 접근하지 못하는 사람들이 USDT를 통해 쉽게 실세계의 결제를 진행할 수 있을 것이다.
이외에도 당연히 스테이블은 USDT0을 통해 기존의 거대한 USDT 유동성을 쉽게 끌어 모을 수 있으며, EVM과 100% 호환가능하기 때문에 USDT를 위한 다양한 디파이 생태계가 구축될 수 있고, USDT0 전송 수수료 무료로 인해 굉장히 빠른 속도로 USDT가 거래될 것이다. 이러한 모든 특성들을 고려해보았을 때 스테이블은 MV=PQ 관점에서 막대한 규모의 온체인 GDP를 가질 잠재력이 있으며, USDT를 위한 초거대 디지털 국가로 자리매김할 수 있을 것이다.
