Làm cách nào để sử dụng OPStack để xây dựng chu kỳ đồng hồ của toàn chuỗi trò chơi?

Tác giả: Gametaverse

Nói chung, trò chơi dựa trên vòng lặp. Vòng lặp trò chơi là một quá trình lặp đi lặp lại thường bao gồm xử lý đầu vào của người dùng, cập nhật trạng thái trò chơi và hiển thị thế giới trò chơi. Vòng lặp này tiếp tục trong khi trò chơi đang chạy, thường chạy hàng chục đến hàng trăm lần mỗi giây để giữ cho thế giới trò chơi trôi chảy.

Tuy nhiên, kiến trúc của chuỗi khối dựa trên đẩy. Chuỗi khối là một cơ sở dữ liệu phân tán chia sẻ và lưu trữ thông tin thông qua các nút trong mạng. Khi một nút tạo một giao dịch mới (chẳng hạn như chuyển khoản, gọi hợp đồng, v.v.), giao dịch đó sẽ được đẩy lên mạng và các nút khác sẽ xác minh và thêm nó vào chuỗi khối sau khi nhận được giao dịch. Đây là một quá trình thụ động, các nút sẽ không chủ động tìm kiếm các giao dịch mới mà đợi các nút khác trong mạng gửi các giao dịch mới. Do đó, kiến trúc của chuỗi khối được cho là dựa trên lực đẩy.

Do đó, điều rất quan trọng là triển khai hệ thống chu kỳ với chu kỳ đồng hồ trong trò chơi toàn chuỗi. Xét cho cùng, trong cái gọi là "thế giới tự trị", tất cả chúng ta đều hy vọng rằng một số NPC hoặc môi trường ảo có thể tự động phát triển theo thời gian, thay vì phát triển thụ động theo đầu vào giao dịch được đẩy lên chuỗi khối.

@therealbytes đã phát triển một chuỗi đánh dấu bằng chứng khái niệm (chuỗi có chu kỳ đồng hồ) dựa trên OP Stack, chạy triển khai đánh dấu tích tự động trong Trò chơi cuộc sống của Conway, hãy xem cách anh ấy triển khai nó.

Để giữ cho bản dịch được đơn giản, chúng tôi dịch nghĩa đen của tick thành "tick", có nghĩa là "chu kỳ xung nhịp đồng hồ".

Ticking-Optimism là một triển khai bằng chứng về khái niệm của "Ticking Blockchain" dựa trên kiến trúc cuộn lên của Optimism Bedrock.

Trong chuỗi đánh dấu, có một hợp đồng thông minh đặc biệt được gọi là "hợp đồng đánh dấu" và mỗi khối sẽ được giao thức gọi tự động. Điều này cho phép các hợp đồng thông minh khác tự động kích hoạt vào những thời điểm hoặc khoảng thời gian cụ thể mà không yêu cầu người dùng gửi giao dịch.

Làm thế nào để đạt được

Kiến trúc tổng hợp mô-đun mới của Optimism, Optimism Bedrock, giới thiệu một loại giao dịch mới được gọi là "Giao dịch tiền gửi". Khác với giao dịch thông thường, giao dịch tiền gửi:

• Các khối từ Lớp 1.

• Không cần xác minh chữ ký.

• Mua gas L2 trên L1 nên gas L2 không được hoàn lại.

Trong Bedrock ban đầu, các giao dịch gửi tiền được sử dụng cho hai mục đích:

• Thực hiện các giao dịch được gửi trực tiếp đến L1.

• Đặt thuộc tính L1 (số, dấu thời gian, hàm băm, v.v.) cho các hợp đồng L2 được triển khai trước trong mỗi khối.

Trong trường hợp sau, các giao dịch được tạo bởi các nút tổng số. Nó không trả tiền gas và gas đã sử dụng không bị trừ vào bể gas.

Ticking-Optimism sửa đổi nút tổng số và cũng tạo ra một "giao dịch đánh dấu" hoạt động theo cách tương tự, nhưng thay vì đặt thuộc tính L1, nó gọi hàm tick() trong hợp đồng được triển khai trước tới địa chỉ 0x42000000000000000000000000000000000000A0. Hợp đồng này có thể gọi một hợp đồng khác bằng cách đặt biến mục tiêu của nó.

Động lực

Để minh họa sức mạnh của tickchains, hãy tưởng tượng một trò chơi trên chuỗi khối nơi nhiều NPC (nhân vật không phải người chơi) di chuyển quanh bản đồ. Không có chuỗi đánh dấu, chúng tôi có hai cách tiếp cận thiết kế chính:

• Lười cập nhật. Về phía khách hàng, các NPC dường như di chuyển liên tục, nhưng vị trí của họ chỉ được cập nhật trên chuỗi khi người dùng gửi giao dịch để tương tác với họ. Sau đó, hợp đồng sẽ tính toán vị trí mới của NPC dựa trên lần cập nhật trực tuyến cuối cùng của nó và số lượng khối đã vượt qua kể từ đó.

• Đánh dấu thủ công. Chúng tôi xác định chức năng cập nhật đặt vị trí của từng NPC trên bản đồ và có một tài khoản bên ngoài gọi nó theo định kỳ.

Với tickchain, giải pháp tương tự như ticking thủ công, nhưng hợp đồng tick gọi chức năng cập nhật tự động thay vì thủ công.

Ưu điểm của việc sử dụng "tự động đánh dấu" của chuỗi đánh dấu thay vì đánh dấu thủ công là:

• Cập nhật được đảm bảo theo thỏa thuận.

• Bản cập nhật sẽ được thực hiện trước tất cả các giao dịch trong khối và không thể thực hiện trước vì bản thân nó là một phần của giao thức.

• Cập nhật các giao dịch không tham gia thị trường gas thông thường.

Tuy nhiên, đánh dấu tự động yêu cầu một chuỗi khối tùy chỉnh. Nếu tốc độ cập nhật là như nhau, đánh dấu thủ công và tự động yêu cầu cùng một tài nguyên máy tính trên nút. Mặt khác, các bản cập nhật lười biếng thường rẻ hơn vì các bản cập nhật trên chuỗi nhỏ hơn và ít thường xuyên hơn.

Ngoài ra, chi phí tính toán của các giao dịch đánh dấu tăng lên khi trạng thái cần được cập nhật tăng lên. Điều này gây thêm áp lực cho các nhà phát triển trong việc thiết kế các ứng dụng của họ sao cho chi phí không bao giờ vượt quá khả năng mà chuỗi có thể hỗ trợ.

Bất chấp những hạn chế lớn này, các đánh dấu tự động phù hợp hơn là các bản cập nhật lười biếng đối với một số loại ứng dụng nhất định.

1. Trạng thái luôn rõ ràng trên chuỗi và cập nhật

Các dấu tích cho phép các hợp đồng thông minh truy cập, với chi phí không đổi, trạng thái động được cập nhật bằng cách sử dụng các biểu thức dạng mở.

Trạng thái (trong ví dụ trên, vị trí của NPC) luôn có thể đọc được trên chuỗi với chi phí gas không đổi, tương đối thấp. Nhưng chi phí tính toán trạng thái hiện tại sẽ tăng theo số lượng khối kể từ lần cập nhật cuối cùng và chi phí gas sẽ tăng nhiều hơn.

Nếu chúng tôi đang cập nhật vị trí của một thực thể đang di chuyển với vận tốc không đổi, thì chúng tôi có thể tính toán vị trí của thực thể đó trong bất kỳ đoạn cụ thể nào từ vị trí đã đặt cuối cùng của nó và số lượng khối kể từ khi cập nhật. Chi phí của hoạt động này không tăng theo số khối giữa các lần cập nhật.

Mặt khác, nếu trạng thái chúng tôi cập nhật giống như Trò chơi cuộc sống của Conway (hoặc mô phỏng ba trọng lực), chi phí cập nhật sẽ tăng tuyến tính với số bước kể từ lần cập nhật cuối cùng. Đây là một vấn đề vì nó có thể phát triển vượt quá những gì người dùng sẵn sàng trả hoặc những gì chuỗi có thể hỗ trợ.

2. Các chức năng khác nhau của client

Với các bản cập nhật lười biếng, logic cập nhật cần được triển khai trong cả hợp đồng thông minh và ứng dụng khách. Với việc đánh dấu, nó chỉ cần được triển khai trên chuỗi khối và khách hàng có thể phản ứng đơn giản với các sự kiện trên chuỗi.

3. Code đơn giản và dễ review hơn

Cập nhật chậm cho phép các nhà phát triển trải rộng logic cập nhật của họ trên nhiều chức năng và hợp đồng thông minh, với mỗi chức năng chỉ được kích hoạt khi một số giao dịch nhất định được thực hiện. Ngược lại, cách tiếp cận tick-tick chỉ yêu cầu một chức năng cập nhật được đảm bảo kích hoạt định kỳ. Cái sau giúp dễ dàng duy trì tính nhất quán và tính toàn vẹn của trạng thái.

Ngoài ra, mỗi khi một trạng thái lười cập nhật mới được thêm vào (ví dụ: một loại NPC mới), tất cả các chức năng cập nhật có thể cần phải được sửa đổi để giải thích cho nó. Điều này làm cho cơ sở mã phức tạp hơn và dễ gặp sự cố.

4. Người dùng không trả chi phí cập nhật

Chi phí của các bản cập nhật lười biếng thường rất khác nhau và người dùng có thể tạo các giao dịch của họ để phần lớn gánh nặng cập nhật rơi vào người khác. Với bọ ve, chi phí của tất cả các hoạt động tương đối ổn định và không dễ bị tấn công bởi MEV.

Bản trình diễn Trò chơi Cuộc sống của Conway

Tôi đã tạo bản trình diễn tickchain chạy phiên bản tương tác của Trò chơi cuộc sống của Conway. Chuỗi đã được sửa đổi để bao gồm logic máy tự động di động trong công cụ thực thi, giúp nó hoạt động hiệu quả hơn, cho phép tạo ra một bảng trò chơi lớn hơn mức có thể được triển khai dưới dạng mã byte hợp đồng thông minh.

Mã nguồn của bản demo:

video giới thiệu: