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.

1005 lines
39 KiB

  1. # Upgrading Tendermint Core
  2. This guide provides instructions for upgrading to specific versions of Tendermint Core.
  3. ## v0.36
  4. ### ABCI Changes
  5. #### ABCI++
  6. Coming soon...
  7. #### ABCI Mutex
  8. In previous versions of ABCI, Tendermint was prevented from making
  9. concurrent calls to ABCI implementations by virtue of mutexes in the
  10. implementation of Tendermint's ABCI infrastructure. These mutexes have
  11. been removed from the current implementation and applications will now
  12. be responsible for managing their own concurrency control.
  13. To replicate the prior semantics, ensure that ABCI applications have a
  14. single mutex that protects all ABCI method calls from concurrent
  15. access. You can relax these requirements if your application can
  16. provide safe concurrent access via other means. This safety is an
  17. application concern so be very sure to test the application thoroughly
  18. using realistic workloads and the race detector to ensure your
  19. applications remains correct.
  20. ### RPC Changes
  21. Tendermint v0.36 adds a new RPC event subscription API. The existing event
  22. subscription API based on websockets is now deprecated. It will continue to
  23. work throughout the v0.36 release, but the `subscribe`, `unsubscribe`, and
  24. `unsubscribe_all` methods, along with websocket support, will be removed in
  25. Tendermint v0.37. Callers currently using these features should migrate as
  26. soon as is practical to the new API.
  27. To enable the new API, node operators set a new `event-log-window-size`
  28. parameter in the `[rpc]` section of the `config.toml` file. This defines a
  29. duration of time during which the node will log all events published to the
  30. event bus for use by RPC consumers.
  31. Consumers use the new `events` JSON-RPC method to poll for events matching
  32. their query in the log. Unlike the streaming API, events are not discarded if
  33. the caller is slow, loses its connection, or crashes. As long as the client
  34. recovers before its events expire from the log window, it will be able to
  35. replay and catch up after recovering. Also unlike the streaming API, the client
  36. can tell if it has truly missed events because they have expired from the log.
  37. The `events` method is a normal JSON-RPC method, and does not require any
  38. non-standard response processing (in contrast with the old `subscribe`).
  39. Clients can modify their query at any time, and no longer need to coordinate
  40. subscribe and unsubscribe calls to handle multiple queries.
  41. The Go client implementations in the Tendermint Core repository have all been
  42. updated to add a new `Events` method, including the light client proxy.
  43. A new `rpc/client/eventstream` package has also been added to make it easier
  44. for users to update existing use of the streaming API to use the polling API
  45. The `eventstream` package handles polling and delivers matching events to a
  46. callback.
  47. For more detailed information, see [ADR 075](https://tinyurl.com/adr075) which
  48. defines and describes the new API in detail.
  49. ## v0.35
  50. ### ABCI Changes
  51. * Added `AbciVersion` to `RequestInfo`. Applications should check that the ABCI version they expect is being used in order to avoid unimplemented changes errors.
  52. * The method `SetOption` has been removed from the ABCI.Client interface. This feature was used in the early ABCI implementation's.
  53. * Messages are written to a byte stream using uin64 length delimiters instead of int64.
  54. * When mempool `v1` is enabled, transactions broadcasted via `sync` mode may return a successful
  55. response with a transaction hash indicating that the transaction was successfully inserted into
  56. the mempool. While this is true for `v0`, the `v1` mempool reactor may at a later point in time
  57. evict or even drop this transaction after a hash has been returned. Thus, the user or client must
  58. query for that transaction to check if it is still in the mempool.
  59. ### Config Changes
  60. * The configuration file field `[fastsync]` has been renamed to `[blocksync]`.
  61. * The top level configuration file field `fast-sync` has moved under the new `[blocksync]`
  62. field as `blocksync.enable`.
  63. * `blocksync.version = "v1"` and `blocksync.version = "v2"` (previously `fastsync`)
  64. are no longer supported. Please use `v0` instead. During the v0.35 release cycle, `v0` was
  65. determined to suit the existing needs and the cost of maintaining the `v1` and `v2` modules
  66. was determined to be greater than necessary.
  67. * All config parameters are now hyphen-case (also known as kebab-case) instead of snake_case. Before restarting the node make sure
  68. you have updated all the variables in your `config.toml` file.
  69. * Added `--mode` flag and `mode` config variable on `config.toml` for setting Mode of the Node: `full` | `validator` | `seed` (default: `full`)
  70. [ADR-52](https://github.com/tendermint/tendermint/blob/master/docs/architecture/adr-052-tendermint-mode.md)
  71. * `BootstrapPeers` has been added as part of the new p2p stack. This will eventually replace
  72. `Seeds`. Bootstrap peers are connected with on startup if needed for peer discovery. Unlike
  73. persistent peers, there's no gaurantee that the node will remain connected with these peers.
  74. * configuration values starting with `priv-validator-` have moved to the new
  75. `priv-validator` section, without the `priv-validator-` prefix.
  76. * The fast sync process as well as the blockchain package and service has all
  77. been renamed to block sync
  78. ### Database Key Format Changes
  79. The format of all tendermint on-disk database keys changes in
  80. 0.35. Upgrading nodes must either re-sync all data or run a migration
  81. script provided in this release. The script located in
  82. `github.com/tendermint/tendermint/scripts/keymigrate/migrate.go`
  83. provides the function `Migrate(context.Context, db.DB)` which you can
  84. operationalize as makes sense for your deployment.
  85. For ease of use the `tendermint` command includes a CLI version of the
  86. migration script, which you can invoke, as in:
  87. tendermint key-migrate
  88. This reads the configuration file as normal and allows the
  89. `--db-backend` and `--db-dir` flags to change database operations as
  90. needed.
  91. The migration operation is idempotent and can be run more than once,
  92. if needed.
  93. ### CLI Changes
  94. * You must now specify the node mode (validator|full|seed) in `tendermint init [mode]`
  95. * The `--fast-sync` command line option has been renamed to `--blocksync.enable`
  96. * If you had previously used `tendermint gen_node_key` to generate a new node
  97. key, keep in mind that it no longer saves the output to a file. You can use
  98. `tendermint init validator` or pipe the output of `tendermint gen_node_key` to
  99. `$TMHOME/config/node_key.json`:
  100. ```
  101. $ tendermint gen_node_key > $TMHOME/config/node_key.json
  102. ```
  103. * CLI commands and flags are all now hyphen-case instead of snake_case.
  104. Make sure to adjust any scripts that calls a cli command with snake_casing
  105. ### API Changes
  106. The p2p layer was reimplemented as part of the 0.35 release cycle and
  107. all reactors were refactored to accomodate the change. As part of that work these
  108. implementations moved into the `internal` package and are no longer
  109. considered part of the public Go API of tendermint. These packages
  110. are:
  111. - `p2p`
  112. - `mempool`
  113. - `consensus`
  114. - `statesync`
  115. - `blockchain`
  116. - `evidence`
  117. Accordingly, the `node` package changed to reduce access to
  118. tendermint internals: applications that use tendermint as a library
  119. will need to change to accommodate these changes. Most notably:
  120. - The `Node` type has become internal, and all constructors return a
  121. `service.Service` implementation.
  122. - The `node.DefaultNewNode` and `node.NewNode` constructors are no
  123. longer exported and have been replaced with `node.New` and
  124. `node.NewDefault` which provide more functional interfaces.
  125. To access any of the functionality previously available via the
  126. `node.Node` type, use the `*local.Local` "RPC" client, that exposes
  127. the full RPC interface provided as direct function calls. Import the
  128. `github.com/tendermint/tendermint/rpc/client/local` package and pass
  129. the node service as in the following:
  130. ```go
  131. node := node.NewDefault() //construct the node object
  132. // start and set up the node service
  133. client := local.New(node.(local.NodeService))
  134. // use client object to interact with the node
  135. ```
  136. ### gRPC Support
  137. Mark gRPC in the RPC layer as deprecated and to be removed in 0.36.
  138. ### Peer Management Interface
  139. When running with the new P2P Layer, the methods `UnsafeDialSeeds` and
  140. `UnsafeDialPeers` RPC methods will always return an error. They are
  141. deprecated and will be removed in 0.36 when the legacy peer stack is
  142. removed.
  143. Additionally the format of the Peer list returned in the `NetInfo`
  144. method changes in this release to accommodate the different way that
  145. the new stack tracks data about peers. This change affects users of
  146. both stacks.
  147. ### Using the updated p2p library
  148. The P2P library was reimplemented in this release. The new implementation is
  149. enabled by default in this version of Tendermint. The legacy implementation is still
  150. included in this version of Tendermint as a backstop to work around unforeseen
  151. production issues. The new and legacy version are interoperable. If necessary,
  152. you can enable the legacy implementation in the server configuration file.
  153. To make use of the legacy P2P implemementation add or update the following field of
  154. your server's configuration file under the `[p2p]` section:
  155. ```toml
  156. [p2p]
  157. ...
  158. use-legacy = true
  159. ...
  160. ```
  161. If you need to do this, please consider filing an issue in the Tendermint repository
  162. to let us know why. We plan to remove the legacy P2P code in the next (v0.36) release.
  163. #### New p2p queue types
  164. The new p2p implementation enables selection of the queue type to be used for
  165. passing messages between peers.
  166. The following values may be used when selecting which queue type to use:
  167. * `fifo`: (**default**) An unbuffered and lossless queue that passes messages through
  168. in the order in which they were received.
  169. * `priority`: A priority queue of messages.
  170. * `wdrr`: A queue implementing the Weighted Deficit Round Robin algorithm. A
  171. weighted deficit round robin queue is created per peer. Each queue contains a
  172. separate 'flow' for each of the channels of communication that exist between any two
  173. peers. Tendermint maintains a channel per message type between peers. Each WDRR
  174. queue maintains a shared buffered with a fixed capacity through which messages on different
  175. flows are passed.
  176. For more information on WDRR scheduling, see: https://en.wikipedia.org/wiki/Deficit_round_robin
  177. To select a queue type, add or update the following field under the `[p2p]`
  178. section of your server's configuration file.
  179. ```toml
  180. [p2p]
  181. ...
  182. queue-type = wdrr
  183. ...
  184. ```
  185. ### Support for Custom Reactor and Mempool Implementations
  186. The changes to p2p layer removed existing support for custom
  187. reactors. Based on our understanding of how this functionality was
  188. used, the introduction of the prioritized mempool covers nearly all of
  189. the use cases for custom reactors. If you are currently running custom
  190. reactors and mempools and are having trouble seeing the migration path
  191. for your project please feel free to reach out to the Tendermint Core
  192. development team directly.
  193. ## v0.34.0
  194. **Upgrading to Tendermint 0.34 requires a blockchain restart.**
  195. This release is not compatible with previous blockchains due to changes to
  196. the encoding format (see "Protocol Buffers," below) and the block header (see "Blockchain Protocol").
  197. Note also that Tendermint 0.34 also requires Go 1.16 or higher.
  198. ### ABCI Changes
  199. * The `ABCIVersion` is now `0.17.0`.
  200. * New ABCI methods (`ListSnapshots`, `LoadSnapshotChunk`, `OfferSnapshot`, and `ApplySnapshotChunk`)
  201. were added to support the new State Sync feature.
  202. Previously, syncing a new node to a preexisting network could take days; but with State Sync,
  203. new nodes are able to join a network in a matter of seconds.
  204. Read [the spec](https://github.com/tendermint/tendermint/blob/master/spec/abci/apps.md)
  205. if you want to learn more about State Sync, or if you'd like your application to use it.
  206. (If you don't want to support State Sync in your application, you can just implement these new
  207. ABCI methods as no-ops, leaving them empty.)
  208. * `KV.Pair` has been replaced with `abci.EventAttribute`. The `EventAttribute.Index` field
  209. allows ABCI applications to dictate which events should be indexed.
  210. * The blockchain can now start from an arbitrary initial height,
  211. provided to the application via `RequestInitChain.InitialHeight`.
  212. * ABCI evidence type is now an enum with two recognized types of evidence:
  213. `DUPLICATE_VOTE` and `LIGHT_CLIENT_ATTACK`.
  214. Applications should be able to handle these evidence types
  215. (i.e., through slashing or other accountability measures).
  216. * The [`PublicKey` type](https://github.com/tendermint/tendermint/blob/master/proto/tendermint/crypto/keys.proto#L13-L15)
  217. (used in ABCI as part of `ValidatorUpdate`) now uses a `oneof` protobuf type.
  218. Note that since Tendermint only supports ed25519 validator keys, there's only one
  219. option in the `oneof`. For more, see "Protocol Buffers," below.
  220. * The field `Proof`, on the ABCI type `ResponseQuery`, is now named `ProofOps`.
  221. For more, see "Crypto," below.
  222. * The method `SetOption` has been removed from the ABCI.Client interface. This feature was used in the early ABCI implementation's.
  223. ### P2P Protocol
  224. The default codec is now proto3, not amino. The schema files can be found in the `/proto`
  225. directory. For more, see "Protobuf," below.
  226. ### Blockchain Protocol
  227. * `Header#LastResultsHash`, which is the root hash of a Merkle tree built from
  228. `ResponseDeliverTx(Code, Data)` as of v0.34 also includes `GasWanted` and `GasUsed`
  229. fields.
  230. * Merkle hashes of empty trees previously returned nothing, but now return the hash of an empty input,
  231. to conform with [RFC-6962](https://tools.ietf.org/html/rfc6962).
  232. This mainly affects `Header#DataHash`, `Header#LastResultsHash`, and
  233. `Header#EvidenceHash`, which are often empty. Non-empty hashes can also be affected, e.g. if their
  234. inputs depend on other (empty) Merkle hashes, giving different results.
  235. ### Transaction Indexing
  236. Tendermint now relies on the application to tell it which transactions to index. This means that
  237. in the `config.toml`, generated by Tendermint, there is no longer a way to specify which
  238. transactions to index. `tx.height` and `tx.hash` will always be indexed when using the `kv` indexer.
  239. Applications must now choose to either a) enable indexing for all transactions, or
  240. b) allow node operators to decide which transactions to index.
  241. Applications can notify Tendermint to index a specific transaction by setting
  242. `Index: bool` to `true` in the Event Attribute:
  243. ```go
  244. []types.Event{
  245. {
  246. Type: "app",
  247. Attributes: []types.EventAttribute{
  248. {Key: []byte("creator"), Value: []byte("Cosmoshi Netowoko"), Index: true},
  249. },
  250. },
  251. }
  252. ```
  253. ### Protocol Buffers
  254. Tendermint 0.34 replaces Amino with Protocol Buffers for encoding.
  255. This migration is extensive and results in a number of changes, however,
  256. Tendermint only uses the types generated from Protocol Buffers for disk and
  257. wire serialization.
  258. **This means that these changes should not affect you as a Tendermint user.**
  259. However, Tendermint users and contributors may note the following changes:
  260. * Directory layout changes: All proto files have been moved under one directory, `/proto`.
  261. This is in line with the recommended file layout by [Buf](https://buf.build).
  262. For more, see the [Buf documentation](https://buf.build/docs/lint-checkers#file_layout).
  263. * ABCI Changes: As noted in the "ABCI Changes" section above, the `PublicKey` type now uses
  264. a `oneof` type.
  265. For more on the Protobuf changes, please see our [blog post on this migration](https://medium.com/tendermint/tendermint-0-34-protocol-buffers-and-you-8c40558939ae).
  266. ### Consensus Parameters
  267. Tendermint 0.34 includes new and updated consensus parameters.
  268. #### Version Parameters (New)
  269. * `AppVersion`, which is the version of the ABCI application.
  270. #### Evidence Parameters
  271. * `MaxBytes`, which caps the total amount of evidence. The default is 1048576 (1 MB).
  272. ### Crypto
  273. #### Keys
  274. * Keys no longer include a type prefix. For example, ed25519 pubkeys have been renamed from
  275. `PubKeyEd25519` to `PubKey`. This reduces stutter (e.g., `ed25519.PubKey`).
  276. * Keys are now byte slices (`[]byte`) instead of byte arrays (`[<size>]byte`).
  277. * The multisig functionality that was previously in Tendermint now has
  278. a new home within the Cosmos SDK:
  279. [`cosmos/cosmos-sdk/types/multisig`](https://github.com/cosmos/cosmos-sdk/blob/master/crypto/types/multisig/multisignature.go).
  280. #### `merkle` Package
  281. * `SimpleHashFromMap()` and `SimpleProofsFromMap()` were removed.
  282. * The prefix `Simple` has been removed. (For example, `SimpleProof` is now called `Proof`.)
  283. * All protobuf messages have been moved to the `/proto` directory.
  284. * The protobuf message `Proof` that contained multiple ProofOp's has been renamed to `ProofOps`.
  285. As noted above, this affects the ABCI type `ResponseQuery`:
  286. The field that was named Proof is now named `ProofOps`.
  287. * `HashFromByteSlices` and `ProofsFromByteSlices` now return a hash for empty inputs, to conform with
  288. [RFC-6962](https://tools.ietf.org/html/rfc6962).
  289. ### `libs` Package
  290. The `bech32` package has moved to the Cosmos SDK:
  291. [`cosmos/cosmos-sdk/types/bech32`](https://github.com/cosmos/cosmos-sdk/tree/4173ea5ebad906dd9b45325bed69b9c655504867/types/bech32).
  292. ### CLI
  293. The `tendermint lite` command has been renamed to `tendermint light` and has a slightly different API.
  294. ### Light Client
  295. We have a new, rewritten light client! You can
  296. [read more](https://medium.com/tendermint/everything-you-need-to-know-about-the-tendermint-light-client-f80d03856f98)
  297. about the justifications and details behind this change.
  298. Other user-relevant changes include:
  299. * The old `lite` package was removed; the new light client uses the `light` package.
  300. * The `Verifier` was broken up into two pieces:
  301. * Core verification logic (pure `VerifyX` functions)
  302. * `Client` object, which represents the complete light client
  303. * The new light clients stores headers & validator sets as `LightBlock`s
  304. * The RPC client can be found in the `/rpc` directory.
  305. * The HTTP(S) proxy is located in the `/proxy` directory.
  306. ### `state` Package
  307. * A new field `State.InitialHeight` has been added to record the initial chain height, which must be `1`
  308. (not `0`) if starting from height `1`. This can be configured via the genesis field `initial_height`.
  309. * The `state` package now has a `Store` interface. All functions in
  310. [state/store.go](https://github.com/tendermint/tendermint/blob/56911ee35298191c95ef1c7d3d5ec508237aaff4/state/store.go#L42-L42)
  311. are now part of the interface. The interface returns errors on all methods and can be used by calling `state.NewStore(dbm.DB)`.
  312. ### `privval` Package
  313. All requests are now accompanied by the chain ID from the network.
  314. This is a optional field and can be ignored by key management systems;
  315. however, if you are using the same key management system for multiple different
  316. blockchains, we recommend that you check the chain ID.
  317. ### RPC
  318. * `/unsafe_start_cpu_profiler`, `/unsafe_stop_cpu_profiler` and
  319. `/unsafe_write_heap_profile` were removed.
  320. For profiling, please use the pprof server, which can
  321. be enabled through `--rpc.pprof_laddr=X` flag or `pprof_laddr=X` config setting
  322. in the rpc section.
  323. * The `Content-Type` header returned on RPC calls is now (correctly) set as `application/json`.
  324. ### Version
  325. Version is now set through Go linker flags `ld_flags`. Applications that are using tendermint as a library should set this at compile time.
  326. Example:
  327. ```sh
  328. go install -mod=readonly -ldflags "-X github.com/tendermint/tendermint/version.TMCoreSemVer=$(go list -m github.com/tendermint/tendermint | sed 's/ /\@/g') -s -w " -trimpath ./cmd
  329. ```
  330. Additionally, the exported constant `version.Version` is now `version.TMCoreSemVer`.
  331. ## v0.33.4
  332. ### Go API
  333. * `rpc/client` HTTP and local clients have been moved into `http` and `local`
  334. subpackages, and their constructors have been renamed to `New()`.
  335. ### Protobuf Changes
  336. When upgrading to version 0.33.4 you will have to fetch the `third_party`
  337. directory along with the updated proto files.
  338. ### Block Retention
  339. ResponseCommit added a field for block retention. The application can provide information to Tendermint on how to prune blocks.
  340. If an application would like to not prune any blocks pass a `0` in this field.
  341. ```proto
  342. message ResponseCommit {
  343. // reserve 1
  344. bytes data = 2; // the Merkle root hash
  345. ++ uint64 retain_height = 3; // the oldest block height to retain ++
  346. }
  347. ```
  348. ## v0.33.0
  349. This release is not compatible with previous blockchains due to commit becoming
  350. signatures only and fields in the header have been removed.
  351. ### Blockchain Protocol
  352. `TotalTxs` and `NumTxs` were removed from the header. `Commit` now consists
  353. mostly of just signatures.
  354. ```go
  355. type Commit struct {
  356. Height int64
  357. Round int
  358. BlockID BlockID
  359. Signatures []CommitSig
  360. }
  361. ```
  362. ```go
  363. type BlockIDFlag byte
  364. const (
  365. // BlockIDFlagAbsent - no vote was received from a validator.
  366. BlockIDFlagAbsent BlockIDFlag = 0x01
  367. // BlockIDFlagCommit - voted for the Commit.BlockID.
  368. BlockIDFlagCommit = 0x02
  369. // BlockIDFlagNil - voted for nil.
  370. BlockIDFlagNil = 0x03
  371. )
  372. type CommitSig struct {
  373. BlockIDFlag BlockIDFlag
  374. ValidatorAddress Address
  375. Timestamp time.Time
  376. Signature []byte
  377. }
  378. ```
  379. See [\#63](https://github.com/tendermint/spec/pull/63) for the complete spec
  380. change.
  381. ### P2P Protocol
  382. The secret connection now includes a transcript hashing. If you want to
  383. implement a handshake (or otherwise have an existing implementation), you'll
  384. need to make the same changes that were made
  385. [here](https://github.com/tendermint/tendermint/pull/3668).
  386. ### Config Changes
  387. You will need to generate a new config if you have used a prior version of tendermint.
  388. Tags have been entirely renamed throughout the codebase to events and there
  389. keys are called
  390. [compositeKeys](https://github.com/tendermint/tendermint/blob/6d05c531f7efef6f0619155cf10ae8557dd7832f/docs/app-dev/indexing-transactions.md).
  391. Evidence Params has been changed to include duration.
  392. * `consensus_params.evidence.max_age_duration`.
  393. * Renamed `consensus_params.evidence.max_age` to `max_age_num_blocks`.
  394. ### Go API
  395. * `libs/common` has been removed in favor of specific pkgs.
  396. * `async`
  397. * `service`
  398. * `rand`
  399. * `net`
  400. * `strings`
  401. * `cmap`
  402. * removal of `errors` pkg
  403. ### RPC Changes
  404. * `/validators` is now paginated (default: 30 vals per page)
  405. * `/block_results` response format updated [see RPC docs for details](https://docs.tendermint.com/master/rpc/#/Info/block_results)
  406. * Event suffix has been removed from the ID in event responses
  407. * IDs are now integers not `json-client-XYZ`
  408. ## v0.32.0
  409. This release is compatible with previous blockchains,
  410. however the new ABCI Events mechanism may create some complexity
  411. for nodes wishing to continue operation with v0.32 from a previous version.
  412. There are some minor breaking changes to the RPC.
  413. ### Config Changes
  414. If you have `db_backend` set to `leveldb` in your config file, please change it
  415. to `goleveldb` or `cleveldb`.
  416. ### RPC Changes
  417. The default listen address for the RPC is now `127.0.0.1`. If you want to expose
  418. it publicly, you have to explicitly configure it. Note exposing the RPC to the
  419. public internet may not be safe - endpoints which return a lot of data may
  420. enable resource exhaustion attacks on your node, causing the process to crash.
  421. Any consumers of `/block_results` need to be mindful of the change in all field
  422. names from CamelCase to Snake case, eg. `results.DeliverTx` is now `results.deliver_tx`.
  423. This is a fix, but it's breaking.
  424. ### ABCI Changes
  425. ABCI responses which previously had a `Tags` field now have an `Events` field
  426. instead. The original `Tags` field was simply a list of key-value pairs, where
  427. each key effectively represented some attribute of an event occuring in the
  428. blockchain, like `sender`, `receiver`, or `amount`. However, it was difficult to
  429. represent the occurence of multiple events (for instance, multiple transfers) in a single list.
  430. The new `Events` field contains a list of `Event`, where each `Event` is itself a list
  431. of key-value pairs, allowing for more natural expression of multiple events in
  432. eg. a single DeliverTx or EndBlock. Note each `Event` also includes a `Type`, which is meant to categorize the
  433. event.
  434. For transaction indexing, the index key is
  435. prefixed with the event type: `{eventType}.{attributeKey}`.
  436. If the same event type and attribute key appear multiple times, the values are
  437. appended in a list.
  438. To make queries, include the event type as a prefix. For instance if you
  439. previously queried for `recipient = 'XYZ'`, and after the upgrade you name your event `transfer`,
  440. the new query would be for `transfer.recipient = 'XYZ'`.
  441. Note that transactions indexed on a node before upgrading to v0.32 will still be indexed
  442. using the old scheme. For instance, if a node upgraded at height 100,
  443. transactions before 100 would be queried with `recipient = 'XYZ'` and
  444. transactions after 100 would be queried with `transfer.recipient = 'XYZ'`.
  445. While this presents additional complexity to clients, it avoids the need to
  446. reindex. Of course, you can reset the node and sync from scratch to re-index
  447. entirely using the new scheme.
  448. We illustrate further with a more complete example.
  449. Prior to the update, suppose your `ResponseDeliverTx` look like:
  450. ```go
  451. abci.ResponseDeliverTx{
  452. Tags: []kv.Pair{
  453. {Key: []byte("sender"), Value: []byte("foo")},
  454. {Key: []byte("recipient"), Value: []byte("bar")},
  455. {Key: []byte("amount"), Value: []byte("35")},
  456. }
  457. }
  458. ```
  459. The following queries would match this transaction:
  460. ```go
  461. query.MustParse("tm.event = 'Tx' AND sender = 'foo'")
  462. query.MustParse("tm.event = 'Tx' AND recipient = 'bar'")
  463. query.MustParse("tm.event = 'Tx' AND sender = 'foo' AND recipient = 'bar'")
  464. ```
  465. Following the upgrade, your `ResponseDeliverTx` would look something like:
  466. the following `Events`:
  467. ```go
  468. abci.ResponseDeliverTx{
  469. Events: []abci.Event{
  470. {
  471. Type: "transfer",
  472. Attributes: kv.Pairs{
  473. {Key: []byte("sender"), Value: []byte("foo")},
  474. {Key: []byte("recipient"), Value: []byte("bar")},
  475. {Key: []byte("amount"), Value: []byte("35")},
  476. },
  477. }
  478. }
  479. ```
  480. Now the following queries would match this transaction:
  481. ```go
  482. query.MustParse("tm.event = 'Tx' AND transfer.sender = 'foo'")
  483. query.MustParse("tm.event = 'Tx' AND transfer.recipient = 'bar'")
  484. query.MustParse("tm.event = 'Tx' AND transfer.sender = 'foo' AND transfer.recipient = 'bar'")
  485. ```
  486. For further documentation on `Events`, see the [docs](https://github.com/tendermint/tendermint/blob/60827f75623b92eff132dc0eff5b49d2025c591e/docs/spec/abci/abci.md#events).
  487. ### Go Applications
  488. The ABCI Application interface changed slightly so the CheckTx and DeliverTx
  489. methods now take Request structs. The contents of these structs are just the raw
  490. tx bytes, which were previously passed in as the argument.
  491. ## v0.31.6
  492. There are no breaking changes in this release except Go API of p2p and
  493. mempool packages. Hovewer, if you're using cleveldb, you'll need to change
  494. the compilation tag:
  495. Use `cleveldb` tag instead of `gcc` to compile Tendermint with CLevelDB or
  496. use `make build_c` / `make install_c` (full instructions can be found at
  497. <https://docs.tendermint.com/v0.35/introduction/install.html)
  498. ## v0.31.0
  499. This release contains a breaking change to the behaviour of the pubsub system.
  500. It also contains some minor breaking changes in the Go API and ABCI.
  501. There are no changes to the block or p2p protocols, so v0.31.0 should work fine
  502. with blockchains created from the v0.30 series.
  503. ### RPC
  504. The pubsub no longer blocks on publishing. This may cause some WebSocket (WS) clients to stop working as expected.
  505. If your WS client is not consuming events fast enough, Tendermint can terminate the subscription.
  506. In this case, the WS client will receive an error with description:
  507. ```json
  508. {
  509. "jsonrpc": "2.0",
  510. "id": "{ID}#event",
  511. "error": {
  512. "code": -32000,
  513. "msg": "Server error",
  514. "data": "subscription was canceled (reason: client is not pulling messages fast enough)" // or "subscription was canceled (reason: Tendermint exited)"
  515. }
  516. }
  517. Additionally, there are now limits on the number of subscribers and
  518. subscriptions that can be active at once. See the new
  519. `rpc.max_subscription_clients` and `rpc.max_subscriptions_per_client` values to
  520. configure this.
  521. ```
  522. ### Applications
  523. Simple rename of `ConsensusParams.BlockSize` to `ConsensusParams.Block`.
  524. The `ConsensusParams.Block.TimeIotaMS` field was also removed. It's configured
  525. in the ConsensusParsm in genesis.
  526. ### Go API
  527. See the [CHANGELOG](CHANGELOG.md). These are relatively straight forward.
  528. ## v0.30.0
  529. This release contains a breaking change to both the block and p2p protocols,
  530. however it may be compatible with blockchains created with v0.29.0 depending on
  531. the chain history. If your blockchain has not included any pieces of evidence,
  532. or no piece of evidence has been included in more than one block,
  533. and if your application has never returned multiple updates
  534. for the same validator in a single block, then v0.30.0 will work fine with
  535. blockchains created with v0.29.0.
  536. The p2p protocol change is to fix the proposer selection algorithm again.
  537. Note that proposer selection is purely a p2p concern right
  538. now since the algorithm is only relevant during real time consensus.
  539. This change is thus compatible with v0.29.0, but
  540. all nodes must be upgraded to avoid disagreements on the proposer.
  541. ### Applications
  542. Applications must ensure they do not return duplicates in
  543. `ResponseEndBlock.ValidatorUpdates`. A pubkey must only appear once per set of
  544. updates. Duplicates will cause irrecoverable failure. If you have a very good
  545. reason why we shouldn't do this, please open an issue.
  546. ## v0.29.0
  547. This release contains some breaking changes to the block and p2p protocols,
  548. and will not be compatible with any previous versions of the software, primarily
  549. due to changes in how various data structures are hashed.
  550. Any implementations of Tendermint blockchain verification, including lite clients,
  551. will need to be updated. For specific details:
  552. * [Merkle tree](https://github.com/tendermint/spec/blob/master/spec/blockchain/encoding.md#merkle-trees)
  553. * [ConsensusParams](https://github.com/tendermint/spec/blob/master/spec/blockchain/state.md#consensusparams)
  554. There was also a small change to field ordering in the vote struct. Any
  555. implementations of an out-of-process validator (like a Key-Management Server)
  556. will need to be updated. For specific details:
  557. * [Vote](https://github.com/tendermint/spec/blob/master/spec/consensus/signing.md#votes)
  558. Finally, the proposer selection algorithm continues to evolve. See the
  559. [work-in-progress
  560. specification](https://github.com/tendermint/tendermint/pull/3140).
  561. For everything else, please see the [CHANGELOG](./CHANGELOG.md#v0.29.0).
  562. ## v0.28.0
  563. This release breaks the format for the `priv_validator.json` file
  564. and the protocol used for the external validator process.
  565. It is compatible with v0.27.0 blockchains (neither the BlockProtocol nor the
  566. P2PProtocol have changed).
  567. Please read carefully for details about upgrading.
  568. **Note:** Backup your `config/priv_validator.json`
  569. before proceeding.
  570. ### `priv_validator.json`
  571. The `config/priv_validator.json` is now two files:
  572. `config/priv_validator_key.json` and `data/priv_validator_state.json`.
  573. The former contains the key material, the later contains the details on the last
  574. message signed.
  575. When running v0.28.0 for the first time, it will back up any pre-existing
  576. `priv_validator.json` file and proceed to split it into the two new files.
  577. Upgrading should happen automatically without problem.
  578. To upgrade manually, use the provided `privValUpgrade.go` script, with exact paths for the old
  579. `priv_validator.json` and the locations for the two new files. It's recomended
  580. to use the default paths, of `config/priv_validator_key.json` and
  581. `data/priv_validator_state.json`, respectively:
  582. ```sh
  583. go run scripts/privValUpgrade.go <old-path> <new-key-path> <new-state-path>
  584. ```
  585. ### External validator signers
  586. The Unix and TCP implementations of the remote signing validator
  587. have been consolidated into a single implementation.
  588. Thus in both cases, the external process is expected to dial
  589. Tendermint. This is different from how Unix sockets used to work, where
  590. Tendermint dialed the external process.
  591. The `PubKeyMsg` was also split into separate `Request` and `Response` types
  592. for consistency with other messages.
  593. Note that the TCP sockets don't yet use a persistent key,
  594. so while they're encrypted, they can't yet be properly authenticated.
  595. See [#3105](https://github.com/tendermint/tendermint/issues/3105).
  596. Note the Unix socket has neither encryption nor authentication, but will
  597. add a shared-secret in [#3099](https://github.com/tendermint/tendermint/issues/3099).
  598. ## v0.27.0
  599. This release contains some breaking changes to the block and p2p protocols,
  600. but does not change any core data structures, so it should be compatible with
  601. existing blockchains from the v0.26 series that only used Ed25519 validator keys.
  602. Blockchains using Secp256k1 for validators will not be compatible. This is due
  603. to the fact that we now enforce which key types validators can use as a
  604. consensus param. The default is Ed25519, and Secp256k1 must be activated
  605. explicitly.
  606. It is recommended to upgrade all nodes at once to avoid incompatibilities at the
  607. peer layer - namely, the heartbeat consensus message has been removed (only
  608. relevant if `create_empty_blocks=false` or `create_empty_blocks_interval > 0`),
  609. and the proposer selection algorithm has changed. Since proposer information is
  610. never included in the blockchain, this change only affects the peer layer.
  611. ### Go API Changes
  612. #### libs/db
  613. The ReverseIterator API has changed the meaning of `start` and `end`.
  614. Before, iteration was from `start` to `end`, where
  615. `start > end`. Now, iteration is from `end` to `start`, where `start < end`.
  616. The iterator also excludes `end`. This change allows a simplified and more
  617. intuitive logic, aligning the semantic meaning of `start` and `end` in the
  618. `Iterator` and `ReverseIterator`.
  619. ### Applications
  620. This release enforces a new consensus parameter, the
  621. ValidatorParams.PubKeyTypes. Applications must ensure that they only return
  622. validator updates with the allowed PubKeyTypes. If a validator update includes a
  623. pubkey type that is not included in the ConsensusParams.Validator.PubKeyTypes,
  624. block execution will fail and the consensus will halt.
  625. By default, only Ed25519 pubkeys may be used for validators. Enabling
  626. Secp256k1 requires explicit modification of the ConsensusParams.
  627. Please update your application accordingly (ie. restrict validators to only be
  628. able to use Ed25519 keys, or explicitly add additional key types to the genesis
  629. file).
  630. ## v0.26.0
  631. This release contains a lot of changes to core data types and protocols. It is not
  632. compatible to the old versions and there is no straight forward way to update
  633. old data to be compatible with the new version.
  634. To reset the state do:
  635. ```sh
  636. tendermint unsafe_reset_all
  637. ```
  638. Here we summarize some other notable changes to be mindful of.
  639. ### Config Changes
  640. All timeouts must be changed from integers to strings with their duration, for
  641. instance `flush_throttle_timeout = 100` would be changed to
  642. `flush_throttle_timeout = "100ms"` and `timeout_propose = 3000` would be changed
  643. to `timeout_propose = "3s"`.
  644. ### RPC Changes
  645. The default behaviour of `/abci_query` has been changed to not return a proof,
  646. and the name of the parameter that controls this has been changed from `trusted`
  647. to `prove`. To get proofs with your queries, ensure you set `prove=true`.
  648. Various version fields like `amino_version`, `p2p_version`, `consensus_version`,
  649. and `rpc_version` have been removed from the `node_info.other` and are
  650. consolidated under the tendermint semantic version (ie. `node_info.version`) and
  651. the new `block` and `p2p` protocol versions under `node_info.protocol_version`.
  652. ### ABCI Changes
  653. Field numbers were bumped in the `Header` and `ResponseInfo` messages to make
  654. room for new `version` fields. It should be straight forward to recompile the
  655. protobuf file for these changes.
  656. #### Proofs
  657. The `ResponseQuery.Proof` field is now structured as a `[]ProofOp` to support
  658. generalized Merkle tree constructions where the leaves of one Merkle tree are
  659. the root of another. If you don't need this functionality, and you used to
  660. return `<proof bytes>` here, you should instead return a single `ProofOp` with
  661. just the `Data` field set:
  662. ```go
  663. []ProofOp{
  664. ProofOp{
  665. Data: <proof bytes>,
  666. }
  667. }
  668. ```
  669. For more information, see:
  670. * [ADR-026](https://github.com/tendermint/tendermint/blob/30519e8361c19f4bf320ef4d26288ebc621ad725/docs/architecture/adr-026-general-merkle-proof.md)
  671. * [Relevant ABCI
  672. documentation](https://github.com/tendermint/tendermint/blob/30519e8361c19f4bf320ef4d26288ebc621ad725/docs/spec/abci/apps.md#query-proofs)
  673. * [Description of
  674. keys](https://github.com/tendermint/tendermint/blob/30519e8361c19f4bf320ef4d26288ebc621ad725/crypto/merkle/proof_key_path.go#L14)
  675. ### Go API Changes
  676. #### crypto/merkle
  677. The `merkle.Hasher` interface was removed. Functions which used to take `Hasher`
  678. now simply take `[]byte`. This means that any objects being Merklized should be
  679. serialized before they are passed in.
  680. #### node
  681. The `node.RunForever` function was removed. Signal handling and running forever
  682. should instead be explicitly configured by the caller. See how we do it
  683. [here](https://github.com/tendermint/tendermint/blob/30519e8361c19f4bf320ef4d26288ebc621ad725/cmd/tendermint/commands/run_node.go#L60).
  684. ### Other
  685. All hashes, except for public key addresses, are now 32-bytes.
  686. ## v0.25.0
  687. This release has minimal impact.
  688. If you use GasWanted in ABCI and want to enforce it, set the MaxGas in the genesis file (default is no max).
  689. ## v0.24.0
  690. New 0.24.0 release contains a lot of changes to the state and types. It's not
  691. compatible to the old versions and there is no straight forward way to update
  692. old data to be compatible with the new version.
  693. To reset the state do:
  694. ```sh
  695. tendermint unsafe_reset_all
  696. ```
  697. Here we summarize some other notable changes to be mindful of.
  698. ### Config changes
  699. `p2p.max_num_peers` was removed in favor of `p2p.max_num_inbound_peers` and
  700. `p2p.max_num_outbound_peers`.
  701. ```toml
  702. # Maximum number of inbound peers
  703. max_num_inbound_peers = 40
  704. # Maximum number of outbound peers to connect to, excluding persistent peers
  705. max_num_outbound_peers = 10
  706. ```
  707. As you can see, the default ratio of inbound/outbound peers is 4/1. The reason
  708. is we want it to be easier for new nodes to connect to the network. You can
  709. tweak these parameters to alter the network topology.
  710. ### RPC Changes
  711. The result of `/commit` used to contain `header` and `commit` fields at the top level. These are now contained under the `signed_header` field.
  712. ### ABCI Changes
  713. The header has been upgraded and contains new fields, but none of the existing
  714. fields were changed, except their order.
  715. The `Validator` type was split into two, one containing an `Address` and one
  716. containing a `PubKey`. When processing `RequestBeginBlock`, use the `Validator`
  717. type, which contains just the `Address`. When returning `ResponseEndBlock`, use
  718. the `ValidatorUpdate` type, which contains just the `PubKey`.
  719. ### Validator Set Updates
  720. Validator set updates returned in ResponseEndBlock for height `H` used to take
  721. effect immediately at height `H+1`. Now they will be delayed one block, to take
  722. effect at height `H+2`. Note this means that the change will be seen by the ABCI
  723. app in the `RequestBeginBlock.LastCommitInfo` at block `H+3`. Apps were already
  724. required to maintain a map from validator addresses to pubkeys since v0.23 (when
  725. pubkeys were removed from RequestBeginBlock), but now they may need to track
  726. multiple validator sets at once to accomodate this delay.
  727. ### Block Size
  728. The `ConsensusParams.BlockSize.MaxTxs` was removed in favour of
  729. `ConsensusParams.BlockSize.MaxBytes`, which is now enforced. This means blocks
  730. are limitted only by byte-size, not by number of transactions.