[Fault Proof] No Reference Input - #469
Open
Drop-Table-Users wants to merge 5 commits into
Open
Conversation
Drop-Table-Users
force-pushed
the
fp/no-reference-input
branch
from
July 24, 2026 10:41
c07936f to
3f741b7
Compare
Drop-Table-Users
force-pushed
the
fp/no-reference-input
branch
from
July 27, 2026 07:13
1442582 to
d527aad
Compare
Drop-Table-Users
marked this pull request as ready for review
July 27, 2026 09:50
colll78
added a commit
that referenced
this pull request
Aug 6, 2026
…ilder PR #469 was cut from a 7/29 base that the current tree has long since overtaken. Its entire on-chain diff is superseded — every `no-reference-input` validator and lib module at HEAD is strictly ahead of the PR's version (native binding, `pexcludes_raw` keying, `HeaderV1`, the `native_binding_fixture_v1` step-01 selectors), so none of it is taken. What is taken and adapted to the current boundary: - `demo/midgard-sdk/src/fraud-proof/no-reference-input.ts`: the step-01..04 datum, state, args, and redeemer schemas, reusing the shared `native.js` envelope so the family matches every other fault-proof family. - `demo/midgard-sdk/src/fraud-proof/contracts.ts`: the `NO_REFERENCE_INPUT_FAULT_PROOF_TITLES` blueprint titles and the `noReferenceInput` chain, applied in the blueprint's parameter order, plus the standalone `buildNoReferenceInputFaultProofContracts` entrypoint. - `demo/midgard-fault-proofs/src/prepare-no-reference-input.ts`: the prepare builder, reconciled against the current tree — the `*V1` core codec names, `ROOT_DOMAINS.transactionsV1`, and the `DaPayloadEnvelopeV1` input that `reconstructDaPayloadV1` now takes instead of a raw payload. - `demo/midgard-fault-proofs/tests/prepare-no-reference-input.test.ts`, with its prev-block payload fixture rebuilt on the current `HeaderV1` shape, the canonical ledger-entry descriptor, and the payload envelope wrapper. Dropped as stale: the PR's on-chain diff, its `NeighborSchema`/`phas.ts` fork fix (already landed), its docs-site and always-succeeds blueprint churn, and its `docs/fault-proofs` status edits, which describe submit tooling this change does not land. The four `submit-no-reference-input-step-0N.ts` builders are deliberately not landed. They resolve contracts through `resolveFaultProofDeploymentContracts`, which requires `noReferenceInput` to be a registered `FraudProofCatalogueCategoryName`. That registration is a deployment-identity change spanning the SDK catalogue order and `FraudProofs`, midgard-core's `DEPLOYMENT_MANIFEST_V1_CONTRACT_NAMES` and V1 catalogue-category order, and two hand-pinned catalogue fixtures whose MPF root and per-category membership proofs must be recomputed — all parent-owned under Q18's `pathsMustNotTouch`. Measured: `fraud_proofs/no_reference_input/step_01` 2/2 under both the stock v1.1.22 `aiken` and the fork; `prepare-no-reference-input.test.ts` 13/13; midgard-sdk `fault-proof.test.ts` 20/20 with the new chain registered; `verify-normalized-format` 8/8; `aiken check --skip-tests` green; manifest quality 0 defects and self-test PASS. The Q18 row now records the harvest, the measured counts, and the submit-step blocker. Refs #469
colll78
added a commit
that referenced
this pull request
Aug 6, 2026
PR #473 is the only source of the `reference-input-no-idx` chain: unlike the #469 harvest, nothing of it exists at HEAD, so the whole four-step family is genuinely new and is taken. It is not taken verbatim — the PR was cut from a 7/29 base whose native-tx commitments the current tree has replaced. Adapted to the current boundary: - `onchain/aiken/lib/midgard/fraud-proofs/reference-input-no-idx/step-0{1..4}.ak` and the four matching validators. The PR opened its preimages with `blake2b_256(codec.encode_native_byte_list(...))`; the current native codec commits every collection with `bounded_collection_v1.from_items`, so step-02 now opens consensus field 1 over `encode_midgard_tx_input` and step-04 opens field 2 over `encode_midgard_tx_output`. Step-04's `Args.outputs_preimage` is `List<MidgardTxOutput>` rather than the PR's `List<ByteArray>`, matching `input-no-idx/step-04.ak`. - Every step carries a positive and a valid-block-negative selector driven by `native_binding_fixture_v1`, mirroring the `input-no-idx` selectors; the PR shipped none. - `demo/midgard-sdk/src/fraud-proof/reference-input-no-idx.ts`: the step-01..04 datum, state, args, and redeemer schemas, plus the field-1 reference-inputs and field-2 outputs commitment helpers, reusing the shared `native.js` envelope and the `input-no-idx` canonical encoders. - `demo/midgard-sdk/src/fraud-proof/contracts.ts`: the `REFERENCE_INPUT_NO_IDX_FAULT_PROOF_TITLES` blueprint titles, the `referenceInputNoIdx` chain in the blueprint's parameter order, and the standalone `buildReferenceInputNoIdxFaultProofContracts` entrypoint. - `demo/midgard-fault-proofs/src/prepare-reference-input-no-idx.ts` with its test, reconciled against the `*V1` core codec names and `ROOT_DOMAINS.transactionsV1`, with the PR's cross-branch `NriReferenceInputPreimageEntry` import inlined and the outputs artifact renamed `outputsPreimageCbor` to say what it holds. Corrected claim: the PR asserted that steps 02-04 compile to the same UPLC as `input-no-idx` and that the two chains share those three scripts. Measured against the current tree, only steps 03 and 04 are shared — `input-no-idx` step-02 has since grown a Direct/Folding state and a four-constructor args enum, so step-02 is now distinct. The tests pin 6 distinct applied hashes across the eight steps, and the whole applied proof surface moves 131 -> 133. Dropped as stale or out of scope: the PR's `rinx-submit-step-0{1..4}.ts` builders and the `bin.ts`/`runtime.ts`/`submit-init.ts` wiring they need, its `catalogue.ts` and `FraudProofs` registration, its always-succeeds blueprint and docs-site churn, and its `docs/fault-proofs` status edits (two of those files are parent-owned). The submit builders are deliberately not landed. They resolve contracts through `resolveFaultProofDeploymentContracts`, which requires the family to be a registered `FraudProofCatalogueCategoryName`. That registration is a deployment-identity change spanning the SDK catalogue order and `FraudProofs`, midgard-core's `DEPLOYMENT_MANIFEST_V1_CONTRACT_NAMES` and V1 catalogue-category order, and two hand-pinned catalogue fixtures whose MPF root and per-category membership proofs must be recomputed. The Q31 manifest row previously recorded a structural-N/A disposition reducing the family to validation-trace ResolveInputs, with "zero standalone reference-input-no-idx family/category inventory" as an expected output and "standalone Q31 family/category appears" as an invalidation trigger. That trigger has now fired, so the row is re-derived: it leases the real family paths, its focusedCommands all resolve, and it records the measured counts and the submit-step blocker. The ResolveInputs guard is kept as the adjacent anchor. Measured: each of `fraud_proofs/reference_input_no_idx/step_0{1..4}` 2/2 under both the stock v1.1.22 `aiken` and the fork, identical counts, 8 selectors total; `prepare-reference-input-no-idx.test.ts` 10/10; midgard-sdk `fault-proof.test.ts` 23/23; `verify-normalized-format` 8/8; `aiken check --skip-tests` green; `tsc --noEmit` clean for midgard-sdk and midgard-fault-proofs; manifest quality 0 defects and self-test PASS. Pre-existing red, unrelated and present at the base commit: `inspect-contracts.test.ts` catalogue-readiness digest and `validation-resolver-applied-hashes.test.ts` applied-hash fixture. Refs #473 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
colll78
added a commit
that referenced
this pull request
Aug 6, 2026
…ation Records the owner-directed harvest of PRs #469/#473/#474 (supersession verdicts, adaptations, added on-chain coverage, the shared catalogue- registration blocker), the 388-validator dual-compiler agreement, the fresh harvest blueprint aaefc713…, and the passing deposit -> L2 -> withdrawal journey (1/1, 204.4 s). Refs #469, #473, #474 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Collaborator
|
Harvest record (owner-directed, 2026-08-05, ledgered in 6ec50b0): the SDK family module, chain builder, prepare-no-reference-input + tests, and index exports were harvested onto the Goal branch as commit 5bd3556 (adapted to current HeaderV1/codecs). The PR's on-chain half (all 8 .ak files) is SUPERSEDED — the Goal branch carries strictly newer versions (native binding, pexcludes_raw keying, fixture selectors this branch lacks), so merging this PR as-is would regress them. Remaining for the family: submit-step builders, blocked on the catalogue/deployment-identity registration tracked as #547. Leaving the PR open for the author's disposition. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Midgard E2E Run - Preprod Transaction Hashes
Setup / Protocol
Reference Scripts
Block Header Commits
DA Attestation L1 Txs
Confirmed-State Merges
Midgard No Reference Input Fault Proof Drill - Preprod
Faulty Block
1cee59cbf369cb140dc98eca8d631e2d113db9c672137eade9d92748584066f67a9802dc076fe850c9d43e5cd4ef13fbd7b2c09942f7d12dd9821ebe#0a610d3aed90add97fe7f698547299f56e6472880814e808334bca3cfc99c2e98dededededededededededededededededededededededededededededededede#0Proof Preparation
b01bc44743de0ede528f1cb8892a7be73b6b0eaacea6a5a4c9a19ed7e2d6ae21623df1167efde14180e94e916f4dad1db9f7c33a8b6d35cb128b14aacee154d23a26f379087c26df632022493d076ec1fe2e043d73f41c1bdd72843503c1c6e0Fault Proof Transactions
2a66406675baf0d6f8d93cb5852803d017a9c1d178537c90a42623ed781ba58e#0Block Removal