Scaling EOSBet

CPU has again become a major issue on the EOS mainnet. Initially, the solutions were simple, and during the first crisis we led the charge to successfully greylist blocktwitter from their spam campaign.

Later, the CPU issues were “solved” by raising the CPU/block limit from 10% (of the 200ms hardcap) to 20%. After this limit was hit, the CPU/block limit was hastily raised to 30%.

This caused a large number of issues with micro-forks and orphaned blocks. Team Greymass even warning that “continued increases would be increasingly harmful and damaging to the ecosystem” and that “it’s a button we cannot keep pushing”. Soon, the CPU/block limit was reduced to 25% and will probably not be touched for the foreseeable future.

Currently, with “real transactions,” the EOS network maximum is around 75–100 transactions per second (https://bloks.io). I say “real transactions” because current transactions have many table reads, writes, and actions (unlike the extremely lightweight blocktwitter spams of yesterday). There are some ways to increase this limit in the near future, like arranging the block producer schedule by longitude (instead of alphabetically as it currently is), and tweaking the block maximum again. Block producers can also make direct P2P connections between their producing nodes, instead of adding (perhaps unnecessary) latency by putting proxy or intermediate nodes between block producers’ producing nodes.

Even with these quick adjustments, it’s doubtful that we will be able to increase the CPU/block ratio above 30–35%. A ratio that’s too high makes the network extremely unreliable, and once blocks go missing, it decreases the effective CPU output of the network.

There are other parameter tweaks we could make that have not yet been discussed. Say blocks in the middle of a block producer’s schedule may have a 40–50% CPU/block cap, while the handoff blocks must be 20%. This is valid, because it allows for heavier blocks to propagate more slowly, while the (often orphaned) handoff blocks remain lightweight.

But, these are simply parameter tweaks. Idealistically, we could achieve around 125–150 real transactions per second if these were implemented today (an increase from the current 75–100 real transactions per second). However, I would not consider this “scaling” by any means.

Scaling a blockchain is hard, a subject of intense debate, and hasn’t truly been solved yet. We can wait for multi-threading, or IBC, but we will be waiting a while as these are quite difficult to implement, and in some cases, are still open problems.

Luckily, we at EOSBet Casino don’t need to solve these hard problems. We can leave these issues to the noble open-source software contributors and developers at block.one

Scaling EOSBet

However, we need to scale EOSBet now and not wait for future, theoretical fixes from block.one. We have a few options, which I will outline:

Option 1: Move to a different eosio blockchain

With the recent launch of TELOS, there is a possibility of porting our contracts over to their blockchain. There are zero applications on their network, and with the assumed low price of the TLOS token, we could hoard a large amount of network bandwidth on TLOS, guaranteeing us a large percentage of their CPU through-put for the foreseeable future of their blockchain.

We would benefit by having 21 similarly decentralized BPs processing our transactions and maintaining the network. Resources would be much cheaper initially, and there would be much less competition in the future after buying up a large amount of cheap TLOS.

We do make some sacrifices — namely we lose the massive network effects that come from being on EOS mainnet. Many users have an EOS mainnet account, and EOS is purchasable on many large exchanges. We cannot say the same about TELOS. It would be easy to make a gateway to transfer EOS tokens to pegged-EOS on the TELOS network. However, this would be a trusted solution, which somewhat defeats the purpose of playing decentralized and trustless blockchain games. It seems that many users do not care about trustlessness, as EOSBet is the only open source dice game, and people play the hundreds of other closed-source dice games. Playing on closed-source smart contracts is inherently non-trustless, but users continue to do so.

The downsides of this solution are that we still have to pay for CPU on the TELOS network, and TELOS naturally has the same exact scale limitations of EOS mainnet. However, if we were able to obtain a quarter of TELOS network bandwidth, and they maxed out at 100 real transactions per second, then we would be able to process 25 bets per second, forever. Not bad.

Option 2: Move to a custom built eosio sidechain

Taking Option 1 to the extreme is easy. We can simply build and deploy a custom eosio side chain, and have the network all to ourselves. With a centralized sidechain, which a custom side-chain would be, we could tweak parameters and increase the CPU/block limit to 100% (We never have to deal with intra-producer latency, we are the producers!). It would be relatively easy to hit 400–500 real transactions per second with this architecture, and maxing out the side chain would be incredibly tough.

But what is the point? If we control every single producing node in a sidechain, we control the entire chain. Winning bets could be forked out of the chain, and it would be easy to run off with funds (which we would never do), and it turns into a wholly trusted solution. However the point of blockchain gaming is trustlessness. Perhaps this is fine, as the current market doesn’t seem to care. But at this point, we are no different than a completely centralized casino site, of which there are tens of thousands in the world. We have the marketing benefit of being on a blockchain, but at this point it’s just a gimmick. Besides, centralized client-server architecture works incredibly well, and has been perfected over decades, so why bother using eosio software at all?

Someone might argue that we create a side-chain, and then hire block producers not affiliated with us to process transactions. Idealistically, this works. However, what happens when we maliciously stop paying these hired block producers? Soon the lights go off on the sidechain, unless the hired block producers are willing to keep producing on the chain while taking a loss every day. Doubtful. This makes it a non-trustless solution.

Option 3: State Channels

For those unfamiliar with the term, state channels are a way of performing a trustless interaction off-chain. In short, a player would agree to an escrow contract with EOSBet. Then, through a series of cryptographically signed messages, the player can play a casino game, or “roll the dice” nearly infinite times. All these dice rolls happen off-chain, are instant, and CPU-free. Once the player is done gambling, the final state of the game (e.g. the player has profited 100 EOS) is broadcast by either party to the blockchain, and the funds are paid to their wallet. Now, rolling the dice 1,000 times requires 2 transactions, instead of 2,000 transactions as it does today!

Even more exciting is that state channels are fully trustless, and disputes can be raised though an on-chain transaction and smart contract. If the casino refused to pay a player for a big win, then a dispute can be raised, and the dispute resolution smart contract could instantly payout the player for this win.

Here we have the best of the two prior solutions. We have full trustlessness, and nearly infinite scale. Dice rolls can be as fast as a web socket stream (i.e. really fast). Transactions are only used to open and close channels, as well as for the rare dispute. With state channels, our blockchain footprint is tiny—you would only make one transaction to us per gambling session!

Of course, the drawback is that state channels with full dispute resolution are extremely difficult to develop. It has taken FunFair years to create viable state channel tech on Ethereum, and their partner casinos still have little-to-zero traction.

Conclusion

We are currently exploring all three of these options to scale EOSBet Casino. The current CPU crisis is unacceptable, and serves to price smaller gamblers completely from the market. Only large whales, with thousands or tens-of-thousands of EOS staked can play for a reasonable length of time.

After our official launch out of beta in 1–2 weeks, which includes a completely redesigned website and new Crash game, we will be launching our first game with our initial state-channel tech. This is only a beta, and the game will be quite simple. However, we’d love to demonstrate the power of this scaling solution to the EOSBet community.

Likewise, we are considering launching a game on a side-chain or on the TELOS network as another proof-of-concept. We don’t believe it’s fair that smaller gamblers do not get to play our games and engage in token mining during times of network congestion. We are committed to the EOSBet project, and are disappointed that we cannot serve all our users effectively. However, clear solutions exist, and we are excited to start developing and incorporating them onto our platform.

Cheers,

Team EOSBet