Blade Games는 ZK 게임 엔진을 출시했습니다: 신뢰 없는 게임 제작

산업 속보

2024-03-15 18:05:13

수집

ZK 신뢰 없는 게임(Trustless Game)은 전체 체인 게임의 다음 물결을 이끌 것입니다.

위챗으로 스캔하기

저자: Blade Research, Delphinus Lab

ZK 신뢰 없는 게임(Trustless Game)은 전체 체인 게임의 다음 물결을 이끌 것입니다.

요약:

Blade Games와 Delphinus Lab이 협력하여 WebAssembly와 zkWASM 기반의 신뢰 없는 zk 게임 엔진(trustless game engine)을 개발했습니다.

우리의 zk 게임 엔진은 타워 디펜스, RPG 등 저속 실시간 게임 카테고리와 방치형 게임, 카드/자동 전투 게임, 인터랙티브 소설 등 다양한 게임 유형을 지원합니다. 간단히 말해, 우리는 게임의 논리를 zkWASM 내에서 실행(계산을 처리하는 "zk 서버")하고, 각 게임의 결과는 zkSNARK 증명을 생성하여 발표합니다. 이 게임 엔진은 C++, Go, Rust 등 언어를 지원하며, 곧 C# 및 Unity 지원도 출시될 예정입니다.

타워 디펜스 게임을 예로 들면, 전형적인 6분 길이의 100파의 괴물과의 한 판의 타워 디펜스 게임에서 총 zkSNARK 증명 생성 시간은 약 3분입니다. 이는 초기 결과일 뿐이며, 우리는 증명 생성 시간을 빠르게 최적화하고 있습니다. (100만 개 명령어의 ZKP 생성 시간은 19초이며, 각 괴물 파는 8만 개 명령어, 한 판 게임은 800만 개 명령어, 8개의 zkSNARK 증명이 클라우드 계산에서 생성되는 시간은 약 3분입니다).

ZKVM 기반의 신뢰 없는 게임에서 유지 비용은 주로 ZK 증명 생성, RPC/호출 데이터 접근 서비스, 체인 상 검증 및 정산 비용에서 발생합니다. 캉쿤 업그레이드(EIP 4844)가 L2에서 시행됨에 따라 신뢰 없는 게임 운영 비용이 크게 줄어들었습니다.

또한, 향후 zkSNARK 증명 재귀(proof recursion) 및 Nebra의 증명 집계 서비스(proof aggregation)를 구현함으로써 ZKP 비용을 더욱 낮출 수 있습니다.

우리의 게임 파트너에는 다음이 포함됩니다:

Dune Factory（@BladeGamesHQ）：황무지 펑크 스타일의 기지 건설 + 타워 디펜스 전략 게임

0xPioneer：'Don't Starve'와 유사한 다중 사용자 온라인 생존 게임

Craftpunk：우주를 테마로 한 오픈 월드 RPG 게임으로, 개조 가능한 우주선과 프로그래밍 생성 맵을 특징으로 합니다.

본문:

이 ZK 게임 엔진은 Blade Games와 Delphinus Lab이 공동 개발하였으며, 본 기사는 양측이 공동 집필하였습니다. 이 글은 더 많은 웹2 게임 개발자와 전체 체인 게임 개발자가 ZK 게임 엔진의 장점과 개발 경로를 이해하는 데 도움이 되고자 합니다.

이것은 신뢰 없는 Web3 브라우저 게임 개발에 대한 가이드입니다. (추가 내용은 https://www.youtube.com/watch?v=dLZbfTWLGNI에서 확인할 수 있으며, 주석은 https://delphinuslab.com/wp-content/uploads/2023/04/zksummit-presentation-zkwasm-game-1.pdf에서 확인할 수 있습니다.)

Web3의 발전과 함께 전체 체인 게임이 다시 우리의 시야에 들어왔습니다. 이들은 탈중앙화, 투명성, 무신뢰 및 커뮤니티 거버넌스에서 더 우수하다고 주장합니다. 그러나 전체 체인 게임은 블록체인의 탈중앙화, 보안성, 확장성의 딜레마를 물려받습니다. 이는 게임 개발자가 전체 체인 게임의 내러티브에서 게임 콘텐츠, 상호작용 빈도, 탈중앙화, 무신뢰 및 커뮤니티 공정성 관리를 다루는 문제에 직면하게 됨을 의미합니다.

따라서 지난 주기 동안 게임 개발자는 아키텍처 수준에서 몇 가지 타협을 이루었고, 널리 알려진 Web2.5 게임 아키텍처를 도입했습니다.

보다 정확하게 말하면, Web2.5는 Web3와 전통 게임을 혼합한 포괄적인 용어입니다. Web2.5는 게임 플레이의 콘텐츠를 강조합니다. 왜냐하면 그들은 게임의 주요 청중이 여전히 Web2에 뿌리를 두고 있다고 믿기 때문입니다. 동시에 그들은 게임에서 Web3 요소(NFT, 경제 모델, 게임 내 수익)를 추가하여 게임을 돋보이게 합니다.

표준 Web2.5 게임 아키텍처는 다음과 같을 수 있습니다:

왼쪽 그림은 게임 엔진이 게임의 상태 기계에 대한 제어와 플레이어 활동에 대한 반응을 보여줍니다. 오른쪽 그림은 게임 상태의 일부 변화와 체인 상에서 가장 가치 있는 데이터들을 드러냅니다.

게임의 핵심 플레이는 대부분 중앙 집중식 게임 서버에서 실행되며, 가장 가치 있는 데이터(NFT, 토큰 보상, 기록 등)는 블록체인에서 추적됩니다.

이 아키텍처의 장점은 게임 서버가 대량의 사용자 거래를 중앙 집중식으로 처리할 수 있다는 것입니다. 이러한 거래는 몇 초 내에 완료될 수 있습니다. 또한 중앙 집중식 서버는 복잡하고 지속적인 게임 플레이를 처리할 수 있으며, 원주율 블록체인에서 이러한 플레이를 처리하는 비용은 너무 높습니다.

그러나 이 아키텍처에서는 게임 엔진과 체인 상 프로토콜 간의 통신 채널이 일반적으로 서명으로 보호되므로 신뢰 없는 것은 아닙니다. 또한 게임 콘텐츠는 커뮤니티와의 합의 없이 변경될 수 있으며, 이는 때때로 기존 플레이어의 기득권을 해칠 수 있습니다(예: 게임 경제 업데이트, 콘텐츠 업데이트 또는 보상 시스템 업데이트).

또한 체인 상 데이터는 블록체인으로 전달된 데이터가 게임 플레이의 유효한 결과인지 확인하기 어렵습니다. 서버는 직무를 이용하여 플레이어 행동을 차별적으로 처리할 수 있습니다(예: 게임 개발자의 개인 계정을 편애하는 방식으로).

Web2 게임은 일반적으로 콘텐츠와 게임 플레이에서 뛰어난 성과를 보이므로, 균형과 공정성을 게임 제공자에게 맡기는 것이 허용됩니다. 그러나 Web2 게임이 Web3 생태계에 진입하기로 결정하면, 경제, 소유권 및 게임 과정에서 가치를 포착하는 것에 더 관심이 있는 암호화 원주율 플레이어를 유치해야 할 수도 있습니다. 이 플레이어들은 게임을 통해 풍부한 결과를 얻는 과정을 즐길 뿐만 아니라, 게임에서 얻은 결과가 의미가 있기를 원합니다(예: "지속 가능성") 또는 심지어 가치 상승 속성을 갖기를 원합니다. 상대적으로, "지속 가능성"의 가치 상승 효과에 대한 기대는 플레이어가 게임 내 선택을 더욱 진지하게 고려하게 만듭니다. 이는 플레이어가 게임 내에서의 사고와 결정 비용이 더 높아지며, 게임 규칙의 공정성과 예측 가능성에 대한 기대를 더욱 심화시킵니다.

결국 플레이어는 게임의 "Web3 특성"을 어떤 방식으로든 통제할 수 있기를 요구할 것입니다. 즉, 공정성과 신뢰 없는 특성은 운영자/게임 개발자가 아니라 정해진 코드 세트에 의해 실행되어야 하며, 이를 통해 더욱 탈중앙화되고 완전히 체인 상에서 구축된 게임을 달성해야 합니다.

이에 대한 간단한 조치는 위 그림의 왼쪽에 있는 모든 내용을 오른쪽 그림(블록체인)으로 이동하는 것입니다. 아키텍처는 다음과 같이 됩니다:

명백히 이 조치는 게임 플레이의 많은 "퇴화"를 초래할 것입니다:

플레이어의 각 행동은 체인 상 서명을 통해 그들의 승인을 나타내야 합니다.
블록체인에서 실행되는 게임 엔진의 규모는 제한됩니다.
많은 가스 비용을 지불해야 합니다.
플레이어와 게임 간의 상호작용 빈도는 블록체인의 TPS(초당 거래 수) 제한에 맞추어 줄어들어야 합니다.

이것이 복잡하지만 풍부한 콘텐츠를 포기해야 한다는 것을 의미할까요? "전체 체인 철학"을 추구하기 위해서요?

제로 지식 가상 머신 기술이 등장하기 전에는 답이 "예"일 수 있었습니다. 그러나 제로 지식 가상 머신 기술이 현재 광범위하게 연구되고 적용되고 있다는 사실을 고려할 때, 우리는 "세 번째 방법"을 갖게 되었습니다. 즉, 완전히 체인 상의 게임과 신뢰 없는 계산을 결합하는 것입니다. 이것은 어떻게 이루어질까요?

ZKVM, 즉 제로 지식 가상 머신은 제로 지식 증명과 가상 머신 기술을 결합한 개념입니다. 이를 이해하기 위해 다음 두 모듈을 분해해 보겠습니다:

제로 지식 증명(ZKP): 이는 한 쪽이 다른 쪽에 특정 값을 알고 있음을 증명할 수 있게 해주는 암호화 방법입니다(예: 키). 동시에 해당 값에 대한 어떤 정보도 누설하지 않습니다. 제로 지식 증명은 거래나 상호작용에서 개인 정보와 보안을 동시에 보호할 수 있습니다. 왜냐하면 실제 데이터를 공유하지 않고도 진술의 진위를 검증할 수 있기 때문입니다.
가상 머신(VM): 가상 머신은 물리적으로 컴퓨터의 소프트웨어 시뮬레이션입니다. 운영 체제와 응용 프로그램을 실행합니다. 현실의 컴퓨터와 마찬가지로 완전히 소프트웨어로 구현됩니다. 가상 머신은 클라우드 컴퓨팅과 단일 컴퓨터에서 여러 운영 체제를 실행하는 데 널리 사용됩니다.

이 두 가지를 결합하여 보면, 제로 지식 가상 머신(ZKVM)은 프로그램이나 계약을 실행할 수 있는 가상 머신이며, 제로 지식 증명의 개인 정보 보호 및 보안 이점을 제공합니다. 이는 우리가 zkVM 내에서 게임 엔진(또는 게임 서버)을 실행하고 zkVM을 사용하여 ZK 증명을 생성하여 블록체인에 게임 논리에 의해 강제 실행된 상태의 다양한 데이터의 실행 결과를 증명할 수 있음을 의미합니다. 따라서 게임 서버는 기본 블록체인에 전송되는 데이터를 조정할 수 없습니다.

이에 따라 전체 체인 게임의 통합 아키텍처는 다음과 같을 수 있습니다:

우리는 이러한 신뢰 없는 전체 체인 게임을 "Trustless Game"이라고 부릅니다.

2. Trustless Game 개발 시 고려해야 할 요소

2.1 초보자 필독

게임 개발은 일반적으로 복잡한 기술, 귀중한 창의성 및 프로젝트 관리 문제를 포함하기 때문에 어려운 일로 여겨집니다. Trustless Game에 ZKVM 기술을 적용할 때 고려해야 할 요소는 다음과 같습니다:

기술 복잡성: Trustless Game에서 게임의 논리는 게임의 시각화와 분리되어야 하며, 논리는 결정적이어야 ZKVM이 증명을 생성할 수 있습니다. 또한 증명은 실행해야 하는 언어 조각에서 생성되므로, 게임 개발자는 게임 플레이를 실행 조각으로 나누고 정기적으로 체인 상 계약과 동기화하여 실행해야 합니다.

예술 및 디자인: 일반적으로 아티스트와 디자이너의 작업은 Trustless Game과 다른 게임에서 다르지 않습니다. 그들의 작업은 증명되어야 하는 논리에 속하지 않기 때문입니다. Trustless Game에서 시각화 개발은 게임의 전반적인 상태를 기반으로 해야 하며, UI/UX는 플레이어 활동을 수집하는 도구로 사용됩니다.

전체 게임 경험: 일반적인 전체 체인 게임과 달리 플레이어는 매번 이동할 때마다 체인 상 행동을 서명할 필요가 없으므로 "빈번한 상호작용형 게임"을 만드는 가능성이 높아집니다. 즉, 플레이어가 빈번하게 상호작용해야 하거나 장려하는 게임을 의미합니다.

그러나 ZKVM의 증명 생성 시간 제한으로 인해 높은 빈도의 상호작용은 ZKVM에서 실행되는 Trustless Game 게임에서는 여전히 불가능합니다. 예를 들어 RTS(실시간 전략 게임) 및 MOBA(예: DOTA)와 같은 게임에서는 플레이어가 지속적으로 유닛과 자원을 조작하고 전략을 조정해야 하므로 이러한 유형의 게임은 ZKVM 기반으로 개발하기 어렵습니다.

반대로, 시뮬레이션 게임 및 방치형/농장형 게임에서는 플레이어가 정기적으로 자원을 조정하고, 시장 행동에 참여하거나 캐릭터를 조작하여 게임 내 성장에 도달해야 합니다. 이러한 게임 장르는 Trustless Game에 매우 적합합니다.

또한 인터랙티브 스토리 게임과 비주얼 노벨도 좋은 선택입니다. 이러한 게임은 지속적인 상호작용이 필요하지 않을 수 있지만, 지속적으로 발생하는 결정 포인트를 통해 플레이어를 끌어들이고 이야기를 형성하며 플레이어의 선택에 따른 결과를 보기 위해 빈번한 상호작용을 장려합니다.

이제 화폐화와 지속 가능성에 대해 이야기해 보겠습니다.

일반적으로 게임의 콘텐츠는 시간이 지남에 따라 발전하여 새로운 플레이어를 유치하고 기존 플레이어를 유지합니다. 이는 게임 플레이의 논리를 동적으로 만들어 ZKVM에서 실행되는 프로그램에 영향을 미칩니다. 이로 인해 발생하는 결과 중 하나는 검증 계약이 변경될 수 있으며 업데이트가 필요하다는 것입니다.

ZK 검증이 필요한 계약의 빈번한 변경을 피하는 두 가지 방법은 다음과 같습니다:

게임 플레이의 변경: 게임 플레이를 추상화하여 프로토콜 계층을 만들고 게임의 이러한 동적 특성을 규칙으로 정의합니다. 이렇게 하면 개발자들은 이러한 규칙 세트를 체인 상에 저장하고 이 규칙을 체인 상 해시로 제출할 수 있습니다. 동시에 게임 엔진이 게임 논리를 실행할 때 현재 규칙 세트의 해시가 약속과 일치하는지 확인한 후 그에 따라 행동할 수 있습니다.
정산의 변경: 보상 시스템은 게임 플레이 자체의 독립적인 계층으로 설정할 수 있습니다. 모든 보상 알고리즘을 게임 플레이에서 생성된 특정 이벤트의 콜백으로 간주할 수 있습니다. 이렇게 하면 보상 콜백을 체인 상에 두고 게임 이벤트에 따라 이러한 콜백을 호출할 수 있습니다.

예를 들어, 다음과 같은 게임 루프가 있습니다:

zkgame {

// 게임 논리

output(events)

}

생성된 이벤트는 실행의 증명 인스턴스가 됩니다. 따라서 우리는 콜백을 계약에 추가할 수 있습니다:

function verify(

bytes calldata events_data,

uint256[] calldata proof,

uint256[] calldata verify_instance,

uint256[] calldata aux,

uint256[][] calldata instances,

RidInfo calldata ridInfo

) public {

…

// events_data가 instances에 있는 해시와 일치하는지 확인합니다.

require(instances.eventshash = hash(eventsdata))

// zk 검증 수행

verifier.verify(proof, verify_instance, aux, instances);

// 이벤트에 대한 보상 논리를 처리하기 위해 콜백 호출

uint256 sideEffectCalled = performtxs(eventsdata, ridInfo.batch_size);

…

}

2.2 게임 실행 논리는 어디에 두어야 할까요?

게임 논리는 주로 두 곳에서 실행됩니다: 프론트엔드 또는 서버 측.

게임 논리를 프론트엔드에 두는 것은 클라이언트-서버(Client-Server) 구조에 비해 게임 아키텍처를 단순화합니다. 이 방법은 프론트엔드가 게임을 시뮬레이션하고 실행 경로가 설정된 후 제로 지식 증명(zk-proof)을 생성할 수 있게 해줍니다. 이후 로컬 zk-prover 또는 원격 증명 서비스를 사용하여 제로 지식 가상 머신(ZKVM)을 위한 ZK 증명을 생성합니다. 그런 다음 이 증명을 기본 블록체인에 업로드하여 정산 계약을 트리거합니다.

반대로 게임 논리를 서버 측에 두는 것은 게임 시뮬레이션과 사용자 간의 상호작용을 더 전문화된 구성 요소(게임 서버)로 이동시키는 것을 의미합니다. 이는 전체 게임 경험을 개선하는 데 다음과 같은 방식으로 기여할 수 있습니다:

더 나은 동기화 효과의 게임 플레이: 서버 측 시뮬레이션은 모든 플레이어가 가능한 한 동기화된 방식으로 게임을 경험하도록 보장합니다. 다중 사용자 게임의 경우, 연결된 모든 클라이언트에서 일관된 게임 상태는 일관되고 경쟁적인 게임 경험에 필수적입니다.
더 나은 자원 관리: 프론트엔드는 콘텐츠 렌더링 및 UI/UX에 집중할 수 있으며, 서버는 중앙 집중식 순서 제어기 및 머클 트리 저장소 제공자로 작용할 수 있습니다.

역사 데이터가 필요 없고 비교적 간단한 순서 논리를 가진 단일 플레이어 PVE 게임(또는 다중 사용자 PVP 게임)의 경우 모든 내용을 프론트엔드에 두는 것이 좋은 선택입니다. 다중 사용자 SLG(시뮬레이션 게임) 또는 AW(자율 세계) 게임과 같은 복잡한 게임의 경우 서버 측 게임이 더 나은 성능을 보입니다.

2.3 게임 개발 아키텍처 선택

전통적인 게임 개발과 ZKVM을 결합하기 때문에 도구 선택을 신중하게 고려해야 합니다.

개발 언어

먼저 전통 프로그래밍 언어인 C#, Rust, C, C++, Go를 사용하여 게임을 개발할 것인지, ZKVM 전용 언어를 사용할 것인지 결정해야 합니다.

전통 프로그래밍 언어의 백엔드 바이트코드는 일반적으로 MIPS, WASM, RISC-V, x86입니다. 이러한 바이트코드를 지원하는 ZKVM이 많지 않기 때문에, 프로그램이 RISC-V 바이트코드로 컴파일될 수 있다면 Risc0를 기본 ZKVM으로 선택할 수 있으며, WASM으로 컴파일될 수 있다면 zkWASM을 기본 ZKVM으로 선택할 수 있습니다.

WebAssembly(WASM)는 고급 언어(C, C++, Rust 등)의 컴파일 대상인 저수준 바이트코드 형식입니다. 이는 이러한 언어로 작성된 코드가 웹에서 거의 네이티브 속도로 실행되도록 설계되었습니다. WebAssembly는 웹 브라우저에서 성능이 중요한 코드를 실행하는 방법을 제공하며, 웹 애플리케이션의 보안성이나 속도를 희생하지 않습니다. 이는 현대 웹 기술 스택의 핵심 부분으로, 개발자가 JavaScript 외의 다른 언어를 사용하여 웹 개발을 할 수 있도록 보완합니다.

게임 엔진

프로그래밍 언어를 선택한 후, 선택한 언어에 기반한 게임 엔진을 선택할 수 있습니다. ZKVM 전용 언어를 선택한 경우, 해당 언어에 대한 성숙한 프레임워크가 없을 수 있으므로 자체 게임 개발 프레임워크를 만들어야 할 수도 있습니다. Rust, C, TypeScript 등의 언어를 사용하는 경우, 선택할 수 있는 많은 프레임워크가 있으며, 그 중 Unity와 Cocos2D를 추천합니다.

증명 생성 비용

일반적으로 증명 비용은 100만 개 명령어의 증명 시간으로 측정됩니다. 따라서 이는 게임 플레이의 실행 경로(각 게임 플레이 상호작용의 명령어 수), 백엔드 바이트코드의 단어 길이 및 ZKVM의 증명 성능에 따라 달라집니다. 간단한 명령어 집합의 경우, 몇몇 ZKVM은 몇 초 내에 100만 개 명령어의 증명을 생성할 수 있습니다(Miden: https://0xpolygonmiden.github.io/miden-base/). 복잡한 명령어 집합(RISCV 32비트, WASM 64비트)의 경우, ZKVM은 GPU에서 12초 이내에 100만 개 명령어의 증명을 생성할 수 있습니다(Risc0 https://www.risczero.com/)에서 약 30초(zkWASM https://github.com/DelphinusLab/zkWasm)의 증명을 생성할 수 있습니다.

3. ZKWASM에서 전체 체인 게임을 위한 MVC(모델-뷰-컨트롤러) 패턴 사용

3.1 MVC(모델-뷰-컨트롤러) 패턴 소개

모델-뷰-컨트롤러(MVC) 패턴은 일반적으로 웹/기업 애플리케이션 개발과 관련이 있지만 게임 개발에도 적용될 수 있습니다. 다만 약간의 조정이 필요합니다. 다음은 게임 개발 환경에서 MVC 구성 요소가 작동하는 방식입니다:

모델(Model):

게임 개발에서 모델은 게임의 데이터와 논리를 나타냅니다. 여기에는 게임 상태(예: 점수, 레벨 및 플레이어 통계), 게임 객체 및 게임 세계를 관리하는 규칙이 포함됩니다. 모델은 게임의 데이터와 상태를 관리하며, 일반적으로 이러한 데이터가 어떻게 표현되거나 표시될지를 알지 못합니다.

뷰(View):

게임 개발에서 뷰는 플레이어에게 게임 상태를 보여주는 역할을 합니다. 여기에는 게임 그래픽 렌더링, 사운드 재생 및 점수, 생명 표시줄 및 메뉴와 같은 UI 요소 표시가 포함됩니다. 뷰는 모델을 관찰하고 게임 세계의 시각적 및 청각적 표현을 업데이트하여 플레이어에게 보여줍니다. 많은 게임 엔진에서 뷰는 렌더링 엔진 및 UI 시스템에 캡슐화될 수 있습니다.

컨트롤러(Controller):

컨트롤러는 키보드, 마우스, 게임 패드 또는 기타 입력 장치에서 오는 사용자 입력을 해석하고 이를 게임 내 행동으로 변환합니다. 예를 들어, 플레이어가 버튼을 눌러 캐릭터가 점프하도록 할 때, 컨트롤러는 이 입력을 처리하고 모델에 행동을 전달합니다. 게임 내의 컨트롤러는 입력 장치와 게임 논리 간의 중개 역할을 합니다.

게임 개발에서 MVC를 적용하는 것은 다음과 같은 뚜렷한 장점을 제공합니다:

관심사 분리: MVC는 코드를 조직하는 데 도움을 주며, 게임 논리를 사용자 인터페이스와 분리하여 개발 과정을 더 관리하기 쉽게 하고 코드를 더 유지 관리하기 쉽게 만듭니다.
유연성: MVC는 동일한 모델에 대해 다양한 뷰를 생성할 수 있게 해줍니다. 이는 여러 관점을 제공하거나 다양한 표시 모드를 지원해야 하는 게임에 매우 유용합니다.
ZK 친화적: 게임 논리를 표현과 분리함으로써 모델은 신뢰 없는 방식으로 실행할 수 없는 유일한 부분이 됩니다. 모델을 ZKWASM에 배치함으로써 핵심 게임 메커니즘은 게임 실행 중 자연스럽게 증명됩니다.

3.2 ZKWASM에서 게임 엔진 설정하기

컨트롤러가 모델과 연결되어 있으며, 모델 처리기를 갖고 있다고 가정합니다. 다음으로, 우리는 컨트롤러와 처리기에 명령 인코딩/디코딩 레이어를 추가할 수 있습니다:

struct GlobalState {

… // 게임 상태를 정의합니다.

}

enum ControllerTag {

}

/// MVC의 컨트롤러

fn controller_A (c) {

let handler_cmd = encode(A, c);

model.handle(handler_cmd)

}

fn controller_B (c) {

let handler_cmd = encode(B, c);

model.handle(handler_cmd)

}

fn controller_C (c) {

let handler_cmd = encode(C, c);

model.handle(handler_cmd)

}

/// MVC의 모델

fn handler(command) {

match command {

A => {},

B => {},

C => {},

}

/// 뷰

fn render(global_state: GlobalState) {

// 전역 상태에 따라 게임 UI를 표시합니다.

}

3.3 게임 플레이 증명 생성하기

게임 플레이의 일부를 처리기에 대한 일련의 컨트롤러 호출로 간주할 수 있습니다. 따라서 게임 플레이의 신뢰 없는 ZK 증명은 다음 코드입니다:

fn execution(cs: Vec) {

for command in cs {

global_state = handler(command);

}

게임 진행 중 마지막으로 컨트롤러가 보낸 명령을 확인하기 어렵고, 모든 명령 처리를 단일 ZK 증명으로 넣기 어렵습니다. 따라서 최선의 방법은 명령을 여러 부분으로 나누고 각각을 증명한 다음, 이를 배치하여 단일 증명을 생성하여 체인 상에서 추가 검증을 수행하는 것입니다.

참고: 위 방법에는 두 가지 누락된 부분이 있습니다:

각 실행 조각 간의 상태 연속성을 어떻게 보장할 것인가
서로 다른 게임 클라이언트에서 오는 컨트롤러가 서로 간섭할 때, 다중 플레이어가 동시에 출현하는 장면을 어떻게 처리할 것인가

다음 장에서는 다중 플레이어 직렬화 및 데이터 접근성에 대해 간략히 소개하겠습니다. 각 주제는 깊이 있게 탐구할 수 있으므로, 우리는 다른 개별 노트에서 더 자세한 내용을 제공할 계획입니다.

4. 다중 플레이어 게임에서 사용자 상호작용 행동 직렬화

모듈화 블록체인 맥락에서 직렬화기는 상호작용이 최종 확인되기 전에 이를 정렬하는 구성 요소 또는 노드입니다. 모듈화 블록체인 아키텍처는 실행, 합의 및 데이터 가용성과 같은 블록체인 기능의 다양한 계층을 서로 다른 구성 요소로 분리합니다. 이 방법은 각 계층을 독립적으로 최적화할 수 있도록 하여 확장성, 보안성 및 효율성을 향상시키는 것을 목표로 합니다.

다중 플레이어 게임을 개발할 때, 우리는 또한 서로 다른 사용자 간의 상호작용을 정렬하는 데 도움이 되는 구성 요소가 필요합니다. 따라서 우리는 모듈화 블록체인에서 직렬화라는 용어를 재사용합니다.

게임은 낮은 지연 시간을 요구하므로, 빠른 정렬 결과를 생성하는 중앙 집중식 직렬화기를 선택하는 것이 좋습니다. 게임 엔진은 직렬화기와 긴밀하게 협력하여 정렬된 거래를 얻을 수 있습니다.

단일 플레이어 상호작용 프로토콜

여기(아래 그림 참조)에서 우리는 플레이어 관점에서 상호작용 프로토콜을 설명합니다. 사용자 거래에서 사용자는 자신의 입력을 설명하고 공개 입력 및 증인 입력을 통해 자신의 신원을 증명합니다. 이러한 입력은 다음과 같은 레이아웃을 가질 수 있습니다:

공개 입력 및 증인 입력:

상호작용 처리 논리:

pub fn zkmain() -> i64 {

let mut hasher = Sha256::new();

// 명령 길이 가져오기

let commandslen = unsafe {wasminput(0)};

// 모든 명령을 처리하고

// 향후 서명 검증을 위한 명령 해시

for _ in 0..commands_len {

let command = unsafe {wasm_input(0)};

hasher.update(command.tolebytes());

step(command);

}

let msghash = hasher.finalize();

let pk = unsafe {BabyJubjubPoint {

x: U256([

wasm_input(0),

]),

y: U256([

wasm_input(0),

])};

zkwasmrustsdk::dbg!("process sig\n");

let sig = unsafe {JubjubSignature {

sig_r: BabyJubjubPoint {

x: U256([

wasm_input(0),

]),

y: U256([

wasm_input(0),

]),

sig_s: [

wasm_input(0),

]};

let msghash_u64 = [

u64::frombebytes(msghash[24..32].try_into().unwrap()),

u64::frombebytes(msghash[16..24].try_into().unwrap()),

u64::frombebytes(msghash[8..16].try_into().unwrap()),

u64::frombebytes(msghash[0..8].try_into().unwrap()),

];

sig.verify(&pk, &msghash_u64);

5. 비용 분석

5.1 비용 개요

ZKVM 기반의 신뢰 없는 전체 체인 게임에서 주요 유지 비용은 ZK 증명 생성, 빠른 데이터 RPC 서비스, 호출 데이터 접근 서비스 및 체인 상 검증 및 정산 비용에서 발생합니다. 캉쿤 업그레이드(EIP 4844)가 L2에서 시행됨에 따라 신뢰 없는 게임 운영 비용이 크게 줄어들었습니다. 또한, 향후 zkSNARK 증명 재귀(proof recursion) 및 Nebra의 증명 집계 서비스(proof aggregation)를 구현함으로써 ZKP 비용을 더욱 낮출 수 있습니다.

5.2 ZK 증명 생성 비용

먼저, ZKVM은 애플리케이션을 실행하고 실행 경로(execution trace)를 생성합니다. 이 경로는 ZKVM이 증명해야 하는 기본적인 것입니다:

이 경로가 ZKVM이 지원하는 바이트코드의 의미를 강제 실행했음을 증명합니다.
일반적으로 ZKVM 자체는 무상태(stateless)입니다. 게임의 유상태 저장(stateful storage)을 지원하기 위해, 데이터 설정 및 가져오기를 머클 증명으로 변환하는 아이디어를 활용합니다.
ZKVM은 일반적으로 실행 경로를 여러 조각으로 나누고 각각에 대해 증명을 생성합니다. 이러한 증명은 함께 배치되어 최종적으로 검증 가능한 단일 증명을 생성합니다.

우리가 사용하는 ZKVM이 시스템 호출(또는 ZKWASM의 호스트 API)로 미리 컴파일된 명령어를 사용하여 머클 증명을 처리한다고 가정합니다. ZK 증명을 생성하는 전체 비용은 다음과 같습니다:

증명 비용 = ZKVMGuest 증명 비용 + 머클 증명 비용 + 배치 증명 비용(BatchProofCost)

일반적으로 등식 오른쪽의 첫 번째 및 세 번째 항목은 순수 ZK 증명 외에 추가 비용을 발생시키지 않습니다. 그러나 두 번째 항목의 비용은 몇 가지 데이터 저장 서비스의 지원이 필요하기 때문에 미묘합니다.

머클 증명의 구성 요소를 다시 살펴보겠습니다:

머클 트리 설정

우리는 전역 데이터를 블록으로 추상화하고 이를 개별적으로 해시 처리합니다. 이러한 해시는 목표 트리의 리프 노드가 됩니다. 그런 다음 리프 노드의 쌍을 해시 처리하여 다음 수준의 노드를 형성하고, 이 과정을 반복하여 최상위에 단 하나의 해시만 남도록 합니다. 이를 머클 루트(Merkle root)라고 합니다. 머클 루트는 트리 내 모든 데이터 블록의 고유한 표현입니다.

데이터 포함 증명

이 증명은 문제의 특정 데이터 블록, 해당 해시 및 머클 트리에서의 소량의 추가 해시로 구성됩니다. 이러한 추가 해시는 검증자가 데이터 세트의 머클 루트를 독립적으로 계산할 수 있도록 하는 데 필요한 최소값입니다.

검증 증명:

검증자는 데이터 세트의 머클 루트를 알고 있지만 모든 데이터의 검증자를 반드시 알고 있는 것은 아닙니다. 그는 제공된 데이터 블록과 추가 해시를 사용하여 머클 루트까지의 해시 경로를 재구성합니다. 계산된 머클 루트가 알려진 머클 루트와 일치하면 증명이 유효하며, 해당 데이터 블록이 데이터 세트의 일부이며 변조되지 않았음을 확인합니다.

상태를 가진 ZK 게임을 유지하려면 머클 데이터 데이터베이스가 필요하여 머클 트리의 리프를 추적하고 빠른 데이터 쿼리 서비스를 제공해야 합니다. 이 서비스는 데이터 수정 빈도가 매우 높고 접근(읽기/쓰기) 수요가 높기 때문에 체인 상에서 완전히 호스팅되기는 어려울 것입니다.

거래가 완료되면 호출 데이터와 최종 상태(새로운 머클 트리 루트로 표시됨)는 접근 가능해야 합니다. 이는 일반적으로 DA 계층 또는 체인 상 txdata 저장을 통해 이루어집니다.

5.3 데이터 비용

Blade Games의 분석에 따르면, ZKWASM, Eth Storage, BNB Greenfield DA 저장 비용 계산기(https://dcellar.io/pricing-calculator) 및 구글 클라우드 저장 계산기(https://cloud.google.com/products/calculator)를 참조하여 다음과 같은 결론을 도출할 수 있습니다: 5,000명의 플레이어가 있는 체인 상 게임을 zk 협처리기 방법으로 운영할 경우, 예상 월 비용은 약 90,000달러로, 이는 고방어, 반 DDOS MMORPG 게임 서버 운영 비용과 유사합니다.

Blade Games의 추정 방법은 다음과 같습니다: 그들은 Unity에서 발표된 사용자 이벤트를 이진 코드로 변환하고 ZKWASM 내에서 실행합니다(ZKWASM은 Delphinuslab에서 개발한 WASM 바이트코드를 지원하는 ZKVM입니다). 그런 다음 ZKWASM은 실행 경로를 생성하고 압축된 경로를 DA 계층에 게시하며, 동시에 체인 상에 경로 해시를 게시하고 디지털 서명으로 불변성을 검증합니다.

ETHstorage와 zkwasm의 테스트 실행에 따르면, 1초 동안의 wasm 이진 파일을 실행하면 100만 줄의 경로가 생성되며, 각 줄의 크기는 40바이트입니다.

우리는 모든 경로를 체인 상에서 증명하거나, 경로를 저장하고 사용자가 결과에 이의를 제기할 경우 증명할 수 있습니다.

모든 경로를 증명하는 ZK 방법

모든 경로를 증명하기로 선택하면, 100만 바이트코드는 단일 RTX4090 그래픽 카드에서 약 25초가 소요되며, 비용은 0.5센트(비용은 1달러당 2000M 명령어)일 수 있습니다. 이 솔루션에서 비용은 주로 증명 능력 비용, 체인 상 검증 비용 및 DA의 호출 데이터 저장 비용에서 발생합니다. 이 방법을 사용하여 매시간 1000억 개의 경로가 있는 다중 사용자 게임을 지원하면, 매시간 약 50달러(월 36,000달러)의 증명 비용이 발생합니다.

사기 증명 방법

가정해 보겠습니다, 총 5,000명의 플레이어가 있으며, 각 플레이어가 평균적으로 2시간 연속 게임을 하고, 각 플레이어가 매시간 86.4만 개의 경로를 생성합니다. 따라서 매일 소비되는 저장량은 60초 * 60분 * 2시간 * 5,000명의 플레이어 * 100만 바이트코드 = 36,000,000,000,000개의 경로입니다. ETHstorage와 zkwasm의 테스트에 따르면, 각 경로는 40바이트의 저장 공간을 소비합니다. 따라서 5,000명의 플레이어가 있는 게임(평균 온라인 시간 2시간)의 경우, 매일 1,440TB의 저장 공간을 소비합니다.

합리적인 비율로 10배 압축된 경로를 사용하면, 매일 144TB의 구글 클라우드 저장 공간을 소비하게 되며, 이는 한 달에 4,320TB에 해당하며, 비용은 약 90,120달러/월(아카이브 저장 계층에서, 표준 저장 계층은 더 높은 데이터 접근 빈도를 허용하며, 비용은 매월 185,000달러가 될 것입니다). 또한 BNB Greenfield에서 서명 데이터를 저장하는 월 비용은 0.0001 BNB로 약 0.03달러입니다. 이 방법에서는 관찰 노드가 경로의 일관성을 검사하고 ZKFraud 증명을 트리거하여 부정직한 거래를 보고할 수 있습니다.

위 논의를 바탕으로 결론을 도출할 수 있습니다: 대규모 플레이어 게임을 운영하는 총 비용은 고방어 반 DDOS MMORPG 게임 서버 운영 비용과 유사합니다.

6. 콘텐츠 업그레이드 및 모듈 프로토콜

성공적인 게임은 일반적으로 동적인 게임 콘텐츠를 가지고 있어 정기적으로 엔진을 업데이트해야 합니다. 이는 암호화 원주율 커뮤니티에서 인기 있는 "코드가 법이다"라는 개념과 모순되는 것처럼 보입니다.

그러나 이 도전에는 잠재적인 해결책이 있습니다.

유지 가능한 규칙을 블록체인에 두는 설계 패턴을 채택함으로써, 게임 플레이의 업그레이드나 수정이 이러한 기본 규칙에 부합하도록 보장할 수 있습니다. 게임 아키텍처 맥락에서 이 주제의 복잡성을 고려하여, 우리는 다음 그림을 사용하여 간단히 설명합니다:

7. 결론

zkVM과 관련 인프라의 출현으로 전체 체인 게임 개발자는 복잡하지만 풍부한 콘텐츠와 "전체 체인 철학"을 모두 고려할 수 있게 되었습니다. 우리는 이러한 "신뢰 없는 게임"이 광범위한 시장 전망과 공간을 가질 것이라고 믿습니다.

zkVM과 모듈화된 실행 계층 개념을 결합함으로써, 게임의 시장 전략(GTM)도 매우 유연해질 것입니다. 게임 플레이어가 Eigenlayer, zkWASM, Berachain 등 인기 있는 프로젝트와 동시에 상호작용하여 에어드랍을 받고, 게임 내에서 본인 스스로의 수익을 얻는 것을 상상해 보십시오. 이는 게임의 초기 냉시작에 큰 도움이 될 것입니다.

독자들이 "개발 비용이 여전히 높지 않나요?"라는 질문에 대해: 우리는 ZKVM 기반의 신뢰 없는 게임에서 캉쿤 업그레이드(EIP 4844)가 L2에서 시행됨에 따라, 재귀 증명, 증명 집계의 적용 및 zkVM 자체의 최적화로 인해 신뢰 없는 게임 운영 비용이 크게 줄어들었다고 생각합니다. Trustless Game 개발에 관심이 있으시다면, 트위터(bladegamesHQ)에서 DM을 주시면, 해당 게임 개발, 코드, GTM에 대한 도움을 드리겠습니다.

Trustless Game 개발에 관심이 있으시다면, 트위터(bladegamesHQ)에서 DM을 주시면, 해당 게임 개발, 코드, GTM에 대한 도움을 드리겠습니다.