#2373 and #2382 add manual submission key management. #2381 requires clients to seal transaction inputs, updates node senders, forwards the sealed inputs through the RPC, and opens them in the validator.
The validator still stores data derived from the plaintext inputs. Complete Phase 1 by storing the accepted SealedMessage instead.
The validator needs the plaintext to verify the proof, reexecute the transaction, and compare the executed header with the proven header. It must write the encrypted record only after all three checks pass. A rejected request must not add a row or change the validated transaction count.
Required Work
Keep the sealed input envelope in the validator handler while it decrypts and validates a copy. After validation succeeds, write one record with:
transaction_id
submission_scheme
submission_key_id
sealed_transaction_inputs
Store the exact serialized SealedMessage accepted by the validator. Store the scheme and key ID used to decrypt it. Do not store the decrypted inputs.
Remove the current derived fields and their indexes from validated_transactions. Current validator queries need only the transaction ID and row count.
Insert the validated marker and sealed inputs in one database write. An existing transaction ID must keep its first accepted ciphertext.
Add comments at the schema and write path that call this record a Phase 1 stand in. The Phase 2 storage work tracked in #2374 will replace it with data encrypted under a fresh content key. Golden EHTDH1 will protect that content key.
Existing rows do not contain the client ciphertext and cannot be migrated. Add a new database migration and require operators to rebootstrap validator databases before deployment.
Tests
For every rejected new transaction, assert that its ID is absent and the validated transaction count is unchanged. Cover failed decryption, invalid TransactionInputs, failed proof verification, failed reexecution, and a header mismatch.
Also cover:
- A valid submission stores the exact scheme, key ID, and ciphertext.
- A duplicate with different ciphertext does not replace the stored record.
- A failed batch item does not create a record.
- Current and grace key submissions store the key metadata used for decryption.
Prerequisites
PR #2381 must be rebased onto the final #2373 and #2382 contract. It must use the shared schedule verifier and pass the envelope key ID to the key provider.
This issue does not change the submission format or client sealing flow owned by #2381.
Scope
This issue does not add Golden, threshold decryption, a forensics API, TEE key custody, or remote prover encryption.
Anyone with the shared submission secret can decrypt these Phase 1 records. The remote prover still receives plaintext inputs. Document both limits (mitigated by TEE deployment).
This issue is complete when the validator stores only the minimum sealed record, and no failed validation path can create or change that record.
#2373 and #2382 add manual submission key management. #2381 requires clients to seal transaction inputs, updates node senders, forwards the sealed inputs through the RPC, and opens them in the validator.
The validator still stores data derived from the plaintext inputs. Complete Phase 1 by storing the accepted
SealedMessageinstead.The validator needs the plaintext to verify the proof, reexecute the transaction, and compare the executed header with the proven header. It must write the encrypted record only after all three checks pass. A rejected request must not add a row or change the validated transaction count.
Required Work
Keep the sealed input envelope in the validator handler while it decrypts and validates a copy. After validation succeeds, write one record with:
Store the exact serialized
SealedMessageaccepted by the validator. Store the scheme and key ID used to decrypt it. Do not store the decrypted inputs.Remove the current derived fields and their indexes from
validated_transactions. Current validator queries need only the transaction ID and row count.Insert the validated marker and sealed inputs in one database write. An existing transaction ID must keep its first accepted ciphertext.
Add comments at the schema and write path that call this record a Phase 1 stand in. The Phase 2 storage work tracked in #2374 will replace it with data encrypted under a fresh content key. Golden EHTDH1 will protect that content key.
Existing rows do not contain the client ciphertext and cannot be migrated. Add a new database migration and require operators to rebootstrap validator databases before deployment.
Tests
For every rejected new transaction, assert that its ID is absent and the validated transaction count is unchanged. Cover failed decryption, invalid
TransactionInputs, failed proof verification, failed reexecution, and a header mismatch.Also cover:
Prerequisites
PR #2381 must be rebased onto the final #2373 and #2382 contract. It must use the shared schedule verifier and pass the envelope key ID to the key provider.
This issue does not change the submission format or client sealing flow owned by #2381.
Scope
This issue does not add Golden, threshold decryption, a forensics API, TEE key custody, or remote prover encryption.
Anyone with the shared submission secret can decrypt these Phase 1 records. The remote prover still receives plaintext inputs. Document both limits (mitigated by TEE deployment).
This issue is complete when the validator stores only the minimum sealed record, and no failed validation path can create or change that record.