WASM is just a tool like any other (C, Python, Go, Js). I am interested in it and have used it for various applications.
I chose OCaml here beacuse it is one of the few “Meta Languages” (see Lisp, Clojure) that is ideal for writing compilers, kernels, etc. It already has a rich library for unikernel development.
I see, some community dev now focuse testing our L2/Sidechain “Supernova” that is compatible with EVM and WASM SC.
Do you have any ideas or thoughts on what type of zApps would be suitable for early usage of your unikernal solution?
I love the proposal and would vote in favour 
I think (all imo) Supernova will provide flexibility for external intensive contract executions and EVM compatibility - whereas the unikernal solution mentioned here would be for native zApps and NoM execution specifically (and maybe BTC in the future?)
Welcome Sir,
could you introduce us to some of your previous work, or give us more insight into your team?
I’ve been doing some research to make sure I understand this proposal.
You are proposing to make unikernel-z, a runtime environment for deploying and executing smart contracts on NoM. Unikernel-z will be a unikernel itself that will “encapsulate the NoM and its nodes”. This runtime environment will enable zApps which are unikernel smart contracts with access to NoM consensus.
I understand unikernels are like .exe with the minimum OS / libraries required to boot and run. They access the processor through the OS or Hypervisor.
Does this mean that Pillars and/or nodes will run within the unikernel-z runtime environment?
In order to run unikernel-z will the operators need access to Bare Metal hardware or the hypervisor? Can unikernel-z be run on a VM offered by Amazon or Digital Ocean, for example?
In order to build and deploy zApps it will likely be written in Ocaml and use MirageOS to build the unikernel. Is that correct? Ocaml looks to be a very performant language used by FB and Jane Street, but maybe the number of devs who can code in Ocaml is limited? Do you see that as an obstacle to adoption? Maybe the benefits of deploying zApps are so great, dev will simply need to learn it.
I assume existing EVM contracts cannot be ported and need to be written from scratch as new zApps. Is that correct? Does that worry you?
Thank you
What is a unikernel? This video does a good job explaining it.
More on MirageOS and how to set it up. “MirageOS is a ‘library operating system’ for constructing secure, high-performance network applications across a variety of cloud computing and mobile platforms.”
Since the community is negotiating against ourselves and suggesting you ask for more funds, can we put a point on what the initial funding request is (amount) and what needs to be delivered (goals & metrics) for funds release?
This is a great post, the MirageOS videos are a perfect introduction to the concept of unikernel. To answer your questions:
Encapsulating the NoM
unikernel-z.zApps
Baremetal/Hypervisor/Cloud
OCaml
Existing EVM contracts
I hope I answered all your quetsions.
Yes this is very helpful. Thank you.
It feels like this proposal could take crypto from analog to digital. The scale of what is possible with this architecture is difficult to imagine given we are living in a 10 tps world on Ethereum with a shitty EVM… and 75% failed TXs on SOL.
It feels like a crypto native bank or games or twitter 2.0 with millions of users could deploy a zApp on NoM and scale up to offer a web 2 experience with a decentralized back end. I can only assume this proposal relies on the assumption that N&T is possible and in a big way because if not the L1 will never handle the load given what could be possible with unikernels.
I can only assume this proposal relies on the assumption that N&T is possible and in a big way because if not the L1 will never handle the load given what could be possible with unikernels.
100% to both of these points.
I am a huge proponent of Narwhal and Tusk
Given the amount of time and work the project phases will require, I think the best option is to separate each phase into its own AZ project. Given that I have already submitted the proposal to the accelerator for 5k/50k, the metrics for the first phase can be broken down:
The timelines provided are approximate and intentionally conservative, allowing for a margin of flexibility.
Thoughts?
How do you demonstrate 1 & 2 and will 3 be an open testnet? I am always looking for ways to spend more money running ZNN infra 
makes sense to me.
unikernel-znnd will be released on the Gittestnet-unikernel-znnd to get on the testnet.I am thinking now that the 50k QSR can be allocated 100% toward Phase 2 zApp development ; I can fuse all of it to spawn a sentinel and use directly for zApp node interface.
I can run znnd on my Raspberry Pi or on AWS, in a VM or on bare metal. I don’t understand what benefits can bring running znnd inside unikernel-z. Dockerizing znnd gives us similar performance and security gains. I don’t think this is the direction outlined in the whitepaper…
I would try to build an unikernel runtime that is able to measure computations in a fully deterministic fashion with on-chain footprint.
We can use zk-proofs to attest a particular computation was carried out inside the unikernel and post the proof on-chain for verification. The embedded contract state can be updated if the verification is successful. Instead of running everything within the EVM, the computation will be offloaded to unikernels. The problem is how to measure computation. This is the tricky part where zk-proofs and other cryptographic schemes are needed.
@EovE7Kj I’m not against your proposal, just thinking out load how I see unikernel-z.
Developing a unikernel for znnd is just the first step in getting to the unikernel-z. Certainly the goal here is not to simply “wrap” the znnd in a unikernel… as you’ve surmised unikernel-z will be much broader scope than that. Although, I will note a unikernel-znnd should have much reduced attack surface, faster boot times, and lower resource overhead than a dockerized counterpart.
This is a great idea, especially offloading the computation to the unikernel. We could implement threshold signatures or MPC here as well. There are numerous implementations and mechanisms that can be employed at this level that could improve Network security and efficiency, and I am open to all ideas from the community.
Your feedback is greatly apprciated @aliencoder, I am a fan of your Supernova chain.
Wanted to share another resource for the community to watch about unikernels.
This is pretty good if you want to learn more about the benefits of unikernels. If you watch, start watching where I’ve linked it. Running zApps and the Smart Contract layer in unikernels will be such a giant leap forward in crypto.
The speaker claims unikernels are 1400 time more secure than a Docker Container. And they are insanely fast. Listen to the test they did on DNS.
They got a DNS unikernel to come up in 45 ms. Sounds like there are limitations on “easily” porting code to run in the unikernel. Speaker mentions this. After watching this video it’s becoming more clear what will be possible on NoM. A lot!! Big applications that require a lot of security and/or scale. Nothing I know of in crypto today can handle this scale and speed.
But, it seems like writing code to run in a unikernel is specialized. I don’t think the “average” crypto bro launching a project will be able to easily spin up a zApp. Maybe I’m wrong. Maybe crypto devs will just have to learn. OCaml sounds very legit. Like something Jane Street would use to manage trading.
Here is that quote. Good article. => The big idea around unikernels
Below is a playlist presented by a software engineer who goes through several academic papers about unikernels. Do not watch this unless you want to really dig. It’s hours of videos.
Here is a unikernel dev kit https://unikraft.org/. They have a Caddy Unikernel we can test out. Maybe the community can learn something by messing around with these.
@EovE7Kj how will Smart Contracts get deployed with this framework?
Will the SC deployer upload the SC to the unikernel-z layer? Or will the deployer need to deploy their own unikernel-z instance and deploy there?
Love too see the excitement surrounding unikernels. The implications of this technology are massive for the blockchain space.
I was going to mention both uikraft and ops (ie. nanovm) can be used for early PoC. In fact, I have already dockerized znnd and converted to a uinikernel .img via ops. I can share this for testing purpose if anyone is interested.
