docs(l1): tradeoffs of transactional RocksDB modes

[Oppen]

A brief pros and cons list to decide whether to turn off optimistic
transactions.

[Copilot]

Pull Request Overview

Adds an internal documentation page outlining pros/cons of using Optimistic, Pessimistic, or Non-Transactional RocksDB modes to inform a decision about disabling optimistic transactions.

• Introduces advantages sections for each transaction mode plus non-transactional usage
• Lists potential alternatives to using DB-level transactions
• Highlights operational considerations for crash recovery and L2 constraints

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Heading is grammatically awkward; consider rephrasing for clarity.

Suggested change

	# Tradeoffs of using or not Optimistic Transaction DB in RocksDB
	# Tradeoffs of Using Optimistic Transaction DB Versus Not Using It in RocksDB

[Copilot]

The trailing question mark signals uncertainty. Either provide data/supporting rationale or remove the entry until confirmed.

Suggested change

	- Lower memory usage?
	- Lower memory usage (confirm).

[Copilot]

The '(confirm)' note indicates an unverified claim; replace with concrete information or remove pending validation.

Suggested change

	- Lower memory usage (confirm).
	- Lower memory usage.

[Copilot]

Sentence is ambiguous ('either much easier or possible'). Clarify whether non-transactional mode enables secondary instances at all, or simply reduces complexity.

Suggested change

	- Secondary instances are either much easier or possible.
	- Secondary instances are only possible in non-transactional mode.

[Copilot]

Term 'Based' is unexplained; add a brief definition or link so readers understand the dependency or future milestone.

Suggested change

	- L2 can't recover from peers (at least until Based), so it should probably remain transactional.
	- L2 can't recover from peers (at least until Based[^based]), so it should probably remain transactional.

[Copilot]

[nitpick] Consider explicitly listing required additional mechanisms (healing pass, crash tests, checkpoints) as 'Operational Requirements' to distinguish them from 'Advantages'; current mix may confuse readers about what is a benefit vs. a cost.

Suggested change

	- `delete_range`: much faster key deletion in bulk, useful during healing.
	- Lower memory usage (confirm).
	- Secondary instances are either much easier or possible.
	## Alternatives to DB Transactions
	- We can use snapshots/secondary instances to provide a consistent view to block production and protocols.
	- We can provide crash safety by adding checkpoints or explicit markers so we can go back to the last known consistent version.
	- We would need to run a healing pass from that point on startup, to fix possible partial changes to tries.
	- We would need to add explicit tests for crashing during writes to make sure we recover correctly.
	- Lower memory usage (confirm).
	- Secondary instances are either much easier or possible.
	## Operational Requirements for Non-Transactional DB
	- Healing pass: On startup, a healing pass must be run from the last checkpoint to fix possible partial changes to tries.
	- Crash safety: Explicit tests for crashing during writes are needed to ensure correct recovery.
	- Checkpoints: Crash safety can be provided by adding checkpoints or explicit markers to allow rollback to the last known consistent version.
	- `delete_range`: Used for much faster key deletion in bulk, which is especially useful during the healing process.
	## Alternatives to DB Transactions
	- We can use snapshots/secondary instances to provide a consistent view to block production and protocols.

[Copilot]

[nitpick] Consider explicitly listing required additional mechanisms (healing pass, crash tests, checkpoints) as 'Operational Requirements' to distinguish them from 'Advantages'; current mix may confuse readers about what is a benefit vs. a cost.

Suggested change

	- We can use snapshots/secondary instances to provide a consistent view to block production and protocols.
	- We can provide crash safety by adding checkpoints or explicit markers so we can go back to the last known consistent version.
	- We would need to run a healing pass from that point on startup, to fix possible partial changes to tries.
	- We would need to add explicit tests for crashing during writes to make sure we recover correctly.
	- We can use snapshots/secondary instances to provide a consistent view to block production and protocols.
	## Operational Requirements for Non-Transactional DB
	- We can provide crash safety by adding checkpoints or explicit markers so we can go back to the last known consistent version.
	- We would need to run a healing pass from that point on startup, to fix possible partial changes to tries.
	- We would need to add explicit tests for crashing during writes to make sure we recover correctly.