{"id":345,"date":"2023-11-23T06:11:28","date_gmt":"2023-11-23T06:11:28","guid":{"rendered":"http:\/\/10.0.1.147\/?page_id=34"},"modified":"2024-07-02T13:27:18","modified_gmt":"2024-07-02T13:27:18","slug":"developers-network-upgrade","status":"publish","type":"page","link":"https:\/\/www.hashcashconsultants.com\/developers-network-upgrade\/","title":{"rendered":"Developers Network Upgrade"},"content":{"rendered":"
This document describes the various mechanisms used to keep the overall system working as it evolves.<\/p>\n<\/div>\n
This uint32 stored in the ledger header describes the version number of the overall protocol. Protocol in this case is defined both as \u201cwire format\u201d\u2013i.e., the serialized forms of all objects stored in the ledger\u2013and its behavior.<\/p>\n
This version number is incremented every time the protocol changes.<\/p>\n
Integration with consensus<\/strong><\/p>\n Most of the time, consensus is simply reached on which transaction set needs to be applied to the previous ledger.<\/p>\n Consensus can also, however, be reached on upgrade steps.<\/p>\n One such upgrade step is \u201cupdate ledgerVersion to value X after ledger N\u201d.<\/p>\n If nodes do not consider that the upgrade step is valid, they simply drop the upgrade step from their vote.<\/p>\n A node considers a step invalid either because they do not understand it or some condition is not met. In the previous example, it could be that X is not supported by the node or that the ledger number didn\u2019t reach N yet.<\/p>\n Upgrade steps are applied before applying the transaction set to ensure that the logic scheduling steps is the same that is processing it. Otherwise, the steps would have to be applied after the ledger is closed.<\/p>\n Supported versions<\/strong><\/p>\n Each node has its own way of tracking which version it supports\u2013for example, a \u201cmin version\u201d, \u201cmax version\u201d\u2013but it can also include things like \u201cblack listed versions.\u201d Supported versions are not tracked from within the protocol.<\/p>\n Note that min Protocol Version is distinct from the version an instance understands: typically an implementation understands versions n \u2026 maxProtocolVersion, where n <= min Protocol Version. The reason for this is that nodes must be able to replay transactions from history (down to version \u2018n\u2019), yet there might be some issue\/vulnerability that we don\u2019t want to be exploitable for new transactions.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":" Network Upgrades Versioning and Upgrading This document describes the various mechanisms used to keep the overall system working as it evolves. Ledger versioning ledgerVersion This uint32 stored in the ledger header describes the version number of the overall protocol. Protocol in this case is defined both as \u201cwire format\u201d\u2013i.e., the serialized forms of all objects […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"template-developers-network-upgrade.php","meta":{"footnotes":""},"class_list":["post-345","page","type-page","status-publish","hentry"],"yoast_head":"\n