LiquidX Released! Blockchain Interoperability is Here with the DAPP Network
DAPP Network Services like Oracles, Storage & Computation Ready for Use on Multiple Smart Contract Blockchains
Whatever network you use — whatever single-chain, dual-chain, or multi-chain strategy you choose — the DAPP Network is here to help you build and run scalable, flexible, immortal dApps. (Click to Tweet).
Since early in our company’s life, we at LiquidApps have publicly held that “the Future is Multichain.”
DApps will have, and should have, the flexibility to run on their choice of one or more blockchains, with open communication and shared services between the various chains.
From its earliest versions, LiquidLink enabled communication between chains, but not chain-agnostic feature parity. However, for the most part, easy use of DAPP Network services was limited to apps running on EOS mainnet.
Now, LiquidX makes the DAPP Network available for every EOSIO chain, and potentially non-EOSIO chains beyond.
Yesterday, LiquidX was released into the wild, along with numerous improvements to vRAM and Zeus SDK. Developers may want to have a look at the release notes.
As the release notes put it, these updates “add liquidx ability to offer service to other EOSIO based chains while using the EOS mainnet for staking, billing, and claim rewards.” This is the full public release of LiquidX, a major step towards a multi-chain future. With LiquidX, the positive-sum games that full blockchain interoperability enables are here.
LiquidX brings all DAPP Network services to multiple blockchains.
The initial design of EOSIO was configured with maximum scalability in mind.
Instead of launching a single chain, Block.one released the EOSIO code as a template for different communities and organizations to utilize as they see fit. While each chain can scale independently, the true power of EOSIO lies in the ability to scale horizontally by having various chains running in parallel and interoperating seamlessly with one another.
Today, that vision is closer to becoming a reality, with sister chains evolving from mere experiments into viable networks with significant development activity. Whereas the EOS mainnet was once the automatic choice, dApps are now choosing more chains than before. Mainstays KARMA and EarnBet have migrated to WAX. Others have launched on Telos. Still others have worked on creating their own EOSIO blockchain, or using multiple chains in combination.
On January 13, 2020, the WAX blockchain announced collaboration with LiquidApps, recognizing that the DAPP Network’s powerful suite of services could boost the usability and flexibility of the WAX blockchain. How exactly this might be implemented was left unsaid — until today.
With LiquidX, standardized and fully interoperable services such as oracles, storage, computation, authentication, SQL databases, and community-created services are available for all EOSIO blockchains, and potentially non-EOSIO Smart Contract blockchains such as Ethereum, as well.
Now, after work by the LiquidApps team adding features, testing, and bug fixing, the latest release has arrived, and that functionality is ready to deploy.
You can read more about the basics of LiquidX in the first LiquidX post. Here, we’ll focus on why dApp developers everywhere and on every chain should want their stack to include LiquidX.
Developers learning a DAPP service on one blockchain can migrate their knowledge to others.
It’s been getting easier by the week to learn about the DAPP Network, with more experienced developers, more documentation and more sample code available to developers everywhere.
But learning a new technology is always a time investment. EOSIO developers learn the same basic smart contract coding techniques regardless of the EOSIO chain they’re building for. With DAPP Network services, this uniformity extends to numerous services used in smart contracts and dApp frontends.
DApps can customize their consensus models and redundancy levels.
Each EOSIO blockchain has its own unique takes on consensus, from Telos’ inclusion of a Worker Proposal System to LynxChain’s implementation of a dApp whitelist maintained by the Block Producers.
Regardless of the details of a dApp’s particular chain, developers can customize the trustlessness of their dApps from front to back. This includes storing frontends on IPFS, failover and child chains, web oracles, vCPU computation, and more.
Flexibility means that dApps don’t have to bind their whole stack’s consensus model to the same model used for their smart contracts.
DApp teams can future-proof their projects.
Blockchains are generally free of congestion — until they’re not. Just as the public eye and popular dApps brought more activity and pressure to other blockchains, any EOSIO sister chain that gains large amounts of attention may face the same challenges.
DAPP Network services provide resources that are resistant to crunch and congestion, helping dApps keep businesses running smoothly when their chains face the trails brought by their own success. As always, our mission is to make life easier and smoother for developers — and by extension, for dApp users.
The DAPP token retains the same core tokenomics but now provisions services on multiple chains.
The DAPP Network’s economics rely on staking the DAPP token on EOS mainnet to DAPP Service Providers, who are paid for their services by the token’s inflation. Settlement and service provisioning remains on the EOS mainnet.
But the community has rallied to offer additional models and flexibility for developers, such as the rental markets offered first by BlockStart and later by Chintai — allowing developers to choose between staking up front and renting DAPP Network resources on demand. Likewise, the community could offer new models as the DAPP Network expands to new blockchains. In some cases, these models may even allow fully abstracted use of the DAPP Network, with the details orchestrated behind the scenes.
Here, as elsewhere, one of the core goals of the whole DAPP Network community is ease-of-use and flexibility for developers.
Even choice of blockchain is now decentralized.
Theoretical decentralization means little on its own, if obstacles keep it out of the realm of practice.
One of the reasons we have promoted full-stack decentralization, from frontend to backend, is that while the important part of a dApp is its business logic — as many Ethereum community members argue — the mere fact that someone could spin up a replacement frontend for your dApp if your frontend is hacked or censored doesn’t mean they will. Or at least it doesn’t mean they will do so quickly. Your users could move on or grow to doubt the dApp’s safety in the meantime.
Choice of blockchain is a critical component of a dApp’s stack. The threat of dApps migrating away should, in theory, incentivize the network to take actions beneficial for dApps. But as migration becomes more difficult, that threat loses force.
The presence of familiar services with identical syntax across chains eases migration considerably.
In addition, LiquidApps has announced LiquidChains, a Blockchain-as-a-Service function where DAPP Service Providers can be used to spin up fully customizable blockchains — permissioned or permissionless, decentralized or centralized, permanent or temporary — easily and cost-effectively.
With LiquidChains, businesses considering transferring pieces of their tech stack onto the blockchain for its various benefits could avoid sacrificing confidence in the future to the volatility of blockchain governance, resources, and price. On the other hand, they could also keep the benefits of interoperability of data and value with public blockchains — benefits which enterprise blockchain solutions do not generally offer out of the box.
Now is the time to adopt. Tell your favorite chains!
Since the inception of the DAPP Network, we have remained committed to the decentralization of power, both for philosophical reasons and for the practical reasons of keeping things immune to corruption and compromise.
Our commitment to decentralization and community means that LiquidApps prefers the DAPP Network be adopted as a system contract under the multisig control of the Block Producers on EOSIO blockchains. This system contract option does not require elevated permissions — multisig is desirable only for decentralization, not because the DAPP Network requires any unusual capabilities beyond non-system smart contracts.
If you are a developer or enthusiast interested in a particular EOSIO blockchain and would like to see the DAPP Network adopted natively, please voice your wishes to that blockchain’s community:
@WAX_io and @LiquidAppsIO can now move forward on the collaboration they announced in January — #LiquidX is out! #WAX #EOSIO (Click to Tweet)
***
#Telos can add even more functionality with the #DAPPNetwork now that #LiquidX can bring it natively to the Telos chain! @HelloTelos @LiquidAppsIO #EOSIO (Click to Tweet)
***
#BOSCore has made huge technical strides. Now they can take it even farther by adding the #DAPPNetwork natively thanks to #LiquidX, which was just released! @Boscore_BOS @LiquidAppsIO #EOSIO (Click to Tweet)
***
Ultra #UOS can ramp up its impressive plans by adding the #DAPPNetwork natively with the new #LiquidX. Oracles, intense computation, distributed storage & more all plugged in!
@ultra_io @LiquidAppsIO #EOSIO (Click to Tweet)
***
It’s time for #Ethereum dApps to look into the #DAPPNetwork. Oracles, computation, storage, and more — all fast and highly customizable.
@VitalikButerin @LiquidAppsIO #ETH #LiquidX (Click to Tweet)
Whatever network you use, whatever single-chain, dual-chain, or multi-chain strategy you choose, the DAPP Network is here to help you build and run scalable, flexible, immortal dApps.
Reach out to LiquidApps to set up a free group chat to explore the options for your dApp.
