Easy, Free, and Forever: The First Immortal LiquidApp is Live!
The future of dApps is here: vRAM, LiquidAccounts, LiquidDNS, IPFS hosting, and RAM-cached sessions converge in an immortal blockchain application with unprecedented ease of use.
In recent weeks, we at LiquidApps have advanced multiple new LiquidServices.
We also released the Zeus SDK to make blockchain development easier, including the out-of-the-box ability to integrate LiquidServices on the DAPP Network into your applications.
Now, for the first time, we’re able to highlight the seamless experience of using a dApp equipped with LiquidAccounts (alpha) and other LiquidServices. We decided to start in familiar territory for devs: the Elemental Battles game created by Block.one as an EOS development tutorial.
Introducing LiquidBattles: the Easiest dApp to Use Ever
Block.one’s Elemental Battles is a simple fantasy card game. As far as gameplay goes, it is just rock-paper-scissors with a couple of added layers of complexity.
But the moment you fire up LiquidBattles (currently on Kylin testnet) on your desktop computer, you’ll realize this is unlike any dApp you’ve used before.
There are no keys to enter, no wallets to open, no transactions to sign. Just a username and password. It’s as seamless as a traditional web app, or even more so.
How is this possible?
When you log into LiquidBattles for the first time, your LiquidAccount (again, currently on Kylin testnet) gets a public/private keypair — just like a mainnet account gets a keypair when you create it in your favorite wallet app. However, when your LiquidAccount private key is used to sign transactions, those transactions are sent to the EOS mainnet by way of a dApp proxy account that also signs them along the way. There is still no way for your LiquidAccount to be used without these keys, but you no longer have to manage RAM, CPU, keys, and permissions just to try a new dApp.
No more managing resources. No more paying for accounts. No more losing keys.
Of course, not every dApp that will be released on the DAPP Network will implement keys as LiquidBattles does.
After all, this game generates your account’s private key from a salt, your username, and your password — and keeps it hidden from you. As long as you remember your password, your private key can always be generated again. Forgetting your password loses your key.
Future dApps using LiquidAccounts may outright give you your keys to keep, whether in a Scatter-based wallet or elsewhere. They may use other factors instead of usernames and passwords to generate keys. And many may include robust key recovery solutions, since everyone forgets things now and then.
Another element that may change in the future is that LiquidBattles’ LiquidAccount keys are managed by the contract that creates them. This is the default, but it is not required. Future dApps on the DAPP Network could collaboratively control a contract which is external to all of them and which does nothing but manage LiquidAccounts. As a bonus, this would allow LiquidAccounts to be “shared” by multiple dApps.
Regardless of how they choose to handle these details, the first dApps destined to ride the track to mass adoption will need a smooth onboarding process. A LiquidApp provides just that.
There are more questions, as well. How could LiquidAccounts send and receive tokens? How could they be used with wallet apps and even implemented across chains?
We will be releasing an article in the near future that delves deeper into the possibilities of LiquidAccounts. For now, let’s look at more of the features of this LiquidApp.
LiquidBattles is not only easy to use — it’s also cheap to run.
The original Elemental Battles would be very expensive to run on mainnet, as large numbers of details are stored in RAM for each user. vRAM enables the game to be deployed at significantly lower RAM costs.
In addition, vRAM contents are cached in RAM during user sessions, meaning that there is zero additional latency while a user is playing the game.
Once a user becomes inactive, this data is evicted back to vRAM. This is, of course, what RAM is intended for: only storing data which is in active use. RAM caching strategies allow dApps to enjoy cost effectiveness without sacrificing performance.
And that’s not all.
LiquidBattles shows the way to dApp immortality.
No matter how unkillable a smart contract may be, a modern dApps’s frontend is still vulnerable.
Of course, if a frontend is compromised, someone else can build a new one pointing to the same smart contract and ultimately save the application from disappearing. But the downtime in the interim can devastate the app’s user base.
With IPFS hosting and LiquidDNS, this version of Elemental Battles isn’t just easier to use — it’s also more resilient.
We’ll talk more about IPFS in a later article, but let’s spend some time on LiquidDNS.
LiquidDNS is a new LiquidService still early in its development. It allows DSPs to run name servers that resolve domains to dApps without users needing to install or configure anything on their end. In combination with decentralized storage solutions, this enables web hosting that cannot be taken offline.
For this release of LiquidBattles, our domain admittedly looks a little strange: cardgame1112.dnsregistry1.com. But any traditional domains obtained anywhere else can now be pointed to an IPFS-hosted dApp with a simple nameserver change.
We should note that since each DSP can run its own DNS name server, there is a degree of trust in each: any particular domain can be taken down. This is a limitation of how the Internet is built, and one that likely cannot be skirted around without special user-side customizations such as EOSDNS. However, while one single domain can be taken down, dApps can use multiple providers and an on-chain table of domains to make this an ineffective attack vector. If one endpoint goes down, the others remain active and accessible.
Censorship, hacks, and unexpected downtime all threaten to derail the performance of web applications. While smart contract technology reduces the risk of failure at the base logic layer, bad actors and technical malfunctions can still target components across the rest of an application’s stack.
As LiquidBattles demonstrates, LiquidApps’ range of services on the DAPP Network can enable developers to finally gift their creations with immortality.
LiquidBattles itself isn’t quite immortal — it’s on Kylin testnet, and uses LiquidApps Kylin DSPs, so the demise of either would end the dApp — but it shows the path to immortality. Mainnet applications built to live forever will use an assortment of providers so that no single party or small group of parties can take them down.
Just as decentralization can power an immortal smart contract, it can now power immortal frontend hosting and immortal domains. For the first time in history, developers face the possibility of easily creating applications that are unhackable all the way through, from backend to frontend.
LiquidBattles gives us a glimpse of the possibilities open to dApps running on the DAPP Network.
Play now, check out the code, or install Zeus SDK to begin building LiquidServices into your own dApp.
Make your dApps easy to use, free, and immortal with LiquidApps. LiquidBattles is first out of the gate on testnet. Which app will lead the charge onto mainnet?
