블레이드 게임즈, ZK 게임 엔진 출시: 신뢰 없이도 가능한 게임 구축
작성자: Blade Research, Delphinus Lab
요약:
Blade Games와 Delphinus Lab은 WebAssembly 및 zkWASM 기반의 신뢰 불필요한(trustless) zk 게임 엔진을 공동 개발했습니다.
우리의 zk 게임 엔진은 타워 디펜스, RPG 등의 저속 실시간 게임 장르뿐 아니라 플레이스먼트 게임, 카드/오토체스 게임, 인터랙티브 소설 등 다양한 유형의 게임을 지원합니다. 간단히 말해, 게임 로직을 zkWASM 내에서 실행되도록 배치하며(이를 "zk 서버"라 부릅니다), 각 게임 세션의 결과는 zkSNARK 증명을 생성하여 블록체인에 제출됩니다. 이 엔진은 C++, Go, Rust 언어를 지원하며 향후 C#과 Unity도 곧 지원할 예정입니다.
타워 디펜스 게임을 예로 들어보겠습니다. 일반적으로 6분간 진행되고 몬스터 웨이브가 100회 발생하는 한 판의 게임에서 zkSNARK 증명 생성 시간은 약 3분 정도입니다. 아직 초기 단계이며, 현재 우리는 증명 생성 시간을 빠르게 최적화하고 있습니다. (백만 명령어당 ZKP 생성 시간은 19초이며, 각 몬스터 웨이브당 8만 명령어, 한 게임당 총 800만 명령어를 처리합니다. 클라우드 기반 컴퓨팅 환경에서 8개의 zkSNARK 증명을 생성하는 데 약 3분 소요)
ZKVM 기반의 신뢰 불필요한 게임에서 유지비용은 주로 ZK 증명 생성, RPC/호출 데이터 접근 서비스, 그리고 체인상 검증 및 정산 수수료에서 발생합니다. 그러나 L2에서 캔쿤 업그레이드(EIP-4844)가 적용됨에 따라 신뢰 불필요한 게임 운영 비용은 크게 감소했습니다.
또한 미래에는 zkSNARK 증명 재귀(proof recursion)와 Nebra의 증명 집계 서비스(proof aggregation)를 도입함으로써 ZKP 비용을 더욱 낮출 수 있습니다.
현재 협업 중인 게임 파트너사는 다음과 같습니다:
Dune Factory (@BladeGamesHQ): 폐허 펑크 스타일의 기지 건설 및 타워 디펜스 전략 게임
0xPioneer: '기근(Don't Starve)'과 유사한 멀티플레이어 생존 시뮬레이션 게임
Craftpunk: 개조 가능한 우주선과 절차적 생성 맵을 갖춘 우주 테마 오픈월드 RPG 게임
본문:
본 zk 게임 엔진은 Blade Games와 Delphinus Lab이 공동 개발하였으며, 본 글 역시 양측이 공동 작성하였습니다. 목적은 더 많은 웹2 게임 개발자들과 풀체인(Full-chain) 게임 개발자들이 zk 게임 엔진의 장점과 개발 경로를 이해하도록 돕는 것입니다.
이 문서는 신뢰 불필요한 Web3 브라우저 게임 개발에 대한 안내서입니다. (추가 내용은 YouTube에서 확인 가능하며, 관련 링크 참고)
웹3 기술의 발전에 따라 풀체인 게임이 다시 주목받고 있습니다. 이들은 탈중앙화, 투명성, 무신뢰성, 커뮤니티 거버넌스 측면에서 우수성을 주장하지만, 동시에 블록체인의 고질적인 문제인 탈중앙화, 보안성, 확장성 삼각형의 딜레마를 그대로 물려받았습니다. 즉, 게임 개발자들은 풀체인 게임의 서사를 구현하면서 게임 콘텐츠, 상호작용 빈도, 탈중앙화, 무신뢰성, 공정한 커뮤니티 관리라는 어려운 문제들에 직면하게 됩니다.
따라서 지난 사이클 동안 게임 개발자들은 아키텍처 차원에서 일부 타협을 하였으며, 일명 Web2.5 게임 아키텍처라 불리는 실용적인 모델을 널리 도입하였습니다.
좀 더 정확히 말하면, Web2.5란 웹3와 전통적인 게임을 결합한 하이브리드 개념입니다. Web2.5는 여전히 게임 플레이 경험 자체를 강조하는데, 그 이유는 핵심 사용자층이 여전히 웹2 기반에 뿌리를 두고 있기 때문입니다. 동시에 NFT, 경제 모델, 플레이 투 언(P2E) 등 웹3 요소를 추가하여 차별화를 꾀합니다.
표준적인 Web2.5 게임 아키텍처는 아래와 같습니다:
좌측 다이어그램은 게임 엔진이 게임 상태 머신을 제어하고 사용자 행동에 반응하는 방식을 보여줍니다. 우측 다이어그램은 게임 상태 일부가 변화하며 체인상 가장 가치 있는 데이터가 공개되는 과정을 나타냅니다.
핵심 게임 플레이는 대부분 중앙집중형 게임 서버에서 실행되며, 가장 중요한 데이터(NFT, 토큰 보상, 기록 등)만 블록체인에 기록됩니다.
이 아키텍처의 장점은 게임 서버가 대량의 사용자 트랜잭션을 짧은 시간 내에 처리할 수 있다는 점입니다. 또한 복잡하고 지속적인 게임 플레이를 중앙집중형 서버에서 처리함으로써 원시 블록체인에서 처리했을 때보다 훨씬 낮은 비용으로 구현할 수 있습니다.
그러나 이 구조에서는 게임 엔진과 체인상 프로토콜 간 통신 채널이 일반적으로 서명으로 보호되기 때문에 완전한 무신뢰성은 보장되지 않습니다. 또한 게임 콘텐츠가 커뮤니티의 합의 없이 변경될 수 있으며, 이는 기존 사용자의 기득권(예: 게임 경제 업데이트, 콘텐츠 수정, 보상 시스템 변경 등)을 해칠 위험이 있습니다.
더욱이 체인상 데이터만으로는 블록체인에 제출된 정보가 실제로 게임 플레이의 유효한 결과인지 확인하기 어렵습니다. 서버는 권한을 이용해 특정 사용자(예: 개발사의 사설 계정)에게 특혜를 줄 수도 있습니다.
웹2 게임은 콘텐츠와 게임 플레이 자체가 우수하기 때문에, 공정성과 균형 조절을 게임 제공업체에 맡기는 것이 일반적으로 수용 가능합니다. 그러나 웹2 게임이 웹3 생태계로 진입하려 할 때는, 경제성, 소유권, 게임 내 가치 포획에 관심 있는 암호화폐 원주민 사용자들을 끌어모아야 합니다. 이들은 단순히 게임을 통해 성과를 거두는 것을 즐길 뿐 아니라, 자신의 성과가 일정한 의미(예: "지속 가능성")를 가지기를 바라며, 심지어 자산 가치 상승까지 기대합니다. 이러한 "지속 가능성"에 대한 기대감은 사용자가 게임 내 선택을 더욱 진지하게 고민하게 만들며, 이는 게임 규칙의 공정성과 예측 가능성에 대한 요구를 더욱 높입니다.
결국 사용자들은 게임의 "웹3적 특성"—즉, 공정하고 무신뢰적인 특성이—운영사나 개발자가 아닌, 코드화된 규칙에 의해 시행되기를 요구하게 되며, 이는 더욱 탈중앙화되고 완전히 체인상에서 구축된 게임을 추구하게 만듭니다.
이에 대해 간단한 해결책은 위 다이어그램 좌측의 모든 처리를 우측(블록체인)으로 옮기는 것으로, 아키텍처는 아래와 같이 됩니다:
분명히 이러한 접근은 게임 플레이에 여러 "퇴화(degradation)"를 초래합니다:
- 사용자의 모든 행동이 체인상 서명을 통해 승인되어야 함
- 블록체인에서 실행되는 게임 엔진의 규모에 제한
- 다량의 가스비 필요
- 블록체인의 TPS(Transaction per Second, 초당 거래 수) 제한으로 인해 사용자와의 상호작용 빈도 감소
이렇게 되면 우리는 풍부하고 복잡한 콘텐츠를 포기하고 "풀체인 철학"을 추구해야 하는 것일까요?
제로지식 가상머신(ZKVM) 기술이 등장하기 전까진 답은 아마도 "그렇다"였을 것입니다. 그러나 지금은 ZKVM 기술이 널리 연구되고 활용되고 있으며, 우리는 "제3의 방법", 즉 풀체인 게임과 무신뢰 컴퓨팅을 결합할 수 있게 되었습니다. 어떻게 가능할까요?
ZKVM(Zero-Knowledge Virtual Machine, 제로지식 가상머신)은 제로지식 증명과 가상머신 기술을 결합한 개념입니다. 이를 이해하기 위해 두 모듈로 나누어 설명하겠습니다:
- 제로지식 증명(ZKP): 한 당사자가 다른 당사자에게 어떤 값을 알고 있음을 정보를 노출하지 않고 증명할 수 있는 암호화 기법입니다. 예를 들어, 키를 알고 있음을 입증하면서 키 자체를 공개하지 않는 방식입니다. ZKP는 실제 데이터를 공유하지 않으면서도 진술의 진위를 검증할 수 있어, 거래나 상호작용에서 프라이버시와 보안을 동시에 보장합니다.
- 가상머신(VM): 실제 컴퓨터를 소프트웨어로 시뮬레이션한 것입니다. 운영체제와 애플리케이션을 실행할 수 있으며 마치 실제 컴퓨터처럼 작동하지만, 완전히 소프트웨어 기반입니다. VM은 클라우드 컴퓨팅이나 하나의 컴퓨터에서 여러 운영체제를 실행하는 데 널리 사용됩니다.
이 두 가지를 결합하면, 제로지식 가상머신(ZKVM)은 먼저 하나의 가상머신이며, 프로그램이나 계약을 실행할 수 있고, 동시에 제로지식 증명의 프라이버시 및 보안 이점을 제공합니다. 즉, zkVM 내에서 게임 엔진(또는 게임 서버)을 실행하고, zkVM이 생성한 ZK 증명을 통해 블록체인에 상태 데이터의 실행 결과가 게임 로직에 의해 강제되었음을 입증할 수 있습니다. 따라서 게임 서버가 최하위 블록체인에 제출하는 데이터를 임의로 조작할 수 없습니다.
이에 따라 풀체인 게임의 종합적인 아키텍처는 아래와 같을 수 있습니다:
이러한 신뢰 불필요한 풀체인 게임을 우리는 "Trustless Game"이라 부릅니다.
2. Trustless Game 개발 시 고려사항
2.1 입문자를 위한 팁
게임 개발은 일반적으로 복잡한 기술, 창의성, 프로젝트 관리 등이 요구되기 때문에 어려운 작업으로 간주됩니다. Trustless Game에 ZKVM 기술을 적용할 경우 고려해야 할 요소는 다음과 같습니다:
기술적 복잡성: Trustless Game에서는 게임 로직과 시각화 요소를 분리해야 하며, ZKVM이 증명을 생성할 수 있도록 로직은 결정론적이어야 합니다. 또한 증명은 실행되는 언어 단위에서 생성되기 때문에, 게임 개발자는 게임 플레이를 여러 실행 단위로 나누고 체인상 스마트계약과 주기적으로 동기화해야 합니다.
아트 및 디자인: 일반적으로 아티스트와 디자이너의 작업은 Trustless Game과 다른 게임에서 크게 다르지 않습니다. 왜냐하면 그들의 작업은 증명 대상이 아니기 때문입니다. 다만 시각화 개발은 게임의 전역 상태를 기반으로 이루어져야 하며, UI/UX는 사용자 행동을 수집하는 도구로 사용됩니다.
전체적인 게임 경험: 일반적인 풀체인 게임과 달리, 사용자가 매번 행동할 때마다 체인상 서명을 할 필요가 없으므로, "빈번한 상호작용이 필요한 게임" 개발이 가능해집니다. 여기에는 사용자 또는 시스템이 자주 상호작용해야 하는 게임이 포함됩니다.
그러나 ZKVM의 증명 생성 시간 제약으로 인해, RTS(실시간 전략), MOBA(DOTA 등)와 같은 고빈도 상호작용 게임은 여전히 ZKVM 기반 Trustless Game으로 개발하기 어렵습니다. 이러한 게임은 사용자가 지속적으로 유닛과 리소스를 조작하고 전략을 조정해야 하며, 이런 유형은 ZKVM 기반으로 개발하기 매우 어렵습니다.
반면에 시뮬레이션 게임, 플레이스먼트/팜 게임 등은 사용자가 정기적으로 리소스를 조정하거나, 시장 활동에 참여하거나, 캐릭터를 조작하여 성장하는 방식이므로 Trustless Game에 매우 적합합니다.
또한 인터랙티브 스토리 게임과 비주얼 노벨도 좋은 선택입니다. 이들 게임은 지속적인 상호작용이 필요하지 않을 수 있지만, 빈번한 의사결정 지점을 통해 사용자를 유도하고 스토리를 형성하며, 사용자의 선택 결과를 확인하고자 하는 빈번한 상호작용을 유도합니다.
다음으로 수익화 및 지속 가능성에 대해 알아보겠습니다.
일반적으로 게임 콘텐츠는 시간이 지남에 따라 발전하여 신규 사용자 유치와 기존 사용자 유지에 기여합니다. 이는 게임 로직이 동적으로 변한다는 것을 의미하며, ZKVM에서 실행되는 프로그램에 영향을 미칩니다. 그 결과 검증용 스마트컨트랙트도 변경되어 업데이트가 필요할 수 있습니다.
ZK 검증용 스마트컨트랙트의 빈번한 변경을 피하기 위한 두 가지 방법은 다음과 같습니다:
- 게임 플레이 변경: 게임 로직을 추상화한 프로토콜 계층을 만들고, 이러한 동적 특성을 규칙으로 정의합니다. 이렇게 하면 개발자는 규칙 세트를 체인상에 저장하고, 해당 해시값을 체인상에 기록할 수 있습니다. 동시에 게임 엔진이 게임 로직을 실행할 때 현재 규칙 세트의 해시값이 약속된 값과 일치하는지 먼저 확인한 후 행동합니다.
- 정산 변경: 보상 시스템을 게임 플레이 자체와 독립된 계층으로 설계할 수 있습니다. 즉, 모든 보상 알고리즘을 게임 내에서 발생하는 특정 이벤트의 콜백 함수로 간주할 수 있습니다. 이를 통해 보상 콜백을 체인상에 두고, 게임 이벤트에 따라 호출할 수 있습니다.
예를 들어 다음 게임 루프가 있다고 가정합니다:
zkgame {
// 게임 로직
output(events)
}
생성된 이벤트는 증명 인스턴스가 됩니다. 따라서 스마트컨트랙트에 콜백을 추가할 수 있습니다:
2.2 게임 로직은 어디에서 실행되어야 하나?
게임 로직은 주로 두 곳에서 실행됩니다: 프론트엔드 또는 서버사이드.
게임 로직을 프론트엔드에 두는 것은 클라이언트-서버(Client-Server) 구조에 비해 아키텍처를 단순화합니다. 이 방법을 통해 프론트엔드는 게임을 시뮬레이션하고 실행 궤적을 구성한 후 제로지식 증명(zk-proof)을 생성합니다. 이후 로컬 zk-prover 또는 원격 증명 서비스를 사용해 제로지식 가상머신(ZKVM)용 ZK 증명을 생성합니다. 그런 다음 이 증명을 최하위 블록체인에 업로드하여 정산 컨트랙트를 트리거합니다.
반면 게임 로직을 서버사이드에 두는 것은 게임 시뮬레이션과 사용자 간 상호작용을 전용 컴포넌트(게임 서버)로 이전하는 것을 의미합니다. 이는 다음 측면에서 전체 게임 경험을 향상시킬 수 있습니다:
- 보다 동기화된 게임 플레이: 서버사이드 시뮬레이션은 모든 사용자가 가능한 한 동기화된 방식으로 게임을 경험하도록 보장합니다. 멀티플레이어 게임에서는 모든 클라이언트의 일관된 게임 상태가 일관되고 경쟁적인 게임 경험을 위해 필수적입니다.
- 자원 관리 개선: 프론트엔드는 콘텐츠 렌더링과 UI/UX에 집중할 수 있으며, 서버는 중앙집중식 순차 컨트롤러이자 메르클 트리 저장소 역할을 할 수 있습니다.
역사 데이터가 필요 없고 순차 논리가 비교적 단순한 싱글 플레이 PVE 게임(또는 멀티 PVP 게임)의 경우, 모든 것을 프론트엔드에 두는 것이 좋은 선택입니다. 반면 SLG(시뮬레이션 게임) 또는 AW(자치 세계)처럼 복잡한 게임의 경우 서버사이드가 더 나은 성능을 발휘합니다.
2.3 게임 개발 아키텍처 선택
기존 게임 개발과 ZKVM을 결합하기 때문에 도구 선택을 신중히 고려해야 합니다.
1. 개발 언어
우선 C#, Rust, C, C++, Go 등의 전통적인 프로그래밍 언어를 사용할지, 아니면 ZKVM 전용 언어를 사용할지를 결정해야 합니다.
전통적인 프로그래밍 언어의 백엔드 바이트코드는 일반적으로 MIPS, WASM, RISC-V, x86입니다. ZKVM 중 이 바이트코드를 지원하는 것이 많지 않기 때문에, 만약 프로그램이 RISC-V 바이트코드로 컴파일된다면 Risc0를 기본 ZKVM으로 선택할 수 있고, WASM으로 컴파일된다면 zkWASM을 기본 ZKVM으로 선택할 수 있습니다.
WebAssembly(WASM)는 고급 언어(C, C++, Rust 등)의 컴파일 대상이 되는 저수준 바이트코드 형식입니다. 이는 이러한 언어로 작성된 코드가 웹상에서 거의 네이티브 수준의 속도로 실행되도록 설계되었습니다. WASM은 웹 브라우저에서 성능이 중요한 코드를 실행할 수 있는 방법을 제공하며, 웹 애플리케이션의 보안이나 속도를 희생하지 않습니다. 현대 웹 기술 스택의 핵심 요소이며, JavaScript 외에도 다른 언어를 사용한 웹 개발을 가능하게 하여 JavaScript를 보완합니다.
2. 게임 엔진
프로그래밍 언어를 선택한 후, 해당 언어 기반의 게임 엔진을 선택할 수 있습니다. 만약 ZKVM 전용 언어를 선택했다면, 해당 언어용 성숙한 프레임워크가 없을 수 있으므로 자체 게임 개발 프레임워크를 만들어야 할 수 있습니다. 반면 Rust, C, TypeScript 등을 사용한다면 Unity와 Cocos2D를 추천드립니다.
3. 증명 생성 비용
일반적으로 증명 비용은 백만 명령어당 증명 시간으로 측정됩니다. 따라서 게임 플레이의 실행 궤적(각 상호작용의 명령어 수), 백엔드 바이트코드의 명령어 길이, ZKVM의 증명 성능에 따라 달라집니다. 단순한 명령어 세트의 경우, 일부 ZKVM은 백만 명령어당 증명을 몇 초 내에 생성할 수 있습니다(Miden). 복잡한 명령어 세트(RISCV 32비트, WASM 64비트)의 경우, ZKVM은 GPU에서 백만 명령어당 증명을 12초(Risc0)에서 약 30초(zkWASM) 사이에 생성할 수 있습니다.
3. ZKWASM 기반 풀체인 게임에서 MVC(Model-View-Controller) 패턴 활용
3.1 MVC(Model-View-Controller) 패턴 소개
Model-View-Controller(MVC) 패턴은 일반적으로 웹/기업 애플리케이션 개발과 연관되지만, 게임 개발에도 적용 가능합니다(일부 조정이 필요하지만). 다음은 MVC 구성 요소가 게임 개발 환경에서 어떻게 작동하는지 설명합니다:
모델(Model):
게임 개발에서 모델은 게임의 데이터와 로직을 나타냅니다. 여기에는 게임 상태(점수, 레벨, 플레이어 통계 등), 게임 오브젝트, 게임 세계를 관리하는 규칙이 포함됩니다. 모델은 게임의 데이터와 상태를 관리하며, 일반적으로 이 데이터가 어떻게 표현될지는 알지 못합니다.
뷰(View):
게임 개발에서 뷰는 게임 상태를 플레이어에게 표시하는 역할을 합니다. 이는 게임 그래픽 렌더링, 사운드 재생, 점수, 생명바, 메뉴 등 UI 요소 표시를 포함합니다. 뷰는 모델을 관찰하고 게임 세계의 시각적·청각적 표현을 플레이어에게 보여주기 위해 업데이트됩니다. 많은 게임 엔진에서 뷰는 렌더링 엔진과 UI 시스템에 캡슐화되어 있습니다.
컨트롤러(Controller):
컨트롤러는 키보드, 마우스, 게임패드 등 입력 장치로부터 사용자 입력을 해석하고 게임 내 동작으로 변환합니다. 예를 들어 플레이어가 버튼을 눌러 캐릭터를 점프시키면, 컨트롤러가 이 입력을 처리하고 모델에 동작을 전달합니다. 게임 내 컨트롤러는 입력 장치와 게임 로직 사이의 중개자 역할을 합니다.
게임 개발에 MVC를 적용하면 다음과 같은 장점이 있습니다:
- 관심사 분리: MVC는 코드를 조직화하고 게임 로직과 사용자 인터페이스를 분리함으로써 개발 과정을 더 쉽게 만들고 코드 유지보수를 용이하게 합니다.
- 유연성: 동일한 모델에 대해 다양한 뷰를 생성할 수 있습니다. 다양한 시점을 제공하거나 다양한 디스플레이 모드를 지원해야 하는 게임에 유용합니다.
- ZK 친화성: 게임 로직과 표현을 분리함으로써, 모델만이 신뢰 불필요하게 실행되어야 하는 부분이 됩니다. 모델을 ZKWASM에 넣음으로써 핵심 게임 메커니즘이 게임 실행 중 자연스럽게 증명됩니다.
3.2 ZKWASM에서 게임 엔진 설정
컨트롤러가 모델에 연결되어 있고 일련의 모델 핸들러를 갖는다고 가정합시다. 이후 컨트롤러와 핸들러에 명령 인코딩/디코딩 레이어를 추가할 수 있습니다:
3.3 게임 플레이 증명 생성
게임 플레이의 일부를 일련의 컨트롤러 호출로 간주할 수 있습니다. 따라서 게임 플레이의 신뢰 불필요한 ZK 증명은 다음과 같습니다:
fn execution(cs: Vec<command>) {
for command in cs {
global_state = handler(command);
}
}
게임 중에는 컨트롤러가 보낸 마지막 명령을 정확히 판단하기 어렵고, 모든 명령 처리를 단일 ZK 증명에 넣는 것도 어렵습니다. 따라서 명령을 여러 부분으로 나누어 증명한 후, 하나의 증명으로 배치 처리하여 체인상 추가 검증을 위한 단일 증명을 생성하는 것이 최선의 방법입니다.
참고: 위 방법에는 두 가지 누락된 부분이 있습니다:
- 각 실행 구간 사이의 상태 연속성을 어떻게 보장할 것인가
- 서로 다른 게임 클라이언트의 컨트롤러가 서로 간섭할 때, 다중 사용자 동시 시나리오를 어떻게 처리할 것인가
다음 장에서는 다중 사용자 순차화(sequencing)와 데이터 접근성(DA)에 대해 간략히 소개하겠습니다. 각 주제는 깊이 있게 다룰 수 있으므로, 별도의 문서에서 더 자세한 내용을 제공할 예정입니다.
4. 멀티플레이어 게임에서 사용자 상호작용 순차화(Sequencing)
모듈화된 블록체인 맥락에서, 시퀀서(sequencer)는 상호작용이 최종 승인되기 전에 순서를 정렬하는 구성 요소 또는 노드입니다. 모듈화된 블록체인 아키텍처는 블록체인 기능의 다양한 계층(예: 실행, 합의, 데이터 가용성)을 별도의 구성 요소로 분리합니다. 이 접근법은 각 계층이 독립적으로 최적화될 수 있도록 하여 확장성, 보안성, 효율성을 향상시키는 것을 목표로 합니다.
멀티플레이어 게임 개발 시에도 서로 다른 사용자 간 상호작용을 정렬하는 구성 요소가 필요합니다. 따라서 모듈화된 블록체인의 시퀀싱 용어를 재활용합니다.
게임은 낮은 지연 시간을 요구하기 때문에, 빠른 정렬 결과를 생성하는 중앙집중형 시퀀서를 선택하는 것이 좋습니다. 게임 엔진은 시퀀서와 긴밀히 협력하여 정렬된 트랜잭션을 동시에 획득할 수 있습니다.
단일 사용자 상호작용 프로토콜
아래 다이어그램에서 사용자 입장에서 상호작용 프로토콜을 설명합니다. 사용자 트랜잭션에서 사용자는 자신의 입력을 기술하고, 공개 입력과 증명 입력을 통해 신원을 입증합니다. 입력은 다음과 같은 구조를 가질 수 있습니다:
공개 입력과 증명 입력:
상호작용 처리 로직:
pub fn zkmain() -> i64 {
let mut hasher = Sha256::new();
// 명령어 길이 가져오기
let commands_len = unsafe {wasm_input(0)};
// 모든 명령어 처리 및
// 향후 서명 검증을 위해 명령어 해싱
for _ in 0..commands_len {
let command = unsafe {wasm_input(0)};
hasher.update(command.to_le_bytes());
step(command);
}
let msghash = hasher.finalize();
let pk = unsafe {BabyJubjubPoint {
x: U256([
wasm_input(0),
wasm_input(0),
wasm_input(0),
wasm_input(0),
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
Blade Research
