Main > Stakeholder Proposals
Proposal: Coordinate mandatory upgrades on-chain
arhag:
--- Quote from: drltc on November 15, 2014, 03:05:31 pm ---To simplify messaging to non-delegates: Tell them something like "The upgrade will go into effect midnight on August 14, you must upgrade your client by then."
Certainty about when and whether the upgrade will occur has more value than having the upgrade occur as soon as it becomes technically possible or leaving the door open to a potential upgrade forever.
[...]
The hard-coded JSON for a new feature only exists in new clients that support that feature. Old clients won't have the hard-coded JSON, and will need some way to get information about the upgrade. This proposal achieves that by putting information about the upgrade on the blockchain.
--- End quote ---
In my opinion these sorts of things shouldn't require blockchain support. I think it should be enough to have a simple message signed by the delegates that is broadcast on the network which the clients recognize and present to the user. It could warn the users that there is a mandatory upgrade, provide a secure link to the place people can download the new client, and give an estimated time that the delegates expect to finish the upgrade process. If the fork happens before a user upgrades their client, the client looking at the blockchain up to the point the quorum was reached (which I think should just be hard-coded to 51 unique active delegates) would still be able to see that the delegates have approved of an upgrade_id that is not supported in their client (and that therefore they have upgrade to a new client). If/when the client is able to download the signed message from the network, the client will then be able to present all the extra information necessary to inform the user on how they need to upgrade their client so they can continue syncing the blockchain. I don't see why it is necessary to formalize the fork block as part of the blockchain rules; it should just be done through the social consensus that the delegates follow.
--- Quote from: drltc on November 15, 2014, 03:05:31 pm ---It won't be impossible to upgrade to the new version; rather it means the semantics changes introduced by the new version will never go into effect. If only 51 delegates have upgraded when the hardfork goes into effect, the chain becomes very fragile. So the solution is to set the quorum much higher than 51 to provide some safety margin.
Again, we say "the upgrade will not go into effect if a quorum hasn't reached consensus by a certain date" instead of "the upgrade will go into effect when a quorum of delegates support it" in order to provide the certainty of scheduling semantics changes to take effect at a specific date/time.
--- End quote ---
I just think it makes more sense to have the blockchain rule be that a quorum of 51 unique active delegates need to approve of the upgrade for the new semantics to go into effect after the end of the next full round, and then just let social consensus, delegates coordinating (for example, as I mentioned through the client version that they publicly broadcast already), and delegate-signed alerts broadcast to the network be used to smooth out the transition process.
--- Quote from: drltc on November 15, 2014, 03:05:31 pm ---Yes, this is true. The key phrase is "If we want to upgrade to the same features" -- which is not always the case. For example, if security bugs are discovered before the new feature goes into effect, the delegates can simply veto the new feature.
--- End quote ---
If somehow security bugs are found between the time the new client is released and the quorum has been reached, the delegates can just stop approving the upgrade_id so that the quorum is not reached (optionally they can also withdraw their approval of the upgrade_id by voting for a NULL upgrade_id). Then a new client fixing the bug with a new upgrade_id is released, and the delegates can then support that upgrade_id instead (when a given delegate approves of one upgrade_id it should make all previous pending ones they approved invalid). Once the quorum of 51 is reached for that new upgrade_id, the blockchain semantics switch over to that new bug-fixed version.
theoretical:
--- Quote from: arhag on November 15, 2014, 01:19:44 am ---I don't understand what the point of upgrade_effective_block is if you need a quorum of delegates to approve the upgrade. Why not just set upgrade_quorum to something like 81 and then upgrade to the new semantics as soon as (either the very next block or maybe the next round or the next next round to be extra careful) 81 unique active delegates have approved of the upgrade?
--- End quote ---
To simplify messaging to non-delegates: Tell them something like "The upgrade will go into effect midnight on August 14, you must upgrade your client by then."
Certainty about when and whether the upgrade will occur has more value than having the upgrade occur as soon as it becomes technically possible or leaving the door open to a potential upgrade forever.
--- Quote from: arhag on November 15, 2014, 01:19:44 am ---Also, I don't get the purpose of the wallet_delegate_propose_upgrade command if the upgrade parameters are already included in the JSON that is hard-coded by the developers in the client.
--- End quote ---
The hard-coded JSON for a new feature only exists in new clients that support that feature. Old clients won't have the hard-coded JSON, and will need some way to get information about the upgrade. This proposal achieves that by putting information about the upgrade on the blockchain.
--- Quote from: arhag on November 15, 2014, 01:19:44 am ---And for that manner why would the upgrade proposal expire?
--- End quote ---
To provide certainty about whether an upgrade will take effect or not, and give market participants time to make arrangements to conduct their business accordingly once they are aware whether the old or new semantics will be in effect going forward.
--- Quote from: arhag on November 15, 2014, 01:19:44 am ---If it fails to reach a quorum by that expiration, does that mean it becomes impossible to upgrade to that new version? Why? What is the purpose of that?
--- End quote ---
It won't be impossible to upgrade to the new version; rather it means the semantics changes introduced by the new version will never go into effect. If only 51 delegates have upgraded when the hardfork goes into effect, the chain becomes very fragile. So the solution is to set the quorum much higher than 51 to provide some safety margin.
Again, we say "the upgrade will not go into effect if a quorum hasn't reached consensus by a certain date" instead of "the upgrade will go into effect when a quorum of delegates support it" in order to provide the certainty of scheduling semantics changes to take effect at a specific date/time.
--- Quote from: arhag on November 15, 2014, 01:19:44 am ---If we want to upgrade to the same features after the expiration point anyway, then it would just mean the developers would have to release a "new" version of the client with a slightly updated JSON and try again. It is not like these upgrades are dynamic; they require changes to the code of the client and require the delegates (and users) to download the new client.
--- End quote ---
Yes, this is true. The key phrase is "If we want to upgrade to the same features" -- which is not always the case. For example, if security bugs are discovered before the new feature goes into effect, the delegates can simply veto the new feature.
arhag:
I don't understand what the point of upgrade_effective_block is if you need a quorum of delegates to approve the upgrade. Why not just set upgrade_quorum to something like 81 and then upgrade to the new semantics as soon as (either the very next block or maybe the next round or the next next round to be extra careful) 81 unique active delegates have approved of the upgrade? Then you know that the worst case scenario is that the delegate participation rate drops to 80% but the upgrade goes through. Delegates can even do this in a two stage process. First they can upgrade their client and update their public information that broadcasts their client version. Then they can wait a day or two for other delegates to also upgrade. When they see enough delegates are on the latest version of the client (say more than 90%), they can then use the wallet_delegate_support_upgrade command to officially broadcast that they want to switch over to the semantics of the new version. This way the upgrade_quorum can be as low as 51 and still allow for smooth transitions as long as delegates follow this social convention.
Also, I don't get the purpose of the wallet_delegate_propose_upgrade command if the upgrade parameters are already included in the JSON that is hard-coded by the developers in the client. And for that manner why would the upgrade proposal expire? If it fails to reach a quorum by that expiration, does that mean it becomes impossible to upgrade to that new version? Why? What is the purpose of that? If we want to upgrade to the same features after the expiration point anyway, then it would just mean the developers would have to release a "new" version of the client with a slightly updated JSON and try again. It is not like these upgrades are dynamic; they require changes to the code of the client and require the delegates (and users) to download the new client.
By the way, I am really happy you are looking into these delegate proposal concepts. After you do this, I am going to start bugging you to try to convince you to add TaPOS and then an extra byte or two to every transaction to allow stakeholders to approve/disapprove any one of a handful of delegate submitted proposals :). This way we can see what is the consensus of the stakeholders on various important topics related to the DAC (non-binding initially). Then, if this is accomplished, I would of course want to push it further: first, by having the delegates submit not just a hash of a JSON to the blockchain for stakeholders to vote on, but the contents of the JSON; then, creating a specification for the JSON (it doesn't actually have to be JSON BTW, protocol buffers would probably make more sense) to describe certain concepts to the DAC such as change the dilution cap or change the minimum collateral ratio or set a yield rate cap on a particular BitAsset, each with their own quorum requirements for the stakeholder vote; and finally, actually have the DAC dynamically "upgrade" to these small changes anytime the quorum requirements for one of these binding proposals is satisfied (I like to call this stakeholders ratifying the delegates' proposals).
theoretical:
Okay. I think I'll remove or adapt the existing proposal code, and work on implementing the OP.
bytemaster:
Yes this is a better system and was the original plan.
The only question is when does it get implemented.
Navigation
[0] Message Index
[#] Next page
Go to full version