I would be interested in testing this. I’m interested in how I’m going to run these in my infra. I use vmware and Proxmox. I see some unikernels can be run in proxmox but require a different configuration and setup. I’d like to test this.
working on the qemu and kvm images now. For reference the docker image is publicly available: docker.io/eove7kj/znnd:latest
Looks like it’s private still.
Hum, it shouldn’t be. I see 6 pulls since I pushed the image.
Are you able to run the following?
docker run -d --name znnd \
-p 35995:35995 \
-p 35996:35996 \
-p 35997:35997 \
-p 35998:35998 \
docker.io/eove7kj/znnd:latest
Sorry, yes I can access this. Just spun it up no problem.
@coinselor took a look at the whitepaper again and noticed this image. Just wanted to share with everyone. Running a zApp on the Sentinel node seems to be consistent with the original vision in the WP.
From the WP.
Periodically, the users will need to pay for the zApps usage; this system will be designed in a similar way gas [53] is implemented for smart contracts as a fees mechanism that prevents abuse and circumvent the Turing completeness property (e.g. infinite loops). This process will be automatized through a series of smart contracts that will be used to manage the zApps operation and the transfer of gas. The user will have the possibility to cancel at any time the execution of the app, by either explicitly sending an abort command or by not paying the corresponding gas to the node.
If anyone else want to test this, here are the steps:
Install Docker
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
Create a Docker Volume
docker volume create znn
Start the Docker Image
docker run -d --name znnd \
-p 35995:35995 \
-p 35996:35996 \
-p 35997:35997 \
-p 35998:35998 \
-v znn:/root/.znn \
docker.io/eove7kj/znnd:latest
I just started to sync. Let’s see how it does with the two tough momentums. I’m running it small 2 vCPUs and 4G Ram to see what happens.
With Unikernel, we can now enable a new era.
Imagine a Zapp within a secure runtime (Lightweight OS mobile app) that blocks unapproved connections and provides a robust framework of decentralized services as plugins ready to go.
A mobile application that runs your packaged Ionic-based Zapps within an ecosystem of Zapps all using the Zenons built-in wallet and Z-unikernel.
Unified interface for users to run multiple Zapps that can share a common identity, wallet, personal storage vault and more.
Every zapps (App capsule) can have its own runtime or unikernel, ex a messenger app inside mobile OS app.
E X A C T L Y
This is what ZenonOS can do, what do the community think?
I have been a fervent supporter after reading the ANN in bitcointalk. Back in the days of the old QT wallet, when the only possible way to buy was via Telegram or Mercatox.
I learn something new every day about this project. And the more I learn the more excited I get. You highlight some amazing possibilities.
TBH we (crypto users) live in a world with such limited, slow and expensive options that it’s really hard to comprehend such a large advancement NoM can bring. This seems like such a large scale improvement, it’s hard to believe it’s feasible.
Have you ever tried Nostr? That’s like messaging with pigeons. And we are talking about enabling a decentralized framework on NoM that could allow messaging apps, banking, video streaming, etc. It’s mind boggling.
I continue to think the L1 needs to be way faster than we think to handle these real world use cases.
NoM will enable real world use cases we are missing.
This - 100%
Traditional L1’s have barely scratched the surface in terms of intrinsic usefulness and it is why congestion, tx failures and fees are high. The L1 that finds a useful method of scaling is the one that will reign supreme in the end.
Imagine 1000’s of different applications existing in their own unique runtime environments – with virtually no overhead – running on top of nodes in the NoM, where participation is incentivized via the rewards for running as a Sentinel. Imagine the TPS with this scale of validators.
It is pretty simple, the OS mobile app is just really a wallet with a app grid view, with one unikernel app store, to download the rest of Zapps running on unikernel. Yes have tried Nostr, can be good to look at how Feeds vision was, using DID, P2P carrier to handle all the data traffic, and using users own private data, think it as a private IPFS server running locally on your device, similar how Manyverse do. The nodes Pillars and sentinal cannot store all the data when we have Zapps like video streaming, social media like Nostr/Soapbox so on.
@EovE7Kj how do you debug unikernel-z
?
Interesting article shared by @rexznn in TG. He also raised the concern above in the town hall we had. The author of this article raises this issues as the single biggest problem with using unikernels in production. Unikernels are unfit for production – The Observation Deck
“Gotta have more htop, baby” - Bruce Dickinson
I am planning to specify a port for gdb
access, this is the same way that ops
manages unikernel debugging.
https://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_130.html
Can we link out to the phase requirements @EovE7Kj ?
- Successful implementation of PoW+PoS consensus mechanism within the unikernel.
- Demonstrable improvement in resource efficiency and performance.
- Deployment of a testnet version of unikernel-z for community testing and feedback.
I don’t think this is the purpose of the unikernel. The unikernel should act as an off-chain component that interacts with an on-chain embedded contract and provides a trustless execution environment for zApps
.
Also the tricky part is to develop a trustless operation environment for the unikernel and design a gas metering mechanism that is managed by an on-chain embedded.