feat(types): increase default SynchronyParams consensus parameters …

…values (cometbft#4249)

Closes cometbft#4246

- `Precision` was set to `505ms`, because it should be greater than
0.5s, as in tendermint/tendermint#7724
- `MessageDelay` was increased to `15s`, following the measurements
reported in tendermint/tendermint#7788, and
considering some outputs of `e2e` tests

---

#### PR checklist

- [ ] Tests written/updated
- [ ] Changelog entry added in `.changelog` (we use
[unclog](https://github.com/informalsystems/unclog) to manage our
changelog)
- [x] Updated relevant documentation (`docs/` or `spec/`) and code
comments

docs/guides/tools/proposer-based-timestamps-runbook.md

@@ -228,13 +228,13 @@ The json output will contain a field named `synchrony`, with the following struc
 
 ```json
 {
-  "precision": "500000000",
-  "message_delay": "3000000000"
+  "precision": "505000000",
+  "message_delay": "12000000000"
 }
 ```
 
 The `precision` and `message_delay` values returned are listed in nanoseconds:
-In the examples above, the precision is 500ms and the message delay is 3s.
+In the examples above, the precision is 505ms and the message delay is 12s.
 Remember, `consensus_quorum_prevote_delay` is listed in seconds.
 If the `consensus_quorum_prevote_delay` value approaches the sum of `precision` and `message_delay`,
 then the value selected for these parameters is too small. Your application will

docs/guides/upgrades/v0.38-to-v1.0.md

@@ -22,16 +22,16 @@ and [UPGRADING.md](https://github.com/cometbft/cometbft/blob/main/UPGRADING.md)
 
 CometBFT `v1.0` contains a new algorithm for generating and verifying block timestamps
 called Proposer-Based Timestamps (`PBTS`).
-The existing algorithm used in CometBFT releases prior to `v1.0`, called [BFT-Time][bft-time] is kept for backwards compatibility.
+The existing algorithm used in CometBFT releases prior to `v1.0`, called [BFT Time][bft-time] is kept for backwards compatibility.
 
-Upgrading to `v1.0` **does not automatically switch the chain from BFT-Time
+Upgrading to `v1.0` **does not automatically switch the chain from BFT Time
 to PBTS**; rather a `ConsensusParam` called `PbtsEnableHeight` was introduced and can be set to a future
-height to transition from BFT-Time to PBTS.
+height to transition from BFT Time to PBTS.
 
 This flexible mechanism allows chains disentangle the upgrade to `v1.0` from the transition
 in the algorithm used for block times.
 
-For further information, please check the [PBTS specification][pbts-spec].
+For further information, please check the [PBTS documentation][pbts-docs].
 
 ## ABCI Local Client Mutex
 
@@ -530,8 +530,8 @@ please see the [Proposer-Based Timestamps](#proposer-based-timestamps-pbts) sect
 
 ```
     "synchrony": {
-        "precision": "500000000",
-        "message_delay": "2000000000"
+        "precision": "505000000",
+        "message_delay": "15000000000"
     },
 ```
 
@@ -601,4 +601,5 @@ Engage with the [CometBFT community](https://linktr.ee/cometbft) for assistance
 experiences regarding the upgrade process.
 
 [pbts-spec]: https://github.com/cometbft/cometbft/blob/main/spec/consensus/proposer-based-timestamp/README.md
+[pbts-docs]: ../../explanation/core/proposer-based-timestamps.md
 [bft-time]: https://github.com/cometbft/cometbft/blob/main/spec/consensus/bft-time.md

types/params.go

@@ -194,10 +194,10 @@ func DefaultFeatureParams() FeatureParams {
 
 func DefaultSynchronyParams() SynchronyParams {
 	// Default values determined based on experimental results and on
-	// https://github.com/tendermint/tendermint/issues/7202
+	// https://github.com/cometbft/cometbft/issues/4246
 	return SynchronyParams{
-		Precision:    500 * time.Millisecond,
-		MessageDelay: 2 * time.Second,
+		Precision:    505 * time.Millisecond,
+		MessageDelay: 15 * time.Second,
 	}
 }