I’ll try to answer all questions to the best of my knowledge.
A decentralized application is an application deployed on a virtual machine running as a state machine on top of a (public) blockchain network.
A zApp is a special kind of dApp that can run on a VM that might not be directly running on a blockchain network and that has particularities such as custom gas mechanisms (for example dApps users pay gas upfront to execute state changes via transactions).
In the case of Uniswap, the code is running on every Ethereum node.
No, we don’t expect for a zApp to run on every Zenon node. Quite the contrary, we want zApps to have the best of both worlds: Web2 efficiency/performance and Web3 security/privacy.
Yes, this is an important distinction between dApps and zApps. You can think of zApps as layer-2 dApps for Zenon.
Actually, it will look like this: Unikernel > WASM runtime (with built-in gas metering and proper sandboxing) > zApp code
EVM is a smart contract runtime where Solidity code is compiled to EVM bytecode and ran on the EVM by every node in a blockchain network.
zApps will run WASM bytecode inside a WASM runtime inside the unikernel and will trigger state changes on a layer-2 with layer-1 settlement via an embedded contract.
The interface part will be no different from any other dApp interface. You are free to build any kind of interface (web/mobile/etc.) and interact with the zApp via RPCs (to call methods) and the corresponding ABI (to invoke functions).
Anyone that wants to be part of this ecosystem and earn rewards.
This is where the things get interesting. Regular dApps cannot scale to millions of users because of one main bottleneck: the underlying blockchain. In order to change the state of a particular dApp, you need to issue a transaction that is recorded on the blockchain. Now imagine 100 million users issuing transactions on Ethereum concurrently.
zApps of the hand can be integrated directly as a layer-2 solution that will work as follows:
- Users will deposit funds in dedicated zApps embedded. The embedded will keep track of balances and will update the state of the balances accordingly
- Sequencers will run the state transition function for zApps on a separate L2 chain
- Zero knowledge proofs will be used to attest the validity of the state transition executions for the L2 on the zApp embedded account-chain
I would encourage anyone to become an infrastructure provider. We can design a system that is more reliable in the long term by requiring a security deposit (a bond that can be slashed) or creating a ranking system based on uptime and other important metrics.
There are 3 different entities in the zApps ecosystem:
- The user that will pay to access/interact with zApps. Regular dApp users pay for every interaction with the smart contracts gas fees that are usually non-negligible.
- The zApp developer that wants to monetize it.
- The infrastructure provider that hosts the zApp.
We need to think of ways to create more demand for ZNN and/or QSR.