Phase 2 has been submitted to the AZ 
Now all focus goes into unikernel for zApps
8 Likes
It might take me a week, but happy to make a hello world or a counter zApp 
4 Likes
Let’s make an app that randomly spawns the name of a Fuddor and when you click on it a meme spawns from the @baggot collection.
1 Like
Forking Morpheus could be a really powerful zAPP. David Johnston and Voorhees involved.
$100M stETH in 2 days
4 Likes
Unikernel gas metering
In order to run decentralized applications inside the unikernel, we need:
- A gas metering system to measure the actual runtime. The cost of running the applications needs to be paid by the user to the network and the service provider. This is another topic that we can decide upon at a later stage.
- A way to modify the state of NoM
In order to implement a gas metering system, we first need to acknowledge that the unikernel will run on untrusted hardware operated by an untrusted party that has full access to modify everything during runtime, including removing or altering the gas metering code or user inputs.
Ethereum solves this issue by having a sandboxed virtual machine called EVM that runs deterministically as a state-machine on thousands of nodes at the same time. If a node tampers with the EVM, it will generate a non-determinism that will cause a fork. In Ethereum, validators are penalized if they vote for a fork (up to 1/2 of the stake), so they are economically aligned to be honest.
My solution? Run a WASM runtime inside an unikernel. Why? Read below:
Food for thought:
https://flavio.castelli.me/2023/02/07/building-a-unikernel-that-runs-webassembly---part-1/
Next steps:
- Provide a way to cryptographically attest the integration and execution of the gas metering code (zk-proofs)
- Create an embedded to modify state
@EovE7Kj your input is required.
5 Likes
Encouraging to see such good performance results with the unikernel.
Could you clarify what the TTM is exactly? From the github document:
Time to First Momentum (TTM) (ms): Time taken to reach the first momentum.
Is this the time taken for a momentum to be received from a peer and to be processed by the node?
3 Likes
@aliencoder your argument is compelling and I am willing to start working on a WASM implementation. I don’t have a ton of experience, but WASM speaks for itself - and there is a rich set of documentation. With these and wide range of available toolkits, I think I should be able to hit the ground running here.
And am a HUGE proponent of both Unikraft and Nanos. I have sandboxed solutions with these in the past before scaling with Mirage.
This is the real meat of this project and I will likely need more input, collaboration from you and the rest of this community. This aspect will likely spread across multiple AZ and require several iterations of testing+development.
This collaborative feedback has me rethinking this project entirely – I welcome more input from the entire community.
5 Likes
Yes, I measured the time that the first full momentum was processed by the node. I had a timer embedded on the vm that was parsing the stdout for the momentum
1 Like
Should not cost gas to spin up a unikernel, should cost gas if a user wants to use your unikernel, ex for renting out computer power, storage and so on.
If i want to own my data/node, set up a storage node or what ever, it should not cost.
I should be able to example take a gas cost if someone want to use my Unikernel znn node, or rent GB to host a Zapp.
I think the gas @aliencoder is referring to is not in reference to the unikernel itself, but the zApp usage, as it is explained in the Whitepaper:
Periodically, the users will need to pay for the zApps
usage; this system will be designed in a similar way gas
[53] is implemented for smart contracts as a fees mechanism rhat 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.
2 Likes
@aliencoder if we go this route and are compiling to WASM, my immediate thought is that we write the smart contracts in Rust (as they compile directly). This also affords us numerous security and memory-safety benefits.
If this is the implementation that we proceed with, we are going to be creating an entirely novel L2
Regarding gas computation mechanisms, I have given this a lot of thought the past weeks. First of all, I think that QSR are ideal for the L2 gas… fusing it for plasma is a PoW utility, QSR already handles operational aspects of transaction processing. We can therefore define gas units as a fraction of one QSR.
Thoughts?
4 Likes
Makes sense. Are you worried about QSR getting really expensive? I assume you’ve looked at the DP plasma post by @vilkris. As usage goes up how do we prevent QSR from becoming too expensive. We would hate to be a feeless network that requires a user to purchase QSR for $1000/ea to transact.
3 Likes
Great, thanks for your answer. Yes do vote for QSR being used as gas.
Did you read the articles? Your input is valuable.
I agree. We need to design a trustless, auditable and cryptographically safe procedure to inject and run the metering code. The state modifier code is also very important.
Concepts that we will need for the implementation:
We can use either ZNN or QSR as gas for the unikernel layer.
Users can generate PoW if they want feeless transactions (simple transfers). Complex operations like embedded (smart contract) interactions will be more expensive and will require QSR - skin in the game.
We should keep things simple.
2 Likes
Couldn’t the smart contract interactions just cost a lot more plasma?
Why would a dynamic plasma solution work for the base layer and not for the smart contract layer?
Because at the base layer PoW can (and should) be quantified (on-chain).
What incentive does the infrastructure provider have to host the hypervisor to run the unikernels if compute will be paid in the form of plasma (PoW or fused plasma)?
If network participants can justify to pay for more and more physical infrastructure with smaller and smaller amounts of QSR, would the amount of QSR needed for gas plausibly go down, as the price of QSR goes up?
Looks a lot like ICP’s reverse gas model. Infrastructure providers will likely be incentivized by receiving payments from hosted zApps. If a zApp is successful, it needs infrastructure to scale and the zApp needs to be able to pay for this extra infra.
As a service node operator, I want to get paid (maybe upfront) to keep the node up and running.
That’s pretty interesting… and there is nothing stopping a large company from running their own infrastructure to host their own zApp I assume.
2 Likes