diff --git a/site/Zcash_Tech/Halo.md b/site/Zcash_Tech/Halo.md index 46bbb1692..70823a6ac 100644 --- a/site/Zcash_Tech/Halo.md +++ b/site/Zcash_Tech/Halo.md @@ -4,127 +4,149 @@ # Halo +## TL;DR -## What is Halo? +- **Halo** is a trustless, recursive zero-knowledge proof system discovered by Sean Bowe at Electric Coin Co. +- It removes the need for a trusted setup, which means new proving systems can be deployed without a ceremony that creates secret "toxic waste." +- Halo uses recursive proof composition: one proof can attest to the correctness of many other proofs. +- Zcash uses the Halo 2 proving system in the Orchard shielded pool, activated with Network Upgrade 5 (NU5). +- The main benefits for Zcash are stronger trust assumptions, easier protocol upgrades, and a foundation for future scalability work. -Halo is a trustless, recursive zero-knowledge proof (ZKP) discovered by Sean Bowe at Electric Coin Co. It eliminates the trusted setup and allows greater scalability of the Zcash blockchain. Halo was the first zero-knowledge proof system that is both efficient & recursive widely regarded as a scientific breakthrough. +--- -![halo](https://electriccoin.co/wp-content/uploads/2021/01/Halo-on-Z-1440x720.png "halo") +## Core Explanation +Halo is a zero-knowledge proof system designed to be both trustless and recursive. It was first described by Sean Bowe at Electric Coin Co. and is widely regarded as a breakthrough because earlier practical zk-SNARK systems either required a trusted setup or made recursion expensive. -**Components** +The trusted-setup problem matters because older proving systems required a common reference string (CRS) to be generated before proofs could be created and verified. If the secret material from that ceremony, often called "toxic waste," was not destroyed, a dishonest party could potentially create fraudulent proofs. Zcash reduced that risk through secure multi-party computation ceremonies for Sprout and Sapling, but Halo removes the need for that kind of ceremony. -Succinct Polynomial Commitment Scheme: Allows a committer to commit to a polynomial with a short string that can be used by a verifier to confirm claimed evaluations of the committed polynomial. +Halo also supports recursive proof composition. Recursion allows one proof to verify other proofs, so a large amount of computation can be compressed into a small proof that is still fast to check. In a blockchain context, that is useful because many participants need to verify the correctness of the system without redoing all of the underlying work themselves. -Polynomial Interactive Oracle Proof: Verifier asks prover (algorithm) to open all commitments at various points of their choosing using polynomial commitment scheme & checks identity holds true between them. +![Halo overview](https://electriccoin.co/wp-content/uploads/2024/03/Halo-on-Z-EX-1024x512.png "Halo overview") +Key components: + +- **Succinct polynomial commitment scheme.** A committer can commit to a polynomial with a short string, and a verifier can use that commitment to check claimed evaluations. +- **Polynomial interactive oracle proof.** A verifier asks the prover algorithm to open commitments at chosen points, then checks that the expected identities hold between them. + +## Visual / Analogy + +Think of Halo recursion like a stack of receipts. Instead of checking every item in every receipt from the beginning, each new receipt can prove that the previous receipts were already checked correctly. A verifier only needs to check the latest proof to gain confidence in the whole chain of work. + +That is the key difference from a normal one-off proof: Halo is built so proofs can reason about other proofs. + +## Deep Dive ### No Trusted Setup -zkSNARKs rely on a common reference string (CRS) as a public parameter for proving & verifying. This CRS must be generated in advance by a trusted party. Until recently, elaborate secure multi-party computations (MPC) as those performed by Aztec network & Zcash were necessary to mitigate the risk involved during this [trusted setup ceremony](https://zkproof.org/2021/06/30/setup-ceremonies/amp/). +zk-SNARKs rely on public parameters for proving and verifying. In many older systems, those parameters had to be generated in advance by a trusted party or by a secure multi-party computation. Zcash and other projects used elaborate [trusted setup ceremonies](https://zkproof.org/2021/06/30/setup-ceremonies/amp/) to reduce the chance that any one participant could compromise the system. -Previously Zcash's Sprout & Sapling shielded pools utilised the BCTV14 & Groth 16 zk-proving systems. While these were secure there were limitations. They were not scalable as they were tied to a single application, the "toxic waste" (remnants from cryptographic material generated during the genesis ceremony) could persist, and there was an element of trust (albeit minute) for users to deem the ceremony acceptable. +Sprout used BCTV14, and Sapling used Groth16. These systems were efficient and secure when the setup was performed correctly, but each setup was tied to specific circuits or applications. The ceremony also introduced a trust assumption: users had to believe that the secret material created during setup was destroyed. -By repeatedly collapsing multiple instances of hard problems together over cycles of elliptic curves so that computational proofs can be used to reason about themselves efficiently (Nested amortization) the need for a trusted setup is eliminated. This also means that the structured reference string (output from ceremony) is upgradeable enabling applications such as smart contracts. +Halo avoids that trusted setup by using a polynomial commitment scheme based on an inner product argument and a recursive technique called **nested amortization**. Instead of relying on secret setup material, Halo repeatedly collapses multiple hard-problem instances together over cycles of elliptic curves. This lets the system prove the correctness of prior proofs without creating new toxic waste. -Halo provides users with two important assurances regarding the security of the large-scale zero-knowledge proof system. Firstly, it enables users to prove that no one who was involved in the genesis ceremony has created a secret backdoor to execute fraudulent transactions. Secondly, it allows users to demonstrate that the system has remained secure over time, even as it has undergone updates and changes. +Halo gives Zcash users two important assurances: -[Sean Bowes Explainer on Dystopia Labs](https://www.youtube.com/watch?v=KdkVTEHUxgo) - +1. No participant in an earlier proving-system ceremony can use hidden toxic waste to create false proofs for the Halo-based system. +2. The proof system can continue to evolve without repeating a trusted setup for each major upgrade. +[Sean Bowe's explainer on Dystopia Labs](https://www.youtube.com/watch?v=KdkVTEHUxgo) ### Recursive Proofs -Recursive proof composition allows a single proof to attest to the correctness of practically unlimited other proofs, allowing a large amount of computation (and information) to be compressed. This is an essential component for scalablilty, not least because it allows us to horizontally scale the network while still allowing pockets of participants to trust the integrity of the remainder of the network. - -Prior to Halo, achieving recursive proof composition required large computational expense and a trusted setup. One of the main discoveries was a technique called **nested amortization**. This technique allows for recursive composition using the polynomial commitment scheme based on inner product argument, massively improving on performance and avoiding the trusted setup. +Recursive proof composition allows one proof to attest to the correctness of many other proofs. This is useful for scaling because a large amount of computation can be compressed into a smaller verification step. -In the [Halo paper](https://eprint.iacr.org/2019/1021.pdf), we fully described this polynomial commitment scheme and discovered a new aggregation technique existed in it. The technique allows a large number of independently created proofs to be verified nearly as quickly as verifying a single proof. This alone would offer a better alternative to the earlier zk-SNARKs used in Zcash. +Before Halo, efficient recursion usually required either a trusted setup or significant proving overhead. Halo's nested amortization technique made recursive composition practical without requiring a trusted setup. +In the [Halo paper](https://eprint.iacr.org/2019/1021.pdf), Electric Coin Co. described a polynomial commitment scheme and an aggregation technique that lets many independently created proofs be verified almost as quickly as a single proof. That alone made Halo a strong alternative to earlier zk-SNARK systems used in Zcash. ### Halo 2 -Halo 2, is a high-performance zk-SNARK implementation written in Rust which eliminates the need for a trusted setup while setting the stage for scalability in Zcash. +Halo 2 is a high-performance zk-SNARK implementation written in Rust. It generalizes the original Halo approach and is the proving system used by Zcash's Orchard shielded pool. - + Halo puzzle illustration -It includes a generalization of our approach called an **accumulation scheme**. This new formalization exposes how our nested amortization technique actually works; by adding proofs to an object called an **accumulator,** where the proofs reason about the previous state of the accumulator, we can check that all previous proofs were correct (by induction) simply by checking the current state of the accumulator. +Halo 2 uses an **accumulation scheme**. In this design, proofs are added to an object called an accumulator. Each new proof reasons about the previous state of the accumulator, so checking the current accumulator state gives confidence that the earlier proofs were also correct. - + Halo 2 accumulation scheme diagram +Halo 2 also builds on improvements in polynomial interactive oracle proofs. In parallel with Halo research, other teams developed more efficient Polynomial IOPs such as Marlin and PLONK. PLONK provides flexibility for application-specific circuits and improved prover performance compared with Sonic. +[Overview of PLONK](https://www.youtube.com/watch?v=P1JeN30RdwQ) -In parallel, many other teams were discovering new Polynomial IOPs that were more efficient than Sonic (used in Halo 1), such as Marlin. +## Practical Implications -The most efficient of these new protocols is PLONK, which grants enormous flexibility in designing efficient implementations based on application-specific needs and providing 5x better prover time from Sonic. +### For Zcash -[Overview of PLONK](https://www.youtube.com/watch?v=P1JeN30RdwQ) +The Orchard shielded pool activated with NU5 in 2022 and uses Halo 2. Orchard was introduced with the same turnstile design used between Sprout and Sapling, with the long-term goal of encouraging migration to a fully trustless proof system and reducing Zcash's implementation complexity and attack surface. +Halo 2 matters for Zcash because it removes the need to coordinate a trusted setup for new shielded-pool upgrades. Trusted setups are difficult to coordinate and introduce systemic risk if the secret material is ever retained. Removing that dependency makes future protocol upgrades safer to ship. -### How does this benefit Zcash? +Orchard also introduced "Actions" to replace the older input/output model for shielded transactions, helping reduce transaction metadata. After NU5, recursive-proof integration became possible, although broader recursive scaling work is still an area of ongoing research and development. -The Orchard Shielded pool activated with NU5 & is the implementation of this new proof system on the Zcash Network. Guarded by the same turnstile design as used between Sprout and Sapling with the intent to gradually retire the older shielded pools. This encourages migration to a fully trustless proof system, reinforcing confidence in the soundness of the monetary base, and reducing the implementation complexity and attack surface of Zcash overall. Following the activation of NU5 mid 2022, integration of recursive proofs became possible (although this is not complete). Several privacy enhancements were also made tangentially. The introduction of 'Actions' to replace inputs/outputs helped reducing the amount of transaction metadata. +### For future scalability -Trusted setups are generally difficult to coordinate & presented a systemic risk. It would be necessary to repeat them for each major protocol upgrade. Removing them presents a substantial improvement for safely implementing new protocol upgrades. +Recursive proof composition has the potential to compress large amounts of computation into proofs that are small and fast to verify. That can support auditable distributed systems, future Zcash protocol extensions, and higher Layer 1 capacity at the upper end of full-node usage, including future protocol directions such as Proof of Stake research. -Recursive proof composition holds the potential for compressing unlimited amounts of computation, creating auditable distributed systems, making Zcash highly capable particularly with the shift to Proof of Stake. This is also useful for extensions such as Zcash Shielded Assets and improving Layer 1 capacity at the higher end of full node usage in the coming years for Zcash. +Halo-style proving systems may also be useful for Zcash Shielded Assets and other privacy-preserving protocol extensions. +## Halo in the Wider Ecosystem -## Halo in the wider ecosystem +Electric Coin Co. has explored Halo research with Protocol Labs, the Filecoin Foundation, and the Ethereum Foundation. The shared interest is better scalability, interoperability, and privacy across Web3 ecosystems. -The Electric Coin Company has entered into an agreement with Protocol Labs, the Filecoin Foundation, and the Ethereum Foundation to explore Halo R&D, including how the technology might be used in their respective networks. The agreement aims to provide better scalability, interoperability and privacy across ecosystems and for Web 3.0. - -Additionally, Halo 2 is under the [MIT and Apache 2.0 open-source licenses](https://github.com/zcash/halo2#readme), meaning anyone in the ecosystem can build with the proving system. +Halo 2 is available under the [MIT and Apache 2.0 open-source licenses](https://github.com/zcash/halo2#readme), so other projects can build with the proving system. ### Filecoin -Since its deployment, the halo2 library has been adopted in projects like the zkEVM, there is potential integration of Halo 2 into the proof system for the Filecoin Virtual Machine. Filecoin requires numerous costly proofs of spacetime / proofs of replication. Halo2 will be pivotal in compressing the space usage, better scaling the network. +The Halo 2 library has been adopted in projects such as zkEVM work, and there is potential for Halo 2 to support Filecoin proof-system improvements. Filecoin requires many costly proofs of spacetime and proofs of replication, so proof compression is valuable for scaling the network. [Filecoin Foundation video with Zooko](https://www.youtube.com/watch?v=t4XOdagc9xw) -Additionally, it would be highly beneficial to both the Filecoin and Zcash ecosystems if Filecoin storage payments could be made in ZEC, affording the same level of privacy for storage purchases that exists in Zcash shielded transfers. This support would add the ability to encrypt files in Filecoin storage and add support to mobile clients so that they could **attach** media or files to a Zcash encrypted memo. +Zcash and Filecoin also have complementary privacy and storage goals. It would be useful for Filecoin storage payments to support ZEC, giving users the same level of privacy for storage purchases that they can get from Zcash shielded transfers. Related work could include encrypted file storage, mobile-client support, and Zcash encrypted memo attachments. -[ECC x Filecoin Blog Post](https://electriccoin.co/blog/ethereum-zcash-filecoin-collab/) +[ECC x Filecoin blog post](https://electriccoin.co/blog/ethereum-zcash-filecoin-collab/) ### Ethereum -Implementation of a Halo 2 proof for the efficient Verifiable Delay Function (VDF) being developed. A VDF is a cryptographic primitive that has many potential use cases. - -It can be used as a source of general purpose randomness including use in smart contract applications as well as leader election in Proof of Stake on Ethereum & other protocols. - -ECC, the Filecoin Foundation, Protocol Labs, and the Ethereum Foundation will also be working with [SupraNational](https://www.supranational.net/), a vendor specializing in hardware-accelerated cryptography, for potential GPU and ASIC design and development of the VDF. - -The [Privacy and Scaling Exploration group](https://appliedzkp.org/) is also researching different ways Halo 2 proofs can improve privacy and scalability for the Ethereum ecosystem. This group rolls up to the Ethereum foundation, and has a broad focus on zero-knowledge proofs and cryptographic primitives. - -## Other projects using Halo - -+ [Anoma, a privacy preserving multichain atomic swap protocol](https://anoma.net/blog/an-introduction-to-zk-snark-plonkup) - -+ [Oribis, an L2 zkRollup on Cardano](https://docs.orbisprotocol.com/orbis/technology/halo-2) +Halo 2 research has also been explored in connection with efficient Verifiable Delay Functions (VDFs). A VDF is a cryptographic primitive that can be used for randomness, smart-contract applications, and leader election in Proof of Stake systems. -+ [Darkfi, a private L1 zkEVM blockchain](https://darkrenaissance.github.io/darkfi/architecture/architecture.html) +ECC, the Filecoin Foundation, Protocol Labs, and the Ethereum Foundation have also worked with [Supranational](https://www.supranational.net/), a hardware-accelerated cryptography vendor, for potential GPU and ASIC design and development of VDF-related work. -+ [Scroll, an L2 zkRollup on Ethereum](https://scroll.mirror.xyz/nDAbJbSIJdQIWqp9kn8J0MVS4s6pYBwHmK7keidQs-k) +The [Privacy and Scaling Exploration group](https://appliedzkp.org/) has researched ways Halo 2 proofs can improve privacy and scalability in the Ethereum ecosystem. +### Other projects using Halo -**Further Learning**: +- [Taiga, Anoma's resource-machine proving system](https://specs.anoma.net/main/arch/node/ordering/execution/taiga.html) +- [Orbis, an L2 zkRollup on Cardano](https://docs.orbisprotocol.com/orbis/technology/halo-2) +- [DarkFi, a private L1 zkVM blockchain](https://dark.fi/book/arch/overview.html) -[An introduction to zkp and halo 2 - Hanh Huynh Huu](https://www.youtube.com/watch?v=jDHWJLjQ9oA) +## Common Mistakes -[Halo 2 with Daira & Str4d - ZKPodcast](https://www.youtube.com/watch?v=-lZH8T5i-K4) +- **Thinking Halo is a wallet or chain.** Halo is a proving-system design, and Halo 2 is an implementation used by Zcash and other projects. +- **Assuming every Zcash pool uses Halo.** Orchard uses Halo 2. Older pools such as Sprout and Sapling used earlier proving systems. +- **Treating recursion as finished scaling by itself.** Halo makes recursive proofs possible, but production scaling still depends on protocol design, engineering work, and wallet/full-node support. +- **Confusing no trusted setup with no cryptographic assumptions.** Halo removes setup trust, but it still depends on the security assumptions of its proof system and implementation. -[Technical Explainer Blog](https://electriccoin.co/blog/technical-explainer-halo-on-zcash/) +## Related Pages -[Halo 2 Community Showcase - Ying Tong @Zcon3](https://www.youtube.com/watch?v=JJi2TT2Ahp0) +- [ZK-SNARKs](/zcash-tech/zk-snarks) - The zero-knowledge proof family that Halo builds on +- [Zcash Shielded Assets](/zcash-tech/zcash-shielded-assets) - Future shielded asset work that can benefit from modern Zcash proving systems +- [Shielded Pools](/using-zcash/shielded-pools) - Orchard, Sapling, Sprout, and transparent value pools +- [Transactions](/using-zcash/transactions) - How Zcash transactions use shielded privacy -**Documentation** +## Further Learning -[Halo 2 resources](https://github.com/adria0/awesome-halo2) +- [An introduction to ZKP and Halo 2 - Hanh Huynh Huu](https://www.youtube.com/watch?v=jDHWJLjQ9oA) +- [Halo 2 with Daira & Str4d - ZKPodcast](https://www.youtube.com/watch?v=-lZH8T5i-K4) +- [Technical explainer blog](https://electriccoin.co/blog/technical-explainer-halo-on-zcash/) +- [Halo 2 community showcase - Ying Tong @ Zcon3](https://www.youtube.com/watch?v=JJi2TT2Ahp0) -[Halo 2 docs](https://zcash.github.io/halo2/) +## Documentation -[Halo 2 github](https://github.com/zcash/halo2) +- [Halo 2 resources](https://github.com/adria0/awesome-halo2) +- [Halo 2 docs](https://zcash.github.io/halo2/) +- [Halo 2 GitHub repository](https://github.com/zcash/halo2) diff --git a/site/Zcash_Tech/Viewing_Keys.md b/site/Zcash_Tech/Viewing_Keys.md index 9482e0b4e..5602529a4 100644 --- a/site/Zcash_Tech/Viewing_Keys.md +++ b/site/Zcash_Tech/Viewing_Keys.md @@ -4,60 +4,127 @@ # Viewing Keys -Shielded addresses enable users to transact while revealing as little information as possible on the Zcash blockchain. What happens when you need to disclose sensitive information around a shielded Zcash transaction to a specific party? Every shielded address includes a viewing key. Viewing keys were introduced in [ZIP 310](https://zips.z.cash/zip-0310) and added to the protocol in the Sapling network upgrade. Viewing keys are a crucial part of Zcash as they allow users to selectively disclose information about transactions. +## TL;DR + +- **Viewing keys** let someone see selected shielded Zcash transaction information without getting spending authority. +- They are useful when a user, exchange, custodian, auditor, or compliance team needs read-only visibility into shielded activity. +- A viewing key is not a private spending key. It cannot move funds by itself. +- Sharing a viewing key still reveals sensitive financial information, so it should only be shared with a trusted party and for a clear purpose. +- Some tools support incoming, full, Sapling, or unified viewing keys differently, so always check wallet and `zcashd` support before importing one. + +--- + +## Core Explanation + +Shielded Zcash addresses are designed to reveal as little information as possible on the public blockchain. That privacy is powerful, but sometimes a user needs to disclose specific shielded transaction information to another party. + +A viewing key is the read-only tool for that job. It allows someone to inspect shielded transaction activity associated with an address or account without receiving the private spending key. In other words, a viewing key can help someone see relevant transaction data, but it should not let them spend the ZEC. + +Viewing keys are an important part of selective disclosure in Zcash. They make it possible to use shielded addresses while still supporting auditing, exchange deposit detection, accounting, or enhanced due diligence when those workflows are needed. + +Viewing-key behavior is documented in [ZIP 310](https://zips.z.cash/zip-0310), and the capability was added to the protocol in the Sapling network upgrade. Unified viewing keys are specified separately in [ZIP 316](https://zips.z.cash/zip-0316). + +## Practical Implications ### Why use a viewing key? -Why would a user ever want to do this? From Electric Coin Co.'s blog on the matter... +Electric Coin Co. gives several useful examples: -*- An exchange wants to detect when a customer deposits ZEC to a shielded address, while keeping the **spend authority** keys on secure hardware. The exchange could generate an incoming viewing key and load it onto an Internet-connected **detection** node, while the spending key remains on the more secure system.* +- **Exchange deposit detection.** An exchange can keep spending keys on secure hardware while loading an incoming viewing key onto an Internet-connected detection node. The detection node can see when a customer deposits ZEC to a shielded address without holding the spend authority. +- **Custody and audits.** A custodian can provide auditors with a full viewing key for shielded addresses so the auditor can verify balances and review transaction activity. +- **Due diligence.** An exchange or regulated service may ask a customer to share a viewing key so it can review shielded transaction activity as part of enhanced due diligence. -*- A custodian needs to provide visibility of their Zcash holdings to auditors. The custodian may generate a full viewing key for each of their shielded addresses and share that key with their auditor. The auditor will be able to verify the balance of those addresses and review past transaction activity to and from those addresses.* +In each case, the viewing key gives visibility without giving control of funds. -*- An exchange may need to conduct due diligence checks on a customer who makes deposits from a shielded address. The exchange could request the customers viewing key for their shielded address and use it to review the customers shielded transaction activity as part of these enhanced due diligence procedures.* +## How to Find Your Viewing Key -### How to find your viewing key +### zcashd -#### zcashd +List all known addresses: -* List all known addresses using *./zcash-cli listaddresses* +```bash +./zcash-cli listaddresses +``` -* Then issue the following command for either UA's or Sapling shielded addresses +Export the viewing key for a supported Unified Address or Sapling shielded address: - *./zcash-cli z_exportviewingkey ""* +```bash +./zcash-cli z_exportviewingkey "" +``` -#### Ywallet +### YWallet -* On the top right corner select "Backup", Authenticate your phone, then simply copy your viewing key that is displayed. +1. Open the account in YWallet. +2. Select **Backup** in the top-right corner. +3. Authenticate on your device. +4. Copy the viewing key shown by the wallet. -### How to use your viewing key +## How to Use Your Viewing Key -#### zcashd +### zcashd -* Use the following with any vkey or ukey: +Use `z_importviewingkey` with a supported viewing key type: -*./zcash-cli z_importviewingkey "vkey/ukey" whenkeyisnew 30000* +```bash +./zcash-cli z_importviewingkey "vkey/ukey" whenkeyisnew 30000 +``` -#### ywallet +Support for different viewing-key formats can vary by `zcashd` version. Check the current RPC documentation for your version before relying on unified viewing-key import. -* In the top right corner, select "Account", click on "+" in the bottom right corner to add and import your viewing key to add your 'read-only' account. +### YWallet + +1. Select **Account** in the top-right corner. +2. Click **+** in the bottom-right corner. +3. Import the viewing key to add a read-only account. - + YWallet viewing key import screen +### Zcash viewing-key explorer + +Open [mainnet.zcashexplorer.app/vk](https://mainnet.zcashexplorer.app/vk) and enter the viewing key to inspect compatible shielded activity. + +Important: this sends viewing-key information to the block explorer service. Only use this option if you are comfortable trusting the operator of that service with the information the viewing key reveals. + +## Deep Dive + +### Viewing keys vs spending keys + +A spending key controls funds. Anyone with the spending key can authorize transactions. A viewing key is different: it is intended for read access. + +That difference makes viewing keys useful, but it does not make them harmless. A viewing key can reveal sensitive information such as transaction history, balances, or counterparties depending on the type of key and the transactions involved. + +### Incoming, full, and unified viewing keys + +Zcash tooling can expose different kinds of viewing keys: + +- **Incoming viewing keys** are focused on detecting incoming payments. +- **Full viewing keys** can reveal broader shielded activity for an address or account. +- **Unified viewing keys** bundle viewing information for a Unified Address across supported receiver types. + +Wallets and node software do not all expose these formats in the same way. When sharing or importing a viewing key, confirm which type you have and what the receiving tool supports. -#### zcashblockexplorer.com +## Common Mistakes -* Simply point your browser to [here](https://zcashblockexplorer.com/vk) and wait for the results! note: this result is now on the zcashblockexplorer node and thus you're trusting this info with the owners of zcashblockexplorer.com +- **Sharing a spending key instead of a viewing key.** A spending key can move funds. Never share it for read-only access. +- **Treating viewing keys as public.** Viewing keys are disclosure tools, not public identifiers. Share them only with parties that should see the associated activity. +- **Assuming a viewing key shows everything.** What it reveals depends on the key type, address type, wallet support, and transaction direction. +- **Entering a viewing key into a third-party website without trust.** A block explorer can be useful, but it also learns what the viewing key can reveal. +- **Forgetting operational separation.** Exchanges and custodians should keep spend authority on secure systems and use viewing keys only for detection or auditing workflows. -### Resources +## Related Pages -While a great technology, it's recommended that you use viewing keys on an as needed basis. +- [Shielded Pools](/using-zcash/shielded-pools) - Orchard, Sapling, Sprout, and transparent value pools +- [Wallets](/using-zcash/wallets) - Wallets that expose shielded-address and viewing-key workflows +- [Transactions](/using-zcash/transactions) - How Zcash transactions move between address types +- [ZK-SNARKs](/zcash-tech/zk-snarks) - The proof system background behind shielded Zcash +- [Halo](/zcash-tech/halo) - The proving-system upgrade behind Orchard -Check out this tutorial on viewing keys. A list of resources on the subject is below if you want to dive deeper: +## Resources - [ECC, Explaining Viewing Keys](https://electriccoin.co/blog/explaining-viewing-keys/) - [ECC, Selective Disclosure and Viewing Keys](https://electriccoin.co/blog/viewing-keys-selective-disclosure/) - [ECC, Zcash Viewing Key Video Presentation](https://www.youtube.com/watch?v=NXjK_Ms7D5U&t=199s) -- [ZIP 310](https://zips.z.cash/zip-0310) +- [ZIP 310: Security Properties of Sapling Viewing Keys](https://zips.z.cash/zip-0310) +- [ZIP 316: Unified Addresses and Unified Viewing Keys](https://zips.z.cash/zip-0316)