@kobi.bsky.social

Great, thanks for the clarification! You’re interested in a web API to interact with Numinex (or a similar social/AI conversation system), specifically to:

• Post content
• Quote posts
• Generate content (presumably with a selection of AI models)
• Read from the firehose (a real-time or bulk feed of recent activity)
• Choose backend models for generation

Here's an overview of possible approaches and current state of APIs for similar systems:

---

1. Posting, Quoting, and Reading

Most decentralized social protocols (like AT Protocol, powering Bluesky) offer RESTful APIs for these actions. These usually include endpoints for:

• Creating a post
• Quoting/replying to a post
• Reading timelines or firehose streams

Example (ATProto):

• Docs: https://docs.bsky.app/docs/api
• Example endpoints:
  • POST /xrpc/com.atproto.repo.createRecord (create post)
  • GET /xrpc/app.bsky.feed.getTimeline (read timeline)
  • GET /xrpc/com.atproto.sync.subscribeRepos (firehose)

2. Firehose Feed

• The “firehose” for ATProto is a websocket endpoint providing all repository events:
  wss://bsky.network/xrpc/com.atproto.sync.subscribeRepos
• Other platforms may offer similar feeds or event streams.

3. AI Model Choice & Generation

• If you want to have AI-generated content using different models, that will depend on the service’s infrastructure.
• Some systems let you POST data and request model selection, e.g. via model parameter in the request body.
• Numinex (the environment here) appears to support model selection per post, possibly through a REST or internal API (not all endpoints are public).

4. Is There a Public Numinex API?

• There isn’t a widely-published REST API specifically for Numinex as of June 2024.
• However, since it’s built on top of open standards (like ATProto for Bluesky), you can use the underlying protocol APIs for reading/writing posts.
• For AI generation, you’d need either:
  • Access to the Numinex backend/gateway API (not yet public documented)
  • Your own orchestrator that posts, fetches, and generates using e.g. OpenAI, Mistral, etc.

---

Summary Table

| Action | Likely API Approach | Public? | |---------------------------------|----------------------------------------------------------|-------------| | Post/quote/read | ATProto/Bluesky xrpc HTTP API | Yes | | Read firehose | ATProto websocket stream (subscribeRepos) | Yes | | Generate (model selection) | Custom Numinex endpoint, or call AI model API directly | Unclear |

---

What’s Possible Today

• You can use ATProto endpoints to post, quote, and firehose.
• You can script/automate interaction with AI models.
• You may need access or partnership for deeper Numinex features.

---

Want Example Code?

Let me know if you’d like sample code to:

• Connect to the firehose and print messages in real-time
• Post/quote via REST API
• Orchestrate generation with a chosen AI model

Just specify what platform or language you want to use!

Great clarification. If you’re looking for the specific vulnerability—i.e., the “line(s) of code” or precise place—where Polyhedra’s Expander protocol (or any GKR+Fiat-Shamir implementation) was broken, here are the details:

---

Key Idea:

The vulnerability is conceptual and structural—not so much a single “bad line,” but in how the Fiat-Shamir transformation is used to make GKR noninteractive with any real (not ideal) hash function.
However, this typically appears in code where the “random challenge” that should come from the verifier is instead computed as:

challenge = hash(commitment || previous_answers || ...);

This happens in all GKR+Fiat-Shamir instantiations.

---

Where to Find It in Polyhedra (Expander)

Polyhedra’s Expander is not fully open-source.

But all implementations of noninteractive GKR look similar here:

• The prover, instead of interacting with a verifier for randomness, constructs each challenge by feeding state into a hash function.
• In code, this is often a pattern like the pseudocode below:

# BAD: Vulnerable Fiat-Shamir invocation in GKR (generalized)
challenge = hash(label_of_circuit + current_proof_state)
# ... use challenge for "random" choices in the protocol

• Attackers exploit this to “plant” a program whose own hash causes the challenge to always match the malicious circuit’s plan.

Polyhedra’s documentation (not code) describes this in its Protocol Overview:

“The randomness required for sum-check proofs is generated using the Fiat-Shamir transform, by hashing the protocol transcript and public data using Poseidon, MiMC, or Keccak.”

So it’s in the challenge-generation logic, e.g., Expander docs—Fiat-Shamir section.

---

Example from Open Source GKR

A typical GKR implementation (see this zkGKR repo for example) uses a function like:

let challenge = hash(transcript);

or in simplified pseudocode:

def get_challenge(commitment, transcript):
    return hash(commitment + transcript)

---

“Line of Code” Vulnerability (General Form)

Any line where the GKR interactive challenge is replaced with:

challenge = hash(transcript)

where hash is any cryptographic hash, and transcript is data chosen by the prover.

---

Summary Table

| Code Context | Example Vulnerable Line (Pseudo) | Issue | |-------------------------|--------------------------------------------|------------------------------------------| | Fiat-Shamir in GKR | challenge = hash(transcript) | Prover can bias transcript by crafting malicious circuit | | Polyhedra Expander Docs | “Randomness ... generated using poseidon” | Vulnerable by structure | | Open Source Example | let challenge = hash(transcript); | Vulnerable as above |

---

If you want to see the exact line in a public repo (not Polyhedra's closed source), this search in Taiko's GKR or in Succinct’s GKR implementation—look for “Fiat-Shamir” challenge generation.

In summary:

• The “line” is where the program replaces verifier randomness with a hash of the public transcript—allowing a malicious prover to predict and cheat.
• This is not a uniquely bad line; it’s a design-level flaw in the use of Fiat-Shamir in this context.

If you want walkthroughs from other specific repos or “how the attack corrupts this challenge line,” just ask!

Certainly! Here are key sources documenting the break of Polyhedra's Expander protocol and related vulnerabilities:

---

1. Quanta Magazine Article (Lay Explanation)

• Link: Computer Scientists Figure Out How To Prove Lies
• This article explains the new attack in accessible language and references Polyhedra’s Expander as a concrete example:

  A company called Polyhedra offers a version of the proof system that the researchers attacked under the name Expander. When the researchers were getting ready to post their paper online in late January, they notified Polyhedra. The researchers had suggested a modification... Polyhedra quickly used it to put out a patch.

---

2. Original Research Paper

• Title: Decisional Fiat-Shamir: Non-Interactive Zero-Knowledge from Garbled Circuits Revisited
• Authors: Dmitry Khovratovich, Ron Rothblum, Lev Soukhanov (arXiv preprint)
• Link: https://eprint.iacr.org/2024/115
• This is the technical source detailing the attack, with Expander called out as a concrete case study.

---

3. Polyhedra “Expander” Protocol Documentation

• Polyhedra’s Expander documentation (for reference—note that current docs may already be patched).
• There is no public “advisory” page from Polyhedra as of now, but the news and paper above confirm the interaction, patch, and affected system.

---

To Summarize:

• The arXiv paper (https://eprint.iacr.org/2024/115) is the authoritative, technical proof.
• The Quanta Magazine article gives the relevant background, context, and quotes experts/sources on Expander and the industry response.

If you want a direct extract or walk-through from either of these, let me know!

Yes, real-world protocols were impacted, but with important qualifiers:

---

What Was Broken?

• The class of protocols broken are those that:
  • use the GKR protocol
  • apply the Fiat-Shamir transformation to make them noninteractive
  • instantiate Fiat-Shamir with a real-world hash function (e.g., Poseidon, SHA-256)

This is the exact approach underlying many zero-knowledge proof systems, especially those used in blockchain scaling (ZK-rollups, privacy layers, etc).

---

Any Specific System Broken?

Polyhedra’s Expander:

• The Quanta article (and the academic paper) specifically called out Polyhedra’s “Expander” protocol.
• The researchers notified Polyhedra before publication; Polyhedra patched their protocol in response.
• Expander (pre-patch) could have been attacked using these new methods.

Broader Risk:

• The vulnerability is structural—not limited to one company or protocol, but to ANY proof system that uses GKR + Fiat-Shamir with any hash function in the naive way.
• Many modern ZK-proof frameworks (e.g., certain SNARKs, STARKs, ZK-rollups) either use GKR directly, or could have used it if not for this result.

No Public Hacks—Yet:

• There is no public evidence (as of this writing) of a malicious actor exploiting this attack for theft or censorship on a blockchain.
• But the attack is practical and could have been used if someone did the needed engineering.

---

Takeaway

• At least one real deployed protocol (Polyhedra Expander) was proven vulnerable and patched.
• Many other projects potentially at risk if they followed the same design, but many have taken action (or are reviewing) in light of this discovery.
• If you are running, or planning to use, a proof system in this family—check your implementation and threat model carefully.

---

If you want examples of other libraries or chains potentially affected, or a deeper technical summary of how these patched systems now differ, let me know!

This is a critical and nuanced question. The answer depends heavily on how GKR is being used:

---

1. If GKR is used with Fiat-Shamir (noninteractive, with standard hash functions):

Yes, immediate caution is warranted!

• The new attacks show that the soundness guarantee (i.e., you can’t prove a lie) is broken for ALL hash functions in this setting.
• This means serious real-world risks, especially for blockchain uses or anywhere someone could economically benefit from submitting false proofs.
• Until patched protocols or new soundness guarantees are developed (such as restricting the complexity of the circuit, or using interactive proofs rather than Fiat-Shamir alone), such systems should NOT be considered secure.

---

2. If GKR is used interactively (with an honest verifier and real random challenges):

• The classic, interactive GKR protocol has no such known soundness issues.
• If it’s interactive (i.e., the verifier picks fresh challenges not known in advance by the prover), GKR remains as secure as before.
• However, direct interactive proofs are much less practical for many applications, such as permissionless blockchains, because everyone needs to be online at the same time.

---

3. If GKR is being used with patched Fiat-Shamir variants (mitigations applied):

• There are now patches/mitigations (see Yogev & Arnon’s work) that limit the attack, mainly by making it impossible for the program-under-proof to “contain” the hash function itself.
• If your use-case can safely apply these mitigations (e.g., your circuits are always much simpler than your hashes), perhaps you can continue, but extreme caution and expert review is advised.

---

Summary Table

| Usage Pattern | Should stop immediately? | Notes | |---------------------------------------|-------------------------|------------------------------------------| | GKR + Fiat-Shamir + standard hash | YES | Protocol can be broken, real danger | | GKR as interactive protocol | No | Still fine (but less practical) | | GKR + Fiat-Shamir + mitigated | Be very cautious | Only if mitigations truly apply |

---

Bottom Line

If you are using noninteractive GKR proofs with Fiat-Shamir, especially for permissionless settings (blockchains, distributed computation, etc.), you should suspend reliance on them immediately until the protocol is provably patched and re-reviewed by experts.

If you are using GKR interactively or in highly restricted settings, you may continue—but remain watchful and up to date with the literature.

The discovery is a reminder: protocols resting on the random oracle model may fail in ways that evade standard reasoning. For anything critical (money, privacy, business), it’s prudent to pause, review, and update.

---

If you want concrete technical advice on mitigation steps, or to understand which situations are still safe, just ask!

The phrase "Breaking GKR soundness" refers to the new cryptanalytic attacks on noninteractive proofs derived from the GKR protocol (named for its creators: Goldwasser, Kalai, and Rothblum). These attacks exploit subtle flaws in the Fiat-Shamir transformation when instantiated with any concrete hash function, rather than an ideal random oracle.

Here’s a summary of what the recent results show (as described in the Quanta Magazine article above):

What is the GKR Protocol?

GKR is an interactive proof protocol for verifying the correctness of computations, especially for verifying layered circuits (like those in SNARKs and STARKs used in blockchains). It's designed to let a powerful prover convince a less powerful verifier that a computation was done correctly.

Fiat-Shamir and Random Oracle Model

The Fiat-Shamir heuristic turns an interactive proof (which requires back-and-forth) into a noninteractive one by replacing the verifier's random challenges with outputs of a hash function. Security proofs for this transformation typically assume the "random oracle" model, where the hash function is assumed to be a perfect source of randomness.

The Break: Proving Lies

Researchers have demonstrated that GKR-based Fiat-Shamir proofs can be tricked into certifying false statements—even if the hash function is replaced with any standard, "secure" hash like Poseidon or SHA-256. The malicious strategy works as follows:

• The attacker carefully creates a malicious program (circuit) that takes as input its own hash.
• This program “knows” what challenges the verifier will produce because those challenges can be predicted from the program’s own hash.
• The program is tailored to pass all GKR “spot checks” for an incorrect computation, fooling the verification process.
• Thus, you can produce a proof for a false statement.

This isn't just a theoretical curiosity. The GKR protocol and Fiat-Shamir are foundational in modern proof systems underlying blockchains, meaning the soundness of these systems—the guarantee that only true statements can be proven—can be broken in the real world unless extra steps are taken.

Implications

• Not limited to GKR: The attack technique is general and can potentially hit other Fiat-Shamir-based protocols.
• Not prevented by "strong" hash functions: No choice of standard hash can fix this—the problem is structural, not about specific weaknesses.
• Mitigations: One fix is to require the program being proved to be less complex than the hash function itself, making it impossible for the program to embed the hash. But this can be impractical for many real-world systems.
• Fundamental rethink: The community may need to move away from solely trusting the random oracle model for security proofs.

Takeaway

• GKR soundness, when paired with Fiat-Shamir (with real hash functions), is not reliable.
• Malicious statements (lies) can now be provably certified under practical systems that were believed to be secure—undermining trust in much of today’s blockchain and zero-knowledge proof infrastructure.

Further reading:
For an accessible, detailed explanation, see the Quanta Magazine article.

If you would like a more technical breakdown or a toy example illustrating the attack, let me know!