Fuel의 FuelVM·Sway, UTXO 기반 설계, 모듈형 롤업 아키텍처와 개발자 경험, 생태계 현황 및 리스크를 정리한다.
URL: https://messari.io/report/fuel-supercharging-modular-execution
멀티체인 경쟁에는 롤업과 앱체인이 개발자와 사용자의 관심을 두고 끊임없이 새로운 플레이어들이 유입되고 있다. 그중 하나가 고도로 구성 가능한 롤업을 위한 모듈형 실행 레이어인 Fuel이다. Fuel은 완전히 새로운 가상머신인 FuelVM을 도입하여, 빌더들이 다양한 기능을 활용해 새로운 형태의 애플리케이션을 개발할 수 있도록 한다.
Fuel V1은 결제(payments)를 위해 이더리움 위에 구축된 최초의 옵티미스틱 롤업이었으며, 스마트 컨트랙트 기능은 없었다. 또한 현재까지도 퍼미션리스 사기 증명 시스템을 갖춘 유일한 옵티미스틱 롤업이다. 최근 라운드에는 Blockchain Capital, Stratos Capital 등이 참여했으며, 해당 자금은 최근 세 번째 테스트넷을 출시한 Fuel V2 개발을 지원한다. Fuel 스택은 모놀리식 체인으로 동작할 수 있는 역량도 갖추겠지만, 팀은 Fuel V2를 사기 증명이 가능한(modular) 실행 레이어로 구축하고 있다.
블록체인의 주요 기능은 세 가지다.
모놀리식 블록체인은 이 모든 기능을 한 체인에서 처리하기 때문에 빠르게 비효율적이 되어 ‘블록체인 트릴레마’를 야기한다. 이더리움의 경우 사용량이 증가하면서 실행 기능을 롤업에 위임하여, L1이 보안과 탈중앙화에 집중할 수 있게 했다. 롤업은 이더리움 상의 스마트 컨트랙트로 상태를 검증하므로 이더리움의 보안을 상속한다.
하지만 롤업의 확장성은 사용하는 DA 솔루션의 처리 용량만큼만 확장할 수 있다. 예를 들어 이더리움은 모놀리식 체인으로서 모든 기능을 처리하므로, 이더리움의 DA 용량이 롤업 확장성의 상한선을 만든다. 과거 LazyLedger로 알려졌던 모듈형 DA 레이어 Celestia는 모듈형 블록체인 개념을 주창했다. Celestia는 DA와 합의에만 집중하도록 설계되어 이더리움보다 더 큰 DA 용량을 처리할 수 있고, 그 결과 롤업 성능을 개선할 수 있다.
모듈형 실행 레이어로서 Fuel은 모놀리식 체인의 일부로도 사용할 수 있고, 결제·합의·데이터 가용성을 별도 레이어로 분리한 실행 환경으로도 사용할 수 있다. 모듈성을 핵심으로 삼기 때문에, Fuel은 특정 구성에 제한되지 않아 높은 대역폭을 달성할 수 있다. Fuel의 첫 구현은 이더리움으로 결제하는 옵티미스틱 롤업이겠지만, 실행 레이어 자체는 궁극적으로 증명 방식 및 체인에 구애받지 않는다.
상대적으로 EVM은 느리고 비용이 많이 든다. 또한 이더리움은 EVM 변경이 기존 스마트 컨트랙트를 깨지 않도록 보장하는 ‘하위 호환성(backward compatibility)’에 영향을 줄 수 있어, EVM을 바꾸는 데 어려움이 있다. 이러한 한계는 FuelVM 개발을 촉진했다. FuelVM은 EVM의 한계를 뛰어넘도록 설계되었고, 효율적인 트랜잭션 처리와 함께 동반 프로그래밍 언어에 초기부터 안전장치를 내장하는 등 선호도가 높은 기능들을 포함한다.
Fuel은 회계(어카운팅) 모델로 비트코인에서 계승한 UTXO 모델을 사용한다. UTXO 모델에서 자산은 주소들 사이의 방향성 비순환 그래프(DAG) 형태로 원장에 저장된다. 트랜잭션에서는 미사용 출력(unspent outputs)이 소비되어 새로운 출력(outputs)을 만든다.
반면 계정 기반 모델은 네트워크 상태의 데이터베이스에 저장된 주소들에 대해 트랜잭션을 더하고 빼는 방식이다. 이더리움, 솔라나, 모든 EVM 기반 체인, 그리고 많은 스마트 컨트랙트 네트워크가 계정 기반 모델을 사용하며, 이는 은행 계정의 동작 방식과 유사하다. 사용자(개인키 소유자)가 토큰 전송 트랜잭션에 서명하면, 송신자의 계정에서 해당 금액이 차감되고 수신자의 계정에는 같은 금액이 가산된다.
Fuel은 UTXO 모델을 사용하기 때문에 지갑이나 계정을 사용하지 않는다. 대신, 트리거된 각 트랜잭션은 토큰을 ‘소각(burn)’하고 ‘생성(create)’한다. 각 UTXO는 고유하게 식별되며 단 한 번만 소비될 수 있어, 이중 지불(double-spend)을 방지하는 데 도움이 된다. 또한 UTXO 기반 시스템이 일반적으로 갖는 코인 UTXO 외에도, Fuel에는 컨트랙트 UTXO가 존재하며, 여기에는 코인 수량, 컨트랙트 ID, 해시, 스토리지 루트(storage root)가 포함된다.
UTXO 사용은 서로 의존성이 없는 주문을 여러 CPU 스레드에서 동시에 병렬 실행할 수 있게 하는 병렬 주문 처리를 가능하게 한다.
FuelVM은 병렬화를 가능하게 하기 위해 엄격한 접근 리스트(strict access lists)를 사용한다. 즉, 각 트랜잭션은 동시에 실행될 경우 동일한 컨트랙트에 영향을 주는 트랜잭션이 겹치지 않도록, 자신이 접근할 수 있는 컨트랙트를 포함해야 한다. 병렬화는 트랜잭션을 순서대로 정렬해 처리하는 방식에 비해 훨씬 높은 처리량을 생성하며, 이는 EVM 비효율의 주요 원인 중 하나다.
EVM은 전역 상태(global state)를 저장하므로, 서로 다른 행위자들이 동일한 스마트 컨트랙트와 상호작용할 수 있다. UTXO에서는 동시성 문제가 발생할 수 있는데, 이는 특정 UTXO와 그에 연결된 스마트 컨트랙트가 한 번만 사용될 수 있기 때문이다. 카르다노는 확장 UTXO(eUTXO) 모델을 사용하며 특히 디파이 애플리케이션에서 이 문제를 겪은 바 있다. 트랜잭션은 보통 여러 사용자가 동시에 하나의 스마트 컨트랙트와 상호작용해야 하지만, 동시성 제약으로 인해 병목이 발생한다.
Fuel은 컨트랙트 UTXO를 통해 이 문제를 피한다. 컨트랙트 UTXO는 컨트랙트 ID로 고유하게 식별되므로, 사용자는 소비할 UTXO ID가 아니라 상호작용하려는 컨트랙트의 컨트랙트 ID를 제공한다. 그러면 어떤 UTXO를 소비할지, 그리고 연결된 컨트랙트의 결과 상태가 무엇이 될지는 블록 생산자가 결정한다. 각 트랜잭션은 컨트랙트 UTXO를 소비하고, 새로운 상태를 가진 새 컨트랙트 UTXO가 생성된다.
FuelVM은 다음과 같은 프로그램 타입을 지원한다: 스마트 컨트랙트, 스크립트, 라이브러리, 프레디케이트. EVM에서는 컨트랙트와의 각 상호작용이 별도의 트랜잭션이지만, FuelVM에서는 스크립트를 통해 하나의 트랜잭션에서 여러 컨트랙트를 호출할 수 있다.
프레디케이트는 UTXO가 소비될 수 있는 조건이다. 프레디케이트는 트랜잭션이 수행될지를 판단하기 위해 True 또는 False로 평가된다. 프레디케이트가 허용된 조건과 일치하지 않으면 트랜잭션은 무효가 되며, 블록에 포함되지 않고 가스도 소비되지 않는다. 이는 트랜잭션 출력이 이전 트랜잭션의 출력에 의존하기 때문에 일정 수준의 원자성(atomicity)이 강제되기 때문이다. 트랜잭션의 비용과 유효성은 실행 전에 예측할 수 있다. 또한 가스 변수에 따른 임의의 정렬이 없으므로 수수료 역시 예측 가능하다.
UTXO와 프레디케이트의 핵심 이점은 상태 증가(state growth)를 최소화하고 계정 추상화(Account Abstraction) (AA)를 도입한다는 점이다. 블록체인이 성장할수록 상태 비대화(state bloat)가 발생하기 쉽다. 상태 비대화는 체인 성능과 노드 운영 요구사항에 대한 압력을 키운다. 그 결과 하드웨어 비용을 감당할 수 있는 노드가 줄어들수록 중앙화 위험은 커진다. 롤업은 L1의 상태 증가 일부를 오프로딩하지만, 사용량이 늘어나면 롤업 역시 상태 비대화에 취약하다.
스크립트와 프레디케이트는 스마트 컨트랙트처럼 데이터를 저장하지 않으므로 상태 증가에 기여하지 않는다. Fuel은 이러한 부담이 덜하므로 성장하더라도 사용자와 활동을 지속적으로 수용할 수 있다.
또한 각 UTXO는 여러 입력을 받아 그에 대응하는 출력을 만들기 때문에, 하나의 트랜잭션에 여러 사용자를 참여시키기 쉽다. EVM에서 멀티시그는 영구적인 컨트랙트들의 집합인 반면, FuelVM에서는 네이티브 멀티시그를 통해 사용자가 온체인에 상태를 저장하지 않고도 프레디케이트를 설정해 트랜잭션을 개시할 수 있다. 이는 사용자 그룹의 활동을 더 빠르고 효율적으로 만든다.
프레디케이트를 통한 계정 추상화
UTXO와 프레디케이트는 자연스럽게 계정 추상화를 낳아, 프로그래밍 가능한 트랜잭션 검증을 가능하게 한다. 더 나아가 Fuel은 무상태(stateless) 계정 추상화를 구현하는데, 이는 외부 상태에 의존하지 않으며 상태 비대화를 유발하지 않는다는 의미다. Fuel에서는 특정 출력(output)에 기반해 소비 가능한 프레디케이트를 프로그램할 수 있다. 예를 들어 “X가 발생해야만 트랜잭션이 유효하다” 같은 조건을 설정할 수 있다. 또한 AA가 프로토콜에 의해 강제되는 것이 아니기 때문에, 개발자는 애플리케이션 레벨에서 커스텀 검증 스킴을 정의할 수 있다.
이더리움은 AA를 코어 프로토콜에 포함하는 방향으로 진행 중이지만, 출력에 기반해 프로그래밍할 수 있는 기능은 제공하지 못한다. Fuel의 AA는 소셜 리커버리, 앱이 트랜잭션 수수료를 보조하는 모델, 다양한 서명 스킴을 사용하는 지갑 등과 같은 유스케이스를 가능하게 한다.
모놀리식 체인에서는 사용자가 최대 보안을 위해 풀노드를 실행하여 체인 상태를 검증할 수 있다. 하지만 네트워크가 확장될수록 하드웨어 요구사항이 평균 사용자에게 과도하게 비싸질 수 있으며, 이는 보안 참여 장벽을 높인다. 비트코인 백서에서는 라이트 클라이언트라는 개념을 제시했는데, 이는 풀노드를 최소화한 형태로 부분적인 보안을 제공하며, 풀노드 없이도 블록을 검증할 수 있게 해준다. 이 시나리오에서 사용자는 블록 헤더만 다운로드하고, 시스템의 다수 풀노드/검증자가 정직하게 동작하며 악성 트랜잭션을 거부한다고 가정한다.
Fuel에서는 라이트 클라이언트가 어떤 주체의 정직성을 신뢰할 필요 없이 사기 증명(fraud proofs)을 통해 블록 검증에 참여할 수 있다. 라이트 클라이언트는 중앙화나 확장성 우려를 유발하지 않으면서도 체인의 보안 보장을 강화한다. 이는 사용자 주권(user sovereignty), 낮은 계산 요구량, 높은 보안 보장이라는 목표에 더 가까워지게 한다.
Fuel 네이티브 토큰에 대한 공개 정보는 없지만, 향후 토큰은 스테이킹 및 트랜잭션 챌린지에 사용될 것으로 보이며, 트랜잭션 수수료는 ETH로 지불될 예정이다. 하지만 이더리움의 ETH처럼 하나의 토큰만 ‘1등급(first-class)’ 대우를 받는 계정 기반 시스템과 달리, Fuel에서 민팅되는 어떤 자산이든 네이티브 토큰과 거의 동일한 기능을 얻는다.
FuelVM에서는 어떤 컨트랙트든 일련의 오퍼코드(opcodes)를 통해 UTXO 기반 네이티브 자산을 민팅할 수 있다. 이렇게 생성된 각 토큰은 네이티브 호출 및 최적화의 이점을 상속한다. 어떤 자산도 특별한 네이티브 기능을 독점하지 않는다.
또한 사용자는 계정 기반 블록체인처럼 소유권을 추적하기 위한 토큰 컨트랙트를 사용하지 않고도 자산을 전송할 수 있어, 스마트 컨트랙트 의존성과 잠재적 취약점을 줄일 수 있다. 토큰 컨트랙트는 소각과 민팅을 처리하는 데만 필요하다.
Sway는 Rust에서 영감을 받은 프로그래밍 언어다. FuelVM을 위해 만들어졌으며, 현대적인 프로그래밍 언어 원칙을 블록체인에 도입하면서 Solidity와 Move가 제공하는 것들을 개선하는 것을 목표로 한다. Sway는 구조체(structs), 트레이트 기반 상속(trait-based inheritance), 제네릭 타입(generic types) 등을 포함한 현대적 언어 설계를 제공하여, 개발자가 표현력 있고 확장 가능한 애플리케이션을 작성할 수 있게 한다. 개발자가 Sway에 적응할 수 있도록, 팀은 Sway 코드 빌드·배포·테스트를 위한 Sway 툴체인 Forc를 구축했다. 여기에는 Sway 툴링에 쉽게 접근할 수 있는 패키지 매니저가 포함된다. 그 외 통합 툴링으로는 VSCode 확장, 테스트 인프라, 블록 익스플로러 등이 있다.
Sway의 안전성(safety) 요소는 매우 중요하다. Sway는 잠재적 취약점과 버그를 점검하기 위해 컴파일 타임 분석 패스(compile-time analysis passes)를 제공한다. 예로 컴파일 타임 재진입(reentrancy) 위반 검사 기능이 있다. Sway가 스마트 컨트랙트가 재진입 공격(스마트 컨트랙트에서 자금을 인출하여 비인가 컨트랙트로 반복 전송하는 공격)에 취약하다고 판단하면, 해당 앱은 배포될 수 없다. 이런 기능은 Solidity에서는 제공되지 않으며, 역사적으로 디파이 프로젝트들은 여러 차례 이러한 취약점으로 피해를 입었다.
새 언어가 제공하는 개발자 경험이 어떻든, 새로운 커뮤니티와 툴링에 익숙해지기까지는 시간이 필요하다. Sway 같은 새로운 언어의 채택은, 감사(audit)된 조합 가능한(composable) 코드 기반과 앱을 유지할 유동성(liquidity) 등 ‘활용 가능한 확립된 기반’이 있다고 개발자들이 느낄 때에만 일어난다. Fuel처럼 완전히 새로운 VM의 경우, 개발자 툴링, 비즈니스 개발, 그랜트 프로그램 같은 지속적 노력에도 불구하고 시간이 더 걸릴 가능성이 높다.
여러 팀이 Web3 스택 전반에서 Fuel로(혹은 Fuel 위에서) 개발 중이며, 대부분은 디파이와 기타 소비자 애플리케이션에서 병렬화를 이용해 트랜잭션을 배치(batching)하는 데 집중하고 있다.
Elix는 낮은 슬리피지로 효율적인 거래를 제공하는 데 초점을 맞춘 DEX다. Elix 팀은 Curve의 집중 유동성 풀 같은 검증된 메커니즘에서 원칙을 차용해, 사용자가 이상적인 조건에서 거래할 수 있게 한다. Elix는 Fuel을 사용함으로써 병렬 처리를 활용할 수 있고, 이는 높은 보안 보장 아래 더 빠른 거래를 의미한다.
Thunder는 최소 수수료로 하나의 트랜잭션에서 대량 거래(bulk trades)를 가능하게 하는 NFT 마켓플레이스다. 숙련된 NFT 트레이더에게 이 마켓플레이스는 병렬화를 통한 빠른 트랜잭션 시간과 함께 더 매끄러운 거래 경험으로 보일 것이다.
예상되는 구현 및 스마트 컨트랙트 리스크 외에도, 프로젝트가 초기 단계라는 점에서 몇 가지 핵심 우려가 있다. Fuel은 개발자 유연성과 더 나은 사용성을 위한 실행 레이어를 만들기 위해 다양한 기능을 구현하지만, EVM에서 제공되는 것과 같은 확립된 개발 인프라가 아직 부족하다. 개발자들은 Solidity 기반 컨트랙트만큼 전투 검증(battle-tested) 및 감사가 충분하지 않은 새로운 코드와 도구를 다루는 데 어려움을 겪을 수 있다.
Fuel은 이미 성공한 범용 롤업들과, 메인넷 출시를 앞둔 zkEVM들과 함께 경쟁 레이스에 합류하게 된다. 특히 Arbitrum과 Optimism이 현재 약 30억 달러의 TVL을 확보하고 저렴하고 빠른 트랜잭션을 제공하는 만큼, 기존 옵티미스틱 롤업들과의 경쟁은 치열할 것이다. 기존 L2들과 차별화하기 위해 Fuel은 Fuel에서만 제공되는 네이티브 애플리케이션들을 대거 도입해, 더 효율적이고 안전한 경험을 제공해야 한다.
Fuel은 모듈화, 완전히 새로운 VM, 그리고 UTXO 모델의 파생 효과 같은 기능을 제공하며 높은 대역폭을 목표로 한다. 이는 이더리움 및 일부 제한적인 설계 특징과 차별화되는 지점이다. Fuel의 접근은 이더리움이 아직 제공하지 못하는 애플리케이션과 사용자 경험을 위한 비옥한 토대를 제공한다. 다만 Fuel V2가 메인넷에 출시되어 시장 점유율을 놓고 기존 롤업들과 경쟁하기까지는 시간이 필요할 것이다. 그럼에도 사려 깊은 설계 선택은 장기적 지속가능성을 확보하는 데 도움이 될 수 있다.
이 보고서는 Immutable Foundation의 의뢰로 작성되었다. 모든 콘텐츠는 저자(들)가 독립적으로 작성했으며, Messari, Inc. 또는 보고서를 의뢰한 조직의 견해를 반드시 반영하지는 않는다. 의뢰 조직은 보고서 내용에 대해 의견을 제공할 수 있으나, Messari는 데이터의 정확성과 객관성을 유지하기 위해 최종 보고서에 대한 편집권을 가진다. 저자(들)는 본 보고서에 언급된 암호자산을 보유하고 있을 수 있다. 본 보고서는 정보 제공 목적이며 투자 조언이 아니다. 투자 결정을 내리기 전에 스스로 조사하고, 독립적인 재무·세무·법률 자문가와 상담해야 한다. 어떤 자산의 과거 성과도 미래 결과를 보장하지 않는다. 자세한 내용은 이용약관을 참고하라.
본 보고서의 어떤 부분도 (a) 어떠한 수단으로든 복사, 복제, 사진복사, 중복 제작할 수 없으며, (b) Messari®의 사전 서면 동의 없이 재배포할 수 없다.
