Today at CryptoNewsZ, we are joined by dynamic entrepreneur and advisor Tal Muskal, the CTO & Co-founder of LiquidApps and LiquidEOS. He is also a senior technical advisor at Bancor, focusing on blockchain interoperability. Tal has co-founded numerous startups and brings over 30 years of experience in software development.
Hello and welcome to CryptoNewsZ, Tal; our readers would love to know more about you and what sparked your interest to join the crypto and blockchain domain.
For a long time, I’ve been an open-source enthusiast, a contributor, and a very early adopter. Naturally, the blockchain and the vision of decentralized applications with the idea around tokens representing an entire project is something that I consider to be the next phase in the evolution of open source.
In parallel, I joined Bancor to focus on a very specific challenge: BancorX, an inter-blockchain communication solution bridging Ethereum and EOS. As I delved into the actual bits and bytes, I saw that I have a lot to contribute to the consensus and scaling aspects of things, as well.
Being the Co-founder of LiquidApps, what was your idea behind the development of LiquidApps? Kindly elaborate.
We started LiquidEOS as an EOS block producer. We were able to get to know the next generation of blockchain and come up with the concept of immortal applications, which are end-to-end fully decentralized applications. Immortal applications are resistant to hacking or compromise because they are free of centralized points vulnerable to attack.
This vision immediately captured my attention, and I started looking at the entire blockchain technology stack as a real alternative to traditional application stacks – a decentralized and free alternative. This, in turn, immediately sparked a new perspective: looking for the biggest gaps in the space that are still holding us back.
The first aspect that we attacked were resource costs and the scalability of resources, but the main idea was to enable immortal applications without having to take a mortgage out on your house or raise millions of dollars. No one will build immortal applications unless they’re affordable. So the first service we released, vRAM, provides blockchain state for applications at a fraction of the cost, without sacrificing decentralization or trust.Interoperability is another main idea behind LiquidApps technology – not just interoperability among different types of blockchain technologies, but also between conventional software development and blockchain development. I think the greatest barrier is bringing developers up to speed on blockchain’s capabilities and the differences between blockchain toolsets and the toolsets they’re used to. That’s a key aspect of what we’re trying to do: make it as seamless as possible to switch to – or rather evolve into – this decentralized paradigm.
Tal, recently LiquidApps produced the first-ever DAPP Network Hackathon, a promising event open to developers around the globe. Please enlighten our readers about what the primary objective behind it was.
We’ve released so many tools over the last couple of months, and we determined that a global, interactive hackathon was the best way to get our early adopters to really know and understand how to use the entire LiquidApps tool stack. It was amazing to see dozens of teams coding and building, and some very exciting projects found their beginnings at the hackathon.
vRAM is a storage solution for dApps. What are the main differences between vRAM and LiquidStorage? Please tell us more about LiquidStorage.
vRAM is an alternative for RAM, not a full storage solution. It’s cheaper, but it doesn’t sacrifice the trust level. vRAM is the place to put the state of your contract. Token balances or data accessed and modified by your contract, which are traditionally placed in RAM, can use vRAM at a fraction of the cost.
LiquidStorage holds the resources and the files that you need to present to the user, not necessarily perform business logic on. For example, the images and the HTML of a website for the frontend of an application are something that you could put on a hosting or storage solution like LiquidStorage.
You could also encrypt things in LiquidStorage in such a way that only the user has the key. This could be used for private data presented in the user’s frontend interface, for example. It could also be an ideal solution for the content and images needed for a decentralized CMS. Alternatively, you could host a personal folder for your own storage – a Dropbox-like solution – if you build the right interface for it.
So, vRAM and LiquidStorage are quite different things. Both rely on IPFS to actually persist the data, but they’re used in very, very different ways.
During the Hackathon, new DAPP Network services were launched such as LiquidHarmony, which is supposed to be an upgrade to LiquidApps’ web oracle service. How does LiquidHarmony improve oracles?
LiquidHarmony is a service that abstracts LiquidOracles and some other services that we had. It’s a generalization of all the services that require doing something on the DSP node and then comparing the consensus in any way.
Anywhere that you would typically use the dispatch command, do something with it, and then perform it on multiple parties and compare the results. Any service that fits this flow, you can build under LiquidHarmony as an extension or plugin.
We realized that many of our services have lots of similarities in the way they work, so we provided a unified framework to build more services that behave in the same way. vCPU, randomness, SQL, web oracles, sidechain oracles – all of these flow in a very similar way. The only difference is that they provide the information from different sources. They all get an input, they run something, and then return results and compare the results for the integrity.
One of the most exciting aspects about LiquidHarmony is that developers can now easily plug in their own services. As long as the service follows the same flow I mentioned, it can be operated in a decentralized way with LiquidHarmony. Even full, containerized applications could potentially be run this way.
LiquidSQL is an extension of LiquidHarmony and uses the Liquid Harmony framework. Please brief us more about LiquidSQL.
LiquidSQL is another extension for the LiquidHarmony framework, and it allows you to access relational databases from your contract. Instead of dealing with multi-index tables, you could develop your application and your contract as if you have a SQL server as the state.
This should allow a lot of people who are not familiar with EOS to model data and start developing much more easily – without needing to learn new query languages, index types, or any of the other items developers face on the formidable blockchain development learning curve.
We want to make it as easy as possible to get non-blockchain developers to start developing smart contracts and dApps. Ideally, development on the blockchain will be even easier than conventional software development.
LiquidOracles stands out by keeping SLAs and data verification on-chain, protecting users from the risks of malicious or accidental failure. Would you like to elaborate on the same?
LiquidOracles are a part of the DAPP Network middleware, which means that all the coordination, verification, and all the logic happens on the base layer on the blockchain.
This effectively means that if we select, let’s say, 10 oracles, and 9 of them provide the same results but 1 of them gives a different result, then you can actually not only ignore that oracle – you can also remove it from your service or from the contract itself.
urthermore, you can code how you react to consensus issues right in the logic of your contract, which opens up interesting possibilities like self-healing consensus or other things that usually require their own new framework.
We’re all about flexibility for dApp developers. dApps can now write their own consensus or their own kind of oracle collaboration scheme and just deploy it as part of their contract. Sure, we provide default and recommended ways to reduce the results and then to select the DSPs, but there is no limit to what you can do in terms of how dynamic or how safe your solution is when it comes to data verification, the SLA, and how you react to misses or failures.
Tal, would you like to tell our readers about your journey from technology to computer science? What was the first application or program you created?
I built interactive greeting cards for Hanukkah rendered in ASCII and written in GW-BASIC when I was around 5 years old. I can’t remember where I found the list of keywords and commands to even write it. I’m not sure where I got it, but at that point, I didn’t even know that it was called programming or that that was what I was doing.
As an advisor and a successful entrepreneur, what advice would you like to give to novices and entrepreneurs who are looking to start their career in the crypto and blockchain community?
Don’t try to force your technology onto solutions. Don’t be a solution looking for a problem. Find where the technology can actually satisfy a real need. Everything starts from the need. Technology is never a solution to anything. The only solution is a product, or a system, or something that uses the technology. So that thing that you’re building as an entrepreneur should start with the question, “what problem am I solving?”
Another common mistake is when an entrepreneur is afraid that people will steal their ideas. Go and talk with as many people as you can. If someone says, “I have a very good idea, but I can’t discuss X because it’s secret,” then you know that they probably won’t be able to execute on whatever that secret is. When a new idea is still very early, hearing other people’s opinions is worth the insignificant risk of someone stealing your idea and executing it better than you.
Advertisement
Advertisement
It was an absolute pleasure talking to you. We at CryptoNewsZ thank you for your valuable time and wish you tremendous success in all your future ventures.
