logos-co/rfp
1
0
Fork 0
mirror of https://github.com/logos-co/rfp.git synced 2026-08-31 05:51:14 +00:00
Code Issues Packages Projects Releases Wiki Activity

RFP-020 + appendix + slides: clarify Schnorr-exposure benefit is public-mode CU only

Browse Source 
Tightens the framing around "LEZ exposing BIP-340 Schnorr verification to
guest programs" so the benefit is stated explicitly: lower public-mode
compute-unit cost on the aggregator write side (analogous to shape D's
ECDSA precompile follow-on, with a smaller engineering ask since the
runtime primitive already exists). It does not unblock private-execution
pull, because a host function lives outside the ZK proof boundary and so
cannot be called from inside the privacy circuit (the same D2 structural
argument that forecloses private pull under an ECDSA precompile).

Also fixes RFP-020's out-of-scope bullet, which previously listed a LEZ
secp256k1 + keccak256 precompile alongside a RISC0 zkVM accelerator as
possible unblockers for private-execution pull. Only the latter (or a
different upstream signature scheme with cheap in-circuit cost) actually
reaches private execution; the precompile is public-mode only.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
fryorcraken
2026-05-05 14:48:44 +10:00
co-authored by Claude Opus 4.7
parent d7094254e0
commit 141611fec8
3 changed files with 67 additions and 40 deletions
Download Patch File Download Diff File Expand all files Collapse all files
RFPs/RFP-020-redstone-oracle-adaptor.md
+1 -1
View File
@@ -56,7 +56,7 @@ Out of scope at the Overview level (full list under Out of Scope below):
- The on-chain TWAP tier and the canonical oracle price account standard, owned by [RFP-019](./RFP-019-twap-oracle.md).
- A Pyth adaptor: depends on Wormhole on LEZ, deferred to a future RFP.
- Pull-mode reads from inside private execution: blocked on a RISC0 signature accelerator, a LEZ secp256k1 + keccak256 precompile, or a different upstream signature scheme that admits acceptable in-circuit cost on RISC0; none of these exist today. A precompile is the subject of a possible cost-conditional public-mode follow-on RFP, and an alternative private-mode-friendly signature scheme (with the corresponding upstream publisher work) is the subject of a possible separate follow-on RFP. Whether either follow-on is warranted depends on consumer-protocol demand for private-execution pull, which is not yet established: some consumer protocols (notably the LSC stablecoin in [RFP-013](./RFP-013-reflexive-stablecoin-protocol.md)) already constrain specific actions to public transactions for their own design reasons, so the capability is worth reaching for only if a downstream consumer actually needs it.
- Pull-mode reads from inside private execution: blocked on either a RISC0 zkVM circuit-level accelerator (e.g. a future `risc0-ecdsa` extension that lowers in-circuit verification cost) or a different upstream signature scheme that admits acceptable in-circuit cost on RISC0; neither exists today. A LEZ secp256k1 + keccak256 *precompile* (a runtime host function) is the subject of a possible cost-conditional public-mode follow-on RFP; that precompile lives outside the ZK proof boundary, so it lowers public-mode write-side cost but does *not* unblock private-execution pull (a host function cannot be called from inside the privacy circuit). An alternative private-mode-friendly signature scheme (with the corresponding upstream publisher work) is the subject of a possible separate follow-on RFP. Whether either follow-on is warranted depends on consumer-protocol demand for private-execution pull, which is not yet established: some consumer protocols (notably the LSC stablecoin in [RFP-013](./RFP-013-reflexive-stablecoin-protocol.md)) already constrain specific actions to public transactions for their own design reasons, so the capability is worth reaching for only if a downstream consumer actually needs it.
## 🔥 Why This Matters
appendix/oracle-ecosystem.md
+57 -30
View File
@@ -507,19 +507,35 @@ libraries (Zcash Foundation FROST [45], Blockstream `bip-frost-dkg`
reference implementation), and ZF is actively building FROST
tooling for Zcash, which aligns with the privacy-asset focus.
**This shape is conditional on LEZ exposing BIP-340 Schnorr**
**verification to guest programs at acceptable cost.** The runtime's
existing BIP-340 primitive validates transaction witnesses only;
it is not callable from a guest program running inside the
RISC-V zkVM. An adaptor that consumes a FROST-aggregated BIP-340
attestation would therefore have to verify the Schnorr signature
in-circuit, with the same unmeasured ZK-proving cost that ECDSA
verification faces under shape D. The "natively verifiable
without a runtime change" framing only holds if Schnorr
verification is later exposed to guest programs as a host
primitive; **absent that, shape B carries the same cost-question as**
**shape D plus the open R&D risks listed below. Pursuing shape B**
**without that runtime exposure is therefore not the right call.**
**The benefit of LEZ exposing the runtime BIP-340 primitive to**
**guest programs is public-mode CU only, not private-execution pull.**
The runtime's existing BIP-340 primitive validates transaction
witnesses only; it is not callable from a guest program running
inside the RISC-V zkVM. An adaptor that consumes a
FROST-aggregated BIP-340 attestation therefore has to verify the
Schnorr signature in-circuit; the cross-scheme bench
([`fryorcraken/lez-signature-bench`](https://github.com/fryorcraken/lez-signature-bench))
measures Schnorr secp256k1 at roughly 9% cheaper per-sig than
ECDSA secp256k1 (5:22 E2E private TX vs 7:26 at 3-of-N on
CPU-only Ryzen 9 7940HS), neither under 30 s. Exposing the
runtime primitive as a guest-callable host function would lower
the public-mode aggregator's write-side compute-unit cost
(potentially a smaller engineering ask than adding a fresh
secp256k1 ECDSA precompile, since the BIP-340 primitive is
already wired into the runtime; analogous to shape D's
cost-conditional precompile follow-on). It would *not* unblock
private-execution pull: a runtime host function lives outside the
ZK proof boundary, so anything inside the RISC-V zkVM circuit
(including private-execution proofs) cannot call it; the same
structural argument that forecloses private pull under D2 applies
to a hypothetical Schnorr host primitive. **Shape B's benefit**
**relative to shape D is therefore at most a public-mode CU**
**advantage conditional on the runtime exposure; it does not change**
**the private-pull picture, which is gated on a RISC0 zkVM**
**circuit-level accelerator or a different signature primitive that**
**admits acceptable in-circuit cost on RISC0, not on a runtime host**
**function.** Combined with the green-field FROST R&D risks listed
below, this is not the right call as the day-one path.
No price-oracle product is deployed in this shape today. Public
framing of FROST by its implementers and grant funders is
@@ -567,17 +583,25 @@ publishers emit BIP-340 attestations natively.
Two disqualifiers apply, either of which is sufficient on its own.
First, shape C carries the same runtime dependency as shape B:
verifying a DLC attestation requires the guest program to verify
BIP-340 Schnorr in-circuit at unmeasured cost, multiplied by N
(the bit-precision of the numeric DLC encoding). Pursuing shape C
is therefore not the right call unless LEZ later exposes Schnorr
verification to guest programs at acceptable cost. Second, even
with cheap Schnorr verification, the structural fit of the DLC
attestation model is prediction markets and discrete-outcome
contracts (which is what the format was designed for), not
streaming price feeds for DeFi protocols. Either condition alone
moves shape C out of scope for the current oracle work; the
description below documents the ecosystem state for reference and
for a future prediction-market RFP.
BIP-340 Schnorr in-circuit, multiplied by N (the bit-precision of
the numeric DLC encoding). Exposing the runtime BIP-340 primitive
to guest programs as a host function would lower the public-mode
write-side CU cost and turn the N-multiplier from a dominant
cost into a constant overhead, but would *not* help private
execution: a host function lives outside the ZK proof boundary,
so private-execution proofs cannot call it (same D2 structural
argument). Pursuing shape C as the day-one path is therefore not
the right call: the in-circuit cost is at parity with shape D's
ECDSA path (the bench measures Schnorr secp256k1 at ~9% cheaper
per-sig), and any public-mode CU advantage is conditional on a
runtime change that LEZ has not committed to. Second, even with
a cheap Schnorr host primitive in public mode, the structural fit
of the DLC attestation model is prediction markets and
discrete-outcome contracts (which is what the format was designed
for), not streaming price feeds for DeFi protocols. Either
condition alone moves shape C out of scope for the current
oracle work; the description below documents the ecosystem state
for reference and for a future prediction-market RFP.
A DLC oracle pre-announces nonce points (R-values) for a future
event with a known maturity time, then at maturity publishes the
@@ -685,12 +709,15 @@ update on LEZ. As
noted in the Signature Verification Schemes section, BIP-340
verification is not exposed to guest programs on LEZ, so each of
those 18 verifications runs in-circuit; the per-update cost is
therefore 18× whatever in-circuit BIP-340 + SHA-256 verification
costs in RISC0 (currently unmeasured). If LEZ later exposes
Schnorr verification as a host primitive at low cost, the
multiplier becomes a constant overhead instead of dominating; until
then, shape C inherits the same in-circuit cost question that
shape D's ECDSA path does.
therefore 18× the bench's measured in-circuit BIP-340 cost
(roughly 271K user cycles per signature, 5:22 E2E private TX at
3-of-N on consumer CPU). If LEZ later exposes Schnorr
verification as a host primitive at low cost, the multiplier
becomes a constant overhead instead of dominating *for the
public-mode write side*; the private-execution picture is
unchanged because a host function cannot be called from inside the
privacy circuit. Until then, shape C inherits the same
in-circuit cost question that shape D's ECDSA path does.
#### Trust and decentralisation
appendix/oracle-ift-research-slides.md
+9 -9
View File
@@ -192,14 +192,14 @@ Caveats: synthetic same-message fixtures, no batch-verify shortcuts, AI-assisted
# Four adaptor shapes
| Shape | What it is | Trust set | Engineering | In-circuit cost question |
| ---------------------------- | --------------------------------------------------------------------------------------------------------- | ---------------------------- | --------------------------------- | ----------------------------------------- |
| **A** Re-signer relayer | Relayer's signature authenticates the LEZ tx itself; program does an equality check on the caller | 1 operator | small | avoided (runtime-handled, not in-program) |
| **B** FROST federation | t-of-n threshold Schnorr emitting one BIP-340 sig | t honest signers | green-field R&D | yes (in-circuit Schnorr) |
| **C** DLC-oracle extension | BIP-340-native publisher (Pythia, etc.) | 1 op (or M-of-K independent) | small to medium | yes (in-circuit Schnorr × N bits) |
| **D** secp256k1 ECDSA on LEZ | RedStone/Pyth ECDSA-keccak verified in program code (day 1); precompile is the cost-conditional follow-on | upstream signers | implementation + cost measurement | yes (in-circuit ECDSA) |
| Shape | What it is | Trust set | Engineering | In-circuit cost question |
|------------------------------|------------------------------------------------------------------------------------------------|------------------------------|-----------------------------------|-------------------------------------------|
| **A** Re-signer relayer | Relayer's signature authenticates the LEZ tx itself | 1 operator | small | avoided (runtime-handled, not in-program) |
| **B** FROST federation | t-of-n threshold Schnorr emitting one BIP-340 sig | t honest signers | green-field R&D | yes (in-circuit Schnorr) |
| **C** DLC-oracle extension | BIP-340-native publisher (Pythia, etc.) | 1 op (or M-of-K independent) | small to medium | yes (in-circuit Schnorr × N bits) |
| **D** secp256k1 ECDSA on LEZ | RedStone/Pyth ECDSA-keccak verified in program code (day 1); precompile as potential follow-on | upstream signers | implementation + cost measurement | yes (in-circuit ECDSA) |
→ **RFP-020 picks D.** RFP-019 (on-chain TWAP) is structurally separate from this choice. Shape A is rejected (trust collapse). Shape B is conditional on LEZ later exposing Schnorr verification to guest programs at low cost. Shape C is documented; structurally a fit for prediction markets, not current oracle work.
→ **RFP-020 picks D.** RFP-019 (on-chain TWAP) is structurally separate from this choice. Shape A is rejected (trust collapse). Shape B's only structural advantage over D would be a smaller LEZ-side ask if the runtime team exposed its existing BIP-340 primitive to guest programs as a host function: public-mode CU lower than D's in-circuit ECDSA, analogous to D2's ECDSA precompile follow-on. Private-execution pull is foreclosed under both shapes for the same D2 reason (host functions live outside the privacy circuit). Shape C is documented; structurally a fit for prediction markets, not current oracle work.
Note:
Quick walk-through of the four:
@@ -208,9 +208,9 @@ A — A LEZ-side process pulls RedStone/Pyth payloads, verifies them off-chain,
The structural test that distinguishes A from B/C/D: **whose signature authenticates the LEZ transaction**. A's transaction is signed by the re-signer (runtime handles verification). B/C/D's transactions carry an upstream publisher's signature inside calldata, distinct from the transaction sender — the guest program has to verify it in-circuit.
B — A t-of-n federation does DKG and produces one BIP-340-verifiable Schnorr signature per price update. Libraries exist (ZF FROST, Blockstream bip-frost-dkg, jesseposner FROST-BIP340) but no oracle is using FROST in production today; FrostOracle (Chen et al., IEEE iThings 2023) is the lone academic proposal, and the closest production precedent is iBTC/DLC.Link's federation for *contract-outcome* attestation, not price feeds. Crucially, BIP-340 verification is not exposed to guest programs on LEZ either (the runtime primitive is for transaction witness only), so a guest program consuming a FROST-aggregated signature has to verify it in-circuit. The bench measures Schnorr secp256k1 in-circuit at ~9% cheaper per-sig than ECDSA secp256k1 (5:22 E2E vs 7:26 E2E at 3-of-N on CPU); neither lands under 30 s, so the in-circuit cost question is the same shape as D. **Shape B is therefore not the right call unless LEZ later exposes Schnorr verification to guest programs at acceptable cost**; without that, you're paying ~91% of D's in-circuit cost plus the green-field R&D risk.
B — A t-of-n federation does DKG and produces one BIP-340-verifiable Schnorr signature per price update. Libraries exist (ZF FROST, Blockstream bip-frost-dkg, jesseposner FROST-BIP340) but no oracle is using FROST in production today; FrostOracle (Chen et al., IEEE iThings 2023) is the lone academic proposal, and the closest production precedent is iBTC/DLC.Link's federation for *contract-outcome* attestation, not price feeds. Crucially, BIP-340 verification is not exposed to guest programs on LEZ either (the runtime primitive is for transaction witness only), so a guest program consuming a FROST-aggregated signature has to verify it in-circuit. The bench measures Schnorr secp256k1 in-circuit at ~9% cheaper per-sig than ECDSA secp256k1 (5:22 E2E vs 7:26 E2E at 3-of-N on CPU); neither lands under 30 s, so the in-circuit cost question is the same shape as D. The benefit of LEZ later exposing the runtime BIP-340 primitive as a guest-callable host function would be public-mode CU only (lower aggregator write-side cost; potentially a smaller engineering ask than adding a fresh ECDSA precompile, since the primitive already exists). It would not reach private execution: a host function lives outside the privacy circuit, so the D2 structural argument applies equally. **Shape B is therefore not the right call**: at most it offers a public-mode CU win conditional on the runtime exposure, while paying ~91% of D's in-circuit cost plus green-field FROST R&D in the meantime, with no improvement on private-execution pull.
C — Bitcoin DLC oracles (Pythia, Sibyls, Suredbits, Ernest Oracle) publish BIP-340 attestations. Two disqualifiers, either sufficient on its own. First, same runtime dependency as B: each verification runs in-circuit at unmeasured cost, and the numeric DLC encoding multiplies that by N (bit-precision of the price), so shape C is not the right call unless LEZ later exposes Schnorr verification to guest programs at acceptable cost. Second, even with cheap Schnorr verification the structural fit is prediction markets and discrete-outcome contracts, not streaming price feeds. Better positioned for a future prediction-market RFP than for the current oracle work. The DLC info is in the appendix for reference.
C — Bitcoin DLC oracles (Pythia, Sibyls, Suredbits, Ernest Oracle) publish BIP-340 attestations. Two disqualifiers, either sufficient on its own. First, same runtime dependency as B: each verification runs in-circuit, and the numeric DLC encoding multiplies that by N (bit-precision of the price); exposing Schnorr as a guest-callable host primitive would lower public-mode CU and turn that N-multiplier from a dominant cost into a constant overhead, but does not help private execution (same D2 structural argument). Second, even with a cheap Schnorr host primitive the structural fit is prediction markets and discrete-outcome contracts, not streaming price feeds. Better positioned for a future prediction-market RFP than for the current oracle work. The DLC info is in the appendix for reference.
D — Implement RedStone's secp256k1 ECDSA + keccak256 verification as RISC-V program code inside the RISC0 zkVM. Push-mode aggregator: write side does the verify once per update, private accounts read the resulting public price account. The cost is the open variable; measuring it is the first deliverable of RFP-020. If measured cost is acceptable, the adaptor ships on the runtime as it stands. If not, a follow-on RFP proposes adding a secp256k1 ECDSA + keccak256 precompile (public-mode only). The precompile is therefore an optimisation path, not a precondition.