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 asked Perplexity.ai - Do EVM smart contracts allow for adaptive smart contracts?
Answer
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]
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.
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.
could just not be compatible, it says in the github notes that it’s only been verified on QEMU and XEN. Pretty sure ProxMox is based on KVM (although they’re pretty much forks of each other)
