diff --git a/_posts/2016-04-15-why-equihash.md b/_posts/2016-04-15-why-equihash.md index 71a485c..8834d43 100644 --- a/_posts/2016-04-15-why-equihash.md +++ b/_posts/2016-04-15-why-equihash.md @@ -10,7 +10,7 @@ post_date: 2016-04-15 00:00:00 --- In our last blog post, we announced that we have started using Equihash as the proof-of-work for block mining in Zcash (#27). -Equihash is a Proof-of-Work algorithm devised by Alex Biryukov and Dmitry Khovratovich. It is based on a computer science and cryptography concept called the Generalized Birthday Problem. +Equihash is a Proof-of-Work algorithm devised by Alex Biryukov and Dmitry Khovratovich. It is based on a computer science and cryptography concept called the Generalized Birthday Problem.

Why are we using it?

Equihash has very efficient verification. This could in the future be important for light clients on constrained devices, or for implementing a Zcash client inside Ethereum (like BTC Relay, but for Zcash). diff --git a/_posts/2016-11-29-zcash-private-transactions.md b/_posts/2016-11-29-zcash-private-transactions.md index be98459..b897f30 100644 --- a/_posts/2016-11-29-zcash-private-transactions.md +++ b/_posts/2016-11-29-zcash-private-transactions.md @@ -25,7 +25,7 @@ Suppose :math:`\mathsf{PK}_1` is Alice's address and she wishes to send her 1 BT Now suppose each note also contains a random 'serial number' (aka unique identifier) :math:`r.` We will soon see this is helpful for obtaining privacy. Thus, the database may look like this. -:math:`\mathsf{Note}_1=` :math:`(\mathsf{PK}_1,r_1)`, :math:`\mathsf{Note}_2=` :math:`(\mathsf{PK}_1,r_1)`, :math:`\mathsf{Note}_3=` :math:`(\mathsf{PK}_2,r_2)` +:math:`\mathsf{Note}_1=` :math:`(\mathsf{PK}_1,r_1)`, :math:`\mathsf{Note}_2=` :math:`(\mathsf{PK}_1,r_2)`, :math:`\mathsf{Note}_3=` :math:`(\mathsf{PK}_2,r_3)` A natural first step towards privacy would be to have the node store only "encryptions", or simply hashes, of the notes, rather than the notes themselves. @@ -64,7 +64,7 @@ More precisely, she does the following.
  • She randomly chooses a new serial number :math:`r_4` and defines the new note :math:`\mathsf{Note}_4=` :math:`(\mathsf{PK}_4,r_4).`
  • She sends :math:`\mathsf{Note}_4` to Bob privately.
  • She sends the nullifier of :math:`\mathsf{Note}_1,` :math:`\mathsf{nf}_2=` :math:`\mathbf{HASH}(\mathsf{r}_1)` to all nodes.
    • -
  • She sends the hash of the new note :math:`\mathsf{H}_4=,` :math:`\mathbf{HASH}(\mathsf{Note}_4)` to all nodes.
    • +
  • She sends the hash of the new note :math:`\mathsf{H}_4=` :math:`\mathbf{HASH}(\mathsf{Note}_4)` to all nodes.
    • Now, when a node receives :math:`\mathsf{nf}_2` and :math:`\mathsf{H}_4,` it will check whether the note corresponding to :math:`\mathsf{nf}_2` has already been spent, simply by checking if :math:`\mathsf{nf}_2` already exists in the nullifier set. If it doesn't, the node adds :math:`\mathsf{nf}_2` to the nullifier set and adds :math:`\mathsf{H}_4` to the set of hashed notes; thereby validating the transaction between Alice and Bob. @@ -97,27 +97,21 @@ Now, when a node receives :math:`\mathsf{nf}_2` and :math:`\mathsf{H}_4,` it wil This is where Zero-Knowledge proofs come to the rescue: -In addition to the steps above, Alice will publish a proof-string :math:`\pi` convincing the nodes that whomever published this transaction knows values :math:`\mathsf{PK}_1,` :math:`\mathsf{sk}_1,` and :math:`r_1` such that -
      -
    1. +In addition to the steps above, Alice will publish a proof-string :math:`\pi` convincing the nodes that whomever published this transaction knows values :math:`\mathsf{PK}_1,` :math:`\mathsf{sk}_1,` and :math:`r_1` such that
      1. The hash of the note :math:`\mathsf{Note}_1=` (:math:`\mathsf{PK}_1,` :math:`r_1)` exists in the set of hashed notes.
      2. :math:`\mathsf{sk}_1` is the private key corresponding to :math:`\mathsf{PK}_1` (and thus, whomever knows it is the rightful owner of :math:`\mathsf{Note}_1`).
      3. The hash of :math:`r_1` is :math:`\mathsf{nf}_2`, (and thus, if :math:`\mathsf{nf}_2` - that we now know is the nullifier of :math:`\mathsf{Note}_1` - is not currently in the nullifier set, :math:`\mathsf{Note}_1` still hasn't been spent).
      -
      2. -
    +  + The properties of Zero-Knowledge proofs will ensure no information about :math:`\mathsf{PK}_1,` :math:`\mathsf{sk}_1,` or :math:`r_1` are revealed by :math:`\pi`.

    The main places above where we cheated or omitted details

    We emphasize that this has been an oversimplified description, and recommend the protocol spec for full details. Here are some of the main things that were overlooked:
      -
    1. -
      1. The hashed notes need to be stored not just as a list, but in a Merkle tree. This plays an important role in making the Zero-Knowledge proofs efficient. Moreover, we need to store a computationally hiding and binding commitment of the note, rather than just its hash.
        2. -
      2. The nullifier needs to be defined in a slightly more complex way to ensure future privacy of the receiver in relation to the sender.
        3. -
      3. We did not go into details on how to eliminate the need for a private channel between sender and recipient.
        4. -
      -
      2. +
    2. The nullifier needs to be defined in a slightly more complex way to ensure future privacy of the receiver in relation to the sender.
      3. +
    3. We did not go into details on how to eliminate the need for a private channel between sender and recipient.
    \ No newline at end of file diff --git a/_posts/2017-05-01-release-cycle-and-lifetimes.md b/_posts/2017-05-01-release-cycle-and-lifetimes.md index 67edf6b..3a0787b 100644 --- a/_posts/2017-05-01-release-cycle-and-lifetimes.md +++ b/_posts/2017-05-01-release-cycle-and-lifetimes.md @@ -71,4 +71,4 @@ Please reach out to us with any feedback on this new release policy. You can fin
    - + \ No newline at end of file diff --git a/_posts/2017-09-22-release-cycle-update.md b/_posts/2017-09-22-release-cycle-update.md index ec3af0e..fad4b4a 100644 --- a/_posts/2017-09-22-release-cycle-update.md +++ b/_posts/2017-09-22-release-cycle-update.md @@ -27,4 +27,4 @@ As we stated previously, once a version is deprecated via the end-of-support hal At block 193076, all nodes running version 1.0.9 which do not have the -disabledeprecation=1.0.9 flag set to opt out of end-of-support halt will automatically shut down. These nodes should already be receiving a related message about the upcoming version deprecation. -Of course we recommend that instead of using the configuration to disable deprecation of 1.0.9 that node operators update to the most recent version of zcashd or another well-maintained implementation. Client and network security improvements are often addressed in releases so it's a good idea to always stay updated with the most recent version. If there is a particular reason why you cannot update or do not want to, please reach out to us in the community chat or by email so we can better understand your needs. We're also happy to answer any questions about the release cycle or deprecation policy and will communicate any future changes to these processes we deem beneficial. +Of course we recommend that instead of using the configuration to disable deprecation of 1.0.9 that node operators update to the most recent version of zcashd or another well-maintained implementation. Client and network security improvements are often addressed in releases so it's a good idea to always stay updated with the most recent version. If there is a particular reason why you cannot update or do not want to, please reach out to us in the community chat or by email so we can better understand your needs. We're also happy to answer any questions about the release cycle or deprecation policy and will communicate any future changes to these processes we deem beneficial. \ No newline at end of file diff --git a/_posts/2017-11-20-new-release-1-0-13.md b/_posts/2017-11-20-new-release-1-0-13.md index 4f5bcc5..27e47fc 100644 --- a/_posts/2017-11-20-new-release-1-0-13.md +++ b/_posts/2017-11-20-new-release-1-0-13.md @@ -27,4 +27,4 @@ Summary of the changes included in this release: We're encouraging all users and miners to update to this new version. See our download page and the 1.0 User Guide for more information. -For a more complete list of changes, see our 1.0.13 GitHub milestone. To follow our progress, watch the GitHub project and join the forum. +For a more complete list of changes, see our 1.0.13 GitHub milestone. To follow our progress, watch the GitHub project and join the forum. \ No newline at end of file diff --git a/_posts/2018-07-13-whats-new-in-sapling.md b/_posts/2018-07-13-whats-new-in-sapling.md index 324697e..022f0ea 100644 --- a/_posts/2018-07-13-whats-new-in-sapling.md +++ b/_posts/2018-07-13-whats-new-in-sapling.md @@ -11,7 +11,7 @@ post_date: 2018-07-13 22:03:46 --- The next major upgrade of Zcash, codenamed Sapling, is scheduled to activate in October 2018. The specific block height has not yet been determined. -Sapling represents over two years of protocol design and engineering with cryptographic breakthroughs that improve the performance and functionality of shielded (encrypted) transactions. Currently, most Zcash transaction use transparent addresses that function in the same way as Bitcoin. This is largely due to the computational cost of proving that shielded transactions are valid. With Sapling, we move one (giant) step closer to moving toward the ubiquity of shielded addresses. +Sapling represents over two years of protocol design and engineering with cryptographic breakthroughs that improve the performance and functionality of shielded (encrypted) transactions. Currently, most Zcash transaction use transparent addresses that function in the same way as Bitcoin. This is largely due to the computational cost of proving that shielded transactions are valid. With Sapling, we move one (giant) step closer toward the ubiquity of shielded addresses.

    Performance for Shielded Transactions

    Changes

    Today, if you create a new z-address it'll look something like this: @@ -22,17 +22,17 @@ A z-address generated after Sapling activation will look something like this: 
    zs1z7rejlpsa98s2rrrfkwmaxu53e4ue0ulcrw0h4x5g8jl04tak0d3mm47vdtahatqrlkngh9sly
    This new, shorter address starts with "zs" and is called a Sapling z-address. The legacy Sprout z-addresses will continue to function after Sapling activates, but will later be deprecated in favor of this new address.

    Implications

    -Payments involving the new Sapling z-addresses can be constructed in as little as a few seconds and with only 40 megabytes of memory. Exchanges, mobile wallet wallet providers, vendors and other 3rd parties will now be able to support shielded addresses. +Payments involving the new Sapling z-addresses can be constructed in as little as a few seconds and with only 40 megabytes of memory. Exchanges, mobile wallet providers, vendors and other 3rd parties will now be able to support shielded addresses. The increased use of shielded addresses will improve the effective privacy for the entire network.

    Decoupled Spend Authority

    Changes

    -All shielded transactions require the creation of a zero-knowledge proof. Today, the hardware that constructs the proof must also be in possession of the spending key that authorizes the transaction. Sapling changes this by allowing the hardware that constructs the proof to be independent from the hardware that signs the transaction. +All shielded transactions require the creation of a zero-knowledge proof. Today, the hardware that constructs the proof must also be in possession of the spending key that authorizes the transaction. Sapling changes this by allowing the hardware that constructs the proof to be independent from the hardware that signs for the transaction.

    Implications

    Enterprises can perform an inexpensive signature step in a trusted environment while allowing another computer, not trusted with the spending key, to construct the proof. Additionally, hardware wallets can support shielded addresses by allowing the connected computer to construct the proof without exposing the spending key to that machine.

    Improved keys

    Changes

    -Shielded addresses currently support an incoming viewing key. Holders of an incoming viewing key for a shielded address are able to see the value of all incoming transactions and the memo field. They cannot see the sending address and cannot spend the funds. +Shielded addresses currently support an incoming viewing key. The holder of an incoming viewing key for a shielded address is able to see the value of all incoming transactions and the memo field. They cannot see the sending address and cannot spend the funds. Sapling extends the capability of the viewing key to include visibility into outgoing transactions for a shielded address. Visibility includes the transaction value, memo field and target address.

    Implications

    diff --git a/_posts/2018-07-25-bitgo-adds-zcash.md b/_posts/2018-07-25-bitgo-adds-zcash.md new file mode 100644 index 0000000..fafb22c --- /dev/null +++ b/_posts/2018-07-25-bitgo-adds-zcash.md @@ -0,0 +1,17 @@ +--- +ID: 3292 +post_title: BitGo Adds Zcash +author: Josh Swihart +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/bitgo-adds-zcash/ +published: true +post_date: 2018-07-25 12:12:23 +--- + + +BitGo, a market leader in institutional-grade cryptocurrency security, today announced support for Zcash. BitGo provides the highest level of security, compliance and custodial services. It is the world's largest processor of on-chain bitcoin transactions — processing 15% of all global bitcoin transactions and $15 billion per month across all cryptocurrencies. The company has a customer base that spans more than 50 countries and includes the world's largest cryptocurrency exchanges. + +"We are working hard to offer our institutional clients the most complete portfolio of digital currencies," said Ben Chan, CTO, BitGo. "Zcash is a compelling digital currency that many hedge funds, exchanges and customers have been asking for because of its emphasis on privacy. We are glad to deliver a secure multi-signature implementation to store Zcash today." + +BitGo represents a growing number of industry leaders that have recently announced support for Zcash. Already this year, Circle and Gemini announced support for Zcash after receiving approval from the NYDFS. Coinbase recently announced it is exploring adding Zcash for its 20+ million customers. We at the Zcash Company are excited that leaders like BitGo are adopting Zcash and that people are awakening to the benefits of financial privacy. We believe the upcoming Zcash Sapling upgrade will fuel greater adoption of Zcash’s privacy features. \ No newline at end of file diff --git a/_posts/2018-08-09-zcash-perspectives.md b/_posts/2018-08-09-zcash-perspectives.md new file mode 100644 index 0000000..2b94426 --- /dev/null +++ b/_posts/2018-08-09-zcash-perspectives.md @@ -0,0 +1,29 @@ +--- +ID: 3316 +post_title: Zcash Community Perspectives +author: Josh Swihart +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/zcash-perspectives/ +published: true +post_date: 2018-08-09 14:27:05 +--- + + +Earlier this year, people in the Zcash ecosystem participated in Zcon0, the first conference for the Zcash community. The conference brought together an eclectic group of brilliant thinkers, cryptographers, engineers, cryptocurrency founders and financial leaders to beautiful Montreal for three days. We met in hotel conference rooms, hallways, restaurants, parks and bars to share progress, challenge ideas and inspire one another. We explored a wide range of topics, including incentives, governance, scaling, circuits and elliptic curves. If you were there, you know how good it was. + +While the main sessions were live-streamed, much of the conversation happened off the main stage. Over the course of the conference, we sat down with various members of the community to capture their perspectives on topics like protocol governance, usability, the upcoming Zcash protocol upgrade, regulation, market sentiment, challenges and, of course, privacy. + +In the coming weeks, we’ll be releasing short videos (via YouTube and Twitter) of these conversations with members of the Zcash Company founders and engineers as well as community thought leaders, including Linda Xie, Jill Carlson, Ruben Galindo, JZ and Peter Van Valkenburgh. +

    Today we’ve released the first two videos in our Perspectives Series

    +Zcash Company CTO Nathan Wilcox on designing for privacy. + +[embed]https://youtu.be/xyNbW5Mdhrw[/embed] + +Ethereum Founder and Chief Scientist Vitalik Buterin on the importance of privacy. + +[embed]https://youtu.be/gcV9KlnW-dc[/embed] + +You will find both these and the upcoming videos on the Zcash YouTube playlist entitled Perspectives. + +We hope that these and upcoming perspectives will inform, inspire and challenge you. Let us know what you think. Post responses and perspectives of your own. Let’s continue to meet, and talk, and educate, and spur one another on. \ No newline at end of file diff --git a/_posts/2018-08-14-completion-of-the-sapling-mpc.md b/_posts/2018-08-14-completion-of-the-sapling-mpc.md new file mode 100644 index 0000000..80c76eb --- /dev/null +++ b/_posts/2018-08-14-completion-of-the-sapling-mpc.md @@ -0,0 +1,45 @@ +--- +ID: 3312 +post_title: Completion of the Sapling MPC +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/completion-of-the-sapling-mpc/ +published: true +post_date: 2018-08-14 21:01:21 +--- +Zcash's next major upgrade, codenamed Sapling, will be activated later this year. One of our final goals before activation is the completion of a multi-party computation ceremony which produces the public parameters that our shielded transactions depend on. + +We're happy to announce the completion of this ceremony! In total, nearly 200 people contributed either directly to the ceremony or to its development, coordination and review. We're including the final parameters in our 2.0.0 release of Zcash later this week. +

    +

    Images from three Powers of Tau participants: (from left) Neal Jayu, Hudson Jameson and Andrew Miller and Ryan Pierce

    + +

    Ceremonies

    +Zcash's underlying zero-knowledge proofs require some system parameters to be constructed. If these parameters are compromised, an adversary could create counterfeit Zcash coins. In our original launch of Zcash, we defended against this by deploying a multi-party computation protocol. The protocol has the property that only one of its participants must be honest in order for the final parameters to be secure. + +In the original ceremony, we only had six participants due to scalability issues of the protocol. In addition, due to the sensitivity of the process to protocol aborts, participants did not apply a wide diversity of individual countermeasures to defend against compromise. + +Last year, we published a new protocol for constructing the parameters which is designed to scale to a large number of participants. Unlike the original protocol, a participant can contribute to the ceremony at any time, and they do not need to be in custody of secrets during the entire duration of the ceremony. + +Additionally, the new protocol is split into two pieces: a circuit-agnostic phase called the Powers of Tau, and a circuit-specific phase that we announced several months ago. This allows the broader public to take advantage of the parameters we produced in order to build their own zk-SNARK protocols with scalable MPCs. +

    Powers of Tau

    +The Zcash Foundation facilitated and hosted the Powers of Tau ceremony, which took place between November 2017 and April 2018. It accepted 87 contributions from cryptographers and members of the community. Only one of these contributions needs to be honestly constructed for the parameters in this phase to be secure. + +The diversity of this ceremony was significant. Participants used a wide variety of hardware and operating systems, and many destroyed their hardware afterward. Anyone was allowed to participate either by asking directly or publicly requesting to participate via a mailing list. + +Most of the participants wrote about their experience and the unique countermeasures they deployed. Andrew Miller and Ryan Pierce famously flew in a plane with radioactive material to seed their random number generator. Filippo Valsorda wrote an independent implementation of the ceremony code in Go. Devrandom developed a trusted build environment for the Rust code. + +You can read more about this ceremony here, along with instructions for how to verify its results. +

    Sapling MPC

    +The Zcash Company hosted the MPC for constructing Sapling's final zk-SNARK parameters. We announced the ceremony in May and accepted contributions through early August. In all, this ceremony accepted over 90 contributions, of which only one must be honestly constructed for the success of this phase. + +The final parameters are now available here. You can verify the parameters using the verify utility in the sapling-mpc repository. Just as in the Powers of Tau ceremony, we applied a random beacon which you can read about in the zapps-wg mailing list. + +All of the participants can run this verifier and check that it outputs a hash that their software produced when they contributed to the ceremony. This allows them to confirm that the final parameters include their contribution. These hashes are also listed, along with the participants, here. +

    Conclusion

    +We're now ready to move ahead with the Sapling upgrade. The parameters produced by these ceremonies are historic: The Powers of Tau and the Sapling MPC are the largest multi-party computations ever performed. + +We'd like to thank the community for participating and improving the quality and security of Zcash and all protocols that build on top of zk-SNARKs. + +We'd also like to thank Jason Davies and Ian Munoz for their efforts in coordinating the ceremonies, and the Zcash Foundation for hosting the Powers of Tau. \ No newline at end of file diff --git a/_posts/2018-08-16-new-release-2-0-0.md b/_posts/2018-08-16-new-release-2-0-0.md new file mode 100644 index 0000000..0e7f440 --- /dev/null +++ b/_posts/2018-08-16-new-release-2-0-0.md @@ -0,0 +1,44 @@ +--- +ID: 3356 +post_title: 'New Release: 2.0.0' +author: Sean Bowe +post_excerpt: "" +layout: post +permalink: https://blog.z.cash/new-release-2-0-0/ +published: true +post_date: 2018-08-16 23:35:58 +--- +We're happy to announce the release of Zcash 2.0.0, the first Sapling-compatible version of the Zcash node software! +

    Sapling Activation

    +

    Mainnet

    +This release is consensus-compatible with the Sapling network upgrade, and so we're encouraging all users and miners to upgrade as soon as possible. The first block of Sapling will be block 419200, which is expected to be mined on the 28th of October 2018, the second anniversary of Zcash's official launch. You can read more about the Sapling network upgrade here or on the Sapling Network Upgrade page. +

    Testnet

    +Sapling will activate on the testnet at block 280000, which is expected about a week after this release. Sapling had previously activated on testnet, but because changes were made to the consensus rules your node will automatically roll back and proceed on the Overwinter testnet branch until Sapling activates again at the new height. +

    Other Notable Changes

    +

    Experimental Sapling RPC Support

    +This release contains only experimental support for Sapling RPC functionality. Full support for Sapling RPC functionality will appear in the 2.0.1 release. + +Developers must specify -experimentalfeatures and -developersapling to use the existing functionality on testnet after activation. Alternatively, developers can use these features in regtest mode. +

    Fix Peer Banning Bug Introduced In Overwinter

    +After Overwinter activation, nodes syncing from a block height prior to the activation height (347500) experienced slow syncing due to a peer banning mechanism that was introduced to mitigate against a class of DoS attacks from Sprout nodes. This fix replaces the use of peer banning with behavior to ignore invalid transactions. +

    Summary of the Changes Included in this Release

    +
      +
    1. Set the Sapling activation height for mainnet and testnet. (#3469)
      2. +
    2. Adopted the official Sapling system parameters. (#3448)
      3. +
    3. Added support for rollbacks of testnet. (#3443)
      4. +
    4. Added experimental wallet support for Sapling z-addresses. (#3273, #3353, #3392, #3429, #3396, #3458)
      5. +
    5. Added experimental support for building Sapling transactions. (#3417)
      6. +
    6. Added experimental support for Sapling note encryption and decryption. (#3324, #3391)
      7. +
    7. Accept the transaction expiry height as a parameter to RPC call createrawtransaction. (#3336)
      8. +
    8. Prepared the codebase for ZIP 32 integration, including bumping the Rust compiler version to 1.28. (#3447)
      9. +
    9. Begin checking the zk-SNARK parameter hash when loaded into memory. (#3441)
      10. +
    10. Always record the best Sapling anchor on disk even if it is for the empty tree, because rollbacks may occur. (#3463)
      11. +
    11. Fixed a bug where nodes may ban peers during synchronization before network upgrade activation. (#3410)
      12. +
    12. Backport upstream improvements to InitialBlockDownload. (#3263)
      13. +
    13. Update the mainnet checkpoints to improve the speed of initial synchronization. (#3246)
      14. +
    +We're encouraging all users and miners to upgrade to this new version.  See the download page for more information. + +For a more complete list of changes, see the 2.0.0 GitHub milestone. To follow our progress, watch the GitHub project and join the forum. + +  \ No newline at end of file diff --git a/_posts/2018-08-17-perspectives-on-sapling.md b/_posts/2018-08-17-perspectives-on-sapling.md new file mode 100644 index 0000000..4521d69 --- /dev/null +++ b/_posts/2018-08-17-perspectives-on-sapling.md @@ -0,0 +1,26 @@ +--- +ID: 3365 +post_title: Perspectives on Sapling +author: Josh Swihart +post_excerpt: "" +layout: post +permalink: > + https://blog.z.cash/perspectives-on-sapling/ +published: true +post_date: 2018-08-17 14:00:06 +--- + + +Last week we introduced a video series called Perspectives. These short interviews were conducted at Zcon0 on various topics relevant to the Zcash community. + +Yesterday, the Zcash Company released the first Sapling-compatible Zcash node software and announced that Sapling activation is set at a block height of 419200, which is expected to occur on Zcash’s second birthday, Oct. 28, 2018. + +Sapling is a major protocol upgrade. Due to recent cryptographic breakthroughs, shielded (or private) addresses and transactions will soon be supported by mobile and hardware wallets, exchanges and payment processors. This will greatly improve the adoption of privacy and bring us closer to our vision of empowering everyone with economic freedom and opportunity. + +For this week’s Perspectives, we’re highlighting Sapling. Zcash engineers Sean Bowe and Ariel Gabizon provide an overview of some of the detail and expected benefits with this upgrade, including proof-construction improvements, new zk-SNARK parameters, and delegated proving. + +[embed]https://youtu.be/KECoajyj8v8[/embed] + +[embed]https://youtu.be/zPFhr546oYc[/embed] + +All videos in the Perspectives series are available on the Zcash YouTube channel. If you missed it, last week’s Perspectives focused on privacy. Take a look at thoughts from Zcash CTO Nathan Wilcox and Ethereum Founder and Chief Scientist Vitalik Buterin. \ No newline at end of file