Skip to content

Instantly share code, notes, and snippets.

@mattdesl

mattdesl/game-l2.md

Last active November 3, 2022 14:26
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mattdesl/5c7da721f0a08ba86cc520d5edbff9c2 to your computer and use it in GitHub Desktop.
Save mattdesl/5c7da721f0a08ba86cc520d5edbff9c2 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
game-l2.md

L2 Games and On-Boarding Flow

This is some loose thinking about how to securely bridge assets from L1 to a L2 for a blockchain game. See Dark Forest game as a reference.

The user experience flow should work like this:

  1. To create an account, the user is prompted with a unique private "serial key" and must copy it safely.
  2. The user can use this key to initialize a game account along with a payment of, say, $5 USD.
  3. Then the user can open the game interface, paste their serial key, and they will see their account has been pre-allocated with $5 USD worth tokens. These tokens can be used for gas fees (to cover the first ~100-1000 transactions depending on L2 network) or to pay for gameplay elements such as expansions and user-created content.
  4. When the user is finished playing, they can withdraw any remaining tokens from the game back to their L1 address—including any new assets or verifiable achievements they might have gained through their gameplay.

The attributes of this model:

  • Easy onboarding: user does not need to have an L2 account or even know anything about the L2.
  • Decentralized, permissionless, and non-custodial: there is no central actor holding custody over user funds or their private keys to their account.
  • Permissionless L1 withdrawal: at any point, even if the game publisher goes insolvent, the user can submit a transaction from their L1 wallet to withdraw their assets from the L2.
  • Not tied to L1 wallet: the user might not even realize they have a crypto wallet in the game, as it would be hidden in the game's UI. At no point do they put their L1 account at risk, as the L2 keys are independent of their L1 wallet.

Fee Models

If desired, the game publisher can optionally decide to take a % cut of profit from this account creation, so that to the user it will feel more like "buying a game." There may be other models such as a DAO or co-op receiving this fee to avoid it falling on a central entity. This % fee might increase the cost of Sybil attacks, which could be useful for some games.

Implementation

Here is loosely how I imagine this could be implemented:

  1. The "serial key" is a private key for a user's L2 account is generated locally and displayed to them without storing it or sending it anywhere. From this, a public key is generated publicAddressL2 which is their new account address on the L2.
  2. A contract on L1 has a payable purchaseTo function which accepts a publicAddressL2 input. This will send the funds to the user's publicAddressL2 on the L2 (maybe splitting funds with the developer if they are taking a % fee).
  3. Upon successful purchase, the contract will provide the user with a ERC-721 NFT that is their "Game Cartridge". This Cartridge can be used to verify deposits and withdraws on the L1 are being executed from the rightful owner, and also as a sort of public badge that points to a user's L2 account address ("I own this character"). The user can transfer or sell their game account since the Cartridge is a regular NFT.
  4. The user now can enter the game interface which is running entirely on the L2, and enter their private key to access their account with pre-allocated funds on it.

Privacy

Originally when I started thinking about this, I imagined a system that would allow for absolute privacy, so that a user can create a new account without having to tie their L1 address to the L2 address. This desire for privacy is not unusual - many gamers like to keep their purchases private.

Privacy can be achieved by skipping the "Game Cartridge" idea and just sending the purchase fee to a single pool on the L2, then generating a zk-SNARK proof showing that the user knows the secret key that can unlock their funds from this pool. The L2 contract will verify the zk-SNARK and release the funds to the user's desired (secret) address, and then apply some nullifier so that nobody else can use this proof to pull tokens from the pool. If there are enough purchases in the pool, it will provide some slight obfuscation as to which L1 account is associated with which L2 account. To cover the initial gas fees involved with pulling the funds out of the pool to the new account, a relayer or gas network will need to be used.

However, what I'm describing now is essentially how Tornado Cash works. Not three days after I posted this idea, Tornado Cash and its open source code happened to be hit with heavy US sanctions. So, at this point it seems like a risk to build a system that allows for private interactions on the blockchain.

Further Thoughts

This post is somewhat related to my thoughts on game NFTs using a L2 rollup (although this post deals with general purpose rollups like zkSync and Scroll, my other post is geared toward application-specific rollup run by the game publisher themselves).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment