Unikernel-z: A unikernel for the Network of Momentum

disk size is definitely 10Gb, so that’s not the issue either

root@pve:/var/lib/vz/template/qcow# qemu-img info znn.qcow2
image: znn.qcow2
file format: qcow2
virtual size: 10 GiB (10737418240 bytes)
disk size: 265 MiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false
Child node '/file':
    filename: znn.qcow2
    protocol type: file
    file length: 265 MiB (278134784 bytes)
    disk size: 265 MiB

ya, that appears to be the size of the qcow2 image

Hey guys, sorry for the late response here. I don’t have a proxmox env but can get one set up shortly. @0x3639 / @romeo I am wondering if the tty output is just somehow being suppressed in your proxmox consoles. Are you able to check your network to see if a new device has joined via dhcp? This is the first step for the unikernel prior to starting znnd

1 Like

No problem, I will try this when I get home. Will also spin up a qemu instance. Thanks :pray:

1 Like

Checking through logs remotely, it appears it did get on the network under hostname ‘localhost’. I’ll still confirm later on by powering up again

1 Like

can you telnet its port 35998 ?

yes, 35995, 7 and 8. If this is running it boots in like 1 second. It’s crazy fast.

I did not think it was running because I did not see any network activity. I’ll leave it running and see what happens.

1 Like

Does it sync the chain automatically and does the data persist?

1 Like

great, this is what I was hoping. the output you see in your console is the syslinux that I used for bios boot; the unikernel-znnd should initialize immediately after and for some reason proxmox does not show it.
A quick and dirty way to check the status of the unikernel node would be to point a local syrius to it, or to use the znn-controller to check momentum height.
In the meantime, I am working on getting a reliable gdb for debug, as well as a potential API


yes, it’s syncing. Does the data persist?

curl -X POST IP:35997 \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc": "2.0", "id": 40, "method": "stats.syncInfo", "params": []}'


for now, data is not persistent. Think of this as a bootable iso, where youre not able to install to any local media. Making the data persistent is not complex; we just need a “NAS” of some kind.

1 Like

Can this be run on a phone? If we can couple it with something like ZeroSync | Header Chain Verifier for IBD this could be a node for the syrius mobile wallet.


absolutely. I just need to compile to ARM


Mine is up and confirmed synching now too :pray:


I have no clue what u guys are talking about!


So as a proof of concept, EovE7Kj has developed a standalone image that when launched immediately starts an embedded ZNN node and commences a sync. For now, the uni-kernal loads within seconds but the sync still would take ages (as with any node), but if it gets paired with a zero-knowledge proof or a bootstrapped node database then in theory you have an instantly available synched node within seconds

the uni-kernals run independently of the layers below, and you don’t need to build out an OS or anything. It’s launch and play

The node is also just one example of what could be packaged within a uni-kernal


Posted an intro blog post: x.com


What other examples could be?

I used chatGPT to come up with this list. I went through a series of questions first describing smart contracts and what they are used for today and then directed it to come up with a list of real world use cases that cannot be solved with smart contracts on Ethereum today given it’s speed and cost.

I believe Unikernels on NoM could be used to facilitate the types of transactions highlighted below. These mostly involve small transactions that need to be fast and feeless (or very cheap).

@EovE7Kj do you agree with these potential use cases?

1. Microtransactions

  • Content Monetization: Platforms that enable micropayments for content (e.g., pay-per-view articles, videos, or music) are impractical on Ethereum due to high gas fees. Ideally, smart contracts could facilitate these transactions directly between consumers and creators, but the costs are prohibitive for small payments.

2. IoT (Internet of Things)

  • Automated Payments: IoT devices could use smart contracts for automated payments for services like electricity, water, or internet based on usage. However, the high transaction fees and slow confirmation times make Ethereum unsuitable for the rapid, low-value transactions required by IoT applications.

3. High-Frequency Trading

  • Financial Trading Platforms: Decentralized exchanges or trading platforms that require high-frequency trading (HFT) are currently impractical on Ethereum due to latency and cost. Traders need fast execution and low fees to make HFT profitable, which Ethereum cannot provide at this time.

4. Gaming

  • In-Game Microtransactions: Games that require frequent microtransactions for in-game purchases, rewards, or transactions between players are hindered by Ethereum’s costs and speed. While some blockchain games exist, they often avoid frequent transactions due to these limitations.

5. Real-Time Bidding

  • Online Advertising: Real-time bidding for online ads, where advertisers bid for ad placements in milliseconds, is not feasible on Ethereum due to slow transaction speeds and high costs. Smart contracts could ideally automate and secure the bidding process, but current performance issues make this impractical.

6. Data Marketplaces

  • Real-Time Data Sales: Platforms that sell real-time data streams, such as financial data, weather data, or sensor data from IoT devices, need fast and cheap transactions to be viable. Ethereum’s current limitations prevent these use cases from being practical.

7. Decentralized Social Media

  • Micro-Tipping and Rewards: Social media platforms that want to implement micro-tipping or reward systems for user-generated content face challenges with Ethereum’s high transaction costs. Ideally, users could tip small amounts of cryptocurrency for posts or comments, but this is currently not feasible.

8. Supply Chain Tracking

  • Per-Item Tracking: While some supply chain solutions exist on Ethereum, tracking each individual item through a complex supply chain can become prohibitively expensive. The ideal use case involves recording every transaction or movement of goods, which is not practical with current gas fees.

9. Healthcare Data Exchange

  • Patient Data Sharing: Secure and efficient sharing of patient data between healthcare providers using smart contracts is a promising use case. However, the cost and speed of transactions on Ethereum make it difficult to implement a system where data can be accessed and updated in real-time.

10. Frequent Lottery or Gaming Systems

  • Instant Lotteries: Systems that require frequent drawing or instant lotteries for a large number of participants would find Ethereum too slow and costly. Smart contracts could automate and secure these processes, but the current performance issues are a barrier.

Imagine if someone came up with a new “Green Thumbs up” button and it was linked to the gravity wallet on NoM. Every time you gave someone a Thumbs Up, it would send then them a few zats.

1 Like