Skip to content

chore(piltover): align with new ProgramInfo enum + plumb katana_tee_config_hash - #72

Merged
kariy merged 1 commit into
feat/teefrom
chore/piltover-abi-enum-split
Apr 29, 2026
Merged

chore(piltover): align with new ProgramInfo enum + plumb katana_tee_config_hash#72
kariy merged 1 commit into
feat/teefrom
chore/piltover-abi-enum-split

Conversation

@kariy

@kariy kariy commented Apr 29, 2026

Copy link
Copy Markdown
Member

Summary

Aligns Saya with cartridge-gg/piltover#feat/tee-persistent's ProgramInfo enum split, and threads the new katana_tee_config_hash field from the Katana RPC response through the TEE pipeline into the on-chain TEEInput.

Why

Piltover now identifies the appchain via two distinct variants:

enum ProgramInfo {
    StarknetOs(StarknetOsProgramInfo),  // 4 SNOS-related hashes
    KatanaTee(KatanaTeeProgramInfo),    // 1 katana_tee_config_hash (Pedersen array)
}

Each deployment commits to one variant; validate_input panics on cross-mode submission. For the TEE path, validate_input also asserts tee_input.katana_tee_config_hash == KatanaTeeProgramInfo.katana_tee_config_hash, so Saya needs to source that exact value (the one Katana attested) and pass it through.

Changes

  • 3 Cargo.toml piltover repoints to cartridge-gg/piltover#feat/tee-persistent. Single source of truth across root + bin/persistent + bin/persistent-tee.
  • 5 Cargo.toml katana-tee revs bumped to 649f0864 (head of feat/test-block-0 after cartridge-gg/katana-tee#1). TeeQuoteResponse now exposes katana_tee_config_hash.
  • bin/ops/src/core_contract/utils.rs::set_program_info prepends Felt::ZERO (the StarknetOs variant index) to the calldata. ops stays ZK-only; symmetric TEE-mode deployment is a separate task.
  • saya/core::TeeAttestation / TeeProof gain katana_tee_config_hash: Felt.
  • bin/persistent-tee/src/{attestor,prover,settlement}.rs plumb the field through: attestor lifts it off the RPC response, prover threads it through both the TeeQuoteResponse round-trip and TeeProof, settlement passes it to TEEInput.katana_tee_config_hash.
  • tests/e2e/tests/settlement.rs matches the StarknetOs variant before reading the four hash fields. Same asserts, one extra match at the top.

What does NOT change

  • LayoutBridgeOutputNoDa / LayoutBridgeOutputWithDa wire format — bin/persistent validity-proof code is byte-identical.
  • TeeInput outer wire shape — only the new field is added; everything else flows through unchanged.
  • bin/persistent Saya logic — only the dep bump.
  • The placeholder TeeProver in saya/core/src/prover/tee/mod.rs — also threads the field through.

Cross-repo

Repo PR Status
cartridge-gg/piltover #16 merged
cartridge-gg/katana-tee #1 merged
dojoengine/katana #556 open (the producer side)
dojoengine/saya this PR here

…onfig_hash

`cartridge-gg/piltover#feat/tee-persistent` (`ebb714b`) split `ProgramInfo` from
a 4-field struct into an enum (`StarknetOs(StarknetOsProgramInfo)` vs
`KatanaTee(KatanaTeeProgramInfo)`). Each Piltover deployment commits to one
variant at config time; `validate_input` panics on cross-mode submission. The
on-chain assertion `tee_input.katana_tee_config_hash == KatanaTeeProgramInfo
.katana_tee_config_hash` now needs the same versioned environment hash to flow
from the Katana node through Saya's TEE pipeline into the settlement payload.

This commit:

* Repoints `piltover` to `cartridge-gg/piltover#feat/tee-persistent` (3 Cargo
  manifests).
* Bumps `katana-tee` deps to `649f0864` to pick up
  `cartridge-gg/katana-tee#1`, which surfaces `katana_tee_config_hash` on
  `TeeQuoteResponse` (5 deps, all in `bin/persistent-tee/Cargo.toml`).
* `bin/ops/src/core_contract/utils.rs::set_program_info` now prepends the
  `StarknetOs` variant index to the calldata. `ops` stays ZK-only; TEE-mode
  deployment is a separate work item.
* Threads `katana_tee_config_hash` through `TeeAttestation` (saya/core),
  `TeeProof` (saya/core), `bin/persistent-tee/{attestor,prover}.rs`, and into
  the on-chain `TEEInput.katana_tee_config_hash` at
  `bin/persistent-tee/src/settlement.rs`.
* Updates `tests/e2e/tests/settlement.rs` to match the `StarknetOs` enum
  variant instead of accessing struct fields directly. The four hash asserts
  are unchanged, just nested behind one match.

Wire format for `update_state(piltover_input)` (both `LayoutBridgeOutput*` and
`TeeInput`) is unchanged. The runtime variant invariant in `validate_input`
fires before any registry call, so cross-mode submission fails fast on chain.

Cross-repo:
- `cartridge-gg/piltover#16` (merged): Cairo-side enum split.
- `cartridge-gg/katana-tee#1` (merged): adds the field on the wire.
- `dojoengine/katana#556` (open): produces the field on the wire + `katana
  init rollup` deployment-side parity.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@kariy kariy changed the title chore(piltover): align with new ProgramInfo enum + plumb katana_tee_config_hash chore(piltover): align with new ProgramInfo enum + plumb katana_tee_config_hash Apr 29, 2026
@kariy
kariy merged commit 0072383 into feat/tee Apr 29, 2026
5 checks passed
kariy added a commit that referenced this pull request Apr 29, 2026
…ployed address

The cherry-pick of #72 onto `main` aligned Saya's Rust code with the new
`ProgramInfo` enum, but the e2e settlement test still deploys the OLD
Piltover Cairo class (vendored at `contracts/core_contract.json`,
generated from the pre-enum-split `piltover` submodule). Result: cainome
reads `get_program_info()` as the new enum shape but the on-chain
contract returns the old 4-felt struct, surfaced as
"Index not handle for enum ProgramInfo".

Bump the `piltover` submodule from `37e487f` to `ebb714b`
(cartridge-gg/piltover#feat/tee-persistent merge head, includes #16's
enum split). Rebuild `contracts/core_contract.json` via
`scarb build` in the submodule.

The new Sierra class hash is
`0x38a8e7e81744f89ae85d64c036101c124c19b4e6844c6d73f922f03d89487e6`
(was `0x...`), so the UDC-derived deployed address changes too. Computed
via `starknet::core::utils::get_contract_address(salt=0x0, class_hash,
calldata=[katana0_addr, 0, Felt::MAX, 0], deployer=0x0)`:

  old: 0x387f8d08b19b4f0b3809a3411eab4a27f804ad672a37faeab77bd99af2b9896
  new: 0x5f8c60f1c40b63452d3b5cb39669d35b37ec57d0761ad12ecdadd00c3d90102

Update all 8 hardcoded references across `compose.{yml,e2e.yml,l2.yml,l3.yml}`
including the `sn_msg` deploy calldata (it takes the Piltover address).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.

1 participant