Build Denial-of-Service, Gas-Griefing, and Unbounded-Work Analysis #80

Summary

Implement a production-grade denial-of-service, gas-griefing, and unbounded-work analysis for StellarChainproofs/ChainProof. This issue is a complete engineering track rather than a narrow detector patch: it requires durable TypeScript architecture, integrated workflows, comprehensive validation, tests, fixtures, and documentation.

Problem statement

Loops, dynamic storage, callback fan-out, revert propagation, and attacker-controlled work can make critical operations impossible even when no direct asset theft occurs.

Required scope

• Identify loops and recursion whose bounds derive from user-controlled or unbounded persistent data.
• Track attacker-controlled array growth, iteration, external-call fan-out, returndata copying, event volume, and storage clearing.
• Detect push-payment patterns, unexpected revert propagation, insufficient gas forwarding, return bombs, and block gas limit dependence.
• Estimate symbolic upper bounds where possible and attach uncertainty when constraints cannot be proven.
• Recognize pagination, pull payments, bounded batches, failure isolation, and other mitigation patterns.
• Test governance execution, reward distribution, liquidation queues, enumerable sets, malicious recipients, return bombs, and safe chunked designs.

Acceptance criteria

• The capability is exposed through coherent @chainproof/core APIs and appropriate CLI, server, editor, action, or plugin surfaces with stable versioned output.
• Analysis behavior is deterministic by default, bounded against adversarial input, and accompanied by precise source locations, evidence paths, assumptions, and confidence where applicable.
• Core logic is separated from transport and presentation layers and does not require external network services in CI.
• New configuration, caches, databases, manifests, or report formats are versioned and include validation, migration, and corruption handling.
• Errors preserve actionable context without leaking source, credentials, local paths, provider data, or other sensitive information.
• Tests include vulnerable and secure fixtures, false-positive controls, malformed input, boundary conditions, failure recovery, and performance safeguards.
• Public APIs and CLI behavior are documented with security assumptions, compatibility constraints, examples, and operational troubleshooting.

Required deliverables

• Production TypeScript implementation placed in the appropriate packages/core, packages/cli, packages/server, packages/vscode-extension, packages/github-action, or clearly justified new workspace package.
• Typed public interfaces, structured diagnostics, deterministic serialization, resource limits, cancellation, and recovery behavior appropriate to the feature.
• Unit, integration, CLI, adversarial, and regression tests plus vulnerable and secure Solidity fixtures or protocol test doubles.
• Documentation for users, rule authors, integrators, and maintainers, including threat model, limitations, compatibility, migration, and troubleshooting.
• A pull-request description explaining architecture, precision/recall considerations, security boundaries, performance measurements, test evidence, and follow-up work.

Integration boundaries

This is deterministic liveness and resource analysis, not the AI gas optimization track in #54.

Avoid unrelated rewrites, placeholder detectors, hidden live-network dependencies, dead code, and changes that weaken existing rules, type safety, security controls, or test coverage.

Minimum implementation requirement

This is intentionally a substantial contributor project. A mergeable pull request must add at least 1,000 lines of meaningful production implementation code for this issue. The minimum excludes tests, documentation, comments-only changes, generated output, vendored code, Solidity fixtures, snapshots, lockfiles, formatting-only churn, and unrelated refactors. Do not pad the implementation to reach the threshold; the required behavior must justify the code through cohesive, maintainable functionality.

CI and conflict-free merge gate

A pull request must not be merged until every required CI check passes on the final commit. At minimum, contributors must preserve a green result for the repository's applicable gates:

• npm ci
• npm run lint
• npm run build
• npm run test
• npm run test:ci --workspace=packages/core
• Package-specific build and test commands for every affected workspace
• The existing ChainProof audit workflow and API documentation build when applicable

Any new workspace, command, detector, report format, plugin capability, server route, compiler adapter, or CI provider integration requires targeted automated coverage. Contributors may not disable tests, relax type or lint rules, reduce coverage, suppress legitimate failures, or alter CI merely to obtain a passing result.

The final PR branch must be updated against the target branch and have no merge conflicts. If rebasing or updating changes the final commit, all required CI checks must run again and pass before merge.