yes, correct. I conflated POC via znnd with the full scope in my original write-up – I’ll change this on the Git.
The idea here was unikernelizing the fundamental element of the NoM - a node - and then using that POC as a foundation for zApp unikernel development.
So what exactly is included in phase 1?
Phase 1 is focusing specifically on znnd. Delivery will consist of compiled targets (vsphere, aws, hyper-v, vdi)
I already have the first vbox image up on the Git for people to spin up and test – this is still in progress and will require improvements to resource allocation.
These different targets can and should be used in the testnet when we begin to integrate zApps.
You submitted a phase 1 for payment in AZ correct? Is that different than the Phase 1 you describe above?
I submitted the phase 1 as outlined above, but was not aware this was a submission for payment. I was only trying to align the first phase described here with the AZ.
As there is no timeline for quorum, I recommend remaining pillars await release of deliverables before voting.
has anyone given the vdi a try? For me: depending on the VM resources it either crashes after first Momentum, or it runs through a bunch of Momentums then hangs. I am still debugging. Could be helpful to have additional eyes on this 
Happy to help, but I could use some extra guidance.
I’ve tried running this in a linux desktop VirtualBox, but I just see a black screen.
Do I need to run this on a VPS? I assume the VPS needs to support nested virtualization. A few guiding steps would be appreciated.
For the time being the vdi is only VirtualBox compatible. I am still working on building .iso for generic VPS, VM, on-prem… but for specific cloud providers (AWS, Azure, DO) I am hoping to eventually provide prebuilt images
There are likely a number of us that would volunteer to run this as coinselor said. We have a group running supernova w/ a chat on TG to troubleshoot - I am guessing most people there will help test this as well.
But yeah for unikernal I will need you to explain some of this like I am a golden retriever lol
As the devs said from the beginning: “Zenon is community”
I ultimately intend for this project to be a launchpad for community-driven development of unikerneled zApps. With that being said, the overall scope and direction of this project and its phases are subject to community feedback and engagement.
For example – since it has already been brought up – OCaml does have a steep learning curve and adoption may be limited… we can absolutely explore implementing WASM or other languages/paradigms for unikernels during zApp phases.
@everlastingOS and @aliencoder have already proposed powerful, feasible use-cases for unikernel-z, and we have only just started the discussion.
I was riding bikes with a buddy who leads up the dev group for a high frequency trading firm. He codes in C and other supporting languages. He must have 30y of experience. I asked him about OCaml and he said he never heard of it. It was sort of funny… He said he is siloed in their tech stack and has no time or incentive to learn anything else.
That doesn’t mean much in this context. I was just surprised someone with that much experience had not heard of OCaml.
You should ask him if he wants to learn and send him here
I’m always trying to find angles to suck my friends in… Start with, have you heard of OCaml?? Then go right to… so I’m working on this crypto project…
Interesting, figured a lot of HFTs use it since it is used heavily at Jane Street.
This is your in, “Ah thought u would be familiar since top firms like Jane Street use it. What do you use, cobol?”
OCaml is a lot more commonly used in France (where it was created). I actually work for a company based in Paris, it’s how I was exposed to the language.
FWIW Arthur Breitman hired a French team to outsource the development of Tezos blockchain (written in OCaml).
I’m keen to test as soon as you have an ISO compatible with vsphere or proxmox - looking for to it 
@EovE7Kj I was looking at the WP again. In the unikernel section the WP states:
“Periodically, the users will need to pay for the zApps usage; this system will be designed in a similar way gas 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.”
Do you have any thoughts on how this will be implemented? Will “fees” be needed to pay for zApp usage, or will the fee be in the form of fused QSR or PoW?
Will the $PP token being dispensed by the faucet be used with zApps in any way?
What are Adaptive Smart Contracts?
Sorry for all the questions. I’m inquisitive.
Sorry for the delayed responses here, I have been traveling the past weeks and have been over my head at my day job.
These are great points; as the WP addressses - smart contracts will need some mechanism of fees for Turing-completeness. When I’d initially read this (years ago), I’d assumed the fees would be ZNN or a ‘wrapped’ version thereof. I am not sure how fusing QSR could be implemented for smart-contract fees, as I had interpreted the zApp layer being a fundamentally separate abstraction.
The notion of PP is very interesting; again I had assumed PP would eventually be converted to QSR, but this opens the door to an entirely new potential for the token.
Adaptive smart contracts essentially refer to smart contracts that can self-modify their behavior or parameters based on certain conditions or external factors. These can be used in dynamic yield farming, atomic swap apps.
Don’t be sorry at all; in fact, your questions have already given me a few new ideas. I am by no means an OG-dev, professorZ, or Mr Kaine. I don’t have all the answers. I am only a member of this COMMUNITY, and am humbly enthusiastic about this project.
We are all in this together. I proposed the unikernel AZ because of the skills and experience that I can bring to the table. With regards to smart-contracts, this is going to be a dynamic work-in-progress of the COMMUNITY.
