Unikernel-z: A unikernel for the Network of Momentum

Development ╰ Funding | Submissions
1

unikernel-z

**Description:**A unikernel for the Network of Momentum

URL: GitHub - EovE7Kj/unikernel-z: unikernel for NoM

Team: EovE7K, bitcoin advocate/acolyte turned ZNNalien. Building and developing since 2013, langages of merit include C, Go, OCaml.

This proposal aims to develop a specialized operating system optimized for running NoM nodes with dual coin support over dual proof-of-work/proof-of-stake (PoW/PoS) consensus mechanism. The primary objective is to achieve feeless transactions by leveraging the unique features in a multi-chain architecture. The proposal focuses on delivering a lightweight, efficient, and secure unikernel solution tailored specifically for the Network of Momentum.

Phases

Phase 1: Testnet

  • High-level overview of main tasks:
    Develop the core components of the Zenon Unikernel, including support for PoW/PoS consensus mechanism, and networking capabilities.
    Optimize resource usage and performance for efficient operation within a unikernel environment.
    Implement basic security measures to protect against common threats and vulnerabilities.
  • Completion of Phase 1 will be measured by:
    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.

Phase 2: zApps

  • High level overview of main tasks:
    Enhance the security features of the unikernel by implementing advanced cryptographic algorithms and secure communication protocols.
    Integrate support for smart contracts and decentralized applications (zApps) within the unikernel environment.
    Conduct comprehensive testing and optimization to ensure reliability, scalability, and compatibility with Zenon's blockchain network.
  • Completion of Phase 2 will be measured by:
    Implementation of advanced security measures and cryptographic protocols to safeguard the integrity and confidentiality of transactions.
    Successful integration of smart contract support, enabling the execution of decentralized applications within the unikernel environment.
    Validation of performance improvements and scalability enhancements through rigorous testing and benchmarking.

Phase 3: Adoptions

  • High level overview of main tasks:
    Finalize documentation and deployment procedures for the unikernel-z, providing comprehensive guidance for node operators and developers.
    Prepare for Alphanet deployment and community adoption, including outreach efforts and educational initiatives.
    Address any remaining issues or optimizations identified during testing and community feedback.
  • Completion of Phase 3 will be measured by:
    Completion of comprehensive documentation covering installation, configuration, and maintenance of the Zenon Unikernel.
    Successful deployment of the Zenon Unikernel on the Alphanet, enabling feeless transactions and supporting the growth of the ecosystem.
    Resolution of any outstanding issues or optimizations based on community feedback and testing results.
19 Likes
2

Exciting stuff and love measurable outcomes at each phase. This is beyond me technically so will let others chime in there. Only question is how do phases and funds request correlate?

1 Like
3

Phases will follow a linear funding progression, as initial phase will require the least amt of resource allocation, subsequent phases will require more.

Phase 1: 1kZNN,10kQSR | majority of budget to be allocated toward testnet development/architecture. Will likely need to work with other devs who have commits to go-zenon)

Phase 2: 1.5kZNN,15kQSR | majority of budget: zApp + smart contracts betas; potential to coincide with other parallel accelerator project(s)

Phase 3: 2.5kZNN,25kQSR | majority of budget: alphanet implementation will be a massive undertaking, especially with regards to long-term support model

3 Likes
5

What’s the probable time line for each phase?

6

Professor E7K,

I’m curious how you came up with the AZ amount. Don’t get me wrong. I am not complaining. I’m just wondering the logic behind the number.

The value of this AZ seems to be greater than what you are asking for.

Thank you and we are here to help in any way possible.

7

lol send this man to negotiating 101

3 Likes
8

With unikernel (an OS) on NoM, will zApps support or running decentralized storage, just like Windows OS handles C:/ drive? So i can be able to access and run my own zApps storage from Raspberry Pi behind my routers NAT, ex a messenger or file sharing (rent out storage for ZNN/QSR) application on NoM.

9

Can you explain how the unikernel will interact with NoM?

10

@0x3639 I could not agree more. It was my understanding that the AZ funding was capped at 5k/50k Z/Q
I have defined each of these phases with clear goals and metrics; but they are more open-ended in their individual scope… as I imagine aspects of each phase could necessitate their own AZ.
With regards to help – I will absolutely be tapping this community as things progress. It’s why I created an open repo rather than a private webpage for this.

4 Likes
11

The unikernel will encapsulate all aspects of the Network, meaning it should eventually be the de facto runtime environment for all nodes. This may be ambitious, but it will not immediately require full overhauls of the existing codebase or network; Phase 1 will focus on “wrapping” our existing znnd in it’s own unikernel. POC of this has already been tested by containerizing the go-zenon codebase and translating it to nanoVM kernel.

This will be a long, constantly evolving project… but the immense benefits (performance, scalability, security, immutability) will be well worth the development

4 Likes
12

You as a user would be interfacing with the zApp via smartcontract. The zApp you are interfacing with can (and should) run on its own unikernel. These in turn would interface with nodes via API, which run on a unikernel-z.

Here, in phase 2, we can achieve POC of a zApp running on its ‘flavor’ of unikernel, interfacing with users and nodes as described above.

1 Like
13

will happily look forward to this development.

14

Per submission yes, but also I think you missed:

Proposals can be split into multiple submissions if they require larger budgets.

15

That project will likely fork into multiple AZ proposals, once POC has been delivered and a functional Testnet is online. For now my initial funding proposal can be disregarded, as it may be more realistic to dynamically assess funding requirements and allocations.

4 Likes
16

I’m familiar with traditional virtualization stacks like docker and vmware. Unikernels are new to me so I have a few stupid questions.

When you refer to the “unikernel” does that mean the unikernel stack / environment?

Does a zApp run in the unikernel stack?

What is the difference between a unikernel and unikernel-z? I think you mentioned that nodes run on a unikernel-z.

17

No stupid questions at all. This terminology can be confusing.

The nodes running unikernel-z provide the necessary runtime environment for deploying and executing smart contracts. The zApp interacts with this backend infrastructure to perform actions on the blockchain network.

A zApp can be thought of as its own entity, with its own unikernel, which interfaces with the NoM on the backend.

Let’s think of unikernel here as the ultimate VM; every one should exist for its own specific purpose, with the exact resources allocated for its existence, and nothing more.

This proposal is focusing on a unikernel which will encapsulate the NoM and its nodes (we can call this unikernel-z). This will bring intrinsic value to the security of the network, but the real value is the introduction of smart contract execution. Think of this as a virtual machine running on the nodes of the network (ie. EVM)

4 Likes
18

NoM only have embedded smart contract for now, is this project will also deploying “new smart contract” ?

As far as I know, the most Unikernel benefit is security. But about performance, can unikernel-z will enhance the NoM performance ? More tps maybe?

And what do you think about Narwhal &Tusk for NoM ? Will we should encapsulate this core upgrade (N&T) to unikernel-z ?

19

Regarding your first point - from what I have surmised, the embedded ‘smart contract’ of the existing NoM was meant to be a “launchpad” toward a conventional L2 transactional space (one meant to coexist with the BTC blockchain). The OG ZNN Dev team could not have possibly meant for ZNN smart contracts to end here…

Unikernel-z will absolutely improve security… but that is only the most salient point. Scalability, redundancy, and performance are guaranteed under a well-deveoped and well-executed unikernal runtime.

If you’ve ever worked in a containerized (Podman/Docker/K8s) environment, you can attest: time to first byte on any given container is orders of magnitude greater than that of its baremetal counterpart, or even a traditional VM. Now, realize that a well-designed unikernel OS can dwarf the performance of a traditional container… the tech speaks for itself.

Lastly: [full disclaimer: this is a personal opinion, and does not speak for the Zenon community] I am of the belief that N+T is a brilliant approach to the BFT question. I would welcome it into the NoM, but that is not for me decide.

6 Likes
20

I’m not a techy person at all, but I remember one of ZNN OG Mr. kainez prefere to build smart contract with WASM
I found this

Can we leverage this project for WASM unikernel smart contract?

21

I re-read this comment and felt compelled to respond again…

One major benefit of the uikernel-ization of the NoM is the fact that NoM smart contracts ARE embedded within (and therefore isolated to) the application layer.

If the end-goal of this Network is for interoperability with BTC (it must be), then the smart contracts layer (L2) must be handled outside of the application layer.

5 Likes