Extend PBFT tests with software version update proposals/votes #1733
Comments
nfrisby
added
consensus
|
If the discussion on Slack is correct, then this actually does not need to happen at all -- instead, the hard fork is triggered by a protocol version update, and software version updates are basically totally irrelevant. But we should confirm that this is the case. |
|
Giving this the same priority as #1514 for now, though we might end up closing this soon. |
|
Conclusion here (@dcoutts , @dnadales , @nc6 ): please correct me if I'm wrong here, but: the publication of software versions onto the blockchain is actually irrelevant for the consensus layer proper (we never look at these versions). In addition, core nodes will probably not update themselves, and so for them too this is not so relevant. However, Daedalus does look at this, and uses it to tell the user to update their wallet (and hence the underlying node), and we will use this in the lead-up to the hard fork, because users must obviously have the latest version of the node installed before they can start running Shelley (a very similar story is true for Shelley-to-Goguen). For this reason, leaving this at high priority. @nfrisby , @mrBliss and I think that testing this should be relatively easy: we must be able to submit and include transactions that update the software versions, and then we should check that the ledger state actually reports these new versions. Consensus itself will be entirely unaffected by this, and so there is no need for restarts or anything like that that would complicate the test infrastructure. Can probably use the existing |
That is correct.
That is being discussed and may be changed. It's possible we'll remove on-chain notifications from Shelley entirely if Daedalus does not need them, because it is the only user of them. And Voltaire will change this all anyway (to be properly decentralised). |
|
Removing high priority, as the wallet team has decided to no longer use this mechanism.
@dcoutts confirms they will be removed. |
1790: Check that Byron can update the software version r=nfrisby a=nfrisby Fixes #1733. I needed to revise the expectations to handle voting more appropriately; there were some slight inaccuracies which I think had been mostly masked by the fact that adopting protocol version requires endorsements and further waiting -- so when _exactly_ the proposal was confirmed hadn't mattered in a test case yet. But for software versions, confirmation is adoption, so accurately predicting when that happen became directly necessary. There is only one proposal, but it proposes both a protocol version and a software version update. The PV update implies the SV update, but not vice versa. For example, the test output includes the following. ``` proposed protocol version was adopted (20 in total): 70% False 30% True proposed software version was adopted (20 in total): 95% True 5% False ``` Co-authored-by: Nicolas Frisby <[email protected]>
1790: Check that Byron can update the software version r=nfrisby a=nfrisby Fixes #1733. I needed to revise the expectations to handle voting more appropriately; there were some slight inaccuracies which I think had been mostly masked by the fact that adopting protocol version requires endorsements and further waiting -- so when _exactly_ the proposal was confirmed hadn't mattered in a test case yet. But for software versions, confirmation is adoption, so accurately predicting when that happen became directly necessary. There is only one proposal, but it proposes both a protocol version and a software version update. The PV update implies the SV update, but not vice versa. For example, the test output includes the following. ``` proposed protocol version was adopted (20 in total): 70% False 30% True proposed software version was adopted (20 in total): 95% True 5% False ``` Co-authored-by: Nicolas Frisby <[email protected]>
Like Issue #1514 but for software updates instead of protocol parameter updates.
A proposal can include a protocol parameter update and/or a software update. The flow of a software update is a prefix of the flow of a protocol parameter update. Once a proposal is put forth, nodes can vote on it. Enough votes confirm it. Once that confirming vote is at least 2k slots old (ie "stable", based on the Byron chain density invariant), any software version update within the proposal has been adopted; nodes are expected to immediately restart in order to continue using new identified software version. This is how the nets' nodes will agree to hard-fork (which can ultimately change anything, including in particular any protocol/node parameters not managed by parameter update proposals). Any protocol parameter update in the proposal is not yet adopted; see Issue #1514 for how that part separately continues.
This test need not actually update any software, but it should at least track that a net can extend a chain so that the tip of the starting chain and the tip extended chain induce two chain validation states that specify different adopted software version numbers.
Related: Issue #1514, Issue IntersectMBO/ouroboros-consensus#706.
The text was updated successfully, but these errors were encountered: