@EovE7Kj looks like we got that last AZ paid. Thank you for all your work so far.
I’ve been having a discussion with another dev about your work and we have some questions. From what i can tell, zApps will run on infrastructure provided by TBD sources. zApps don’t run on Pillars or Sentinels(?) they run on infrastructure provided by hosts. As far as I can tell these hosts do not exist yet. I have a few questions:
- What incentives do the hosts have in order to provide infrastructure to run zApps? Will those incentives come from zApp usage or somewhere else?
- Can hosts spin up on AWS / DO / etc or do they need offer hosting services on bare metal equipment? Last time I checked I think you can run a unikernel on QEMU on linux hosted at AWS, for example. That seems like double virtualization. Do you see that as an obstacle / issue for zApps adoption?
- If a zApp runs on an individual host, how can we rely on the output of the zApp if no other nodes are confirming the output?
- How does a zApp ensure the host is not manipulating the gas measurement and charging too much gas for usage?
- BTW where does the SC live. The WP image below shows the SC outside the zApp envt.
Maybe your work will include the deployment of sentinels too, per the image below from the WP. And unikernels run on sentinels. And the sentinels are what confirm the output and ensure gas is metered correctly. Is this where you are headed?
Sorry for the delayed response here, @0x3639. I’m in the middle of a busy season and have been traveling over the past few months.
As I mentioned previously, the ultimate goal is for zApps to run on Sentinels, with participant nodes receiving incentives in the form of qas (quasar-gas), determined by Pillar quorum. Each Sentinel and their associated zApp(s) will operate entirely within a custom unikernel. To drive interest in participation, we need to enhance the visibility of Sentinel hosts and effectively market the potential for zApp integration, which will attract new Sentinels to the network.
Regarding zApp integration, it’s essential that the target remains limited to Sentinels. We want to keep Pillars separate, as their potential for BTC operability within Pillars far surpasses that of zApps.
The foundational mechanisms for network integration are still being researched and tested, nothing has been made public yet. I am currently focusing on a WASM-based approach for a completely “EVM-less” contract mechanism. Once we have a release ready, we will likely start another thread dedicated entirely to Sentinel integration and launch new AZ(s) for this. Designing a novel smart contract implementation is no trivial task.
For now, the existing uk-devkit approach allows anyone to spin up a zApp within a unikernel before interfacing with the network. This was intended as a sandbox for developers to build in… unfortunately, interest has been quite low on this front, and I have yet to hear from anyone with a feasible, meaningful application.
Keep in mind the points below come from someone with a purely technical background and are not meant to demean or offend anyone currently working on marketing the brand.
Since the launch of this unikernel AZ and @aliencoder’s massively impressive Supernova extension chain, the most significant issue I see is not technical but rather in a deficient marketing strategy.
There seems to be a lack of proactive engagement on social media and a clear strategy to promote the unique features and potential of the Network. Driving interest in NoM is going to be the paramount issue that will determine the overall success of the network and its ability to attract developers.
I believe your Unikernel development is far more impressive and can really be a game changer for NoM this upcoming bull market.
We need to see what’s the best approach… but I’m here to help and support your initiatives.
Re marketing: no offense taken. Zenon organic marketing bro’s often times feel deficient, but it’s not for a lack of effort.
Aliencoder has been great about sharing ideas and providing snippets of info for marketers to work with, and fostering an environment where marketing coexists with devops. I mention this as an example how to enable the marketing teams to perform intelligent, informed, and effective outreach.
Toward that notion, any information, vision, insights, KOLs, target markets, or strategies that you have in mind will be invaluable.
You made some rather direct implications about pillars and sentinels. If we can gain better understanding, we can communicate to the market more effectively.
The more that devs share with the marketing team, the more intel and ammunition we have to work with, and the less it sounds like vapor / “potential” / zoon.
Aliens are unphazed by price action, but when it comes to reaching new prospects, our chart doesn’t inspire confidence in the network’s unrealized potential.
The more snippets, substance, and signs of high IQ, the better.
The community has been good about staying on topic and task in Matrix channels. Would you be willing to join a focused channel for Unikernel Z discussion and coodination?
Nobody named EovE7Kj is in it for the limelight, but I’m advocating for close coordination between devs and marketing.
Summary of Important Quotes to Help Understand This Work
From reading the quotes below here are my summary notes:
- Each zApp runs on it’s own unikernel
- zApps will run on Sentinels
- Gas to run zApps will be paid in fused QSR called “qas”
- Nodes (Pillars, Sentinels, Sentries, etc) of the network are their own unikernel called unikernel-z.
- Sentinels will receive incentives to run zApps. I assume through protocol emissions.
- SC Runtime is WASM inside the unikernel
- SC are written RUST which can compile to WASM directly
- I think this means zApps run on a unikernel with an embedded WASM runtime. Separately, SC are written and compiled to WASM. The SC interacts with the zApp through the WASM “interface”. The end user interacts with the SC through some Web2 interface. User >> SC >> zApp. The zApp then communicates with the Nodes of the network to change the state of the to be deployed embedded contract. I hope this is generally correct.
Open questions?
- What is the difference between the SC and zApp? I think the SC “programs” the zApp or gives it a set of instructions to run.
- Will a zApp be generic allowing several different SC to interact with it? Or, will one SC require an individual zApp? Meaning, if someone wants to deploy a SC, they also need to deploy a zApp?
- What is an Adaptive Smart Contract? I think it means the conditions of the smart contract can be changed continuously. So a SC is not static, it can adapt or change in the future after being deployed (on the fly) based on user input.
Notes to self
- I don’t think we should say we are a decentralized unikernel host. We will host zApps which happen to run on Unikernels
- Users will NOT be be able to run random Unikernels on NoM.
- NoM will fundamentally change how Smart Contracts are run. Rather than running on all nodes, a SC will run on a single zApp and I assume the output and gas usage will get confirmed by other Sentinels in the network by relaying messages.
A few notes on your summary:
Nodes (Pillars, Sentinels, Sentries, etc) of the network are their own unikernel called unikernel-z.
Ideally, yes. But this all depends on participation of the node hosts. While their nodes would be more secure and efficient running within unikernel, some hosts may still prefer to run on a traditional OS… I see no reason to “force” the implementation of the unikernel globally. Sentinels will have a modified unikernel that allows for the SC integration and application-layer interface. Sentinels will obviously be incentivized via qas from zApp integration, but not forced to participate.
SC are written RUST which can compile to WASM directly
This is still in POC, and other options are still on the table.
I think this means zApps run on a unikernel with an embedded WASM runtime
More generally, zApps are colocated with Sentinels within a custom unikernel that integrates the application layer to the NoM via smart contract.
To answer your questions:
What is the difference between the SC and zApp? I think the SC “programs” the zApp or gives it a set of instructions to run.
Fundamentally, a zApp is any application with its code written to the NoM via smart contracts.The smart contracts are the backend logic that connect the application to the blockchain.
Will a zApp be generic allowing several different SC to interact with it? Or, will one SC require an individual zApp? Meaning, if someone wants to deploy a SC, they also need to deploy a zApp?
These are great questions, and the implementation really depends on the developer(s). A well-designed zApp can allow multiple smart contracts to interact with it via interfaces or APIs, making it easier for developers to integrate different contracts into a unified user experience.
Without a zApp, I don’t see how an SC would have a usable interface for users to interact with its functionalities.
What is an Adaptive Smart Contract?
“Adaptive” = capable of modifying its behavior/functionality – or even its own code --in real-time based on external conditions.
This is kind of a blockchain buzzword, but the underlying concept is in no way novel in programming. Contextual awareness and “meta”-programming have been around since the days of Lisp.
All of this depends on the creativity and capabilities of developers who seek to harness the tech in meaningful ways.
Vitalik wrote the EVM, he didn’t create Uniswap.
This goes back to my earlier comments about markenting awareness in the Network… We can create a groundbreaking smart contract mechanism for Layer 1, but the real value comes from how the community engages with it. If there isn’t sufficient interest in the Network, the potential value added remains negligible.
Marketing:
iPods were a hit because apple understood to sell the experience (“1000 songs in your pocket”), not the feature (“5GB of storage”).
This requires alignment between engineers and marketers. And Product Market Fit (PMF).
In Zenon, there is a disconnect:
Engineers build core tech they think the market wants, but are unable to explain it beyond its features. Then they blame marketers for being incapable to create demand for it. Engineers fail to understand that what you build is not what you sell. You sell what you use it for. To those who actually need it.
Marketers blame engineers for building features for which the market seemingly doesn’t have any demand - because they lack the understanding to translate features into marketable use cases that target a specific audience (e.g. other devs).
Result: both groups don’t speak to each other but blame one another for their own failures.
Welcome to open source development.
I think the biggest point that I am trying to make with regards to “marketing” is this – the blockchains that are built to last are the ones that have inherent functional value. Because they DO something aside from creating returns from the people investing in it. If we want the network to last in any meaningful way, we want to attract developers to the platform, rather than trying to build an investor base. To that end, it’s essential to steer marketing away from price discussions and speculation, and instead toward the ecosystem. Developers and users are more likely to invest their time and resources in platforms that prioritize real-world solutions and long-term growth, rather than those that are merely caught up in speculative hype
I don’t see a price listed anywhere on these. I don’t immediately see any mention about returns or delegation or rewards or token farming on their home pages. 10+ years old, and the most successful blockchains in the world are still focusing on developers.
Why aren’t we?
Can you provide an example of how I could explain to a dev why they would want to explore the unikernel sandbox, and where I would direct them to start?
Where would you recommend finding these people?
If these are the wrong questions, please share answers to better questions. Anything, really.
Also sent you a dm on Matrix. 
Ethereum has become a highly successful and attractive platform for developers due to several key factors. Ethereum was the first blockchain to introduce smart contracts, enabling developers to raise millions through ICOs (though the majority were scams). This motivated many developers to create Dapps, some of which are widely used.
Zenon has fewer financial resources available for marketing and developer outreach, relying instead on organic growth and community-driven efforts ,which can be slower and less effective compared to well-funded marketing campaigns. With low to no liquidity and presence on smaller exchanges, Zenon struggles to generate the visibility needed to attract developers who are often drawn to projects with strong financial incentives, market activity, and trading opportunities.
Literally this. Ethereum’s success is based on it becoming the first massive shitcoin casino in the world, allowing a plethora of grifters scam the shit out of the market.
Smart contracts were an innovation, sure. But it would be foolish to ignore just how much ETH’s metheoric (no typo) rise contributed to the adoption of the network.
Stop fooling yourself with “price doesn’t matter” cope. Yes, devs are the target audience. Guess what, devs want to contribute to something that displays growth. What is a tried and tested way to telegraph growth? Investor demand…
How else do you explain the success of Solana? Because of muh tech? Get outta here (@Stark321 this isn’t directed at you)
@EovE7Kj Looks like someone has taken your advice and is reaching out to BTC devs.
https://x.com/ppddsspp/with_replies
@Stark wonder if we develop a landing page that compliments ppddsspp’s efforts.
I’m game. Let’s do it.
I don’t mean to bring any contention to this forum, or make this thread about ‘technical’ vs. ‘social’ paradigms.
I never implied price doesn’t matter, of course it does. I meant simply that there is a very important difference between intrinsic value and market valuation.
The ephemeral attention of an increasingly fickle crypto community often distorts the bigger picture. It’s easy to get swept up by price fluctuations and short-term hype, but in the long run, the most robust and innovative technologies will prevail. In my experience, the crypto community today tends to overlook what truly sustains a blockchain in the long run: the strength of its underlying technology.
Blockchains with robust consensus mechanisms, scalability, decentralization, and strong developer ecosystems will outlast the hype.
You actually make my point for me here with regards to measures of success. Do I equate rapid short-term growth to “success”? Thankfully, no.
Solana did some impressive things when building their blockchain and its PoH and Tx mechanisms. What the crypto community did with their blockchain is another story altogether.
What’s written to a blockchain today is just a prelude. The real story unfolds in the next five to ten years, when real-world use cases mature and the market weeds out projects that lack meaningful utility. Blockchain as a whole hasn’t even scratched the surface of its potential. This current era—dominated by speculative tokens and meme coins—is simply a phase. Whether Solana is going to be the blockchain equivalent of Netscape or Google remains to be seen, and only a fool would claim that they know otherwise.
@EovE7Kj is a zApp deployed to all sentinels? If this is the case how do you orchestrator which sentinel will run the SC code and which ones verifies it?
Or will a zApp developer host the zApp themself on their own sentinel (or maybe on a hosting provider’s sentinel)? Then that sentinel will pass the output to others to verify. If those other sentinels don’t host the zApp I assume the SC itself will have some way for other sentinels to verify the output of the zApp run on another sentinel.
I’m trying to create a simple thread on X and want to make sure I understand this correctly.
Will zApps have to spend QSR, or will qas function as something akin to plasma where it recharges or perpetually reserves a portion of bandwidth?
In other words:
On ICP, canisters have to be recharged with tokens or else they go offline. Will zApps be the same?
@EovE7Kj can you please elaborate on the “fee” mechanism to interact with SC on NoM. Which one of these statements is true (based on your latest design ideas)?
-
A SC user will pay a “fee” in the form of
qas(a fraction of QSR) to interact with a Smart Contract. A “fee” in this case is a cost, like gas in ethereum. It will NOT be fused and returned. Theqaswill exchange from one party to another. Presumably from the user to the Sentinel that runs the zApp. -
A SC user will pay a “fee” in the form of
qasby fusing QSR. After the SC runs theqaswill be returned to the party that fuses it.
We are getting confused by the word “fee”. This word appears in the WP (or a variation of it). I think the WP implies SC require a fee that is NOT fused and returned. But we are really not sure.