Author Topic: Proposal: Coordinate mandatory upgrades on-chain  (Read 2423 times)

0 Members and 1 Guest are viewing this topic.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
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.

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.

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.

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.

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.

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.
« Last Edit: November 15, 2014, 04:27:13 pm by arhag »

Offline theoretical

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?

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.

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.

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.

And for that manner why would the upgrade proposal expire?

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.

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?

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.

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.

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.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: 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).

Offline theoretical


Okay.  I think I'll remove or adapt the existing proposal code, and work on implementing the OP.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline bytemaster

Yes this is a better system and was the original plan.   

The only question is when does it get implemented.

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
BM talked about "votable" hardforks in the future .. what you are proposing seems pretty much related ..

it reminds me also of how bitcoin changes block version numbers over time .. something in the line with .. if 80% or more of the last 100 blocks or so are of version X thn version X-1 is considered obsolete ..

Offline theoretical


Hmm, looking at the code I see a bunch of stuff related to "proposals" is already in there, but is apparently disabled by https://github.com/BitShares/bitshares/commit/f0a447eb15171af8f2149150e96912c6d5a95211

What are these proposals and why were they disabled?
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline theoretical


Currently, mandatory upgrades [1] are implemented by updated clients changing semantics on a hard coded block number.

This has the disadvantage that non-updated clients aren't aware of the upgrade taking place, rather they eventually see all delegates signing off on a malformed chain when the new semantics eventually allow a previously invalid transaction.

I propose allowing delegates to publish the following transaction types:

    wallet_delegate_propose_upgrade upgrade_name upgrade_id upgrade_quorum proposal_expiration_block upgrade_effective_block
    wallet_delegate_support_upgrade upgrade_id

upgrade_id is the hash of a JSON object hard-coded in updated clients, specifying the upgrade's parameters.

    blockchain_get_upgrade_support upgrade_id

The upgrade process then looks like this:

- Developers create code to implement new semantics
- Developers create upgrade_id
- upgrade_quorum is the number of delegates which need to sign the upgrade (usually 51)
- After proposal_expiration_block passes, wallet_delegate_support_upgrade operations on this upgrade_id become invalid
- upgrade_effective_block is the block when the new semantics go into effect

Currently checking whether an upgrade is enabled is done by statements like this:

    if( pending_block_num == BTS_V0_4_17_FORK_BLOCK_NUM )
    if( pending_block_num > BTS_V0_4_21_FORK_BLOCK_NUM )

The hardcoded constant BTS_Vx_y_z_FORK_BLOCK_NUM will simply be replaced by get_upgrade_effective_block(upgrade_id).

The get_upgrade_effective_block() function will be the upgrade_effective_block if at least upgrade_quorum delegates issued wallet_delegate_support_upgrade transactions before the proposal_expiration_block.

[1] "Mandatory upgrade" is preferred to "hardfork" for marketing reasons.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk