These are all feasible zApp implementations, and this is good to circle back on this discussion. Now that the phase 1 delivery is complete, I am starting to brainstorm a potential zApp(s) for phase 3.
Personally I think a Uniswap type DEX is a logical first step. We can fork the uniswap front end and showcase what is possible on NoM. Everyone wants to trade tokens.
What is a “simple” idea that is useful, demonstrates the unikernel architecture and showcases adaptive smart contracts? I understand what an Adaptive Smart Contract is, but I’m not entirely sure what about our architecture that makes them possible. Maybe @EovE7Kj if we understood that, we can brainstorm more ideas.
Currently, we don’t have the architecture to make adaptive smart contracts. @aliencoder’s work on supernova chain is opening doors to EVM support, and the potential for embedded contracts within unikernel-z is what I am focusing on here.
Any decentralzied application you can think of can be offloaded to unikernel as opposed to running in EVM. An oracle network, a social network, a CDN, or even an NFT arcade are all feasible.
Some great web3 examples have been built on cartesi, you can check out their rollup lab
I have conceptualized this as a sort of “Zenon unikernel dev kits”, the way we have the SDKs.
The idea is: you write your zApp in your language of choice - Go, JS, C, whatever - you run a binary ELF to compile it to a qcow2 unikernel image. At compile time, it will identify all the necessary components, libs, packages, and build the unikernel around it, implementing the computation mechanisms (gas metering, contract execution)
Phase 1 delivery is complete. I am still working on the performance analysis for the unikernel; I will await Phase 1 to reach quorum until I submit it for Phase 2
Prime Dice - Looks like there might be some geo restrictions.
DEX (back to original idea)
Decentralized Voting System - Delegators or pillars create a poll that is voted on. Votes require a signed message (absent a Web3 wallet). The vote is then associated with a pillar and weighted based on amount of ZNN delegated. The goal is to determine a delegator weighted response by Pillar to a pole. Wait… not sure this requires a smart contract. Sounds like math only. Let me think about a variation that is more useful.
I am nearly done writing up the znnd performance analyses. Compared to a baremetal ubuntu server and unikernel-znnd docker image, it is several orders of magnitude greater for boot time and time to first momentum.
I will post the phase2 shortly after phase1 reaches quorum.
Still brainstorming zApp development and a standardized unikernel framework for it.