Skip to content

SPIKE: Protocol 28 (CAP-0085)#1525

Draft
sisuresh wants to merge 1 commit into
stellar:mainfrom
sisuresh:p28-cap-0085
Draft

SPIKE: Protocol 28 (CAP-0085)#1525
sisuresh wants to merge 1 commit into
stellar:mainfrom
sisuresh:p28-cap-0085

Conversation

@sisuresh

Copy link
Copy Markdown

SPIKE (draft): Protocol 28 / CAP-0085 — externally managed contract executables. Based on the canonical XDR in stellar/stellar-xdr#308.

Changes

  • Makefile: pin the next XDR channel to stellar-xdr#308 head (76218a99) and add XDR_FEATURES_NEXT=CAP_0085_EXECUTABLE_REF (next-only; curr pin/features left unchanged — protocol 28 is not on curr yet).
  • xdr/next/Stellar-contract.x + regenerated src/base/generated/next_{generated.js,d.ts}: SCVal SCV_EXECUTABLE_TAG (22), ContractExecutable CONTRACT_EXECUTABLE_EXTERNAL_REF (2), and ContractExecutableExternalRef struct. String fields typed string | Buffer (the codec's convention; ScString is a value, not a type).
  • Added scripts/post-process-generated.py (xdrgen const-inlining, mirrors the CAP-0084 stack) and applied it to next_generated.js: the next codec was un-loadable on main (bare SCSYMBOL_LIMIT/SC_SPEC_DOC_LIMIT → ReferenceError), which blocked verifying the new types.
  • Verified: next codec round-trips scvExecutableTag and ContractExecutable external_ref; pnpm build:prod (tsc) passes.

Deferred

  • No SDK convenience constructor for external-ref executables or for building an SCV_EXECUTABLE_TAG (host-side operation; scValToNative's default already decodes the arm). Flagged for reviewer.
  • curr const-inlining left untouched (pre-existing; curr uses the older declaration style the script would corrupt, and it's out of scope for CAP-0085).
  • Full make generate at the new pin would also surface an unrelated upstream Stellar-ledger.x comment change (stellar-xdr main, not Update Axios #308); not in this PR's committed files (targeted edits).

Upstream

Independent of the CAP-0083/CAP-0084 p28 SPIKE stacks. Stays draft.

Pin the vendored next-channel XDR to stellar-xdr#308 head
(76218a994f8c5ba752cba368080fb2f89843ad3c) and enable
CAP_0085_EXECUTABLE_REF on the `next` channel only (protocol 28 is not on
`curr` yet; the curr pin is left unchanged). Split the Makefile
XDR_FEATURES into _CURR/_NEXT so the cap flag applies to next only.

Targeted codec additions to src/base/generated/next_{generated.js,d.ts}
(regen-shape preserved): SCVal SCV_EXECUTABLE_TAG arm (22), ContractExecutable
CONTRACT_EXECUTABLE_EXTERNAL_REF variant (2), and ContractExecutableExternalRef
struct. String fields are typed `string | Buffer` per the codec's existing
convention (ScString is a value, not a type). scValToNative's default case
already handles the new SCVal arm, so no hand-written SDK helpers were added.

Wire scripts/post-process-generated.py (xdrgen const-inlining, mirrors the
CAP-0084 stack) into the Makefile and apply it to next_generated.js: the
next codec was un-loadable on main (bare `SCSYMBOL_LIMIT`/`SC_SPEC_DOC_LIMIT`
refs ReferenceError), which blocked verifying the CAP-0085 types. curr is
left untouched (it uses the older declaration style; the script would corrupt
it and curr is out of scope for CAP-0085).

Verified: next codec round-trips scvExecutableTag and ContractExecutable
external_ref; `pnpm build:prod` (tsc) passes against the new .d.ts.

Canonical XDR: stellar/stellar-xdr#308. Host draft context:
stellar/rs-soroban-env#1703.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Backlog (Not Ready)

Development

Successfully merging this pull request may close these issues.

1 participant