CryptoScalies: Cute Lizards at Scale

A revised version of this article is available under at https://medium.com/alacris/cryptoscalies-cute-lizards-at-scale-5ac34e6cc2af

In our previous article, Scaling your dApps with Legicash, we gave a general description of the Legicash architecture. Let us now examine how it can help build everyone’s favorite distributed application (dApp) of the day: trading non-fungible assets with pseudo-random characteristics derived from a “genome,” visualized graphically as cute animals. In other words, CryptoKitties and its many spin-offs. Of course, this frivolous example will only be a fun device to examine issues that crop up in all dApps, including more serious ones like a decentralized exchange (DEX), or an on-chain car-rental service.

Despite CryptoKitties’ popularity, one thing that limits its usage is its reliance on an Ethereum transaction to generate each new kitty. Since Ethereum can only handle about 15 transactions per second for all users in the entire world, this proved to be a severe bottleneck at the height of CryptoKitties’ popularity, slowing all transactions on the network to a crawl.

What if we could scale this dApp so it could be used by hundreds of millions of users at a rate of thousands of transactions per second? What if this scaling could be achieved without jamming the Ethereum blockchain, yet with all transactions 100% backed by Ethereum tokens? The Legicash architecture enables a variant of this dApp that scales beyond what on-chain designs allow.

Let’s call this variant CryptoScalies. This time the cute animals are lizards with scales, at scale. Of course, since the Legicash architecture isn’t fully implemented yet, this will be a thought experiment — but one that hopefully clarifies the goal we are working towards.

CryptoScalies can be written as a series of “layer 3” applications on top of Legicash, defining a new asset class and ways to use it, and automatically benefiting from the scalability and security of the Legicash network of side-chains. Because CryptoScalies scale, users can breed and trade them as fast as they’d like. Side-chains also serve as marketplaces where users can publish sale listings and purchase offers for CryptoScalies, or even conduct auctions. But thanks to scaling, there is more to CryptoScalies than breeding and trading. Users can also organize play dates for their CryptoScalies so they can socialize and practice cooperative activities or competitive sports. Did you know that CryptoScalies enjoy improvisational jazz? That they love playing tennis doubles and team tournaments?

Scaling with Facilitators

Breeding and trading CryptoScalies, having them play together or against each other, etc., are all made possible through facilitators: servers that act as intermediaries between users to help dApps scale, and manage auditable side-chains. Facilitators can thus serve as brokers, auctioneers, matchmakers, tournament organizers, or other intermediary roles for all activities involving CryptoScalies. Users put each of their assets under the temporary and revocable care of a facilitator. Facilitators will then receive orders from users as to how they want to trade CryptoScalies, or how they want their CryptoScalies to interact with others, and under what specific conditions they are ready to transact.

Facilitators can orchestrate all these interactions with high throughput and low latency because they are authorized by users to do so independently of the main-chain consensus. They do update the main-chain, but only with a very short cryptographic summary of large batches of activity, from which each constituent action can be succinctly proven. Amortizing this small on-chain transaction over a large number of users makes side-chain interaction extremely cheap.

These characteristics mean that dApps on Legicash can scale. Facilitators are a generic solution to scaling all kinds of dApps: take our basic dApp for fast payment, and extend it with additional operations to handle your new assets and transactions.

Interactions between CryptoScalies

Thanks to facilitators, CryptoScalies can not only reproduce and change owners, but interact with each other, in a matter of milliseconds. These interactions would not be possible without scaling, as enabled by our facilitators. We will demonstrate two kinds of ways that Facilitators can help scale activities between users: first, cooperative activities, illustrated with improvisational jazz and payment channels; and second, competitive activities, illustrated with a tennis match, but also auctions and exchanges.

In a cooperative activity, like musical improvisation, where the interests of all participants are already aligned, and the number of participants is relatively small (say a few dozens at most), it is better and faster for these participants to conduct their operations directly amongst each other without a referee. The facilitator will thus help them setup a shared interaction channel, where participants can conduct all their operations among each other off-chain, using multiparty signatures to validate the progress of their interaction and only posting to the side-chain (and indirectly to the main-chain) the final result of their interaction, if any. A well-known particular case for such a setup is payment channels in the style of the Bitcoin Lightning Network. Using Legicash allows these channels to scale further as a layer 3 solution than they can on Bitcoin as a layer 2 solution: it can be hundreds of times cheaper to create such channels as layer 3 on a side-chain than it takes to create a single channel as a layer 2 solution directly on the main-chain; and the latency to full confirmation is only marginally slower, as they propagate from users to the side-chain to the main-chain.

In a competitive activity like a tennis match or tournament, the interests of participants are locally opposed to each other; the facilitator can then act as a neutral referee who will ensure interactions are fair without sacrificing latency. Typically, the game mechanics involves users each making strategic choices or contributing to random seeds and publishing a digest of their choices in a first phase. In a second phase they reveal their verifiable choices, leaving no way to cheat, except trying to time out rather than lose explicitly. With a neutral referee, those who fail to reveal their choices in a timely fashion lose their match by default and get excluded from their tournaments. Low-stake tournaments can have long timeouts, whereas high-stake tournaments will require players to remain constantly connected. Repeat offenders may also get excluded from all further activities unless they pay a suitable penalty to fully compensate victims and show their atonement. More generally, users who fail to complete their part of the protocol are increasingly penalized as their misbehavior repeats and/or as the stakes get higher. In financial transactions, they may have to pay interest or rent on the assets immobilized by the other parties during their lack of response, taken out of the collateral bond that was posted. On the other hand, in higher trust settings, when friends play for fun, acquaintances play with low stakes, or business partners interact in repeat business, they may nominate a referee among themselves, or rent a trusted yet affordable one, who can serve them as a faster, layer 3 solution. Users can thus achieve higher speed and lower transaction fees without sacrificing the security of transactions being ultimately backed by the blockchain.

In all of these cases, the Legicash architecture can help create new applications not otherwise possible, using side-chains to enforce verifiable computations.

Holding Facilitators Accountable

Facilitators can be a great resource if they are indeed honest and competent. But why should anyone trust them? For the very same reason that you might trust anyone else — because facilitators are motivated by the profits from behaving honestly and will be held accountable if they don’t. Facilitators are competing on a free market and will lose their customers if they don’t offer the best value for their customers in terms of service and price.

We have designed Legicash so that a facilitator only loses money by acting maliciously while honest behavior earns business, and in turn, profits from fees.

Real-time auditing of a facilitator’s behavior ensures that there is a limit to how much damage they can do before they are caught — at which point they forfeit the bond that they posted as collateral. If that limit is small enough compared to the bond, it will not be in their interest to cheat at all. There is still the case of the incompetent facilitator getting hacked by those who might profit at the expense of both the facilitator and the users; but even in this case, the limits on possible damage mean that the risk is insurable — and on-chain or off-chain means are available to make honest users whole. We also expect hacks to be rare because Legicash will provide code with enough proof of correctness that it will not be the weakest link in the security defenses, as well as guidelines and training to deploy our code securely.

A facilitator’s track record can be established because its public keys provide a long-term pseudonymous identity. If a facilitator has been providing great service, they will be very recognizable. If a facilitator behaves dishonestly, they will have to create a new identity, post another bond, and build a reputation from scratch, just to be able to cheat again. Moreover, the Legicash architecture allows for people and institutions that already have a reputable identity to become facilitators that are recognizable and therefore, more likely to be a preferred facilitator. Based on this identity and reputation, some may even be able to purchase insurance so that users would be fully compensated even if the facilitator were to fail or get hacked, improving their trustworthiness to users. Users will thus have a wide range of facilitators to choose from, depending on their risk profile.

The last aspect of accountability that ensure that there will indeed be a free market in facilitators is that users can repudiate an unsatisfactory facilitator — users can at any point unilaterally extract their assets from their facilitator’s custody by appealing to the main-chain contract.

Reasons to leave may include:

• The facilitator could be incompetent or dishonest.
• The facilitator’s servers could be destroyed or captured.
• The powers-that-be in a country where the facilitator operates could prohibit the facilitator from handling further transactions.
• The facilitator could increase their fee schedule beyond what the user is willing to pay.
• Network disruption could make it impossible or impractical for the user to communicate with the facilitator.
• A spokesperson for the facilitator made disparaging comments about the user’s favorite celebrity.

Ultimately, any user’s reasons are their own, wise or frivolous.

Whatever the case, users can move all of their assets to another facilitator, without justification or cooperation from their original facilitator. In the Legicash architecture, this is guaranteed by the smart contract that binds the side-chain to the main-chain. Users can post transactions on the main-chain that the contract forces the facilitator to process. Users can even post transactions on the side-chain of another facilitator who will batch such transactions on the main-chain. Thus, mass exits from a side-chain can scale when that side-chain suddenly becomes unpopular — whether because of a fee hike, a scandal, or cheating.

This right to exit possessed by every user ensures free competition among facilitators. But what if all facilitators hike their fees at the same time? The right to enter ensures that anyone can become a facilitator, even you, dear reader, if you believe that you could provide a cheaper, better service to yourself, your friends, and other “victims of the system,” and still swim in gold. It’s a free market out there, and we expect competition to keep prices down and service quality up.

Verifiable Computations

The main technical challenge in holding facilitators accountable is, how can you audit a facilitator’s behavior, in real-time, and verify that they are indeed honest? That’s where the Legicash architecture brings new answers.

As for the verification of the result of interactions between CryptoScalies, the Legicash architecture makes that efficient because it shifts most of the work from the shared network where computations are expensive, to the individual users and facilitators for whom it is cheap. The network doesn’t run the computations, it only verifies them. The interactions will be specified in the Legicash programming language, which will allow for extraction of all components of the system: the software that partakes in the protocol, the software that computes the results, the software that produces a proof that the result is correct, the software that checks the proof that the result is correct, the software that argues the proof before the consensus (if required), etc. Application programmers will be able to write the software once and be confident that all these components will be consistent with each other and that the system is secure.

There remains the issue of making transaction data available for audit. Repudiable facilitators are required to constantly maintain a suitably indexed journal of all their activities on a side-chain. Then they must constantly publish this journal to a court registry, that makes the data available to verifiers and serves as an oracle to make this availability known to the main-chain. The Legicash contract on the main-chain then relays the public status of the data. Facilitators partake in the court registry and watch each other; they risk their own money if another facilitator starts lying, and an adversary would have to capture a majority of facilitators to take over the system.

In the end, facilitators leave behind an audit trail and the transactions they facilitate are only considered confirmed after the trail is validated. This leaves precious little space for a facilitator to cheat in any way without getting caught and losing big. Whether they match users on an exchange, preside over auctions, arbitrate a tennis match, facilitate payments, or conduct any kind of activity, this activity can all be audited and verified. The only leeway they have is in denying or delaying service to some users while processing other users faster. Quality of service is not verifiable by the court system, but it is measurable by the users who can compare how each other fare and decide where to bring their business and at what price.

Confirmation, Fast and Slow

Transactions go through many stages, and which stage you consider “confirmed” depends on how much you trust other participants with respect to the transaction amounts at stake.

1. If a close friend or an otherwise reputable person promises to send you money to pay their share of a restaurant bill, you can probably take them at their word and cover their meal without waiting for the payment to clear two hours later. For somewhat larger bills from less trusted people who are nevertheless well-identified and solvent, you can also probably take their word and escalate the situation if they don’t pay you in a timely manner: first, follow up casually, and if all else fails, take them to small claims court. In all these cases, you don’t need the facilitator network to authorize an immediate transaction; still the network can bring you peace of mind, especially in the border cases where you might not be so sure about the trustworthiness of the other person.
2. If you fully trust that the facilitator is not colluding with a customer because it’s a big, known financial institution and the amount is small enough, you may serve that customer as soon as the facilitator sends confirmation of the transaction, which takes a fraction of a second.
3. If the payments you receive are suitably insured (at a small premium) or if you reasonably trust the facilitator not to cheat on the transaction you are receiving, then you may serve the customer as soon as a quorum of the court registry agrees that the transaction looks good, which typically takes a few seconds.
4. If you have no reason whatsoever to trust either the customer or their facilitator, or if the transaction is large enough that you should take extra precautions, then you should definitely wait for the consensus to fully confirm the transaction, which may take one hour, or even several hours, depending on the facilitator configuration.

There are all kinds of transactions, and a large number of them fit into Cases 2 and 3 above, at which point the Legicash system will make them fast when they would otherwise be slow. Other transactions, such as in Case 4, are actually made somewhat slower, but are also cheaper, than by directly using the main-chain. Notably, most casual payments can be transacted quickly as in Case 3: Small payments in stores up to a few thousand dollars using a reputable facilitator such as an established financial institution. As for playing tournaments between CryptoScalies through a reputable facilitator, it can also be considered fast for most purposes; but don’t go spending or gambling away all your earnings before they are fully confirmed.

In conclusion, Legicash can help you develop dApps that scale, in a safe way. The volume of transactions can be large. The cost of transactions will be low. The effective latency of transactions will be low in a wide variety of cases and the security of the system will be much better than if you had to rebuild the same system from scratch using lower-level tools than those that Legicash offers.

If you enjoyed reading the article or would like to follow along with our progress, we invite you to share your thoughts and continue the conversation on Telegram at https://t.me/LegicashCommunity.