It is a minor version change, not a hardfork. It contains some improvements, but no changes in consensus. In particular blocks produced by nodes on different minor versions are still compatible.
You are viewing a single comment's thread from:
It is a minor version change, not a hardfork. It contains some improvements, but no changes in consensus. In particular blocks produced by nodes on different minor versions are still compatible.
Do minor version changes still not require only 17/20 witnesses or do they require 20/20? The chain, based on Peakd, is still 1.27.0.
No, no. The minor version is not even subject to witness vote. The chain is on version 1.27, period. All nodes on version 1.27, regardless of minor version or configuration, agree on what is part of consensus. But each node can be on different minor version, nodes can also run slightly different code even if they are on exactly the same version, just due to differences in configuration.
For example:
Version 1.27.1 fixes some bug in the API. API node that runs original 1.27.0 can be crashed with certain calls, but nodes on 1.27.1 and later will respond correctly. It means it is recommended that API node operators update their nodes, but if not, it won't affect the chain in any way.
1.27.2 adds new APIs and collects extra data on RC, which might come in handy, but again, is not do-or-die type of change.
Sometimes minor version can include change that touches consensus, but it can do so only in one way - to constrain it further. Such change is called a soft fork. F.e. we might want to limit transfers to no more than 10k HIVE (I know, ridiculous, but it should illustrate how soft forks work). A new minor version includes such limit as a soft fork. It means that all new transactions that arrive at node with such change will be subjected to that extra rule. Also if that node is a witness node, it won't include transfers exceeding extra limit in the blocks it produces. However if such transfer is passed to witness that does not have that limit, and block is created that includes that transaction, then all the nodes (including those with extra limit), will still accept it as valid. In practice it means that the more witnesses use new version, the (statistically) harder it is for transaction that violates extra rule to be included in the block, but only when absolutely all witnesses use new version, then it becomes impossible for such transaction to be passed to the chain. Soft forks are often used to add a constraining rule prior to that rule becoming part of consensus in upcoming hardfork. 1.27.3 contains sort of that type of change (limit on minimum RC delegation), except it affects RC, which is not (yet) part of consensus despite being required for all but leaf nodes. Whole RC plugin works using soft fork mechanism all the time - when payer has not enough RC, the node drops transaction that is perfectly valid from perspective of consensus, but if such transaction somehow reaches the block, it will only "protest" into the log. In similar fashion witness plugin limits number of concurrent custom operations that a single user can execute per block, as well as prevents private key to be passed in transfer memo (the private key in memo is valid from consensus point of view, but invalid when extra soft fork rule of witness node is applied).