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.
I am close. Hoping to carve out some time this weekend to complete.
I asked Perplexity.ai - Do EVM smart contracts allow for adaptive smart contracts?
No, traditional Ethereum Virtual Machine (EVM) smart contracts do not natively support adaptive or self-modifying behavior. EVM smart contracts are designed to be immutable once deployed on the Ethereum blockchain.
The immutability of smart contracts is a core principle in Ethereum, ensuring that the code and logic of a contract cannot be altered after deployment. This provides security, transparency, and predictability, as all parties interacting with the contract can be certain that the rules will not change unexpectedly.[1][4]
However, there are ways to introduce some level of adaptability or upgradability to EVM smart contracts through specific design patterns and proxy contracts. Some common approaches include:
Proxy Patterns: These involve deploying a proxy contract that acts as an intermediary between the user and the actual logic contract. The logic contract can be upgraded by deploying a new version and updating the proxy to point to the new contract address.[2]
Eternal Storage Patterns: These separate the contract’s code and storage into different contracts. The code contract can be upgraded while maintaining the same storage contract, preserving the contract’s state.[5]
Governance Mechanisms: Some contracts implement on-chain governance mechanisms that allow authorized parties (e.g., token holders) to vote on proposed upgrades or parameter changes to the contract’s logic.
While these patterns enable upgradability, they do not provide true self-modifying or adaptive behavior as seen in Zenon Network’s Adaptive smart contracts. The upgrades or changes in EVM smart contracts still require external triggers or interventions, rather than being driven autonomously by the contract itself based on conditions or external factors.[1][4]
Citations:
[1] Blockchain smart contracts: Applications, challenges, and future trends | Peer-to-Peer Networking and Applications
[2] https://www.usenix.org/system/files/sec21summer_rodler.pdf
[3] Top 9 smart contract platforms to consider in 2024 | TechTarget
[4] Smart Contracts: All You Need to Know in One Read
[5] What are Upgradable Smart Contracts? - ImmuneBytes
The PP token on the Network now isn’t the same as PP from the testnet that was converted to QSR. I thought the PP on the network now was just another ZTS that was created by someone?
Ya, $PP is really perplexing to me. Appears that Rigel created it and started to dispense it fairly in Aug 2023 with an air drop to all users. He somehow created a vanity ZTS address that ended in pp. I would like to know how. I asked this in TG.
And the $PP token was in the marketing video exactly when the “Adaptive Smart Contract” image appeared. That leads me to believe $PP could be used to fuel adaptive smart contracts in some way. BUT, if this was planned from the release of this video (Nov 26, 2021 ) how is it that the token was only created in 2023? That seems pretty risky to telegraph the $PP token but create it years later.
UPDATE: I’m 99% sure my theories are fake news and failed schizo. But I’m leaving 1% out there due to this image (adaptive smart contracts and PP on the same…). Maybe Rigel is building something that uses PP to fuel a zApp. But, that is complete speculation.
For anyone else looking into $PP, it was not in the genesis.json.
I did notice this in there:
"ExtraData": "000000000000000000004dd040595540d43ce8ff5946eeaa403fb13d0e582d8f#We are all Satoshi#Don't trust. Verify",
I think we should focus on adding more value to ZNN or QSR rather than other ZTS tokens.
Please be respectful to other members - no need for direct personal comments
I hope to run this today in Proxmox
Setup Instructions
Nice proof-of-concept. The next milestone can be a gas metering implementation for the unikernel.
UPDATE!
The qcow2 build that was pushed last night was not the correct image. I am re-uploading with the correct build now. @0x3639 I will let you know when this is ready.
New release
@EovE7Kj check zama. I’m researching how we can integrate a gas metering system inside the unikernel controlled by an embedded contract.
Is it hard to create a custom module that is loaded by the unikernel? Can you tell a bit about the lifecycle of an unikernel? Thanks!
which version on Proxmox are you running?
pve-manager/8.2.2/9355359cd7afbae4 (running kernel: 6.8.4-3-pve)
did your test boot past this point?
