Tbh, it’s an interesting thinking and unfortunate that the team does not care to elaborate on how they see the role of unikernels wrt smart contracts / vm implementations now. But to me it currently sounds unnecessary, as I think what you describe could be done with just smart contracts as well. Possible though that I’m not getting the full picture you have in mind.
A consistent theme in the feedback is keep the process simple. The World’s Simplest DAO framework looks pretty simple. And I like that.
At the core, we are proposing the BIP process. Not sure if that process is “simple” but it’s proven. That process can be run by any pillar who choses to engage. As more Pillars engage, the more complicated it will get BUT will also get more resilient and decentralized.
For me, the voting mechanism is still in question. I feel like Authors should be able to propose the threshold level with some minimum requirements.
Also, I continue to question Informational ZIP approvals. I don’t think they should need a vote. Voters could get vote fatigue IMO. They need rigorous debate, like we are having here. But once that debate is done, why can’t a Pillar publish them without a vote? Like the BIP process. And to prevent Spam, maybe a Pillar needs to donate ZNN to the AZ framework for the community to consider them complete.
These are zips for initiatives that don’t change code in any way right? Then I agree, don’t see the necessity for this category at all in the process.
Correct. But I do think they have a place. This ZIP Process framework is an informational ZIP. There might be things the community wants to announce to users that need an Informational ZIP.
BIP9 is an informational and technical in nature:
I also think informational BIPs / ZIPs can lead to important code changes.
Ok but then we would want to have consensus on that
Does being sympatico with the BTC ethos mean we need to follow their upgrade processes? I know it’s tried and true, but is it suitable for where ZNN is at the moment? Just playing devil’s advocate - I won’t pretend to now the answer, but I thought I’d ask.
Another consideration is how to motivate inactive pillars to participate in governance. Maybe it’s something I missed, but where is the proverbial boot to the ass that will get them to join the top 30 or so and actually do stuff?
1 Like
OK. So you think voting on these informational type ZIPs is important?
If we consider the zip currently in discussion informational, yes, I think there should be voting on it
1 Like
Good point. In all honesty I think we tried to build on the work / research Romeo did. He researched BIPs / EIPs, etc… and I believe his original proposal followed the BIP process generally. So we tried to build on that work but propose a structure that did not need a central editor.
I did not look carefully at the other blockchain improvement procedures. But I’m happy to review any that folks think are relevant!!
1 Like
Not to get too off topic.
But I think it’s possible that with unikernals you can bypass the browser for dapps.
Like you have a game written in C++ and it installs with a unikernal module that is customized for the game and then you could have token economies and nfts and maybe other data structures all running natively in the game.
and then this sort of concept could be used for any kind of application.
Instead of accessing “web 3” through a browser like with other blockchain platforms, unikernals could let applications use web 3 directly without all the constraints that browsers and scripting languages bring.
Just wanted to add that for a voting structure based around the delegated weight i think would help if the top 30 pillar rewards get redistributed more evenly to all pilars. It would help balance out the weight so when delegates want to vote with their coins it could have more impact on a lesser spread accross all pillars.
#Pillardown
1 Like
Hm but the browser in web3 is needed on the side of the user to interact with the contracts. Unikernels were proposed to be run by the nodes, so it has nothing to do with how the user is able to use the apps.
If we’re talking about the ability to use other languages to build the apps, that’s something that would also be solved with wasm or potentially other stacks, where a library has been built that bridges the gap from user level app to ledger.
But yes, we’re getting off topic
Fwiw I don’t think Informational is a good label for these kinds of proposals. It’s not just information. Even though it might not be enforceable on protocol level, you want to define a process that’s giving direction to the network, and which you assume, when accepted, will be enforced on the social layer. Don’t know if every possible topic from Informational goes this far (if not, we agree again, why vote on it at all?), but I think Informational is misleading here, and invites to formulation of nonsense zips that don’t need consensus.
Maybe Directional is better?
2 Likes
Important Notes from Twitter Spaces:
- The ZIP framework is simply a roadmap. Community members and economic actors will choose to follow it or not. They do not need to follow it. No one can force them to follow it. They can choose to follow it or create their own process.
- Informational & Implementation ZIPs should not need a vote. If community members adhere to informational ZIPs over time they will be considered adopted by the community. Maybe we should consider changing “Approved” to “Published” and remove the voting requirement.
- The intermediate voting steps for Hard and Soft forks are not necessary. The active dialogue about ZIPs and feedback from the community and pillars will give the Author(s) sufficient comfort about support before starting to code. A vote should not be necessary to signal support. The tone of the discussion and feedback publicly from Pillars should be sufficient.
- @georgezgeorgez recommends that we “recommend” all ZIPs be submitted / introduced a certain way. Similar to the BTC mailing list. We might consider requiring the first submission be on the forum. The forum is run and owned by the community. We can host it ourselves. It’s difficult to take down.
- Voting for Hard & Soft forks should not be mandated in the ZIP framework. Each update will have different significance, so it’s impossible to know today what should be required. Each ZIP could have a separate discussion about how it will get activated. The Author could propose it but will get debated by the community
- It’s unclear how Sentinels will play a roll in hard & soft forks and the ZIP process. But their roll will be important as momentums will require PoW links. If a spork activates and Sentinels don’t follow the Spork the momentums will not have Tx in them (did I say that correctly?)
- The general theme is the network is about opting in. We cannot force anyone to do anything. We should not propose a rigid structure that cannot be enforced.
- Also, other Pillars can create their own ZIP framework if the one in discussion is too rigid or too lax. Community members might follow it if gets support.
- Other Pillars can also fork, modify and/or improve the one being proposed now and build community support around it.
1 Like
I can see your point about the informational label.
How about procedural? After all, we are establishing the accepted way of doing something.
Made A LOT of edits and updates based on various extensive discussions with community members. Some minor terminology / typo mistakes but should be 98% finalized unless I made some big brain doo-doo
2 Likes
Guys if anyone has comments please provide them soon. We are getting ready to post to github next week.
1 Like
ZIP:deeZNNutz-0001 published on github for review. We need to clean up the repo and add a pillar signature. Open to comments.
2 Likes
Does anyone have an objection to adding this recommendation from @georgezgeorgez to ZIP:deeZNNutz-0001? We can test making a change and updating the change log.
1 Like
Yes I do tbh. I dont see a reason to add it to the ZIP Process itself, it’s more a general commentary rather than a change or extension of the process. The process is already quite extensive, let’s try not to lengthen it further unless absolutely necessary.
Maybe you can instead cross post it as a comment/reply to the original ZIP post in your git repo.