Skip to content

More BSTM Updates#268

Merged
Eric-Warehime merged 1 commit intomainfrom
eric/bstm-updates-0
Mar 30, 2026
Merged

More BSTM Updates#268
Eric-Warehime merged 1 commit intomainfrom
eric/bstm-updates-0

Conversation

@Eric-Warehime
Copy link
Copy Markdown
Contributor

Adds a section for deployment practices and risks to look out for when integrating parallel execution.

@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps bot commented Mar 26, 2026

Greptile Summary

This PR adds a Safe Deployment Practices section to the Block-STM documentation, covering three important deployment considerations for teams integrating parallel execution: phased rollout strategy, message type validation requirements (including a CosmWasm caveat), and caching/indeterminism risks.\n\nThe content is technically sound and provides genuinely useful operational guidance. A few minor formatting issues are worth cleaning up before merge:\n\n- An accidental line break leaves the word "extensive" orphaned on its own line in the introductory sentence.\n- The three sub-topic bullet points (_Phased Rollout_, _Message Type Support_, _Caching Risks_) are followed by unindented paragraphs, which in Markdown/MDX will render the explanatory text as standalone paragraphs rather than content associated with the bullet — consider indenting or converting to ### subheadings.\n- __not__ on line 54 should be **not** for more portable MDX bold syntax.

Confidence Score: 4/5

Documentation-only PR that is safe to merge; minor formatting fixes recommended but not blocking.

The new section adds valuable operational guidance with accurate technical content. No code is changed. The three style/formatting issues identified (orphaned line break, unindented bullet content, __ vs ** bold) are cosmetic and don't affect the accuracy or usability of the docs, but fixing them would improve rendered quality and source readability.

sdk/next/experimental/blockstm.mdx — minor formatting cleanup in the new Safe Deployment Practices section

Important Files Changed

Filename Overview
sdk/next/experimental/blockstm.mdx Adds a "Safe Deployment Practices" section covering phased rollout, message type support caveats, and caching risks. Minor formatting issues: orphaned word on its own line, un-indented bullet content that may render detached from its heading, and __not__ bold syntax that is less portable than **not**.

Reviews (1): Last reviewed commit: "More updates" | Re-trigger Greptile

Comment on lines +34 to +36
Given the Block-STM executor is a general purpose parallel execution engine, we recommend a phased rollout with
extensive
testing for each application individually.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Accidental line break splits intro sentence

The word extensive is orphaned on its own line, which appears to be an editing artifact. While most Markdown renderers will collapse this into a single space, it reads awkwardly in source and could confuse future editors.

Suggested change
Given the Block-STM executor is a general purpose parallel execution engine, we recommend a phased rollout with
extensive
testing for each application individually.
Given the Block-STM executor is a general-purpose parallel execution engine, we recommend a phased rollout with extensive testing for each application individually.

(Also note: "general-purpose" should be hyphenated when used as a compound modifier before a noun.)

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Comment on lines +38 to +61
* _Phased Rollout_

Since parallel execution is purely a performance optimization, applications should expect to calculate the same
AppHash when using Block-STM as they would when serial execution is enabled via the default TxRunner. This allows teams
to turn on parallel execution for a fraction of their nodes--API nodes instead of validators or on a portion of a
distributed validator cluster for example.

Running with a mixed fleet of parallel and serial execution for an extended time should minimize blast radius in the
event that a failure occurs.

* _Message Type Support_

We have done testing on as many of the core SDK message types as possible, but given the Cosmos SDK allows arbitrary
message creation it will be impossible to validate all message types that exist and all combinations of workflows.
Each team integrating Block-STM in production should validate their own message types for both correctness and performance.

NOTE: We specifically have __not__ validated support for CosmWasm message types run using Block-STM. Run independent
validation before enabling if your chain uses CosmWasm.

* _Caching Risks_

Block-STM works via dependency tracking within the SDK's `MultiStore` interface. Any data which could cause stateful
changes to execution that lives outside the store poses the biggest risk for indeterminism. We recommend in general
avoiding the use of cached data, in memory stores, or persisting any state outside the scope of a `Store`.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Bullet content not indented under list items

In Markdown/MDX, a blank line after a list item followed by non-indented text breaks the association — the paragraphs render as standalone text outside the list rather than as continuations of each bullet. This means readers may not visually connect each heading (_Phased Rollout_, _Message Type Support_, _Caching Risks_) with its explanatory paragraph.

To keep content inside the list item, indent the paragraphs with at least two spaces:

* _Phased Rollout_

  Since parallel execution is purely a performance optimization, applications should expect to calculate the same
  AppHash when using Block-STM as they would when serial execution is enabled via the default TxRunner. ...

* _Message Type Support_

  We have done testing on as many of the core SDK message types as possible, ...

* _Caching Risks_

  Block-STM works via dependency tracking within the SDK's `MultiStore` interface. ...

Alternatively, use ### subheadings instead of italic bullets for each sub-topic, which is more consistent with the rest of the document's structure.

message creation it will be impossible to validate all message types that exist and all combinations of workflows.
Each team integrating Block-STM in production should validate their own message types for both correctness and performance.

NOTE: We specifically have __not__ validated support for CosmWasm message types run using Block-STM. Run independent
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Use ** for emphasis instead of __

Double-underscores for bold (__not__) can behave inconsistently in some MDX parsers, particularly when surrounded by non-whitespace characters. The ** syntax is more portable and consistent with the rest of the document.

Suggested change
NOTE: We specifically have __not__ validated support for CosmWasm message types run using Block-STM. Run independent
NOTE: We specifically have **not** validated support for CosmWasm message types run using Block-STM. Run independent

@mintlify
Copy link
Copy Markdown

mintlify bot commented Mar 26, 2026

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated (UTC)
cosmos-docs 🟢 Ready View Preview Mar 26, 2026, 3:11 PM

@evanorti
Copy link
Copy Markdown
Contributor

LGTM. Merge away!

@Eric-Warehime Eric-Warehime merged commit 71fe82a into main Mar 30, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants