Documentation

The expectation and observation regarding whether the hard-fork proposal successfully updated the protocol version

As ProtocolVersionUpdateLabel, but for software version updates

Note that software version updates are adopted sooner than and perhaps independently of protocol version updates, even when they are introduced by the same proposal transaction.

The protocol info for a node as well as some initial transactions

The transactions implement a smoke test for the hard-fork from Byron to Shelley. See PR #1741 for details on how that hard-fork will work. The key fact is that last thing the nodes will ever do while running the Byron protocol is adopt a specific (but as of yet to-be-determined) protocol version. So this smoke test ensures that the nodes can in fact adopt a new protocol version.

Adopting a new protocol version requires four kinds of event in Byron. Again, see PR #1741 for more details.

• Proposal transaction. A protocol parameter update proposal transaction makes it onto the chain (it doesn't have to actually change any parameters, just increase the protocol version). Proposals are MempoolUpdateProposal transactions; one is included in the return value of this function. In the smoke test, we immediately and repeatedly throughout the test add the proposal to CoreNodeId 0's mempool; this seems realistic.
• Vote transactions. A sufficient number of nodes (floor (0.6 * pbftNumNodes) as of this writing) must vote for the proposal. Votes are MempoolUpdateVote transactions; one per node is included in the return value of this function. In the smoke test, we immediately and repeatedly throughout the test add each node's vote to its own mempool; this seems realistic.
• Endorsement header field. After enough votes are 2k slots old, a sufficient number of nodes (floor (0.6 * pbftNumNodes) as of this writing) must then endorse the proposal. Endorsements are not transactions. Instead, every Byron header includes a field that specifies a protocol version to endorse. At a particular stage of a corresponding proposal's lifetime, that field constitutes an endorsement. At all other times, it is essentially ignored. In the smoke test, we take advantage of that to avoid having to restart our nodes: the nodes' initial configuration causes them to immediately and always attempt to endorse the proposed protocol version; this seems only slightly unrealistic.
• Epoch transition. After enough endorsements are 2k slots old, the protocol version will be adopted at the next epoch transition, unless something else prevents it. In the smoke test, we check the validation state of the final chains for the new protocol version when we detect no mitigating circumstances, such as the test not even being scheduled to reach the second epoch.

Classify the a QuickCheck test's input and output with respect to whether the protocol/software version should have been/was updated