Blade Games ra mắt động cơ trò chơi ZK: Xây dựng trò chơi phi tin cậy
Tuyển chọn TechFlowTuyển chọn TechFlow
Blade Games ra mắt động cơ trò chơi ZK: Xây dựng trò chơi phi tin cậy
Trò chơi không tin cậy (Trustless Game) dựa trên ZK sẽ dẫn dắt làn sóng trò chơi chuỗi toàn phần tiếp theo.
Chuyên sâu báo cáo Web3Tác giả: Blade Research, Delphinus Lab
Phiên bản tóm tắt:
Blade Games và Delphinus Lab hợp tác xây dựng một công cụ chơi game không cần tin cậy (trustless game engine) dựa trên WebAssembly và zkWASM.
Công cụ chơi game zk của chúng tôi có thể hỗ trợ các thể loại game thời gian thực tốc độ thấp như phòng thủ tháp, RPG, cũng như các thể loại khác như game đặt nhân vật, game thẻ bài/tự điểu kỳ, tiểu thuyết tương tác. Nói đơn giản, chúng tôi đặt logic trò chơi vào bên trong zkWASM (một "máy chủ zk" xử lý tính toán), mỗi ván chơi sẽ tạo ra bằng chứng zkSNARK trước khi được công bố. Công cụ này hỗ trợ các ngôn ngữ lập trình như C++, Go, Rust, và sắp tới là C# và Unity.
Ví dụ với một trò chơi phòng thủ tháp, một ván chơi điển hình dài 6 phút với 100 đợt quái vật, tổng thời gian tạo bằng chứng zkSNARK khoảng 3 phút. Đây vẫn chỉ là kết quả ban đầu, chúng tôi đang nhanh chóng tối ưu hóa thời gian tạo bằng chứng. (Thời gian tạo ZKP cho 1 triệu lệnh là 19 giây; mỗi đợt quái vật gồm 80.000 lệnh, mỗi ván 8 triệu lệnh; sử dụng 8 bằng chứng zkSNARK trên hệ thống điện toán đám mây, thời gian tạo bằng chứng khoảng 3 phút).
Trong trò chơi không cần tin cậy dựa trên ZKVM, chi phí vận hành chủ yếu đến từ việc tạo bằng chứng ZK, dịch vụ truy cập dữ liệu RPC/gọi hàm, và chi phí xác minh cũng như thanh toán trên chuỗi. Với nâng cấp Cancun (EIP-4844) áp dụng trên L2, chi phí vận hành trò chơi không cần tin cậy đã giảm đáng kể.
Hơn nữa, bằng cách triển khai trong tương lai kỹ thuật đệ quy bằng chứng zkSNARK (proof recursion) cùng dịch vụ tập hợp bằng chứng (proof aggregation) của Nebra, chúng ta có thể tiếp tục giảm chi phí ZKP.
Các đối tác phát triển game của chúng tôi bao gồm:
Dune Factory (@BladeGamesHQ): Một trò chơi chiến lược xây dựng căn cứ + phòng thủ tháp theo phong cách hậu tận thế cyberpunk
0xPioneer: Trò chơi sinh tồn mô phỏng nhiều người chơi trực tuyến tương tự Don't Starve
Craftpunk: Một trò chơi nhập vai thế giới mở lấy chủ đề vũ trụ, có tàu vũ trụ tùy chỉnh được và bản đồ được tạo ngẫu nhiên theo chương trình
Phần nội dung chính:
Công cụ chơi game ZK này do Blade Games và Delphinus Lab đồng phát triển, bài viết này do cả hai bên cùng soạn thảo nhằm giúp nhiều nhà phát triển game web2 và game toàn chuỗi hiểu rõ hơn về lợi thế và con đường phát triển của công cụ chơi game ZK.
Đây là một hướng dẫn về phát triển game trình duyệt Web3 không cần tin cậy. (Có thêm nội dung trình bày trên youtube, liên kết liên quan)
Cùng với sự phát triển của Web3, game toàn chuỗi lại thu hút sự chú ý. Chúng tuyên bố vượt trội hơn về mặt phi tập trung, minh bạch, không cần tin tưởng và quản trị cộng đồng. Tuy nhiên, game toàn chuỗi cũng kế thừa những khó khăn về phi tập trung, an ninh và khả năng mở rộng của blockchain — điều này nghĩa là các nhà phát triển phải đối mặt với thách thức về nội dung game, tần suất tương tác, mức độ phi tập trung, công bằng và quản lý sự công bằng của cộng đồng trong câu chuyện game toàn chuỗi.
Do đó, trong chu kỳ trước, các nhà phát triển game đã đạt được một số thỏa hiệp ở cấp kiến trúc và đưa ra một thực tiễn được gọi phổ biến là kiến trúc game Web2.5 — hiện tại là kiến trúc tốt nhất trong thực tế.
Chính xác hơn, Web2.5 là một thuật ngữ tổng hợp kết hợp giữa Web3 và game truyền thống. Web2.5 nhấn mạnh vào lối chơi vì họ tin rằng đối tượng chính của game vẫn nằm sâu trong Web2. Đồng thời, họ thêm vào các yếu tố Web3 (NFT, mô hình kinh tế, kiếm tiền từ game) để làm nổi bật sản phẩm của mình.
Một kiến trúc game Web2.5 tiêu chuẩn có thể như sau:
Bên trái minh họa cách công cụ chơi game kiểm soát máy trạng thái của trò chơi và phản ứng với hoạt động người chơi. Bên phải minh họa một phần trạng thái trò chơi thay đổi, đồng thời tiết lộ những dữ liệu giá trị nhất trên chuỗi.
Phần lớn lối chơi cốt lõi chạy trên một máy chủ game tập trung, trong khi những dữ liệu có giá trị cao nhất (NFT, phần thưởng token, hồ sơ, v.v.) được theo dõi trên blockchain.
Ưu điểm của kiến trúc này là máy chủ game có thể vận hành theo chế độ tập trung để xử lý lượng lớn giao dịch người dùng, hoàn thành trong vài giây. Ngoài ra, máy chủ tập trung có thể xử lý lối chơi phức tạp và liên tục, thường quá tốn kém nếu xử lý trên blockchain gốc.
Tuy nhiên, trong kiến trúc này, kênh giao tiếp giữa công cụ chơi game và giao thức trên chuỗi thường được bảo vệ bằng chữ ký, do đó chưa đạt mức độ không cần tin cậy. Hơn nữa, nội dung game có thể bị thay đổi mà không cần sự đồng thuận của cộng đồng, đôi khi gây tổn hại đến lợi ích hiện tại của người chơi (ví dụ như cập nhật kinh tế game, nội dung hoặc cơ chế phần thưởng).
Thêm vào đó, dữ liệu trên chuỗi rất khó kiểm tra xem dữ liệu truyền lên blockchain có thực sự là kết quả hợp lệ từ lối chơi hay không. Máy chủ có thể lợi dụng vị trí để xử lý khác biệt hành vi người chơi (ví dụ ưu ái tài khoản riêng của nhà phát triển game).
Vì game Web2 thường xuất sắc về nội dung và trải nghiệm chơi, nên việc giao phó sự cân bằng và công bằng cho nhà cung cấp game là chấp nhận được. Tuy nhiên, khi game Web2 quyết định bước vào hệ sinh thái Web3, nó cần thu hút thêm những người chơi bản địa crypto quan tâm đến kinh tế, quyền sở hữu và việc thu giữ giá trị trong quá trình chơi. Những người chơi này không chỉ thích thú với quá trình đạt được kết quả phong phú từ trò chơi, mà còn mong muốn kết quả họ đạt được trong game có ý nghĩa nhất định (ví dụ "bền vững"), thậm chí mang thuộc tính tăng giá. Mong đợi về hiệu ứng gia tăng "bền vững" này khiến người chơi nghiêm túc hơn với lựa chọn trong game — nghĩa là chi phí suy nghĩ và ra quyết định trong game của họ cao hơn, làm tăng thêm kỳ vọng về sự công bằng và có thể dự đoán được của luật chơi.
Cuối cùng, người chơi sẽ yêu cầu họ có thể kiểm soát theo một cách nào đó đặc điểm "Web3" của game — đặc điểm công bằng và không cần tin cậy không nên do nhà vận hành/nhà phát triển game thực thi, mà nên do một bộ mã cố định đảm nhiệm, nhằm tạo ra một trò chơi phi tập trung hơn, hoàn toàn xây dựng trên chuỗi.
Về vấn đề này, một biện pháp đơn giản là chuyển tất cả nội dung ở phía trái sơ đồ trên sang phía phải (blockchain), khiến kiến trúc trở thành như sau:
Rõ ràng, biện pháp này sẽ dẫn đến nhiều "suy thoái" trong lối chơi:
- Mỗi hành động của người chơi đều phải được biểu thị qua chữ ký trên chuỗi để xác thực ủy quyền
- Quy mô công cụ chơi game chạy trên blockchain bị hạn chế
- Phải trả phí gas lớn
- Tần suất tương tác giữa người chơi và game phải giảm xuống để phù hợp với giới hạn TPS (giao dịch mỗi giây) của blockchain
Liệu điều này có nghĩa là chúng ta phải từ bỏ nội dung phức tạp nhưng phong phú để theo đuổi "triết lý toàn chuỗi"?
Trước khi công nghệ máy ảo kiến thức không (ZKVM) xuất hiện, câu trả lời có lẽ là "có". Tuy nhiên, hiện nay công nghệ ZKVM đã được nghiên cứu và ứng dụng rộng rãi, chúng ta có "phương án thứ ba": kết hợp game hoàn toàn trên chuỗi với tính toán không cần tin cậy. Làm thế nào để đạt được điều này?
ZKVM, hay máy ảo kiến thức không, là một khái niệm kết hợp giữa bằng chứng kiến thức không và công nghệ máy ảo. Để hiểu rõ, hãy phân tích hai thành phần:
- Bằng chứng kiến thức không (ZKP): Là một phương pháp mã hóa cho phép một bên chứng minh với bên kia rằng họ biết một giá trị (ví dụ khóa), mà không tiết lộ bất kỳ thông tin nào về giá trị đó. Bằng chứng kiến thức không có thể bảo vệ quyền riêng tư và an toàn trong giao dịch hoặc tương tác, vì chúng có thể xác minh tính đúng đắn của một tuyên bố mà không cần chia sẻ dữ liệu thực tế.
- Máy ảo (VM): Là mô phỏng phần mềm của một máy tính vật lý. Nó chạy hệ điều hành và các ứng dụng — giống như máy tính thật, chỉ khác là hoàn toàn dựa trên phần mềm. Máy ảo được sử dụng rộng rãi trong điện toán đám mây và chạy nhiều hệ điều hành trên một máy tính đơn lẻ.
Kết hợp lại: Máy ảo kiến thức không (ZKVM) trước hết là một máy ảo có thể thực thi chương trình hoặc hợp đồng, đồng thời mang lại lợi thế về quyền riêng tư và an toàn từ bằng chứng kiến thức không. Điều này nghĩa là chúng ta có thể chạy công cụ chơi game (hoặc máy chủ game) bên trong zkVM, và dùng zkVM tạo bằng chứng ZK để chứng minh với blockchain rằng kết quả thực thi dữ liệu trạng thái khác nhau là do logic game buộc phải thực hiện. Do đó, máy chủ game không thể điều chỉnh dữ liệu gửi đến blockchain nền tảng.
Do đó, kiến trúc tổng hợp cho game toàn chuỗi có thể như sau:
Chúng tôi gọi những game toàn chuỗi không cần tin cậy này là: Trustless Game.
2. Các yếu tố cần cân nhắc khi phát triển Trustless Game
2.1 Những điều người mới cần biết
Việc phát triển game thường được coi là khó khăn vì nó liên quan đến công nghệ phức tạp, sáng tạo quý giá và quản lý dự án. Khi áp dụng công nghệ ZKVM vào Trustless Game, các yếu tố có thể liên quan như sau:
Mức độ phức tạp công nghệ: Trong Trustless Game, logic game cần được tách khỏi phần hiển thị, và logic phải mang tính tất định để ZKVM có thể tạo bằng chứng. Ngoài ra, do bằng chứng được tạo trên từng đoạn mã cần thực thi, nhà phát triển game cần chia lối chơi thành các đoạn thực thi và đồng bộ định kỳ với hợp đồng trên chuỗi.
Nghệ thuật và thiết kế: Nói chung, công việc của nghệ sĩ và nhà thiết kế trong Trustless Game không khác biệt so với game khác, vì công việc của họ không thuộc phần logic cần được chứng minh. Trong Trustless Game, phát triển phần hiển thị cần dựa trên trạng thái toàn cục của game, và UI/UX cũng được dùng như công cụ thu thập hoạt động người chơi.
Trải nghiệm chơi game tổng thể: Khác với game toàn chuỗi thông thường, người chơi không cần ký mỗi lần di chuyển trên chuỗi, điều này tăng khả năng tạo ra "game tương tác thường xuyên" — những game yêu cầu hoặc khuyến khích người chơi tương tác thường xuyên.
Tuy nhiên, do bị giới hạn bởi thời gian tạo bằng chứng ZKVM, tương tác tần suất cao vẫn không khả thi đối với Trustless Game chạy trên ZKVM, ví dụ như RTS (chiến thuật thời gian thực) và MOBA (như DOTA), nơi người chơi phải liên tục điều khiển đơn vị, tài nguyên và điều chỉnh chiến lược để đánh bại đối thủ — những thể loại này rất khó phát triển dựa trên ZKVM.
Ngược lại, trong game mô phỏng và game đặt nhân vật/trang trại, người chơi cầnđịnh kỳ phân bổ tài nguyên, tham gia hành vi thị trường hoặc điều khiển nhân vật để đạt được sự phát triển trong game — những thể loại này rất phù hợp với Trustless Game.
Hơn nữa, game truyện tương tác và tiểu thuyết hình ảnh cũng là lựa chọn tốt. Những game này có thể không yêu cầu tương tác liên tục, nhưng thu hút người chơi bằng các điểm ra quyết định xuất hiện liên tục, định hình câu chuyện và khuyến khích tương tác thường xuyên để xem kết quả từ lựa chọn của người chơi.
Tiếp theo, hãy nói về thương mại hóa và tính bền vững.
Nói chung, nội dung game phát triển theo thời gian để thu hút người chơi mới và giữ chân người chơi cũ. Điều này khiến logic chơi game trở nên động, ảnh hưởng đến chương trình chạy trên ZKVM — một hệ quả là hợp đồng xác minh có thể cần thay đổi và cập nhật.
Có hai cách để tránh thay đổi thường xuyên hợp đồng cần xác minh ZK:
- Thay đổi lối chơi: Trừu tượng hóa một tầng giao thức cho lối chơi, và định nghĩa các đặc điểm động của game thành các quy tắc. Như vậy, nhà phát triển có thể lưu trữ tập quy tắc này trên chuỗi và cam kết hash tập quy tắc đó lên chuỗi. Đồng thời, khi công cụ chơi game chạy logic, nó có thể trước tiên kiểm tra xem hash tập quy tắc hiện tại có khớp với cam kết hay không, rồi hành động tương ứng.
- Thay đổi thanh toán: Hệ thống phần thưởng có thể là một tầng độc lập với lối chơi. Chúng ta có thể coi mọi thuật toán phần thưởng là callback cho một số sự kiện được tạo ra trong lối chơi. Bằng cách này, có thể đặt các callback phần thưởng lên chuỗi và gọi chúng theo các sự kiện trong game.
Ví dụ, ta có vòng lặp game sau:
zkgame {
// Logic game
output(events)
}
Các sự kiện được tạo ra sẽ trở thành ví dụ chứng minh thực thi. Vì vậy, chúng ta có thể thêm callbacks vào hợp đồng:
2.2 Logic chơi game nên đặt ở đâu?
Logic game chủ yếu chạy ở hai nơi: phía trước (frontend) hoặc phía máy chủ (server-side).
Việc đặt logic game ở phía trước đơn giản hóa kiến trúc game so với cấu trúc khách-hàng - máy chủ (Client-Server). Phương pháp này cho phép phía trước mô phỏng game và tạo bằng chứng kiến thức không (zk-proof) sau khi thiết lập quỹ đạo thực thi. Sau đó, nó sử dụng zk-prover cục bộ hoặc dịch vụ chứng minh từ xa để tạo bằng chứng ZK cho máy ảo kiến thức không (ZKVM). Tiếp theo, bằng chứng này được tải lên blockchain nền tảng để kích hoạt hợp đồng thanh toán.
Ngược lại, đặt logic game ở phía máy chủ nghĩa là chuyển việc mô phỏng game và tương tác người dùng sang một thành phần chuyên dụng hơn (máy chủ game). Điều này có thể cải thiện trải nghiệm chơi game tổng thể ở các khía cạnh sau:
- Lối chơi đồng bộ tốt hơn: Mô phỏng phía máy chủ đảm bảo tất cả người chơi trải nghiệm game một cách đồng bộ nhất có thể. Đối với game nhiều người chơi, trạng thái game nhất quán trên mọi client kết nối là cực kỳ quan trọng để tạo trải nghiệm chơi nhất quán và cạnh tranh.
- Quản lý tài nguyên tốt hơn: Phía trước có thể tập trung vào render nội dung và UI/UX, trong khi máy chủ đóng vai trò là bộ điều khiển tuần tự tập trung và nhà cung cấp lưu trữ cây Merkle.
Đối với game PVE đơn người (hoặc PVP nhiều người) không cần dữ liệu lịch sử và có logic tuần tự đơn giản, đặt mọi thứ ở phía trước là lựa chọn tốt. Đối với các game phức tạp như SLG nhiều người chơi (game mô phỏng) hoặc game AW (thế giới tự trị), hiệu suất tốt hơn khi đặt ở phía máy chủ.
2.3 Lựa chọn kiến trúc phát triển game
Vì chúng tôi kết hợp phát triển game truyền thống với ZKVM, cần cân nhắc kỹ lưỡng việc chọn công cụ.
1. Ngôn ngữ phát triển
Trước tiên, cần quyết định xem nên dùng ngôn ngữ lập trình truyền thống như C#, Rust, C, C++, Go để phát triển game, hay dùng ngôn ngữ đặc thù cho ZKVM.
Bytecode backend của các ngôn ngữ lập trình truyền thống thường là MIPS, WASM, RISC-V, x86. Vì không nhiều ZKVM hỗ trợ các bytecode này, nếu chương trình có thể biên dịch thành bytecode RISC-V, bạn có thể chọn Risc0 làm ZKVM nền tảng; nếu có thể biên dịch thành WASM, hãy chọn zkWASM làm ZKVM nền tảng.
WebAssembly (WASM) là một định dạng bytecode cấp thấp, dùng làm mục tiêu biên dịch cho các ngôn ngữ cấp cao (như C, C++, Rust, v.v.). Nó được thiết kế để cho phép mã viết bằng các ngôn ngữ này chạy gần tốc độ gốc trên mạng. WebAssembly cung cấp cách chạy mã đòi hỏi hiệu năng cao trong trình duyệt web mà không hy sinh an toàn hay tốc độ của ứng dụng web. Đây là một phần quan trọng trong stack công nghệ web hiện đại, bổ sung cho JavaScript bằng cách cho phép nhà phát triển sử dụng các ngôn ngữ khác ngoài JavaScript để phát triển web.
2. Công cụ chơi game
Sau khi chọn ngôn ngữ lập trình, chúng ta có thể chọn công cụ chơi game dựa trên ngôn ngữ đó. Nếu chọn ngôn ngữ đặc thù ZKVM, có thể cần tự xây dựng framework phát triển game vì có thể chưa có framework trưởng thành cho ngôn ngữ đó. Nếu dùng Rust, C, Typescript, thì có nhiều framework để chọn, trong đó chúng tôi khuyến nghị Unity và Cocos2D.
3. Chi phí tạo bằng chứng
Thông thường, chi phí bằng chứng được đo bằng thời gian tạo bằng chứng cho 1 triệu lệnh. Do đó, nó phụ thuộc vào quỹ đạo thực thi của lối chơi (số lượng lệnh cho mỗi tương tác chơi), độ dài bytecode backend và hiệu suất chứng minh của ZKVM. Với tập lệnh đơn giản, một số ZKVM có thể tạo bằng chứng cho 1 triệu lệnh trong vài giây (Miden). Với tập lệnh phức tạp (RISCV 32-bit, WASM 64-bit), ZKVM có thể tạo bằng chứng trong 12 giây trên GPU (Risc0) đến khoảng 30 giây (zkWASM).
3. Sử dụng mô hình MVC (Model-View-Controller) trong ZKWASM cho game toàn chuỗi
3.1 Giới thiệu mô hình MVC (Model-View-Controller)
Mặc dù mô hình Model-View-Controller (MVC) thường liên quan đến phát triển ứng dụng Web/doanh nghiệp, nó cũng có thể áp dụng cho phát triển game — mặc dù cần một số điều chỉnh. Dưới đây là cách các thành phần MVC hoạt động trong môi trường phát triển game:
Mô hình (Model):
Trong phát triển game, mô hình đại diện cho dữ liệu và logic của game. Bao gồm trạng thái game (như điểm số, cấp độ, thống kê người chơi), các đối tượng game và các quy tắc quản lý thế giới game. Mô hình chịu trách nhiệm quản lý dữ liệu và trạng thái game, thường thì nó không biết dữ liệu sẽ được trình bày hoặc hiển thị như thế nào.
Giao diện (View):
Trong phát triển game, giao diện chịu trách nhiệm hiển thị trạng thái game cho người chơi. Liên quan đến việc render đồ họa game, phát âm thanh và hiển thị các phần tử UI như điểm số, thanh máu, menu. Giao diện quan sát mô hình và cập nhật biểu diễn hình ảnh và âm thanh của thế giới game để hiển thị cho người chơi. Trong nhiều công cụ chơi game, giao diện có thể được gói gọn trong bộ render và hệ thống UI.
Bộ điều khiển (Controller):
Bộ điều khiển diễn giải đầu vào từ bàn phím, chuột, tay cầm chơi game hoặc thiết bị đầu vào khác và chuyển đổi thành hành động trong game. Ví dụ, khi người chơi nhấn nút để nhân vật nhảy, bộ điều khiển xử lý đầu vào này và truyền hành động đến mô hình. Trong game, bộ điều khiển đóng vai trò trung gian giữa thiết bị đầu vào và logic game.
Việc áp dụng MVC trong phát triển game mang lại những lợi ích nổi bật sau:
- Tách biệt mối quan tâm: MVC giúp tổ chức mã nguồn, tách rời logic game khỏi giao diện người dùng, giúp quá trình phát triển dễ quản lý hơn và mã dễ bảo trì hơn.
- Tính linh hoạt: MVC cho phép tạo các giao diện khác nhau cho cùng một mô hình. Điều này rất hữu ích khi cần cung cấp nhiều góc nhìn hoặc hỗ trợ nhiều chế độ hiển thị khác nhau.
- Thân thiện với ZK: Bằng cách tách logic game khỏi phần hiển thị, mô hình là phần duy nhất cần được thực thi một cách không cần tin cậy. Bằng cách đặt mô hình vào ZKWASM, cơ chế cốt lõi của game sẽ được chứng minh một cách tự nhiên trong lúc chạy.
3.2 Thiết lập công cụ chơi game trong ZKWASM
Giả sử bộ điều khiển kết nối với mô hình và có một tập xử lý mô hình. Tiếp theo, chúng ta có thể thêm một lớp mã hóa/giải mã lệnh cho bộ điều khiển và các xử lý, như sau:
3.3 Tạo bằng chứng cho lối chơi
Chúng ta có thể coi một phần lối chơi là một chuỗi các lời gọi xử lý từ bộ điều khiển. Do đó, bằng chứng ZK không cần tin cậy cho lối chơi là đoạn mã sau:
fn execution(cs: Vec<command>) {
for command in cs {
global_state = handler(command);
}
}
Trong quá trình chơi, rất khó xác định lệnh cuối cùng do bộ điều khiển gửi, và khó đưa tất cả xử lý vào một bằng chứng ZK duy nhất. Do đó, cách tốt nhất là chia lệnh thành nhiều phần, chứng minh từng phần, rồi gom nhóm để tạo một bằng chứng duy nhất để xác minh trên chuỗi.
Ghi chú: Xin lưu ý rằng phương pháp trên còn thiếu hai phần:
- Làm sao đảm bảo tính liên tục trạng thái giữa các đoạn thực thi
- Khi các bộ điều khiển từ nhiều client game khác nhau can thiệp lẫn nhau, xử lý tình huống nhiều người chơi cùng lúc như thế nào
Trong các chương tiếp theo, chúng tôi sẽ giới thiệu ngắn gọn về việc tuần tự hóa nhiều người chơi (sequencing) và khả năng truy cập dữ liệu (DA). Vì mỗi chủ đề đều có thể đào sâu, chúng tôi dự định cung cấp nội dung chi tiết hơn trong các ghi chú riêng biệt khác.
4. Tuần tự hóa (sequencing) hành vi tương tác người dùng trong game nhiều người chơi
Trong bối cảnh blockchain mô-đun, bộ tuần tự (sequencer) là thành phần hoặc nút chịu trách nhiệm sắp xếp các tương tác trước khi xác nhận cuối cùng. Kiến trúc blockchain mô-đun tách biệt các chức năng blockchain khác nhau (ví dụ thực thi, đồng thuận và khả năng truy cập dữ liệu) thành các thành phần riêng biệt. Cách tiếp cận này nhằm nâng cao khả năng mở rộng, an toàn và hiệu quả bằng cách cho phép mỗi tầng được tối ưu độc lập.
Khi phát triển game nhiều người chơi, chúng ta cũng cần một thành phần giúp sắp xếp thứ tự tương tác giữa các người dùng khác nhau. Do đó, chúng tôi mượn lại thuật ngữ "tuần tự hóa" từ blockchain mô-đun.
Vì game yêu cầu độ trễ thấp, nên tốt nhất chọn một bộ tuần tự tập trung để tạo kết quả sắp xếp nhanh. Công cụ chơi game cũng có thể phối hợp chặt chẽ với bộ tuần tự để đồng thời lấy các giao dịch đã được sắp xếp.
Giao thức tương tác cho một người chơi
Ở đây (xem hình dưới), chúng tôi mô tả một giao thức tương tác từ góc nhìn người chơi. Trong giao dịch người dùng, người dùng mô tả đầu vào của họ, và chứng minh danh tính bằng đầu vào công khai và đầu vào bằng chứng, có thể có cấu trúc như sau:
Đầu vào công khai và đầu vào bằng chứng:
Logic xử lý tương tác:
pub fn zkmain() -> i64 {
let mut hasher = Sha256::new();
// get the command length
let commands_len = unsafe {wasm_input(0)};
// processing all commands and
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
Blade Research
