<div style="font-family: Arial, sans-serif; font-size: 14px;"><span>Interesting design — reusing the orchard crate as-is and only serializing the two order-sensitive structures is the right cut.</span><div><br></div><div><span>One question on the construction. Anchors are Merkle roots of the global tree, and the global tree is appended in GHOSTDAG accepted order. If a chain-block subtree root gets reordered (a block moves within </span><span style="font-size:0.875rem">the blue set before it is final), every leaf position after it shifts, so a spend proof built against an anchor that included that block no longer opens. How far behind the tip does an anchor have to be </span><span style="font-size:0.875rem">for its path to be stable, and does that distance eat the 1-second latency? (I hit the same thing on my own chain — nullifiers that bind to an in-tree position force you to scope the spent set per epoch.)</span></div><div><br></div><div><span>The other thing I would think about early is a cryptographically relevant quantum computer, because a privacy chain is the harvest-now-decrypt-later target par excellence: the whole ledger is public </span><span style="font-size:0.875rem">ciphertext by design. Under Shor, three parts of Orchard go at once — the note encryption (ECDH on Pallas, so every past transaction gets decrypted retroactively), RedPallas spend authorization (theft), </span><span style="font-size:0.875rem">and the IPA commitment in Halo 2 (discrete-log binding, so forged proofs = undetectable inflation). Pedersen hiding is information-theoretic, so amounts stay hidden, but binding does not. It is a little </span><span style="font-size:0.875rem">ironic that the trusted-setup toxic waste your whitepaper is proud to have removed gets replaced by a discrete-log assumption with a known quantum break.</span></div><div><br></div><div><span>I went the other way on <a target="_blank" rel="noreferrer nofollow noopener" href="https://sigilgraph.org">https://sigilgraph.org</a> — shielded notes whose spend proofs are hash-based STARKs (transparent, no curve, no pairing), so at least the proof system has no known quantum attack; the </span><span style="font-size:0.875rem">rest of the stack is being moved the same way. Whether full-scale machines are five years away or always five years away (the New Scientist piece: </span><a target="_blank" rel="noreferrer nofollow noopener" href="https://www.newscientist.com/article/2582565-why-full-fledged-quantum-computers-might-always-be-five-years-away/" style="font-size:0.875rem;word-break:break-word">https://www.newscientist.com/article/2582565-why-full-fledged-quantum-computers-might-always-be-five-years-away/</a><span style="font-size:0.875rem">) matters less for a privacy coin than for a payment coin, because the recorded ciphertext </span><span style="font-size:0.875rem">waits.</span></div><div><span style="font-size:0.875rem">Unrelated plug, since your repo is Rust: if compile times hurt, </span><a target="_blank" rel="noreferrer nofollow noopener" href="https://fluxapp.xyz" style="font-size:0.875rem">https://fluxapp.xyz</a><span style="font-size:0.875rem"> is a Rust build platform I built and dogfood; SIGIL is compiled with it.</span></div><div><br></div><div><span> -- Viktor</span></div><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div>
<div style="font-family: Arial, sans-serif; font-size: 14px;" class="protonmail_signature_block">
<div class="protonmail_signature_block-user">
<div>Really important if something matters<br></div>
</div>
<div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div>
<div class="protonmail_signature_block-proton">
Afsendt med <a href="https://proton.me/mail/home" target="_blank">Proton Mail</a> sikker e-mail.
</div>
</div>
<div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div class="protonmail_quote">
fredag den 11. september 2026 kl. 20:56, skrev zikky via cryptography <cryptography@metzdowd.com>:<br>
<blockquote class="protonmail_quote" type="cite">
<div dir="auto">ZKas is a one month old cryptocurrency that combines Kaspa's GHOSTDAG BlockDAG - fast, parallel, proof-of-work block production with Zcash's Orchard shielded protocol, so that every amount, sender, and recipient is hidden by construction.<br></div><div dir="auto"><br></div><div dir="auto">Zcash's privacy is considered to be the most advanced but it's not enabled by default, so receives criticism from people (e.g. Edward Snowden).<br></div><div dir="auto">Kaspa's DAG achievements enable it to produce 100 blocks per second but it's a transparent ledger. <br></div><div dir="auto"><br></div><div dir="auto">ZKas combines Kaspa's and Zcash's work and creates the fastest privacy network with 1 second block time and mandatory hardest encryption.<br></div><p class="">ZKas combines Orchard's confidentiality with a GHOSTDAG BlockDAG. This is workable because an Orchard transaction is self-contained: it balances its own value through homomorphic Pedersen commitments of the form cv = [v]G + [rcv]H (G, H generators on Pallas) and proves its own validity in zero knowledge, independent of the order of other transactions. Only two structures are globally order-sensitive: the set of spent-note nullifiers N and the Merkle tree of note commitments T. A BlockDAG already linearizes its accepted transactions, and ZKas advances N and T along that existing order. Confidentiality therefore adds little latency, and the problem that usually makes a private chain hard — keeping global state consistent under parallel block production — reduces to reusing an ordering the engine already computes.<br></p><p class="">The privacy layer is Orchard, Zcash's third-generation shielded protocol, reused through the audited orchard crate rather than re-implemented. Orchard's Action (a merged spend-and-output) uses Pedersen value commitments (homomorphic, so the circuit simply enforces sum vin = sum vout), Sinsemilla note commitments cm = SinsemillaCommit_rcm(g_d || pk_d || v || ρ || ψ) where g_d is the diversified base, forming a depth-32 Merkle tree, and nullifiers nf = Extract_P([PRF^{nf}_{nk}(ρ) + ψ] · G + cm). These are adopted as-is. Critically, Orchard has no interstitial treestates: transactions within a block do not chain tree state to one another, which is what makes the three-tier construction of §6 possible.<br></p><p class="">Statements are proven in Halo 2 over the Pallas/Vesta (Pasta) curve cycle. Halo 2 needs no trusted setup — a decisive property for a coin with no trusted-setup ceremony and no privileged parties — because its polynomial commitments are inner-product arguments (transparent, discrete-log based). The IPA also supports efficient batch verification of many proofs at once and recursive composition, the two levers ZKas uses to make shielded verification scale.<br></p><p class="">Only two structures must be globally consistent. The nullifier set N holds every nullifier ever spent; it is append-only and checkable forever, so a repeat is a double-spend. The note-commitment tree T is a fixed depth-32 Sinsemilla Merkle tree of all note commitments (2^{32} leaves), and its root is the anchor. Everything else in a shielded transaction is self-contained: each transaction balances its own value locally via the Pedersen homomorphism, and Orchard's absence of interstitial treestates means transactions in a block do not chain tree state to each other. Hence the only ordering that matters is at the level of these two structures.<br></p><p class="">Shielded state on a DAG — the core construction<br></p><p class="">This is the one component of ZKas that is genuinely new.<br></p><p class="">The note-commitment tree is built in three layers so that the only serialized step is as small as possible. The bundle subtree is built entirely by the wallet from a single transaction's new commitments (a small Sinsemilla Merkle tree over the Action outputs), with no consensus involvement and complete order-independence. The chain-block subtree is accumulated when a block is processed from the bundle contributions it carries (another Sinsemilla Merkle of those bundle roots); parallel blocks build their own subtrees with zero contention. The global tree is advanced only inside the virtual processor by appending finalized chain-block subtree roots in GHOSTDAG accepted order, yielding the single global root rt = MerkleSinsemilla(rtblock1, rtblock2, …). This is the single serialized operation, and the engine already produces that exact order.<br></p><p class="">Zcash's early pools (Sprout, Sapling) needed a trusted setup ceremony in which a group generated secret randomness to build the proving parameters and then destroyed it, because anyone who kept that toxic waste could counterfeit coins undetectably. ZKAS has no ceremony and no trusted setup at all. It uses Orchard/Halo 2 (Zcash's own post-2022 system), whose parameters are derived from public, reproducible formulas (Pasta curve constants and the IPA generators). There is no secret that ever exists, so there is nothing to leak and nothing to trust. It shares the same privacy lineage as Zcash but is built entirely on the setup-free generation, so the counterfeiting risk that the ceremony existed to mitigate simply does not apply.<br></p><div dir="auto"><br></div><div dir="auto">Enthusiasts and developers are welcomed.<br></div><div dir="auto"><br></div><div dir="auto"><a href="https://zkas.info/whitepaper.html" rel="noreferrer nofollow noopener" target="_blank" style="word-break: break-word;">https://zkas.info/whitepaper.html</a><br></div><div dir="auto"><a href="https://zkas.info/" target="_blank" rel="noreferrer nofollow noopener">https://zkas.info/</a></div><div dir="auto"><a href="https://github.com/firecash/zkas-rusty" rel="noreferrer nofollow noopener" target="_blank" style="word-break: break-word;">https://github.com/firecash/zkas-rusty</a><br></div><div dir="auto"><a href="https://discord.com/invite/jysMS4XNFT" rel="noreferrer nofollow noopener" target="_blank" style="word-break: break-word;">https://discord.com/invite/jysMS4XNFT</a><br></div>
</blockquote><br>
</div>