
전체 체인 게임 코어 분석: MUD 엔진과 World Engine
저자: Solaire, YBB Capital

과거 블록체인의 체인 구조적 제약으로 인해 체인 상에서 실용적인 DApp을 구축하는 것은 결코 쉬운 일이 아니었다. 하지만 이러한 제약에도 불구하고 탐험가들은 멈추지 않았고, "x * y = k"라는 유명한 고정 곱 풀 공식이 세상에 등장하면서 수백 줄의 코드로 이루어진 Uniswap은 DeFi를 선도하며 크립토(Crypto) 서사에 근본적인 변화를 가져왔다. 단순한 DApp조차 개발자의 창의성 아래서 이처럼 큰 성과를 거둘 수 있다면, 게임이나 소셜 플랫폼을 완전히 체인 위에 구축하는 복잡한 애플리케이션은 어떨까? 과거에는 미친 생각처럼 보였겠지만, 롤업(Rollups)이 확장성을 열어준 오늘날, 이러한 가능성은 점점 현실감을 더해가고 있다.
DeFi는 크립토에 수천억 달러의 TVL(총 잠금 가치)을 가져왔다. 그보다 훨씬 복잡한 DApp은 어떻게 구현될 수 있을까? 그리고 이것이 다시 한 번 크립토를 새로운 차원으로 이끌 수 있을까? 아마도 초기 단계에 있는 풀체인 게임(Full-Chain Game)이 그 답을 줄 수 있을 것이다. 본문은 풀체인 게임의 역사, 현재 정의, 창작 및 실행 방식, 그리고 크립토 미래에 대한 의미라는 네 가지 측면에서 풀체인 게임을 심층 분석한다.
풀체인 게임의 기원과 발전
풀체인 게임의 역사는 10년 전으로 거슬러 올라간다. Mikhail Sindeyev는 Namecoin을 포크하여 세계 최초의 블록체인 게임인 《Huntercoin》을 개발했다. 《Huntercoin》은 2013년 실험 프로토타입으로 시작되어 금세 많은 온라인 열성 팬들을 확보했으며, 유명한 bitcointalk.org 회원들로부터 지지를 받았다. 기술 애호가들의 비디오 게임 사랑 덕분에 가장 인기 있는 Huntercoin 게시물은 조회 수 38만 회 이상을 기록했다. 그러나 안타깝게도 Mikhail Sindeyev는 2014년 2월 뇌졸중으로 사망했고, 《Huntercoin》의 개발은 중단되었으며, 토큰 HUC는 2015년 거의 제로로 추락했다. 비록 풀체인 게임의 첫 시도는 성공하지 못했지만, 다행히 이야기는 계속되었다.
2020년 Gubsheep(Brian Gu), Alan Luo, SCOTT SUNARTO는 소설 《삼체: 어둠의 숲》에서 영감을 받아 동명의 MMORTS 우주 정복 게임 《Dark Forest》를 개발했다. 이 게임은 이더리움 위에 구축되었으며 모든 규칙과 로직을 스마트 계약에 작성함으로써 모든 행동이 체인 상 트랜잭션이 되는 풀체인 게임이다. 핵심 게임 컨텐츠는 ZK-Snarks(제로 난지 증명) 기술을 활용하여 '전쟁의 안개'를 구현하고, 삼체 소설 속 '어둠의 숲 법칙'(한 행성 문명이 발견되면 반드시 다른 문명의 공격을 받는다)을 재현했다.

예를 들어, 플레이어가 행동을 취할 때 어둠의 숲 법칙 때문에 자신의 좌표를 노출할 수 없으면서 A 행성에서 B 행성으로 이동해야 한다면, 두 좌표를 제출하여 유효성을 입증해야 한다. 그러나 이더리움 블록체인 정보는 완전히 투명하므로, 《Dark Forest》는 다음과 같은 방법으로 정보를 숨긴다. 플레이어는 출발 행성과 목적지 행성을 선택하는데, 이 두 행성의 위치는 플레이어의 개인 정보다. 출발 행성과 목적지 행성 위치의 해시 값을 계산한 후, 이 해시 값을 블록체인에 제출한다. 이 단계에서는 플레이어가 커밋(Commit 단계)을 제출하게 되며, 해시 함수의 일방향성 덕분에 제출된 해시 값만으로는 실제 행성 위치를 알 수 없다. 다음 단계는 검증(Reveal 단계)인데, 여기서 플레이어는 자신의 행동이 유효하다는 제로 난지 증명을 생성하여 제출한다. 이 증명은 누구나 검증 가능하지만, 플레이어의 행성 위치 정보는 전혀 노출되지 않는다.
이렇게 하여 정보가 완전히 투명한 이더리움 위에서도 정보를 숨기는 최초의 풀체인 게임이 탄생했다. 이 광기 어리고도 창의적인 실험은 곧장 전체 크립토 커뮤니티에 센세이션을 일으켰고, 비탈릭 부테린(Vitalik, 이더리움 창시자)은 직접 트위터에서 이를 리트윗하며 칭찬하기까지 했다.
그러나 《Dark Forest》가 출시되자 1만 명 이상의 플레이어가 몰리면서 문제도 드러났다. 이더리움의 성능은 이런 복잡한 애플리케이션을 지원하기에 부족했다. 게임 출시 당일 블록체인이 마비되었고, 수 조 가스(Gas)가 소모됐다. 또한 게임이 DeFi 앱의 라이브러리와 아키텍처를 기반으로 설계되어 있어, 나중에 최적화를 시도해도 고통을 완화할 뿐 근본 해결은 되지 않았다.
이 실험을 통해 ZK-Snarks의 전망과 풀체인 게임의 한계를 깊이 고민한 창시자 Brian Gu는 제로 난지 증명 기술 발전을 위해 연구소인 0xPARC를 설립했다. 0xPARC 산하의 또 다른 팀인 Lattice는 풀체인 게임 엔진 MUD의 설계 및 유지 관리를 맡았다. 다른 공동 창시자 SCOTT SUNARTO는 풀체인 게임 전용 분할 롤업(Rollup) 프레임워크인 World Engine을 개발하기 시작했다.
제로 난지 증명은 오늘날 이미 널리 사용되고 있으며 잘 알려져 있다. 본문에서 주로 다룰 내용은 이후 두 항목인 MUD 엔진과 World Engine, 즉 창조와 실행이다. 다만 그 전에 주도자(0xPARC)가 풀체인 게임에 대해 정의한 개념과 새로운 인식 방식을 이해할 필요가 있다.
자율 세계(Autonomous Worlds)
0xPARC의 암호화 게임 논문집 《Autonomous Worlds》의 주장에 따르면, 풀체인 게임은 적어도 다섯 가지 기준을 따라야 한다:
-
데이터는 블록체인에서 유래한다: 블록체인은 데이터의 보조 저장소일 뿐 아니라 전용 서버에 저장된 데이터의 '미러'도 아니다. 자산 소유권 등의 정보 외에도 모든 의미 있는 데이터가 블록체인에서 접근 가능해야 한다. 이를 통해 게임은 프로그래밍 가능한 블록체인의 장점을 충분히 활용할 수 있다—투명한 데이터 저장, 무허가 상호운용성;
-
논리와 규칙은 스마트 계약으로 구현된다: 예를 들어 게임 내 전투 자체도 체인 상에서 실행된다;
-
게임 개발은 오픈 에코시스템 원칙을 따른다: 게임 계약과 접근 가능한 클라이언트 모두 오픈소스다. 제3자 개발자는 플러그인, 타사 클라이언트, 상호운용 가능한 스마트 계약을 통해 완전히 재배포하거나, 맞춤화하거나, 심지어 자신만의 게임 경험으로 포크(fork)할 수 있다. 이는 다시 게임 개발자가 (동기부여가 일치된) 커뮤니티 전체의 창의적 성과를 활용할 수 있게 한다;
-
게임은 영구적으로 체인에 존재한다: 이는 위 세 가지와 밀접하게 관련된다. 하나의 게임이 진정한 암호화네이티브 게임인지 여부를 판단하는 기준은 바로 "내일 핵심 개발자가 제공하는 클라이언트가 사라져도 게임을 계속 플레이할 수 있느냐?" 하는 질문이다. 대답은 종종 "그렇다"가 된다. 오직 게임 데이터 저장이 무허가이며, 게임 로직이 무허가로 실행 가능하고, 커뮤니티가 핵심 팀의 인터페이스에 의존하지 않고도 핵심 스마트 계약과 상호작용할 수 있을 때만 그렇다;
-
게임은 우리가 가치 있다고 여기는 것들과 상호운용 가능해야 한다: 블록체인은 가치 개념 자체에 대해 로컬 애플리케이션 인터페이스(API)를 제공하며, 디지털 자산은 기본적으로 우리가 관심 있는 다른 자산과 상호운용 가능하다. 이는 게임의 깊이와 의미를 반영할 뿐 아니라, 오히려 그 깊이와 의미를 강화하며 게임 세계를 '실제' 세계와 연결시킨다.
이 기준에 따라 구축된 풀체인 게임은 블록체인을 기반으로 한 세계, 즉 Autonomous Worlds(자율 세계)라고 볼 수 있다.
그렇다면 '세계'란 무엇인가? 세계는 현실 세계만을 가리키는 것이 아니다. 세계의 매체는 소설, 영화, 게임, 시, 혹은 법률 체계일 수 있다. 그러나 이 모든 세계들은 중심(작가, 개발자 또는 집단)이 프레임워크와 규칙을 설정한 후 우리에게 전달한다. 이 세계들 간의 자율성 정도도 다르다. 예를 들어, 오픈 월드 게임으로 유명한 《Minecraft》(《마인크래프트》)는 플레이어에게 매우 높은 자율성을 제공한다. 다양한 블록 조합과 규칙 수정을 통해 플레이어는 자신만의 세계를 창조할 수 있다. 반면 자율성이 낮은 세계는 소설 세계일 수 있는데, 예를 들어 **《Harry·Potter》의 마법 세계는 JK 롤링이 창조한 규칙과 프레임워크에 기반한다.
블록체인을 세계의 기반으로 삼는다면, 블록체인은 상태에 포함된 모든 노드 엔티티의 집합을 명확하게 보관한다. 또한 컴퓨터 코드를 통해 규칙을 형식적으로 정의한다. 블록체인 기반의 세계는 거주자가 합의에 참여하도록 만든다. 이는 컴퓨터 네트워크를 운영하여 새로운 엔티티가 도입될 때마다 합의를 이룬다.
세계의 관점에서 보면, 두 가지 블록체인 개념을 정의할 필요가 있다:
-
블록체인 상태 루트(State Root): 상태 루트는 세계 내 모든 엔티티를 압축한 것이다. 상태 루트를 알면 어떤 엔티티가 가상인지 확인할 수 있고, 세계의 상태 루트를 믿는다는 것은 세계 자체를 믿는다는 것을 의미한다. 0x411842e02a67ab1ab6d3722949263f06bca-20c62e03a99812bcd15dce6daf26e는 2022년 7월 21일 07:30:10PM UTC 기준 이더리움—블록체인 기반 세계의 상태 루트다. 이 상태 루트를 계산할 때, 이더리움 세계의 모든 엔티티가 고려된다. 이는 특정 시점에서 그 세계의 전체 내용을 나타낸다;
-
블록체인 상태 전이 함수(State Transition Function): 각 블록체인은 상태 전이 함수를 정의한다. 이는 명확한 도입 규칙이라고 볼 수 있다. 이는 '세계'의 이전 상태—가상 엔티티의 집합—이 사람과 기계의 입력을 통해 새로운 가상 엔티티를 어떻게 도입하는지를 정의한다. 비트코인의 경우, 상태 전이 함수는 잔액이 주소 사이에서 어떻게 소비되고 이전되는지를 정의한다.
따라서 풀체인 게임을 블록체인을 기반으로 한 세계로 본다면, 이 탈중앙화된 세계는 무한한 자율성을 가지며, 자율 세계라고도 할 수 있다.
창조의 딜레마
초기 풀체인 게임의 새로운 설계를 탐색하는 과정에서 개발자들은 반복적으로 전통적인 DApp 아키텍처와 DeFi 앱 구축용 라이브러리의 한계에 부딪혔다. 《Dark Forest》와 기타 초기 풀체인 게임은 당시 DeFi 앱을 위한 아키텍처와 라이브러리를 따라야 했고, 이들이 풀체인 게임 구축의 기본 선택지가 되었다.
초기 풀체인 게임 개발 패턴은 네 가지로 요약할 수 있다:
-
다양한 계약이 동일한 상태에 접근할 때: 여러 스마트 계약이 동일한 데이터나 상태를 수정하면 데이터 불일치 등의 문제가 발생할 수 있다. 때때로 Diamond Pattern(다이아몬드 패턴, Solidity 스마트 계약의 다중 상속 문제 해결 방법)으로 해결한다;
-
여러 데이터 구조 작성: 각 엔티티(게임 내 병사, 행성 등)마다 고유한 데이터 구조와 타입을 갖는다;
-
Getter 함수 작성: 이는 데이터 구조로부터 배치 요소를 반환하는 함수로, 체인에서 초기 상태나 데이터를 가져오는 데 사용된다. 예를 들어 getPlanets() 함수는 모든 행성 목록을 반환할 수 있다;
-
이벤트: 각 데이터 구조는 이벤트를 포함하는데, 이는 스마트 계약의 특정 기능으로, 새 블록이 체인에 추가될 때 앱이 상태를 동기화하거나 업데이트할 수 있도록 한다. 예를 들어, 새로운 행성이 생성되면 이벤트가 발생하고, 앱은 이를 감지하여 표시되는 행성 목록을 업데이트한다.
이런 방식으로 풀체인 게임을 구축하는 것은 매우 고통스러웠다. 지속적인 최적화로 고통을 완화할 수는 있지만, 이런 구축 방식은 진정한 범용 엔진을 사용하는 것과는 아직 멀었다.
세계의 창조자—MUD 엔진

MUD 엔진은 개발자들이 과거와 현재의 문제를 고민한 결과 탄생했다. MUD는 복잡한 애플리케이션을 구축하기 위한 이더리움 앱 프레임워크다. MUD는 데이터와 로직을 조직하는 규칙을 제공하고 저수준 복잡성을 추상화함으로써 개발자가 앱 기능에 집중할 수 있도록 한다. 또한 체인 상 데이터 저장 방식을 표준화한다. 이러한 표준 데이터 모델 덕분에 MUD는 계약과 클라이언트 상태를 동기화하는 모든 네트워크 코드를 제공할 수 있다.
현재 MUD 최신 버전은 다섯 가지 구성 요소를 갖추고 있다:
-
Store: 체인 상 데이터베이스;
-
World: 표준화된 접근 제어, 업그레이드, 모듈을 제공하는 진입점 프레임워크;
-
tools: Foundry 기반 초고속 개발 도구;
-
클라이언트 데이터 저장소: 체인 상 상태를 마법처럼 반영;
-
MODE: SQL 쿼리를 사용할 수 있는 Postgres 데이터베이스.
EVM 완전 호환성과 극도의 자유도
MUD의 범용성은 이더리움 메인넷에만 국한되지 않는다. 언어가 지원된다면 MUD는 Polygon, Arbitrum, Optimism, Gnosis Chain 등 EVM 호환 체인 어디에서나 원활하게 작동할 수 있다.
또한 MUD는 자율 세계(Autonomous Worlds)와 체인 상 게임 커뮤니티에서 선호되는 프레임워크이지만, 그 응용은 훨씬 광범위하다. 동시에 MUD는 개발자를 특정 데이터 모델에 얽매이지 않도록 높은 자유도를 제공한다. 간단히 말해, Solidity의 맵과 배열로 구현 가능한 모든 기능은 MUD에서도 쉽게 구현 가능하다. 데이터 가용성 측면에서도 메인넷이나 롤업에 배포된 MUD 앱은 ENS, Uniswap 등의 전통적인 이더리움 앱과 견줄 만하다.
핵심 아이디어
MUD는 체인 상 복잡한 애플리케이션을 위해 설계된 고도로 협업된 라이브러리와 도구 세트로서, 세 가지 핵심 아이디어를 중심으로 한다:
-
모든 체인 상 상태는 MUD 체인 상 데이터베이스 Store에 저장된다: Store는 SQLite 데이터베이스와 유사한 내장형 EVM 데이터베이스로, 테이블, 열, 행 개념을 갖춘다. Store를 사용하면 데이터를 더 구조화해 관리할 수 있으며, Solidity 컴파일러가 제공하는 저장 방법에 의존할 필요가 없다. 또한 런타임에 테이블 생성을 지원하고, 인덱스 뷰를 자동 생성하기 위한 훅(hook)을 등록할 수 있어 유연성이 높다;
-
로직은 상태 독립적이며, 사용자 정의 권한을 통해 서로 다른 계약으로 분할된다: "World"는 진입점 역할을 하며, 다양한 스마트 계약이 "Store"에 접근하는 것을 조정한다. "World"가 배포되면 자동으로 "Store"가 생성되고, "Store" 내 각 테이블은 특정 네임스페이스 하에 등록된다. 기능(예: 주소 간 송금 로직)이 "World"에 추가되면 이 역시 네임스페이스 하에 등록되며 "시스템(system)"이라 불린다. 이 "시스템"들은 실제로 스마트 계약이지만, 전통적인 스마트 계약과 달리 상태 독립적이며 직접 데이터를 보유하지 않는다. 대신 "World Store"를 이용해 데이터를 읽고 쓴다. 이러한 설계 덕분에 동일한 체인에 배포된 한 "시스템"은 서로 다른 "World" 간에 재사용이 가능하다;
-
인덱서나 서브그래프 없이도 프론트엔드가 동기화 가능: Store(및 확장된 World)를 사용하면 체인 상 데이터가 자동으로 내부 검사를 수행(Introspection)하고, 모든 변경 사항은 표준 이벤트를 통해 방송된다. "MODE" 노드를 통해 체인 상 상태가 실시간으로 SQL 데이터베이스로 변환되어 최신 상태를 유지한다(밀리초 단위 지연). 또한 MUD는 MUD QDSL, GraphQL 등 일련의 쿼리 도구를 제공하여 프론트엔드 동기화를 단순화한다. React 개발자를 위해선 전용 Hooks도 제공하여 컴포넌트 상태를 자동으로 바인딩하고 업데이트할 수 있다.
제약을 깨다
세 가지 핵심 아이디어를 바탕으로, 과거의 어려움을 예로 들어 MUD가 어떻게 복잡한 애플리케이션의 제약을 깨뜨리는지 살펴보자.
-
다양한 계약이 동일한 상태에 접근할 때: "World"와 "Store" 구조를 사용해 체인 상 상태를 중앙 집중적으로 관리한다. 모든 스마트 계약("시스템")은 "World"를 통해 "Store"의 데이터에 접근하고 수정한다. 이를 통해 모든 상태 변경이 중앙 진입점을 거쳐 데이터 불일치나 충돌 위험이 줄어든다. 네임스페이스와 경로를 통해 MUD는 데이터에 대한 세밀한 접근 제어를 제공한다. 서로 다른 "시스템"은 서로 다른 권한을 갖고, 특정 데이터나 상태를 수정할 수 있는 권한이 있는 "시스템"만이 수정할 수 있도록 보장한다;
-
데이터 구조: 전통적인 Solidity 저장 방식과 달리, MUD의 "Store"는 SQLite와 유사한 테이블, 열, 행 개념을 제공하여 데이터를 더 구조화해 저장하고 관리할 수 있다. 각 엔티티(병사, 행성 등)는 자신만의 테이블을 갖고, 각 테이블은 해당 엔티티의 다양한 속성을 저장하기 위해 여러 열을 가질 수 있다;
-
Getter 함수: MUD의 "Store"가 구조화된 데이터 저장을 제공하므로 데이터를 가져오는 것이 훨씬 간단하고 직관적이다. 개발자는 전용 getter 함수를 작성하지 않고 SQL과 유사한 쿼리 언어를 사용해 데이터를 가져올 수 있다. 예를 들어 모든 행성을 가져오려면 행성 테이블을 간단히 쿼리하면 되고, getPlanets() 함수를 작성할 필요가 없다;
-
이벤트: MUD는 자동 내부 검사 기능을 제공하므로, 데이터 변경 사항이 자동으로 시스템에 의해 인식되고 해당 이벤트가 발생한다. 앱은 이러한 이벤트를 감지해 상태를 동기화하거나 업데이트할 수 있으므로, 각 데이터 구조마다 수동으로 이벤트를 정의할 필요가 없다.
이상은 MUD의 기본 구성 요소와 일부 사용 방법에 대한 설명이다. MUD는 더 복잡한 시나리오와 애플리케이션도 구축할 수 있다.
세계를 운용하다, World Engine
풀체인 게임의 운용은 이더리움에게 항상 큰 도전이었다. 롤업의 급속한 발전과 캔쿤 업그레이드가 다가옴에 따라, 앞으로는 비용이 크게 낮아지고 속도가 크게 향상될 전망이다. 풀체인 게임은 이제 출발 준비를 마쳤다. 그러나 현재 주류 롤업은 대부분 거래를 위해 설계되었으며, 풀체인 게임을 위해 특별히 만들어진 롤업은 없다.
Argus 산하의 핵심 제품인 World Engine은 풀체인 게임을 위해 진정으로 설계된 샤딩 아키텍처 롤업이다. 아직 공개 테스트가 없어, 이 글에서는 프로젝트의 블로그와 발표를 통해 World Engine을 분석하겠다.
풀체인 게임에 필요한 롤업은?
-
높은 처리량과 높은 TPS: 빠른 트랜잭션 처리, 낮은 지연 시간, 뛰어난 확장성;
-
읽기 및 쓰기 확장성: 대부분의 레이어2는 고 동시성 처리를 위해 대량 쓰기를 설계하지만, 게임은 플레이어 위치를 읽어야 하므로 읽기도 쓰기만큼 중요하다;
-
수평 확장 가능한 체인: 수평 확장성은 더 많은 노드와 리소스를 추가해 시스템 처리 능력을 높이고 성장하는 수요에 적응하는 것을 말한다. 이를 통해 Noisy Neighbor 문제(한 애플리케이션이 다른 애플리케이션에 부정적 영향을 미쳐 리소스 경쟁과 성능 저하를 일으키는 현상)를 피할 수 있다;
-
유연성과 맞춤화: 유연성과 맞춤화를 통해 상태 머신을 쉽게 수정하고 게임 설계에 적합하게 만들 수 있다. 예를 들어 게임 루프를 포함해 스스로 실행되도록 하는 것 등;
-
틱률(Tick rate): 틱(tick)은 게임 시간의 원자 단위이며, 게임이 충분히 낮은 지연을 원한다면 더 높은 틱률 또는 초당 더 많은 블록이 필요하다.
샤딩 아키텍처
위 목표를 달성하기 위해 팀은 21세기 초와 20세기 90년대 후반의 초기 온라인 게임, 특히 MMOs의 부흥기를 참고해 영감을 얻었다. 초기 온라인 게임은 서버와 네트워크 기술이 제한적인 상황에서 많은 플레이어의 상호작용을 지원하기 위한 방법을 찾아야 했다. "샤딩(sharding)"은 그 해결책 중 하나였다. 핵심 아이디어는 플레이어를 서로 다른 서버 또는 "샤드(shard)"에 분산시키는 것으로, 각 샤드는 독립적으로 일정 수의 플레이어, 게임 맵, 데이터를 호스팅할 수 있다.
예를 들어 Ultima Online은 초기 MMORPG로, 서버에 샤딩 개념을 구현했다. 게임 내 다른 샤드는 서로 다른 가상 세계를 나타내며, 각 샤드는 일정 수의 플레이어를 수용할 수 있다. 이렇게 하는 장점은 다음과 같다:
-
확장성: 플레이어를 다른 샤드에 분산시킴으로써 게임은 더 많은 플레이어 수용에 더 쉽게 확장할 수 있다;
-
부하 감소: 샤드는 단일 서버의 플레이어 수와 데이터량을 줄여 서버 부하를 낮추고 성능을 향상시킨다;
-
혼잡 방지: 샤드는 동일 지역 내 플레이어의 혼잡을 줄여 더 원활한 게임 경험을 제공한다;
-
지리적 최적화: 플레이어를 가까운 샤드에 배정함으로써 네트워크 지연을 줄이고 게임 반응 속도를 높일 수 있다.
그렇다면 이 개념을 World Engine에 어떻게 적용할 수 있을까? 과거의 많은 샤딩 정렬기와 달리, "World Engine"의 설계는 특정 요구에 더 적합하다. 최적화 방향은 처리량과 실행 시간이다. 효율적인 "틱률"(초당 업데이트 빈도)과 블록 시간을 보장하기 위해 기본적으로 동기식이다. 설계 목표는 트랜잭션이 신속하게 처리되어 효율적인 게임 경험 또는 시스템 성능을 유지하는 것이다. 정렬 방식은 전체 정렬을 강제하지 않고 부분 정렬 방식을 채택한다. 즉, 각 트랜잭션이 다른 모든 트랜잭션 뒤에 발생해야 한다는 것을 요구하지 않는 것이다. 이는 정렬 부담을 줄여 높은 처리량과 빠른 블록 시간의 요구를 더 잘 충족시킨다.
여기서 핵심은 두 가지 구성 요소, EVM Base Shard(EVM 샤드)와 Game Shard(게임 샤드)다. EVM 샤드는 순수한 EVM 체인이다. 진정한 핵무기는 게임 샤드로, 본질적으로 고성능 게임 서버처럼 설계된 미니 블록체인이다. World Engine은 bring-your-own-implementation 인터페이스를 갖추고 있어, 사용자의 취향에 따라 이 샤드를 맞춤화할 수 있다. 구축한 샤드를 기반 샤드에 주입할 수 있다. 표준 인터페이스만 구현하면 되는데, 우리가 익숙한 Cosmos처럼, Cosmos는 IBC 인터페이스를 갖추고 있다. 우리는 이것을 유사한 사양으로 통합할 수 있으며, 자신의 샤드를 World Engine 스택에 가져올 수 있다.
Cardinal은 World Engine의 첫 번째 게임 샤드 구현체다. Entity-Component-System(ECS) 게임 아키텍처를 사용하며, 데이터 중심 아키텍처이다. 이를 통해 게임을 병렬화하고 게임 계산 처리량을 높일 수 있다. 구성 가능한 "틱률"을 갖고 있으며, 최대 초당 20회 틱을 지원한다. 블록체인 관점에서는 초당 20개 블록을 의미한다. 또한 자체 색인화(self-indexing) 기능을 갖추고 있어 외부 인덱서가 필요 없다.
또한 샤드는 지리적 위치 기반으로 지연을 줄일 수도 있다. 예를 들어, 정렬기가 미국에 있다면 아시아 플레이어는 트랜잭션이 정렬기에 도달할 때까지 300밀리초 지연을 겪어야 한다. 게임에서는 이는 큰 문제다. 300밀리초는 매우 긴 시간이며, 200밀리초 지연의 FPS 게임을 플레이하려 한다면 사실상 PPT를 보는 것과 다름없다.
결론: 풀체인 게임에 대한 사고
풀체인 게임은 아시아 암호화폐 커뮤니티 내에서 비교적 냉담한 분야였지만, Starknet의 게임 엔진 Dojo 출시와 OP Stack 기반 개념 검증형 틱(tok) 체인 개발 시연을 계기로 점점 논의가 활발해지고 있다. 본문에서 다룬 범위는 《Dark Forest》에서 파생된 생태계로, 현재 풀체인 게임 생태계 중 가장 강력한 편이다.
역사적, 기술적 측면에서의 탐구를 통해 롤업과 DApp이 여전히 매우 높은 성장 잠재력을 가지고 있음을 알 수 있다. 더 먼 시각에서 보면, 인프라가 향상됨에 따라 게임뿐만 아니라 다양한 복잡한 아이디어들도 MUD를 통해 구축되고, 더욱 복잡한 롤업 방식 위에서 융합 및 상호작용할 수 있을 것이다. 블록체인의 새로운 패러다임은 풀체인 게임에서 시작될지도 모른다.
풀체인 게임에 대해서는 확장 가능한 내용이 많다. 예를 들어 Loot에서 파생된 풀체인 게임 생태계가 Starknet 발전을 촉진시켰으며, 상태 동기화 구현, ECS 아키텍처 활용 등이 있다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News














