User problem

Status: design proposal. There is no general-purpose service ABI implementation or release commitment. We want a CellScript parent Script to invoke independently implemented verification services, pass bounded arguments, receive typed results, and guarantee that failures cannot masquerade as successful verification. Prefer evaluating reuse of ckb-script-ipc; consider an independent implementation only where a concrete incompatibility justifies it.

CellScript compiles to CKB ELF. The existing open child-verifier profiles in #28/#29 only admit restricted argument-free paths. Separate specialised ZK and byte-context transports also exist. Existing spawn/pipe primitives or specialised calls do not establish a general-purpose, parameterised, arbitrary-typed cross-contract service. #80 constrains Script instances; it does not automatically extend VerifierHandle argv.

The overall choice and SSRI work are linked under Design workstreams below. This issue owns the on-chain invocation contract; an off-chain service-query adapter is no substitute for VM acceptance here.

Define what an “invocation” means

Different Script groups in the same CKB transaction validate their own rules independently. A child spawned by a parent Script executes in the caller's transaction/Script context; it does not automatically become another Script group belonging to the referenced contract, nor does it acquire spending authority over that group's Cells.

The first experiment should use an ordinary, stateless document-digest policy verifier. The parent obtains the inspected data and domain from the real transaction; the child validates one fixed request and returns an explicit result. A request may contain a selected instance, but that instance is explicit data to be checked, not the child's automatically acquired load_script identity. Its response also cannot substitute for actual execution of credential Type and holder Lock Scripts.

sequenceDiagram
  autonumber
  participant P as Parent Script
  participant I as Identity / instance admission
  participant C as Child verifier
  participant G as Other required Script groups
  P->>I: Actual CellDep, policy, concrete target
  I-->>P: Exact permitted code and profile
  P->>P: Construct bounded request and domain from transaction
  P->>C: spawn + request
  C->>C: Check method, context, lengths and business rules
  C-->>P: Bounded response or failure
  P->>P: Validate result, complete protocol, check child status
  Note over P,C: Cleanup, waiting and failure semantics must be frozen for the chosen protocol
  G->>G: Independently validate their Lock / Type rules
  Note over P,G: Every required group must succeed for the transaction to pass

Pinned source observations, without a premature ranking

Research baseline: ckb-script-ipc @ 4044faee.

• The #[service] macro generates Rust trait clients/servers and request/response enums, reducing handwritten communication code.
• The Channel uses serde_json by default; Packet uses VLQ framing. The default RequestPacket method_id is 0; the generated payload expresses the method. One cannot insert an SSRI 64-bit path and claim compatibility.
• Spawn helpers return two Pipes; the common API does not expose process_id to the caller. The server runs a repeated-request loop. Explicit WAIT/exit inspection or one-shot termination may require adaptation or upstream extensions; do not assume these are already exposed by the high-level API.
• The inspected packet reader allocates according to a length declared by its peer. A CellScript profile must impose a pre-allocation input ceiling and define VLQ/version/integer-conversion boundaries. This is an integration requirement, not a claim that an upstream vulnerability has been found.
• The library also has a native service-execution entry point; an SSRI-vs-IPC comparison cannot be reduced to “one is off-chain, the other on-chain”.

Underlying behaviour follows RFC 0050 and pinned CKB source. CellScript's current accepted baseline uses CKB f7fa4436737756f97a24e254f22c13a36316ecea / 0.207.0. New experiments must record the actual VM/ckb-std/library versions; the CKB name alone does not establish universal network support.

Contract to freeze for v1

Suggested initial experiment: one child, one fixed method, one request/response, fixed-width data, and no recursive calls. A second experiment can examine the benefit of two sequential requests to one child. These are decision candidates; numeric budgets must be fixed before measurements rather than delegating all limits to the chain-wide cycle budget.

A return value may be used only after semantic checks. A bare true, for example, cannot authorise cross-instance actions: the request must bind at least the current domain, consumer, target code/instance, method, and relevant state. If binding the full raw transaction hash, account for the fact that witnesses/signatures are not covered by the raw hash. Specify which payloads are committed separately, avoiding self-reference and omitted authorisation.

Implementation approaches to compare

1. Upstream macro + default Channel/JSON: directly interoperable with the pinned baseline; measure total costs including identity and resource checks.
2. Reuse upstream framing/runtime + explicitly negotiated bounded codec: can default-macro interoperability be preserved? If not, introduce a distinct profile name and capability-discovery rules.
3. Fixed Molecule/byte transport: baseline extension of existing specialised CellScript calls; implement independently only if evidence on boundaries and maintenance cost warrants it.
4. Retain specialised calls and defer generalisation: a valid outcome if there is no further application benefit or measurable costs are unacceptable.

SSRI may share an abstract interface description, but matching names do not make method IDs, argv, frames, or JSON/Molecule interoperable. Conversion requires bidirectional golden vectors and explicit disclosure of types/errors that cannot be mapped losslessly.

Incremental implementation and native Rust comparison

1. Implement the same one-shot verifier in native Rust with pinned ckb-std, explicitly handling the actual CellDep, context, request origin, and failure propagation. Rust can also wrap these checks in reusable libraries; repeated handwritten code is not an inevitable Rust disadvantage.
2. Benchmark the unmodified upstream IPC library on the same scenario. Prepare a minimal adaptation list for genuinely missing exit/budget APIs and prioritise discussion of upstream contributions.
3. Use the existing fixed CellScript path as a third baseline before designing a candidate service description. New syntax is a subsequent choice; first assess whether existing typed metadata can express it.
4. Freeze wire vectors and a host reference decoder. Feed identical requests to the Rust server and generated candidate, requiring identical outcomes and errors.
5. Carry ownership/effects, IR, codegen, checker, LSP/formatter, WASM summary, and builder through the explicitly supported scope; reject unsupported type combinations at compile time.
6. Exercise valid and malicious transactions using the real scheduler, parent/child processes, and all required Script groups. Compare maximum successful and latest-failing cycles, memory, ELF size, and transmitted bytes. Host mocks or native-server success are not substitutes.

Failure matrix (review these first)

Authoring direction — 2026-10-19

Apply the authoring requirements in #47/#48/#49 to the candidate service interface. Review named service methods with typed requests/results, structurally resolved target policies, and named budgets declared once at the appropriate service or session scope. Ordinary application code should express the business request, checked result, and permitted effects without repeatedly supplying role ordinals, positional size parameters, raw file descriptors, or framing details. Generated adapters may carry that plumbing, but must bind it to the same canonical interface and execution evidence. This is an API design target, not an implemented syntax or a choice of transport.

A one-shot call may encapsulate spawn/send/read/close/wait only if its declared success condition includes the required child termination and error checks. A repeated-request session must expose its bounded lifetime and completion obligation; early returns and failures must have specified cleanup and acceptance behaviour. Helpers must not let an unchecked response or unfinished session be treated as successful verification. Review these obligations explicitly even when the call site becomes concise.

Keep local borrowing separate from messaging. A bounded non-escaping helper may inspect a local view under its original provenance and lifetime; transferring a request across processes requires a specified bounded encoding, never a borrowed pointer or implicit shared ownership. Decoding a response grants no Cell lifecycle authority. Fixed-width messages must remain investigable without #47 allocation; nested messages depend only on the chosen #48 codec scope. If owned buffers or collections are needed, make their allocation scope and named byte/element limits explicit.

Before stable API review, provide complete one-shot and two-request examples with declarations, caller and server, helper composition, and terminal failure paths. Show the Rust and CellScript forms under equivalent identity, context, codec, and budget rules. Keep source ergonomics, wire compatibility, process lifecycle, and independent checker evidence as separately assessed criteria; a shorter call cannot weaken any acceptance condition.

Dependencies on #47/#48/#49 and later applications

Fixed request/response does not require a general heap or nested dynamic values. Nested variable-length messages depend on the specific codec in #48, not automatic support for arbitrary recursive objects on issue closure. Owned dynamic collections depend on #47 when actually required; bounded read-only decoding can stand alone. #49 governs heterogeneous Cell collections and correspondence, and is not replaced by IPC. Hooks #69, economic deltas #71, and routers #75 must separately establish user authorisation, complete asset flows, and actual Script-group execution.

Design closure criteria

• Review complete typed one-shot and repeated-request authoring examples against [0.33][Runtime] Add bounded allocation-backed value collections and deterministic Map/Set #47/[0.33][ABI] Support bounded nested dynamic values with canonical codecs #48/[0.33][Runtime] Extend bounded Cell selection and correspondence for heterogeneous and dynamic data #49, including named limits, bounded helper composition, encoding ownership, early-exit cleanup, and mandatory child completion before stable API freeze.
• Full target, method, context, permission, codec, budget and termination contracts, with owners and decision criteria for unresolved questions.
• Reproducible trade-off assessment of all four approaches; disclose every incompatibility with upstream defaults.
• Equivalent Rust/upstream-IPC/fixed-CellScript experiments and measurement plans with concrete artefacts and expected results.
• Failure matrix mapped to compiler/checker/VM/whole-transaction levels, documenting any unproven properties.
• Upstream discussions, actual review feedback, and maintainer decisions recorded. Create separate implementation acceptance items; design approval is not completion.

Questions for reviewers: How should the service loop lifecycle interact with parent acceptance? Does default JSON convenience outweigh its protocol costs, and what measurements support that? Can we keep upstream-client interoperability while enforcing limits before allocation? Which child results merit typed capabilities and which should remain ordinary data? Who maintains versioning and adapters?

Design workstreams

Overall selection: #81. SSRI entry and off-chain context: #82. This issue is #83. Fixed-message experiments need not wait for the SSRI entry or full completion of #47/#48/#49.

Further reading

ProtocolBundle end-to-end tutorial.