Mirroring: Trade on L1 // Play on L2
In line with our upcoming migration to Arbitrum Nova, we are launching Mirroring: new tech enabling a huge step forward in adoption-readiness for web3 gaming.
When we launched Pirate Nation, building something fully on chain was really important to us. Because of the way different chains work, we wanted to have a game that ran across multiple chains, so we could minimize the technical trade-offs associated with each chain. In other words, we wanted to have our cake, and eat it too.
We are pleased to inform the web3 community: the time has come to have our cake, and we shall be eating it too.
Within the coming days as we complete our migration to Arbitrum Nova, we will be releasing our Mirroring tech. Mirroring is a huge paradigm shift for how we build games, and further enables us to have assets on the chains where liquidity lives and game on the chains that are best suited to scalability, frictionless player experience, and underlying costs.
Within our current setup, mirroring replaces bridging. (For context: currently to play Pirate Nation, you must bridge your Founder’s Pirates NFTs to Polygon).
Mirroring opens up some distinct advantages of us over a bridging model, but with some interesting trade-offs. Some of the advantages we have are:
- NFTs always tradable 24/7- no more locking!
- Simplified shopping experience, there’s only one chain for purchasing.
- Less friction to play: unlike a bridge user does not have to do any extra steps to move the token to another network.
Altogether, this represents a massive step forward in on-chain gaming moving towards wider adoption, and mainstream-readiness.
So how does mirroring work?
When you purchase a NFT on Ethereum (L1), we monitor the L1 Token contract looking for any Transfer event. When a transfer event occurs, we have a similar, yet different contract on L2 that is only tradable by us. This contract is used by the gameplay contracts on L2 to verify you are infact, the owner of your particular token.
When you make a purchase on layer 1, we watch all the token transfer events of our token, and using our mirroring system to react in a 3 step process.
The first step moves the token to a temporary address that restricts the usage of the token in L2. For Pirate Nation this is the Sea address (0x5EA). We thought this was fitting. We use this step to be able to tell users how long it will generally take for their pirates to come on board into the game, and be ready to play.
Once we’re satisfied that the block is going to go ahead and be confirmed, we move the token to the new owner.
Finally, we verify that everything went already and the block has been put at rest.
We also have a separate task that scans for finalized transactions, and that is equipped to handle things like downtime of the mirroring system or catching re-orgs. This process will scan through ownership values and put them in their appropriate places.
The impacts of opening up trade.
One of the downsides to call out to this approach is that we do in fact, place a restriction on our game design. Because it takes time to travel across the sea to the new owner, if the NFT was involved in a long gameplay action that was triggered between the user buying and the NFT moving, the new owner could end up with a different style asset that they have asked for. While in the current gameplay of Pirate Nation the world is very safe, the worst thing that could happen is you end up with a little less energy then you have planned, we have quite a few features planned that could have negative impacts on your character.
To supplement this, Tokens that will have negative impacts associated with them will be required to have appropriate two step cooldowns to allow for this. This will allow the buyer to be able to see what is happening and gamble on the outcome. An interesting example of this is with Ship Building, you could be crafting an improvement to a ship that has a random outcome, you then decide to put this on the market. The market will see a ship that is ‘under construction’ and buyers will get the chance to gamble on whether the upgrade is a good one or a bad one. The key is that we must have a part of the game inform the potential buyers that there is a potential change in their digital good.
NFTs and bridges, not a match made in heaven.
One of the biggest advantages of this approach over using a traditional bridge, is that when you use bridging, typically a bridge owns your asset on the other network. In our previous implementation of bridging, this was certainly the case, and for our original L1 contract, Polygon bridge owns a significant amount of Pirate NFTs!
This means that you’re heavily reliant on the bridge, if the bridge were to go down at some point, you don’t actually own the token on the other network anymore as you bridged it. While this is no problem for things like ERC20 tokens or even ERC1155 tokens where the tokens are not unique and have a larger supply, for things like 1/1’s it is a nightmare.
If for example there was a bad actor in the bridge, it would be very difficult to get that asset back as you can’t just mint back a 1/1.
Ownership is key here.
To solve the above solution, the key is to never have the ownership on L1 be compromised. By ensuring the player always holds the L1 token, they will always own the token. Ownership matters.
Layer 2 and portability.
Mirroring brings portability here, enabling a multi chain experience where if the layer 2 had issues, we could easily continue on another chain. If for some reason there was downtime, we could easily look up the Layer 1 for ownership properties and continue on another chain.
Interoperability.
Some major advantages of mirroring over other technologies like Bridging or even using L1 → L2 messaging is that you can work with any existing NFT, as long as it supports the ERC721Spec. This means our L2 games can use any existing NFT to play games, which can allow some pretty nice interoperability between different games.
Additionally, because there are no changes needed on the L1 side, the L1 can be gas optimized for transfers. This means you can make your L1 contracts specific to your use case. In the case of minting the PirateNFTL1 again, we considered various contracts (ERC721, ERC721A, TinyERC721 and ERC721Enumerable) and landed on using ERC721 without enumerable, as it was the most gas efficient for our existing ownership distribution.
Mirror, mirror on the wall.
We’re incredibly excited to launch mirroring in the days ahead. Watch our twitter for the latest updates on our migration, and upcoming spaces we’ll host to dive deeper into the tech behind our mirroring system!
Onward!
Proof of Play Team
