Submit High-Level Technical Architecture Proposal by ethanfrey · Pull Request #11 · stellar-registry/cli

ethanfrey · 2026-06-10T11:13:24Z

As discussed, here is my proposal of a high-level technical architecture and how the various teams would collaborate in this framework.

See the rendered version here

chadoh

Overall this looks GREAT. Thank you! I have a few comments & suggestions before merging:

chadoh · 2026-06-10T15:29:47Z

+  end
+  subgraph AHA["Aha — contracts + read"]
+    BReg["Build-info registry<br/>contract"]
+    VContract["Verification contract<br/>(Registry sibling)"]


I'm not convinced it's useful to have a Verification contract separate from the main contract. Convince me.

All contracts could be merged into one. Logically they are independent actions, so you could write 3 contracts (trigger, attestations, and your current registry), but you could also fold this all into your current registry.

Feel free to modify, this will be your code

chadoh · 2026-06-10T16:02:27Z

+- **Sandboxes run on a different machine from the control plane.** The worker executes untrusted build logic (a contract's `build.rs` can do anything), so it must be isolated from the host and, critically, from the signing key. The worker returns only a result and a computed hash; it can never sign or submit. Hermetic, network-isolated rebuild is the defense against build-time exfiltration — not source scanning.
+- **Elastic in the bootstrap phase.** During the initial back-verification crunch the engine fans out to many ephemeral workers to attempt thousands of candidate blobs (and, for metadata-absent blobs, multiple `version × flag × arch` combinations) in parallel. This is where most of the day-one coverage is produced.
+- **Down to one isolated worker in steady state.** Once the corpus is processed, ongoing verification of new deployments needs only a single isolated worker. An operator who wants lower ops overhead can run the worker on the same machine as the control plane — an explicit security-for-simplicity tradeoff, not a default.
+- **Image trust as a gradient.** The engine records `arbitrary → auditable → sdf_trusted` rather than a binary, anchored on the SDF-allowlisted trusted images.


This point seems like it's in the wrong place. This is a feature of the system as a whole, not of the Verifier engine. The Verifier Engine runs a single check and reports its binary result to the Verification Contract. Right? This could probably be moved to the bulleted list in "Indexer | Query API" instead, bu the "Variable trust at the endpoint" already sort of covers it.

Suggested change - **Image trust as a gradient.** The engine records `arbitrary → auditable → sdf_trusted` rather than a binary, anchored on the SDF-allowlisted trusted images.

The "suggested change" somehow got messed up above; see comment below for well-formed "remove this line" gh suggestion.

chadoh · 2026-06-10T16:24:57Z

+
+**Milestone 2 — Verification engine (lead: Runtime Verification).** RV implements the verification side: the hermetic rebuild engine, signing, and claim submission, tested end-to-end. Aha provides **stub contracts** for the build-info trigger and claim write path (minimal — just enough to exercise the flow). Ethan guides the design where needed.
+
+**Milestone 3 — Contracts, indexer & query engine (lead: Aha).** Finalize the two contracts, build the GoldSky indexer and the query API. In parallel, ongoing recovery of existing contracts' build metadata and verification of the flow at scale.


Just a quick note here that this "two contracts" language occurs throughout. If we decide to go with just-the-one, we will need to scan the whole document for these occurrences.

chadoh · 2026-06-10T16:29:09Z

+- **Sandboxes run on a different machine from the control plane.** The worker executes untrusted build logic (a contract's `build.rs` can do anything), so it must be isolated from the host and, critically, from the signing key. The worker returns only a result and a computed hash; it can never sign or submit. Hermetic, network-isolated rebuild is the defense against build-time exfiltration — not source scanning.
+- **Elastic in the bootstrap phase.** During the initial back-verification crunch the engine fans out to many ephemeral workers to attempt thousands of candidate blobs (and, for metadata-absent blobs, multiple `version × flag × arch` combinations) in parallel. This is where most of the day-one coverage is produced.
+- **Down to one isolated worker in steady state.** Once the corpus is processed, ongoing verification of new deployments needs only a single isolated worker. An operator who wants lower ops overhead can run the worker on the same machine as the control plane — an explicit security-for-simplicity tradeoff, not a default.
+- **Image trust as a gradient.** The engine records `arbitrary → auditable → sdf_trusted` rather than a binary, anchored on the SDF-allowlisted trusted images.


Not sure what happened with my previous "suggestion":

Suggested change

- **Image trust as a gradient.** The engine records `arbitrary → auditable → sdf_trusted` rather than a binary, anchored on the SDF-allowlisted trusted images.

I applied another suggestion that seemed identical to this one. Gonna mark this as done

The "Image trust as a gradient" bullet point is still in the doc. I think we should remove it from this "Verifier engine" section.

Co-authored-by: Chad Ostrowski <221614+chadoh@users.noreply.github.com>

elizabethengelman

Just looked at this and #9 for the first time, so I'm adding some questions as I'm processing things. Feel free to punt on answering them until after the RFP due date if they're not helpful in the short term. But overall, this looks great & I'm excited to see how this project evolves!

elizabethengelman · 2026-06-11T16:42:21Z

+
+**Trigger A — native SEP-58 metadata in the wasm (the end state).** Any wasm uploaded to the network is checked. If it already embeds sufficient SEP-58 build metadata (`bldimg`, `bldopt`, source identifiers), that upload itself is enough: verifiers pick it up directly from the wasm and run verification immediately, with **no registry contract involved**. This is the steady-state path — a wasm that ships with proper metadata is verifiable the moment it lands.
+
+**Trigger B — build-info registry (the bridge from today).** Many already-deployed wasms carry no metadata, and not every future upload will embed it. The build-info registry covers them. Keyed by `wasm_hash`, it lets build info be submitted for a wasm that lacks it on-chain. Writing it **emits a build-info event** verifiers pick up, exactly as native metadata would. For **existing contracts** that predate the standard, build info is recovered off-chain and written here by an **authorized manager key** — the original wasm uploader or an Aha-governed manager, *not* anyone, so the registry can't be spammed with junk build info. This contract is the bridge between the current state (most contracts unverifiable) and the end state (metadata native in the wasm).


The way I'm reading this is that Trigger B includes these 2 scenarios:

old contracts that don't have build info because they predate the build info standard

new contracts that don't imbed build info for whatever reason

To make sure I'm understanding, the former scenario is handled by recovering build info off-chain and a manual write, which will emit the build info event which notifies the verifiers.

For the latter scenario, does this happen automagically by way of the registry? or is this also a manual process?

That's all correct! For the latter scenario: nothing automagical. These wasm authors would need to go through the same Registry Governance Proposal To Add Wasm Build Info process as the former scenario.

elizabethengelman · 2026-06-11T16:50:59Z

+  IX->>IX: materialize into queryable view
+```
+
+Authorization — who may register build info, who may submit claims, manager-key governance — is owned by Aha. The claim shape and event schemas are fixed in Milestone 1 so all parties build against a stable interface.


Maybe a question for @chadoh, but is this where Tansu comes in?

Yes, these will be proposals created in Tansu. A small security council of known reviewers will vote on these proposals, and if the proposal passes, then the build info will be added to the registry.

Note that this is only for the root registry. The unverified registry could have these build_info_added events (or whatever the name turns out to be) emitted willy-nilly, but there is no reason for source verifiers to listen to those events. And other subregistries will be owned by various orgs (OZ, blend, etc), each of which are free to define their own governance processes. It's unclear to me at this point if source verification services will care to verify the sources of wasms added to these other subregistries.

ehildenb · 2026-06-11T19:27:54Z

This looks good to me overall from the Runtime Verification perspective!

`rfps/source-verification` is now a directory with: - README.md: the copy-pasted source of the RFP document itself - full-application.md: our work-in-progress responses for the full form submission - technical-architecture-highlevel.md: copy-pasted from #11

`rfps/source-verification` is now a directory with: - README.md: the copy-pasted source of the RFP document itself - full-application.md: our work-in-progress responses for the full form submission - technical-architecture-highlevel.md: copy-pasted from #11 Co-authored-by: Ethan Frey <ethanfrey@noreply.github.com>

chadoh · 2026-06-11T20:19:52Z

Closing in favor of #8, which now includes this full document.

Submit High-Level Technical Architecture Proposal

d066f38

chadoh requested changes Jun 10, 2026

View reviewed changes

chadoh reviewed Jun 10, 2026

View reviewed changes

ethanfrey and others added 4 commits June 11, 2026 12:54

Update rfps/technical-architecture-highlevel.md

708616e

Co-authored-by: Chad Ostrowski <221614+chadoh@users.noreply.github.com>

Update rfps/technical-architecture-highlevel.md

4922025

Co-authored-by: Chad Ostrowski <221614+chadoh@users.noreply.github.com>

Update rfps/technical-architecture-highlevel.md

795f0ca

Co-authored-by: Chad Ostrowski <221614+chadoh@users.noreply.github.com>

Update rfps/technical-architecture-highlevel.md

29f8eac

Co-authored-by: Chad Ostrowski <221614+chadoh@users.noreply.github.com>

elizabethengelman reviewed Jun 11, 2026

View reviewed changes

elizabethengelman mentioned this pull request Jun 11, 2026

Source Verification RFP Submission #9

Closed

chadoh closed this Jun 11, 2026


		Milestone 2 — Verification engine (lead: Runtime Verification). RV implements the verification side: the hermetic rebuild engine, signing, and claim submission, tested end-to-end. Aha provides stub contracts for the build-info trigger and claim write path (minimal — just enough to exercise the flow). Ethan guides the design where needed.

		Milestone 3 — Contracts, indexer & query engine (lead: Aha). Finalize the two contracts, build the GoldSky indexer and the query API. In parallel, ongoing recovery of existing contracts' build metadata and verification of the flow at scale.


		Trigger A — native SEP-58 metadata in the wasm (the end state). Any wasm uploaded to the network is checked. If it already embeds sufficient SEP-58 build metadata (`bldimg`, `bldopt`, source identifiers), that upload itself is enough: verifiers pick it up directly from the wasm and run verification immediately, with no registry contract involved. This is the steady-state path — a wasm that ships with proper metadata is verifiable the moment it lands.

		Trigger B — build-info registry (the bridge from today). Many already-deployed wasms carry no metadata, and not every future upload will embed it. The build-info registry covers them. Keyed by `wasm_hash`, it lets build info be submitted for a wasm that lacks it on-chain. Writing it emits a build-info event verifiers pick up, exactly as native metadata would. For existing contracts that predate the standard, build info is recovered off-chain and written here by an authorized manager key — the original wasm uploader or an Aha-governed manager, not anyone, so the registry can't be spammed with junk build info. This contract is the bridge between the current state (most contracts unverifiable) and the end state (metadata native in the wasm).

Conversation

ethanfrey commented Jun 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chadoh left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elizabethengelman left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ehildenb commented Jun 11, 2026

Uh oh!

chadoh commented Jun 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ethanfrey commented Jun 10, 2026 •

edited

Loading