OpenZeppelin / openzeppelin-labs

A space for the community to interact and exchange ideas on the OpenZeppelin platform. Do not use in production!
https://openzeppelin.com/
MIT License
375 stars 116 forks source link

Kernel instances publishing dynamics discussion #70

Open spalladino opened 6 years ago

spalladino commented 6 years ago

This is an issue for discussing dynamics on publishing new kernel versions.

1- If there is a fixed price for publishing new versions, and the supply decreases constantly (since publishing new versions burns tokens), then the effective price of publishing actually goes up. Should we change this into a value that depends on the total supply, or fluctuates according to other values?

teempai commented 6 years ago

I don't know all the other dynamics at play, so do the rewards for publishing an updated kernel version go up at the same rate as the publishing price? If so, this isn't necessarily a problem, but it does mean that not everyone can easily participate.

It will be hard to keep the price of publishing in any way constant without pricing in fiat. Tying to supply could work, but as long as speculation is raging, it won't be directly correlated with market price and could create strange dynamics in the interim. Maybe there's something with a bonding curve that could work to at least limit the publishing price movements.

You could potentially allow for variable publish pricing and use the amount as an indicator of confidence in the update. Sort of like how Numerai uses the stakes as an indicator of algo performance.

P.s. Bare with me as I remind myself about the dynamics you guys had :)

cburniske commented 6 years ago

i don't think i understand all the moving parts here, and we should talk more about the idea of "the supply decreases constantly," but generally i would say it is okay for the cost of something to go up as that service becomes increasingly valuable to the world, especially in governance settings. for example, it has become more and more costly to run for president in the US (in real terms), and one could argue that's because it's become more and more valuable to be the president making decisions. as zeppelin's community scales, any actions will affect a wider set of actors, and therefore these actions should be higher stakes (more costly) to ensure people are acting in the best interest of the community. if you look at DCR, for example, it has become more and more costly to buy "tickets" (for voting) over time, both in terms of DCR and certainly in dollar terms, because there are more and more people participating. the other side to this cost though, is the reward, which i'm not sure i have a clear picture of...

teempai commented 6 years ago

@cburniske The broader ideology is/was that there should not be financial barriers to entry in developing the core protocol. I agree that as the stakes go up, the cost of participation can go up as well, but I also feel like development skill & capital often don't go hand in hand. However, if the cost goes up, it just means that a developer needs to find a sponsor of sorts, which might be acceptable.

wendyxs commented 6 years ago

I think another more interesting implication perhaps beyond even the long term supply decrease is if you fix the price in tokens rather than $ or some sort of other relative factor, then it gets outrageously expensive to publish if some sort of speculation takes a hold of the market. These short term swings are more worrisome to me.

fzeoli commented 6 years ago

I think that the main way upgrades will be published will be through some well capitalized sponsor funding the effort, given high costs and risks for an independent developer to go at it on their own. A high fee that works as a spam/quality filter that remains low enough to be affordable for organizations sounds good to me. If an independent developer wanted to publish an upgrade but can't afford the publishing fee, then finding a sponsor/collaborators would be the way to go.

I do think the fee should more stable than what a token price can provide, so maybe fix it to a moving average of the price (maybe 100-200?) using the built-in oracles