Repository navigation
Create vendor Space and Time - #46
Conversation
|
|
||
| ## Strengths | ||
|
|
||
| - **Extreme performance:** As the first sub-second ZK prover, the protocol can execute analytic queries over 1M+ rows in less than a second. It can aggregate over millions of rows of indexed data within Ethereum block time on a single NVIDIA T4 GPU. |
There was a problem hiding this comment.
Could you define "Extreme performance"?
Do you have links to benchmarks that define "Extreme performance"?
There was a problem hiding this comment.
"As the first sub-second ZK prover" doesn't give much information about the performance of your tool.
There was a problem hiding this comment.
Sure, we have links to our benchmarks in our GitHub repo: https://github.com/spaceandtimefdn/sxt-proof-of-sql#benchmarks.
The claim of being “the first sub-second ZK prover” should be read together with the clarification that the proving applies to "analytic queries over 1M+ rows". The confusion may come from not explicitly stating that "the protocol can execute and prove these queries"
There was a problem hiding this comment.
Thanks! The phrase "the first sub-second ZK prover" reads more like a marketing claim than a technical description of the tool. Might be better to reframe it as suggested above, and link to the benchmark for clarity.
| ## Architecture | ||
|
|
||
| - **Decentralized validator set holding tamperproof tables:** Indexed blockchain data (events, txns, balances, etc with block hashes as attestation source) as well as signed user/enterprise-loaded datasets are held by a global validator network that collectively updates commitments on each table (with BFT consensus and threshold signatures) as batches of new data are added. | ||
| - **Prover nodes:** When a contract/API issues a query, a prover executes the SQL and generates the ZK proof before relaying both back to a relayer contract for verification and data-callback to client contract; with a next-gen proving pipeline (AST → witnesses → commitments → constraints → sum-check → openings). |
There was a problem hiding this comment.
Could you define "next-gen proving pipeline"? Is there a link to an academic definition or reference to a specific scheme that could help the reader?
There was a problem hiding this comment.
We have a very detailed Whitepaper that describes our next-gen proving pipeline: https://sxtdocspub.blob.core.windows.net/docs/sxt-whitepaper.pdf
In short, “next-gen proving pipeline” refers to our use of commitment schemes such as Dory and proving via sum-check (for example a16z's Jolt coprocessor uses our Dory and sum-check repo). The parenthetical (AST → witnesses → commitments → constraints → sum-check → openings) is meant to describe the concrete stages of that pipeline.
Concretely:
- SQL is parsed into an AST and relational plan
- The plan is executed to produce witness data
- Witnesses are committed using standard polynomial commitments
- Constraints are generated and verified via sum-check, followed by opening proofs
This proving system allow us to prove analytical / aggregate queries over 1M+ row tables in less than one second.
There was a problem hiding this comment.
Same comment as above about "next-gen proving pipeline".
Your description here looks great. Could you include it in your card?
|
Thanks @miguel-bm! |
Add a more technical description of Prover nodes. Co-authored-by: Carlos Bort <carlosebort@gmail.com>
Improve description of Performance. Co-authored-by: Carlos Bort <carlosebort@gmail.com>
|
Looks great! |
What are you adding?
Description
Add Space and Time as a vendor.
Checklist