github.com/adoriasoft/tendermint@v0.34.0-dev1.0.20200722151356-96d84601a75a/UPGRADING.md (about)

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