In the past year, rollups have become one of the leading hopes of scaling Ethereum on “layer 2”. With gas fees surging throughout the year with the rise of DeFi, they indeed offer a great way to off-load smart-contract computations as well as storage in the network’s global state.
So what are rollups on Ethereum? Roughly speaking, users of a rollup-enabled application can still perform smart-contract operations as normal (e.g. transfers or swaps of tokens). The transaction data is recorded on the base chain (Ethereum in this case), but execution of the operation is done by some external entity (the relayer). Changes to the state are still synchronised back to the base chain by the relayer, although with some delay and in batches. This removes the computation cost from the base network, and also reduces state changes if some operations inside a batch cancel out (similar to how MimbleWimble improves scalability).
Of course, there is also a catch: The external computation and task of synchronising state changes back to the base chain done by the relayer introduces, at least initially, a trusted entity. There are two main ways to remove or reduce the required trust in the relayer:
Optimistic rollups like Optimism introduce fraud-proofs and slashing for this; in other words, the relayer is “trusted”, but other network participants can monitor its work and claim parts of a security deposit if it is acting maliciously. In this way, the relayer is kept honest through game-theoretic incentives, as long as at least some honest actors are watching the network constantly (and as long as the value at stake is less than the relayer’s security deposit).
zkRollups like Loopring and zkSync, on the other hand, verify all state updates of the relayer through a zero-knowledge proof that has to be bundled with the update. This ensures that the relayer can not cheat by sending an invalid state update; but it still has some freedom in ordering or even censoring transactions. The security model of zkRollups is thus much tighter than optimistic rollups, as funds stored on the rollup are never at risk. The drawback is that generating ZKPs for the update is non-trivial, and at least currently still limiting what kind of applications can be run on zkRollups.
GSPs are “rollups on steroids”
How is this related to Xaya? Well, for everyone familiar with our design, rollups will ring a bell. Rather than being created as a complete smart-contract platform, the Xaya blockchain is designed from the ground up to be a base layer for data availability. The actual applications built on Xaya (which we call GSPs) are detached; their computations and state do not burden the base network. This allows games on Xaya to be highly complex, like our two flag-ship products Taurion and SME. Thus, the scalability boost of rollups has always been a core part of Xaya’s scalable design.
But Xaya even goes one step further: By design, the base chain does not need any information at all about states of individual applications. This means that the synchronisation step of rollups on Ethereum, which creates the main issues and difficulties for them, is not there at all. Hence, applications built on Xaya have all the scalability benefits of rollups, without the need of a centralised relayer, without the need to watch over them constantly and without the limitations and technical complexity of ZKPs.
There are, of course, trade-offs to make: By removing synchronisation of game states back to the base chain, Xaya limits composability of individual applications. On Ethereum and in the DeFi space, this “money lego” has been a massive driver of innovation. For those use cases, it is certainly crucial to ensure interoperability of applications through a link between the layer-2 data and base chain, as done by rollups. Xaya, on the other hand, has been designed as a platform for highly complex and more separated applications like individual MMO worlds, that feature their own, internal economy following individual game design. For them, it is not necessary to synchronise detailed state between individual applications; it is enough to facilitate trustless, decentralised and smooth movement of value, e.g. through atomic trades and Democrit.
Hence, Xaya has been designed back from the start in 2016 with the same scalability in mind that rollups are now bringing to platforms like Ethereum. Its focus on complex applications rather than composable smart contracts allows it to even go further, removing the complexities and trust that rollups require due to their relayer. If one considers rollups as “layer 2” scaling, then the Xaya platform can be seen as native layer-2 by design. In that sense, game channels on Xaya would even be a layer-3 scaling technology. (But since GSPs, like rollups on Ethereum, still require data storage on the base chain, we actually consider neither them nor rollups as full layer 2 ourselves.)
So to summarise, we’ve seen that Xaya’s design with GSPs brings the same (or even more) scalability benefits for complex applications and games that are currently being developed for Ethereum with rollups. At the same time, Xaya’s focus on gaming rather than individual, interoperable smart contracts allows it to avoid the technical complexities and trade-offs related to trust/centralisation that rollups face. We are all very excited to see scaling technology like rollups evolve for the general blockchain and smart-contract ecosystem — but developers on Xaya have already been able to build highly scalable games without having to worry about the underlying technology for quite some time.
By Daniel Kraft November 2020
Want to know more about the benefits of blockchain for gaming?
Join the conversation: