feat(dashmate): expose Tenderdash consensus DoS rate-limit knobs

[shumkov]

What

Exposes three Tenderdash [consensus] rate-limit knobs through dashmate so operators can override them from dashmate config. The keys map:

TOML (config.toml)	dashmate (camelCase)	default
verification-rate-limit	verificationRateLimit	300
peer-vote-rate-limit	peerVoteRateLimit	600
peer-data-rate-limit	peerDataRateLimit	500

These are node-wide / per-peer verification-work budgets used by Tenderdash's consensus DoS-hardening. They did not exist in dashmate before this PR (0 hits for all spellings).

Why (this is prep, not urgent)

A Tenderdash node with these keys omitted falls back to its compiled-in defaults (300 / 600 / 500), because the generated config.toml is unmarshalled on top of the default config struct. So dashmate-managed nodes already run the correct defaults today, and nothing here is required for a node or a devnet to run. This PR is preparation so the limits can be tuned (e.g. limit sweeps) later without hand-editing config.toml.

Changes (4 files, all in packages/dashmate)

1. templates/platform/drive/tenderdash/config.toml.dot — emit the three keys as bare numbers (they are floats) in the [consensus] block.
2. configs/defaults/getBaseConfigFactory.js — add the three defaults (300 / 600 / 500) to the consensus object.
3. src/config/configJsonSchema.js — add three number properties (minimum: 0) and extend the consensus required array. The consensus object is additionalProperties: false, so both the properties and the required edit are mandatory or a config carrying the keys fails validation.
4. configs/getConfigFileMigrationsFactory.js — a backfill migration so an existing (pre-this-release) config gains the now-required keys and keeps validating after upgrade.

Schema enforces only minimum: 0. The stricter "0 or >= 33" rule for verificationRateLimit is left to Tenderdash's own ValidateBasic at node start, consistent with how dashmate treats other Tenderdash-validated numbers.

⚠️ Migration version placeholder — must fix before release

The migration is keyed at 4.2.0 as a placeholder for the release that will actually ship this change. getConfigFormatVersion makes the newest migration key the effective config-format version, so this key both drives the backfill and stamps the format. Set this key to the real shipping dashmate version before merge/release. Current packages/dashmate version is 4.1.0.

Verification

Full monorepo yarn install (Rust/wasm native builds) was not run in this environment. Instead the JS was checked directly:

• node --check on all three edited .js files — pass.
• Built the base config via getBaseConfigFactory() → new Config('base', options) validates the defaults against the schema (Ajv) on construction — pass (proves the defaults ⇄ schema required/additionalProperties:false edits are consistent).
• Simulated the backfill migration on a config with the keys removed, then re-applied via Config.set (re-validates) — result matches defaults 300 / 600 / 500 — pass.
• Negative control: a config missing verificationRateLimit is rejected by the schema with a required error — pass (confirms the required edit actually bites; the positive check is not tautological).

Recommend running packages/dashmate yarn test:unit in CI — in particular test/unit/config/configFile/migrateConfigFileFactory.spec.js, which migrates an old config fixture to the latest and asserts deep-equality with the freshly built default config (exercises the migration + defaults together).

Dependency order

This is the top of a three-repo chain (prep only):

platform (this PR) → a dashmate release carrying these keys → dash-network-deploy ansible plumbing → per-network dash-network-configs override.

The downstream dash-network-deploy change is BLOCKED-ON a dashmate release that contains this PR (its dashmate_version must be bumped to that release). None of this blocks a first devnet, which runs the built-in defaults.

---

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 372334aa-fb2e-4957-b2dd-ed96a684a4dd

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}