You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

661 lines
25 KiB

  1. # Upgrading Tendermint Core
  2. This guide provides steps to be followed when you upgrade your applications to
  3. a newer version of Tendermint Core.
  4. ## v0.34.1
  5. ### ABCI application changes
  6. A new form of evidence: amnesia evidence, has been added. Potential amnesia and
  7. mock evidence have been removed. Applications should be able to handle these
  8. evidence types.
  9. ## v0.34.0
  10. **This release is not compatible with previous blockchains** due to switching
  11. from amino to proto3 encoding and breaking changes to the header.
  12. ### ABCI application changes
  13. New ABCI methods (`ListSnapshots`, `LoadSnapshotChunk`, `OfferSnapshot`, and
  14. `ApplySnapshotChunk`) were added for the highly anticipated state sync feature.
  15. With it, new nodes are able to join the network in a matter of seconds. Read
  16. [the spec](https://docs.tendermint.com/master/spec/abci/apps.html#state-sync)
  17. if you want to learn more & support it (with cosmos-sdk you get it
  18. automatically). If you don't want to support it, just leave these methods
  19. empty.
  20. `KV.Pair` has been replaced with `abci.EventAttribute`. `EventAttribute.Index`
  21. field allows ABCI applications to dictate which events should be indexed.
  22. ### P2P Protocol
  23. The default codec is now proto3, not amino. Check out the [TODO]() for
  24. motivation behind this change. The schema files can be found in the `/proto`
  25. directory. In the future we're considering using gRPC for the remote private
  26. validator and ABCI
  27. ([\#4698](https://github.com/tendermint/tendermint/issues/4698)).
  28. ### Blockchain Protocol
  29. `Header#LastResultsHash`, which previously was the root hash of a Merkle tree
  30. built from `ResponseDeliverTx(Code, Data)` responses, became the root hash of a
  31. Merkle tree built from:
  32. - `BeginBlock#Events`;
  33. - root hash of a Merkle tree built from `ResponseDeliverTx(Code, Data,
  34. GasWanted, GasUsed, Events)` responses;
  35. - `BeginBlock#Events`.
  36. ### Tx Indexing
  37. - Tendermint will now rely on the application entirely to tell it what txs to index. This means that in the `config.toml`,
  38. generated by Tendermint, there will not be a way to specify which txs to index. `tx.height` & `tx.hash` will always be indexed when using the `kv` indexer.
  39. The application will need to decide if they would like to allow the node operator to decide what to index or if it will enable
  40. indexing for all txs. Application's can notify Tendermint to index a specific tx by setting `Index: bool` to true in the Event Attribute.
  41. ```go
  42. []types.Event{
  43. {
  44. Type: "app",
  45. Attributes: []types.EventAttribute{
  46. {Key: []byte("creator"), Value: []byte("Cosmoshi Netowoko"), Index: true},
  47. },
  48. },
  49. }
  50. ```
  51. ### Protobuf
  52. With this release we are happy to announce the full protobuf migration of the Tendermint repo. This consists of changes that you may need to be aware of:
  53. - All proto files have been moved under one directory, `/proto`. This is in line with the recommended file layout by [buf](https://buf.build), you can read more about it [here](https://buf.build/docs/lint-checkers#file_layout)
  54. - We use the generated protobuf types for only on disk and over the wire serialization. This means that these changes should not effect you as user of Tendermint.
  55. - A few notable changes in the abci:
  56. - In `ValidatorUpdates` the public key type has been migrated to a protobuf `oneof` type. Since Tendermint only supports ed25519 validator keys this is the only available key in the oneof.
  57. ### Consensus Params
  58. Various parameters have been added to the consensus parameters.
  59. #### Version Params (New)
  60. - `AppVersion` - this contains the ABCI application version
  61. #### Evidence Params
  62. - `MaxNum` - cap the total amount of evidence by a absolute number (Default: 50)
  63. - `ProofTrialPeriod` - duration (blocks) in which a node has to provide proof of correctly executing a lock change in the event of amnesia evidence (Default: 50000, half MaxAgeNumBlocks)
  64. ### Crypto
  65. #### Keys
  66. All keys have removed there type prefix. Ed25519 Pubkey went from `PubKeyEd25519` to `PubKey`. This way when calling the key you are not duplicating information (`ed25519.PubKey`). All keys are now slice of bytes(`[]byte`), previously they were a array of bytes (`[<size>]byte`).
  67. The multisig that was previously located in Tendermint has now migrated to a new home within the [Cosmos-SDK](https://github.com/cosmos/cosmos-sdk/blob/master/crypto/types/multisig/multisignature.go).
  68. #### Merkle
  69. From the merkle package `SimpleHashFromMap()` and `SimpleProofsFromMap()` were removed along with all the prefixes of `Simple`. If you are looking for `SimpleProof` it has been renamed to `Proof` within the merkle pkg. Previously there were protobuf messages located in the merkle pkg, these have since been moved to the `/proto` directory. The protobuf message `Proof` that contained multiple ProofOp's has been renamed to `ProofOps`. This change effects the ABCI type `ResponseQuery`, the field that was named Proof is now named `ProofOps`.
  70. ### Libs
  71. The Bech32 pkg has been migrated to a new home, you can find it in the [Cosmos-SDK](https://github.com/cosmos/cosmos-sdk/tree/4173ea5ebad906dd9b45325bed69b9c655504867/types/bech32)
  72. ### CLI
  73. `tendermint lite` has been renamed `tendermint light` and has a slightly different API.
  74. Check out [the docs](https://docs.tendermint.com/master/tendermint-core/light-client-protocol.html#http-proxy) for details.
  75. ### Light client
  76. The old `lite` package is removed in favor of the new `light` package. Check
  77. out [this
  78. article](https://medium.com/tendermint/everything-you-need-to-know-about-the-tendermint-light-client-f80d03856f98)
  79. if you want to learn why the rewrite was needed and what comprise the new light
  80. client.
  81. Doc: https://pkg.go.dev/github.com/tendermint/tendermint/lite2?tab=doc
  82. `Verifier` was broken up in two pieces: core verification logic (pure `VerifyX`
  83. functions) and `Client` object, which represents the complete light client.
  84. RPC client can be found in `/rpc` directory. HTTP(S) proxy is located in
  85. `/proxy` directory.
  86. ## v0.33.4
  87. ### Go API
  88. - `rpc/client` HTTP and local clients have been moved into `http` and `local`
  89. subpackages, and their constructors have been renamed to `New()`.
  90. ### Protobuf Changes
  91. When upgrading to version 0.33.4 you will have to fetch the `third_party`
  92. directory along with the updated proto files.
  93. ## v0.33.0
  94. This release is not compatible with previous blockchains due to commit becoming
  95. signatures only and fields in the header have been removed.
  96. ### Blockchain Protocol
  97. `TotalTxs` and `NumTxs` were removed from the header. `Commit` now consists
  98. mostly of just signatures.
  99. ```go
  100. type Commit struct {
  101. Height int64
  102. Round int
  103. BlockID BlockID
  104. Signatures []CommitSig
  105. }
  106. ```
  107. ```go
  108. type BlockIDFlag byte
  109. const (
  110. // BlockIDFlagAbsent - no vote was received from a validator.
  111. BlockIDFlagAbsent BlockIDFlag = 0x01
  112. // BlockIDFlagCommit - voted for the Commit.BlockID.
  113. BlockIDFlagCommit = 0x02
  114. // BlockIDFlagNil - voted for nil.
  115. BlockIDFlagNil = 0x03
  116. )
  117. type CommitSig struct {
  118. BlockIDFlag BlockIDFlag
  119. ValidatorAddress Address
  120. Timestamp time.Time
  121. Signature []byte
  122. }
  123. ```
  124. See [\#63](https://github.com/tendermint/spec/pull/63) for the complete spec
  125. change.
  126. ### P2P Protocol
  127. The secret connection now includes a transcript hashing. If you want to
  128. implement a handshake (or otherwise have an existing implementation), you'll
  129. need to make the same changes that were made
  130. [here](https://github.com/tendermint/tendermint/pull/3668).
  131. ### Config Changes
  132. You will need to generate a new config if you have used a prior version of tendermint.
  133. Tags have been entirely renamed throughout the codebase to events and there
  134. keys are called
  135. [compositeKeys](https://github.com/tendermint/tendermint/blob/6d05c531f7efef6f0619155cf10ae8557dd7832f/docs/app-dev/indexing-transactions.md).
  136. Evidence Params has been changed to include duration.
  137. - `consensus_params.evidence.max_age_duration`.
  138. - Renamed `consensus_params.evidence.max_age` to `max_age_num_blocks`.
  139. ### Go API
  140. - `libs/common` has been removed in favor of specific pkgs.
  141. - `async`
  142. - `service`
  143. - `rand`
  144. - `net`
  145. - `strings`
  146. - `cmap`
  147. - removal of `errors` pkg
  148. ### RPC Changes
  149. - `/validators` is now paginated (default: 30 vals per page)
  150. - `/block_results` response format updated [see RPC docs for details](https://docs.tendermint.com/master/rpc/#/Info/block_results)
  151. - Event suffix has been removed from the ID in event responses
  152. - IDs are now integers not `json-client-XYZ`
  153. ## v0.32.0
  154. This release is compatible with previous blockchains,
  155. however the new ABCI Events mechanism may create some complexity
  156. for nodes wishing to continue operation with v0.32 from a previous version.
  157. There are some minor breaking changes to the RPC.
  158. ### Config Changes
  159. If you have `db_backend` set to `leveldb` in your config file, please change it
  160. to `goleveldb` or `cleveldb`.
  161. ### RPC Changes
  162. The default listen address for the RPC is now `127.0.0.1`. If you want to expose
  163. it publicly, you have to explicitly configure it. Note exposing the RPC to the
  164. public internet may not be safe - endpoints which return a lot of data may
  165. enable resource exhaustion attacks on your node, causing the process to crash.
  166. Any consumers of `/block_results` need to be mindful of the change in all field
  167. names from CamelCase to Snake case, eg. `results.DeliverTx` is now `results.deliver_tx`.
  168. This is a fix, but it's breaking.
  169. ### ABCI Changes
  170. ABCI responses which previously had a `Tags` field now have an `Events` field
  171. instead. The original `Tags` field was simply a list of key-value pairs, where
  172. each key effectively represented some attribute of an event occuring in the
  173. blockchain, like `sender`, `receiver`, or `amount`. However, it was difficult to
  174. represent the occurence of multiple events (for instance, multiple transfers) in a single list.
  175. The new `Events` field contains a list of `Event`, where each `Event` is itself a list
  176. of key-value pairs, allowing for more natural expression of multiple events in
  177. eg. a single DeliverTx or EndBlock. Note each `Event` also includes a `Type`, which is meant to categorize the
  178. event.
  179. For transaction indexing, the index key is
  180. prefixed with the event type: `{eventType}.{attributeKey}`.
  181. If the same event type and attribute key appear multiple times, the values are
  182. appended in a list.
  183. To make queries, include the event type as a prefix. For instance if you
  184. previously queried for `recipient = 'XYZ'`, and after the upgrade you name your event `transfer`,
  185. the new query would be for `transfer.recipient = 'XYZ'`.
  186. Note that transactions indexed on a node before upgrading to v0.32 will still be indexed
  187. using the old scheme. For instance, if a node upgraded at height 100,
  188. transactions before 100 would be queried with `recipient = 'XYZ'` and
  189. transactions after 100 would be queried with `transfer.recipient = 'XYZ'`.
  190. While this presents additional complexity to clients, it avoids the need to
  191. reindex. Of course, you can reset the node and sync from scratch to re-index
  192. entirely using the new scheme.
  193. We illustrate further with a more complete example.
  194. Prior to the update, suppose your `ResponseDeliverTx` look like:
  195. ```go
  196. abci.ResponseDeliverTx{
  197. Tags: []kv.Pair{
  198. {Key: []byte("sender"), Value: []byte("foo")},
  199. {Key: []byte("recipient"), Value: []byte("bar")},
  200. {Key: []byte("amount"), Value: []byte("35")},
  201. }
  202. }
  203. ```
  204. The following queries would match this transaction:
  205. ```go
  206. query.MustParse("tm.event = 'Tx' AND sender = 'foo'")
  207. query.MustParse("tm.event = 'Tx' AND recipient = 'bar'")
  208. query.MustParse("tm.event = 'Tx' AND sender = 'foo' AND recipient = 'bar'")
  209. ```
  210. Following the upgrade, your `ResponseDeliverTx` would look something like:
  211. the following `Events`:
  212. ```go
  213. abci.ResponseDeliverTx{
  214. Events: []abci.Event{
  215. {
  216. Type: "transfer",
  217. Attributes: kv.Pairs{
  218. {Key: []byte("sender"), Value: []byte("foo")},
  219. {Key: []byte("recipient"), Value: []byte("bar")},
  220. {Key: []byte("amount"), Value: []byte("35")},
  221. },
  222. }
  223. }
  224. ```
  225. Now the following queries would match this transaction:
  226. ```go
  227. query.MustParse("tm.event = 'Tx' AND transfer.sender = 'foo'")
  228. query.MustParse("tm.event = 'Tx' AND transfer.recipient = 'bar'")
  229. query.MustParse("tm.event = 'Tx' AND transfer.sender = 'foo' AND transfer.recipient = 'bar'")
  230. ```
  231. For further documentation on `Events`, see the [docs](https://github.com/tendermint/tendermint/blob/60827f75623b92eff132dc0eff5b49d2025c591e/docs/spec/abci/abci.md#events).
  232. ### Go Applications
  233. The ABCI Application interface changed slightly so the CheckTx and DeliverTx
  234. methods now take Request structs. The contents of these structs are just the raw
  235. tx bytes, which were previously passed in as the argument.
  236. ## v0.31.6
  237. There are no breaking changes in this release except Go API of p2p and
  238. mempool packages. Hovewer, if you're using cleveldb, you'll need to change
  239. the compilation tag:
  240. Use `cleveldb` tag instead of `gcc` to compile Tendermint with CLevelDB or
  241. use `make build_c` / `make install_c` (full instructions can be found at
  242. https://tendermint.com/docs/introduction/install.html#compile-with-cleveldb-support)
  243. ## v0.31.0
  244. This release contains a breaking change to the behaviour of the pubsub system.
  245. It also contains some minor breaking changes in the Go API and ABCI.
  246. There are no changes to the block or p2p protocols, so v0.31.0 should work fine
  247. with blockchains created from the v0.30 series.
  248. ### RPC
  249. The pubsub no longer blocks on publishing. This may cause some WebSocket (WS) clients to stop working as expected.
  250. If your WS client is not consuming events fast enough, Tendermint can terminate the subscription.
  251. In this case, the WS client will receive an error with description:
  252. ```json
  253. {
  254. "jsonrpc": "2.0",
  255. "id": "{ID}#event",
  256. "error": {
  257. "code": -32000,
  258. "msg": "Server error",
  259. "data": "subscription was cancelled (reason: client is not pulling messages fast enough)" // or "subscription was cancelled (reason: Tendermint exited)"
  260. }
  261. }
  262. Additionally, there are now limits on the number of subscribers and
  263. subscriptions that can be active at once. See the new
  264. `rpc.max_subscription_clients` and `rpc.max_subscriptions_per_client` values to
  265. configure this.
  266. ```
  267. ### Applications
  268. Simple rename of `ConsensusParams.BlockSize` to `ConsensusParams.Block`.
  269. The `ConsensusParams.Block.TimeIotaMS` field was also removed. It's configured
  270. in the ConsensusParsm in genesis.
  271. ### Go API
  272. See the [CHANGELOG](CHANGELOG.md). These are relatively straight forward.
  273. ## v0.30.0
  274. This release contains a breaking change to both the block and p2p protocols,
  275. however it may be compatible with blockchains created with v0.29.0 depending on
  276. the chain history. If your blockchain has not included any pieces of evidence,
  277. or no piece of evidence has been included in more than one block,
  278. and if your application has never returned multiple updates
  279. for the same validator in a single block, then v0.30.0 will work fine with
  280. blockchains created with v0.29.0.
  281. The p2p protocol change is to fix the proposer selection algorithm again.
  282. Note that proposer selection is purely a p2p concern right
  283. now since the algorithm is only relevant during real time consensus.
  284. This change is thus compatible with v0.29.0, but
  285. all nodes must be upgraded to avoid disagreements on the proposer.
  286. ### Applications
  287. Applications must ensure they do not return duplicates in
  288. `ResponseEndBlock.ValidatorUpdates`. A pubkey must only appear once per set of
  289. updates. Duplicates will cause irrecoverable failure. If you have a very good
  290. reason why we shouldn't do this, please open an issue.
  291. ## v0.29.0
  292. This release contains some breaking changes to the block and p2p protocols,
  293. and will not be compatible with any previous versions of the software, primarily
  294. due to changes in how various data structures are hashed.
  295. Any implementations of Tendermint blockchain verification, including lite clients,
  296. will need to be updated. For specific details:
  297. - [Merkle tree](https://github.com/tendermint/spec/blob/master/spec/blockchain/encoding.md#merkle-trees)
  298. - [ConsensusParams](https://github.com/tendermint/spec/blob/master/spec/blockchain/state.md#consensusparams)
  299. There was also a small change to field ordering in the vote struct. Any
  300. implementations of an out-of-process validator (like a Key-Management Server)
  301. will need to be updated. For specific details:
  302. - [Vote](https://github.com/tendermint/spec/blob/master/spec/consensus/signing.md#votes)
  303. Finally, the proposer selection algorithm continues to evolve. See the
  304. [work-in-progress
  305. specification](https://github.com/tendermint/tendermint/pull/3140).
  306. For everything else, please see the [CHANGELOG](./CHANGELOG.md#v0.29.0).
  307. ## v0.28.0
  308. This release breaks the format for the `priv_validator.json` file
  309. and the protocol used for the external validator process.
  310. It is compatible with v0.27.0 blockchains (neither the BlockProtocol nor the
  311. P2PProtocol have changed).
  312. Please read carefully for details about upgrading.
  313. **Note:** Backup your `config/priv_validator.json`
  314. before proceeding.
  315. ### `priv_validator.json`
  316. The `config/priv_validator.json` is now two files:
  317. `config/priv_validator_key.json` and `data/priv_validator_state.json`.
  318. The former contains the key material, the later contains the details on the last
  319. message signed.
  320. When running v0.28.0 for the first time, it will back up any pre-existing
  321. `priv_validator.json` file and proceed to split it into the two new files.
  322. Upgrading should happen automatically without problem.
  323. To upgrade manually, use the provided `privValUpgrade.go` script, with exact paths for the old
  324. `priv_validator.json` and the locations for the two new files. It's recomended
  325. to use the default paths, of `config/priv_validator_key.json` and
  326. `data/priv_validator_state.json`, respectively:
  327. ```
  328. go run scripts/privValUpgrade.go <old-path> <new-key-path> <new-state-path>
  329. ```
  330. ### External validator signers
  331. The Unix and TCP implementations of the remote signing validator
  332. have been consolidated into a single implementation.
  333. Thus in both cases, the external process is expected to dial
  334. Tendermint. This is different from how Unix sockets used to work, where
  335. Tendermint dialed the external process.
  336. The `PubKeyMsg` was also split into separate `Request` and `Response` types
  337. for consistency with other messages.
  338. Note that the TCP sockets don't yet use a persistent key,
  339. so while they're encrypted, they can't yet be properly authenticated.
  340. See [#3105](https://github.com/tendermint/tendermint/issues/3105).
  341. Note the Unix socket has neither encryption nor authentication, but will
  342. add a shared-secret in [#3099](https://github.com/tendermint/tendermint/issues/3099).
  343. ## v0.27.0
  344. This release contains some breaking changes to the block and p2p protocols,
  345. but does not change any core data structures, so it should be compatible with
  346. existing blockchains from the v0.26 series that only used Ed25519 validator keys.
  347. Blockchains using Secp256k1 for validators will not be compatible. This is due
  348. to the fact that we now enforce which key types validators can use as a
  349. consensus param. The default is Ed25519, and Secp256k1 must be activated
  350. explicitly.
  351. It is recommended to upgrade all nodes at once to avoid incompatibilities at the
  352. peer layer - namely, the heartbeat consensus message has been removed (only
  353. relevant if `create_empty_blocks=false` or `create_empty_blocks_interval > 0`),
  354. and the proposer selection algorithm has changed. Since proposer information is
  355. never included in the blockchain, this change only affects the peer layer.
  356. ### Go API Changes
  357. #### libs/db
  358. The ReverseIterator API has changed the meaning of `start` and `end`.
  359. Before, iteration was from `start` to `end`, where
  360. `start > end`. Now, iteration is from `end` to `start`, where `start < end`.
  361. The iterator also excludes `end`. This change allows a simplified and more
  362. intuitive logic, aligning the semantic meaning of `start` and `end` in the
  363. `Iterator` and `ReverseIterator`.
  364. ### Applications
  365. This release enforces a new consensus parameter, the
  366. ValidatorParams.PubKeyTypes. Applications must ensure that they only return
  367. validator updates with the allowed PubKeyTypes. If a validator update includes a
  368. pubkey type that is not included in the ConsensusParams.Validator.PubKeyTypes,
  369. block execution will fail and the consensus will halt.
  370. By default, only Ed25519 pubkeys may be used for validators. Enabling
  371. Secp256k1 requires explicit modification of the ConsensusParams.
  372. Please update your application accordingly (ie. restrict validators to only be
  373. able to use Ed25519 keys, or explicitly add additional key types to the genesis
  374. file).
  375. ## v0.26.0
  376. This release contains a lot of changes to core data types and protocols. It is not
  377. compatible to the old versions and there is no straight forward way to update
  378. old data to be compatible with the new version.
  379. To reset the state do:
  380. ```
  381. $ tendermint unsafe_reset_all
  382. ```
  383. Here we summarize some other notable changes to be mindful of.
  384. ### Config Changes
  385. All timeouts must be changed from integers to strings with their duration, for
  386. instance `flush_throttle_timeout = 100` would be changed to
  387. `flush_throttle_timeout = "100ms"` and `timeout_propose = 3000` would be changed
  388. to `timeout_propose = "3s"`.
  389. ### RPC Changes
  390. The default behaviour of `/abci_query` has been changed to not return a proof,
  391. and the name of the parameter that controls this has been changed from `trusted`
  392. to `prove`. To get proofs with your queries, ensure you set `prove=true`.
  393. Various version fields like `amino_version`, `p2p_version`, `consensus_version`,
  394. and `rpc_version` have been removed from the `node_info.other` and are
  395. consolidated under the tendermint semantic version (ie. `node_info.version`) and
  396. the new `block` and `p2p` protocol versions under `node_info.protocol_version`.
  397. ### ABCI Changes
  398. Field numbers were bumped in the `Header` and `ResponseInfo` messages to make
  399. room for new `version` fields. It should be straight forward to recompile the
  400. protobuf file for these changes.
  401. #### Proofs
  402. The `ResponseQuery.Proof` field is now structured as a `[]ProofOp` to support
  403. generalized Merkle tree constructions where the leaves of one Merkle tree are
  404. the root of another. If you don't need this functionality, and you used to
  405. return `<proof bytes>` here, you should instead return a single `ProofOp` with
  406. just the `Data` field set:
  407. ```
  408. []ProofOp{
  409. ProofOp{
  410. Data: <proof bytes>,
  411. }
  412. }
  413. ```
  414. For more information, see:
  415. - [ADR-026](https://github.com/tendermint/tendermint/blob/30519e8361c19f4bf320ef4d26288ebc621ad725/docs/architecture/adr-026-general-merkle-proof.md)
  416. - [Relevant ABCI
  417. documentation](https://github.com/tendermint/tendermint/blob/30519e8361c19f4bf320ef4d26288ebc621ad725/docs/spec/abci/apps.md#query-proofs)
  418. - [Description of
  419. keys](https://github.com/tendermint/tendermint/blob/30519e8361c19f4bf320ef4d26288ebc621ad725/crypto/merkle/proof_key_path.go#L14)
  420. ### Go API Changes
  421. #### crypto/merkle
  422. The `merkle.Hasher` interface was removed. Functions which used to take `Hasher`
  423. now simply take `[]byte`. This means that any objects being Merklized should be
  424. serialized before they are passed in.
  425. #### node
  426. The `node.RunForever` function was removed. Signal handling and running forever
  427. should instead be explicitly configured by the caller. See how we do it
  428. [here](https://github.com/tendermint/tendermint/blob/30519e8361c19f4bf320ef4d26288ebc621ad725/cmd/tendermint/commands/run_node.go#L60).
  429. ### Other
  430. All hashes, except for public key addresses, are now 32-bytes.
  431. ## v0.25.0
  432. This release has minimal impact.
  433. If you use GasWanted in ABCI and want to enforce it, set the MaxGas in the genesis file (default is no max).
  434. ## v0.24.0
  435. New 0.24.0 release contains a lot of changes to the state and types. It's not
  436. compatible to the old versions and there is no straight forward way to update
  437. old data to be compatible with the new version.
  438. To reset the state do:
  439. ```
  440. $ tendermint unsafe_reset_all
  441. ```
  442. Here we summarize some other notable changes to be mindful of.
  443. ### Config changes
  444. `p2p.max_num_peers` was removed in favor of `p2p.max_num_inbound_peers` and
  445. `p2p.max_num_outbound_peers`.
  446. ```
  447. # Maximum number of inbound peers
  448. max_num_inbound_peers = 40
  449. # Maximum number of outbound peers to connect to, excluding persistent peers
  450. max_num_outbound_peers = 10
  451. ```
  452. As you can see, the default ratio of inbound/outbound peers is 4/1. The reason
  453. is we want it to be easier for new nodes to connect to the network. You can
  454. tweak these parameters to alter the network topology.
  455. ### RPC Changes
  456. The result of `/commit` used to contain `header` and `commit` fields at the top level. These are now contained under the `signed_header` field.
  457. ### ABCI Changes
  458. The header has been upgraded and contains new fields, but none of the existing
  459. fields were changed, except their order.
  460. The `Validator` type was split into two, one containing an `Address` and one
  461. containing a `PubKey`. When processing `RequestBeginBlock`, use the `Validator`
  462. type, which contains just the `Address`. When returning `ResponseEndBlock`, use
  463. the `ValidatorUpdate` type, which contains just the `PubKey`.
  464. ### Validator Set Updates
  465. Validator set updates returned in ResponseEndBlock for height `H` used to take
  466. effect immediately at height `H+1`. Now they will be delayed one block, to take
  467. effect at height `H+2`. Note this means that the change will be seen by the ABCI
  468. app in the `RequestBeginBlock.LastCommitInfo` at block `H+3`. Apps were already
  469. required to maintain a map from validator addresses to pubkeys since v0.23 (when
  470. pubkeys were removed from RequestBeginBlock), but now they may need to track
  471. multiple validator sets at once to accomodate this delay.
  472. ### Block Size
  473. The `ConsensusParams.BlockSize.MaxTxs` was removed in favour of
  474. `ConsensusParams.BlockSize.MaxBytes`, which is now enforced. This means blocks
  475. are limitted only by byte-size, not by number of transactions.