Updated details [ZEC] ZCASH + Announcing Zcash Cloud Mining

The Near Future of Zcash

Our Mission
is to make Zcash the premier platform for commerce — secure,
borderless, and available equally to every person on our planet. We
believe that Zcash can do for resource sharing and coordination what the
Internet did for communication.

the story so far

Zcash first launched on October 28, 2016. During the first few months of its life, we focused on stabilization and incremental improvement.

We delivered a series of improvements (the “Zcash Sprout” series of releases) which fix bugs and improve usability based on iterative feedback from our lovely users. Our users are the best! ❤

At the same time, we've been monitoring and supporting the continuous reliable operation of the global Zcash network. So far, the network has experienced zero downtime, and no security breaches.

Now we are announcing our development priorities for the next stage of Zcash's growth.

stability

Our first and second priorities will always be:

Security and reliability, and

Iterative improvement in response to demand from our users.

We will continue to vigilantly guard the security of the system,
support our users, and deliver regular stable releases as we have been
doing.

innovation

Payment Disclosure will allow you to reveal the information about a specific payment (including the encrypted memo field) in the blockchain to a specific party of your choice.

This could be used, for example, by an exchange to prove to a
customer or to a third party adjudicator that they sent a certain
payment, without revealing the payment information to any unauthorized
parties. (Payment Disclosure on GitHub)

Payment Off-loading will allow users of light wallets to send Zcash to shielded addresses without placing any funds at risk. (Payment Off-loading on GitHub)

Cross-Chain Atomic Transactions (“XCAT”), part of our Project Alchemy initiative,
will allow transactions that span multiple blockchains. This will
enable you to trade Zcash, Ethereum, and Bitcoin tokens without relying
on an intermediary. (XCAT on GitHub)

The “Sapling” Cryptography Upgrade
will be our first upgrade of the core Zcash protocol which will bring
efficiency improvements and enable new kinds of core protocol features.
The primary example being:

The Sapling upgrade with User-Issued Tokens will require a network-wide upgrade,
and once we reach that stage we will name the new release series “Zcash
Sapling”. At that point the infant Zcash Sprout series will be no more.

this is only the beginning

This is only the beginning! There are already many gleams in our eyes
for dramatic, breakthrough improvements that we intend to make after
Sapling. Along the way we might also adapt our priorities to support new
developments, like Lightning Network or its more privacy-protecting
cousin BOLT.
Other teams and companies may also come out with applications that
extend Zcash or leverage its unique features, so stay tuned.

We will continue to listen carefully to our users, and learn from
them what improvements will help them the most, both in the short term
and the long term. Join the growing Zcash community and let us know what you envision for the future!

As we wrote at the beginning, the ultimate destiny of Zcash lies not in our hands but in yours.

History of Hash Function Attacks

The SHA-1 hash function, which has long been considered insecure, is now officially broken
as of yesterday. Given the renewed interest in hash function
collisions, I'd like to point out an article I wrote about attacks on
secure hash functions, in the hopes that you will find it useful and
interesting.

You can can read the full article at https://z.cash/technology/history-of-hash-function-attacks.html.

The main result of this investigation is that a cryptosystem which is
invulnerable to collision-attacks (even if it is still vulnerable to
pre-image attacks), is much stronger than one which is vulnerable to
collision-attacks. Another interesting takeaway is that it looks like
sometime between 1996 (Tiger) and 2000 (Whirlpool), humanity might have
learned how to make collision-resistant hash functions, since none of
the prominent secure hash functions designed since that era have
succumbed to collision attacks. Maybe modern hash functions like
SHA-256, SHA-3, and BLAKE2 will never be broken

As a graphical reference for the article, I've included a color-coded
chronological view of collision attacks, and of second pre-image
attacks, as well as a survey of the best known attacks on secure hash
functions.

By,

Zooko Wilcox

Thanks to Andreas Hülsing, Samuel Neves, and Zcash engineer Daira Hopwood for their input on this investigation.

Dev Update - March 3 - 2017

This week we’re getting ready for the 1.0.72this note9 by Zooko for his perspective of the next release.

Much of engineering time went towards last minute developments to
include in this next release in addition to testing and review for any
remaining pull-requests tagged for 1.0.7.

One of the more urgent projects we’re working on is documentation and
signaling for best privacy and security practices when using Zcash.
There are some key considerations for all users interested in
maintaining optimal privacy and security when interacting with the
network. We hope to have a first version posted to the website for the
1.0.7 release. In particular, there are two types of analysis that could
potentially lead to privacy leaks: those on transaction graphs and
those on network graphs. In short, we recommend the use of shielded
addresses to protect against transaction graph analysis and IP
obfuscation tools like Tor to protect against network graph analysis.
More on that in an official document in the coming days!

We focused some time on reviewing the Payment Disclosure ZIP draft1
so that next week, work can be put towards a prototype. This is a big
step towards improving shielded address functionality and is one of the near future priorities for Zcash engineering. Some examples listed in the ZIP include:

A sender may need to prove that their payment was sent and received
by a recipient. For example, a customer paid too much for an item and
would like to claim a refund from the vendor.

A third party needs to verify that a payment between sender and
recipient was executed successfully. For example, a regulator needs to
confirm a transfer of funds between two parties

We decided the initial release of Payment Disclosure would come as an
experimental feature - only available to nodes with experimental flag
marked in the config at startup. There is expectation for some
efficiency loss so releasing as an experimental feature will allow us to
get some feedback and insight on the effects on efficiency.

Another one of our near future priorities, payment off-loading (technically referred to as delegated proving1)
also received focused engineering and discussion time this week. A
prototype has been in the works with a ZIP for specifying the initial
implementation coming next.

The HTLC improvements1 for Bitcoin and Zcash are well underway, a step towards XCAT, another near future priority!

We also did some exploration of transaction malleability solutions
such as Bitcoin’s segwit and Bitcoin Classic’s Flexible Transactions.
More discussion and research is required for any decision to be made.
You can always take part in the discussion (and other topics!) by
joining the Community chat1. Our devs typically hold these in the #zcash-dev and #zcash-wizards channels.

We also released the initial chapter of a series of blog posts on explaining zk-SNARKs. This first one on Homomorphic Hiding6.

Make sure to keep an eye out for the 1.0.7 release on Monday and to update your nodes when it’s available!

R3 Report on Confidentiality & Privacy for Blockchains

Last year, R3Blockseer)
a report that compares and contrasts the different techniques for
making blockchains more private. The report was completed in early
November and distributed to the R3 consortium’s membership, where it was
well-received. Today, R3 have published it on their website.

In the report, we describe and compare various approaches to adding
confidentiality and privacy to blockchains, including various tumbling
and mixing protocols such as Coinjoin and Coinshuffle, the use of
stealth addresses, Pedersen commitments with range proofs (more commonly
known as Confidential Transactions), ring signatures (used by Monero)
and zero-knowledge proofs (as implemented in Zcash). We also take a look
at the Hawk and Enigma protocols for enabling the use of private smart
contracts and multi-party computation of encrypted data.

The report is aimed at a non-technical audience, so our descriptions
and explanations of how the various techniques work, are written to
facilitate a high-level understanding by people with no background in
computer science or cryptography, rather than being exhaustively
accurate. For people who are interested in delving deeper into the
detail that we have glossed over, we’ve provided links in the footnotes
to the relevant source material and academic papers.

Blockchain technology is a fast-evolving field, so this report is
necessarily a snapshot of the confidential and privacy techniques that
were public at the time it was written. The intervening months have seen
the release of R3's CordaJP Morgan's Quorum, and Chain has previewed their "Confidential Assets" technology. We expect to see further developments and progress in this space throughout 2017.

We’d like to thank R3 for commissioning this report, and our
co-author Danny Yang for working with us to make it happen. We’d also
like to thank everyone who provided feedback and suggestions,
particularly Andrew Miller, Antony Lewis, Ariel Gabizon, Emily Rutland,
Ian Grigg, Ian Miers, Mike Ward, Paige Peterson, Shihao Guo, Tim Swanson
and Vitalik Buterin.

Jack Gavigan

Zcash Release V 1.0.7-1

his release fixes several documentation issues with the 1.0.7 release.

Upcoming Testnet Upgrade

The Zcash testnet will soon be upgraded in order to resolve an issue with the Testnet Founders Reward addresses. This will not
affect the main Zcash network. Testnet users must upgrade to at least
version 1.0.7 by block 53127, as that is when the testnet network
changes will take place. Users who do not upgrade may be left on their
own chain, contributing to a chain fork.

BLS12-381: New zk-SNARK Elliptic Curve Construction

Our team is continually working to improve the security, performance and usability of our privacy-preserving shielded transactionsnear future priorities blog post, we are working on a collection of cryptographic improvements for the next version of Zcash named Sapling. One of our goals is to make shielded payments more efficient and less memory intensive. We also intend to improve the concrete security level of the elliptic curve construction that we use for our zk-SNARK proofs.

I spent some time last month designing and implementing a new
pairing-friendly elliptic curve construction that is optimal for
zk-SNARKs at the 128-bit security level. The construction minimizes
performance and usability costs while increasing our security margins.

The construction will appear in an upcoming paper by our scientists,
where it will be accompanied by a more thorough description of the
construction and how it was selected.

It is possible to construct a new BN curve that targets 128-bit
security, even according to this conservative estimate, by selecting a
curve closer to q≈2384" role="presentation">q≈2384

. However, the larger group order r" role="presentation">r impairs the performance of multi-exponentiation, fast fourier transforms and other cryptographic operations that we need to perform efficiently in zk-SNARK schemes and multi-party computations. Additionally, the larger scalar field Fr" role="presentation">Fr

makes keying material unnecessarily large.

Barreto-Lynn-Scott curves

Barreto-Lynn-Scott (BLS) curves are a slightly older class of
pairing-friendly curves which now appear to be more useful for targeting
this security level. Current research suggests that with q≈2384" role="presentation">q≈2384

, and with an embedding degree of 12, these curves target the 128-bit security level. Conveniently, the group order for these curves is r≈2256" role="presentation">r≈2256

, which allows us to avoid the performance and usability drawbacks that accompany a larger scalar field.

BLS12-381

In zk-SNARK schemes, we need to manipulate very large polynomials over the scalar field Fr" role="presentation">Fr

. We can perform efficient multi-point evaluation/interpolation with fast fourier transforms, so long as we ensure Fr" role="presentation">Fr is equipped with a large 2s" role="presentation">2s

root of unity.

As is common,
we target a subfamily of these curves that has optimal extension field
towers and simple twisting isomorphisms. In order to ensure Montgomery
reductions and other approximation algorithms are space-efficient, we
target r≈2255" role="presentation">r≈2255

so that the most significant bit of r" role="presentation">r (and q" role="presentation">q

) are unset with 64-bit limbs.

As usual, in order to optimize for pairing performance, we ensure the
parameterization of the BLS curve has low Hamming weight. The curve we
have ultimately chosen is named BLS12-381 as q≈2381" role="presentation">q≈2381

Rust language implementation

I have begun working on an implementation of the construction in Rust as part of my bellman
zk-SNARK project. The library has the goal of being portable, standards
compliant, and high performance. Due to the nature of zk-SNARK schemes,
it is difficult to efficiently construct proofs in constant time, and
so the library does not currently focus on side channel resistance.

Future blog posts will describe a number of techniques and tools that
our scientists have devised for using this curve construction to
optimize Zcash.

Menzes, Sarkar and Singh (http://eprint.iacr.org/2016/1102.pdf) show 2^110 is a conservative estimate for the size of the space of polynomials that needs to be scanned for smooth polynomials. However, for the case q=p^12 relevant for BN curves there is no currently published efficient method for scanning this space. (Checking each polynomial separately for smoothness would result in total running time larger than 2^128.) Thus, to the best of our knowledge the most efficient currently known fully described algorithm for breaking the curve Zcash is presently using is Pollard's rho, which would run in time sqrt(q)~2^127. (Our thanks to Palash Sankar and Shashank Singh for helping understand their result.)

These nodes are run independently, although it is part of a Zcash
accepting project. Thus, in terms of a transient internet, these Zcash
hidden service .onion's are likely to remain stable for the foreseeable
future and beyond.

Some issues we're looking at include setting up better stress tests for memory usage of the client (#2155#2119), a small bug in progress reporting in debug logs (#2111#2096) and cleaning up some references to bitcoin from the original fork (#17561).

We also had a topical meeting to discuss fee mechanisms. We started the discussion by breaking down the effects of fees in 3 stages:

No contingency for block space (what we currently see now)

An intermediate phase (perhaps when we see the first full block or a first spam attack)

When there's high demand for transaction throughput

We didn't end up at a concrete solution but definitely made progress on considering the various options (constant fee, weighted randomized fee, dynamic fee based on average block availability, etc) and their consequences.We're thinking that by the time stage 3 would happen, we would already have solutions in place to mitigate it like BOLT and/or a blocksize increase. Our goals are to make fees as natural and user friendly as possible while maintaining security against detrimental flood attacks (while also considering the fact that the more minor flood/dos attacks we've seen in bitcoin have no lasting effect and should not stress too much about those.)
Because Zcash transactions with transparent addresses are lighter weight but don't offer privacy and transactions with shielded addresses are heavier weight but offer the private capabilities that we want to promote the use of, all of the models we discussed were not based on actual transaction size.

While we already have a Tor service hosting the https://z.cash1explaining zk-SNARKs to continue our effort in decypering the “moon math” behind the zero-knowledge system driving the privacy in Zcash.

As mentioned last week, a few of us will be attending the Tor meeting to see what kind of support our teams can give to one another. And relatedly, it's great to see the Zcash community thinking along the same lines.

We also set the next Show & Tell1zmsg4, a small program for sending messages via zcash encrypted memo fields.

Finally, while not explicitly engineering related, the Zcash Foundation initial board was announced todaynew category in this forum specifically for suggestions to the Foundation and hope the community takes advantage of it – especially in these early days!

Announcing the Zcash Foundation

Our Mission is to give every person in the world economic freedom — to do for cooperation what the Internet did for communication.

The organization we created to launch this project is a startup. This
provides a tight-knit, focused team, rapid decision-making, and the
possibility of generating additional funding, such as by building
blockchain solutions for industry.

However in the long run it would not be appropriate for a single
for-profit company to have this much power over the evolution of the
Zcash technology. Ultimately, there will need to be an independent,
inclusive, non-profit body to steward the technology in the interests of
all users.

I hope that The Foundation will also serve as a forum for the Zcash
community to work its way through governance issues such as the ones
that are currently rending the Bitcoin community.

The Zcash Foundation is funded by the blockchain itself. A portion of the Zcash Founders' Reward ¹²
have been donated to the Foundation. These coins will be distributed
incrementally over the next 3 and ⅔ years, until November 2021. The
total amount donated is 273,000 ⓩ coins. At today's price ($49/ZEC) that
would be worth more than $13 million!

This has been made possible by donations from some of the founders of
the Zcash project. I personally have donated half of all of the coins I
was due to get from the Founders' Reward, and many of my colleagues
have donated as generously or even more so!

The initialBoard of Directors of the Foundation is four of the people that I most trust and respect
in the field. I personally am not a director of the Foundation, and none
of the Directors are employees of the Zcash Company. Nor do I or the
Zcash Company have the ability to defund the Foundation. So, it is
already, at its birth, independent of me and of the Company.

Please read the Foundation'sHello World blog post to see their initial plans and how you can get involved and help make Zcash live up to its potential!

Spinning Off Our Sibling Company

The Zcash company grew out of a company named “Least Authority”. It was when we were Least Authority that we did a security audit of EthereumCryptoCat, GlobalLeaksSpiderOak, and Ooni). Least Authority also developed the advanced cryptographically-protected, decentralized file store, Tahoe-LAFS.

When we formed a new company to launch Zcash (the “Zerocoin
Electric Coin Company”, a.k.a. “The Zcash Company”), we split off from
Least Authority and at first I tried to continue acting as the CEO of
both companies at once. Perhaps I was influenced by the legends of Elon
Musk and Jack Dorsey, two people who currently serve as CEOs of two
different companies.

But you know what? No way was that going to work. The run-up to the Zcash
launch consumed all of my time and attention, and the Least
Authoritarians continued to develop their cutting-edge open source
technology, but they had to do so without any business support from me.

Therefore I'm delighted to announce that our sibling company, Least
Authority, now has a new full-time CEO: Liz Steininger. I've worked with
Liz before on Internet freedom technology; I trust her ethics and her
judgment. Her excellent skills at organization, planning, and business
are a good match for the excellent cryptography and coding skills of the
other Least Authoritarians.

Least Authority has incorporated in Berlin, Germany (the world capitol
for Internet freedom hackers) and launched a new web site. The team
continues to do specialized security audits and create freedom-compatible
technologies, and has some big things in the works that you'll hear more
about soon, including a user-friendly way to use their secure storage
product.

Right now you can sign up for Least Authority's “S4” service, which is
a cloud storage service built on top of Amazon S3, with the addition of
our advanced open source end-to-end encryption so that your data is never
exposed to snooping or injection.

(P.S. For fans of cryptocurrency history, here's that time I posted about
Tahoe-LAFS on BitcoinTalk.org back in 2010 and Satoshi Nakamoto
replied.)

Explaining SNARKs Part III: The Knowledge of Coefficient Test and Assumption

In Part II, we saw how Alice can blindly evaluate the hiding \(E(P(s))\) of her polynomial \(P\) of degree \(d,\) at a point \(s\)
belonging to Bob. We called this "blind" evaluation, because Alice did not learn \(s\) in the process.

However, there was something missing in that protocol -
the fact that Alice is able to compute \(E(P(s))\) does not guarantee she will indeed send \(E(P(s))\) to Bob,
rather than some completely unrelated value.

Thus, we need a way to "force" Alice to follow the protocol correctly.
We will explain in part IV precisely how we achieve this.
In this post, we focus on explaining the basic tool needed for that -
which we call here the Knowledge of Coefficient (KC) Test.

As before, we denote by \(g\) a generator of a group \(G\) of order \(|G|=p\) where
the discrete log is hard.
It will be convenient from this post onwards to write our group additively rather than multiplicatively.
That is, for \(\alpha\in\mathbb{F}_p,\) \(\alpha\cdot g\) denotes the result of summing \(\alpha\) copies of \(g.\)

The KC Test

For \(\alpha\in\mathbb{F}_p^*\) [1], let us call a pair of elements \((a,b)\) in \(G\) an \(\alpha\)-pair
if \(a,b \neq 0\) and \(b=\alpha\cdot a.\)

He sends to Alice the "challenge" pair \((a,b).\) Note that \((a,b)\) is an \(\alpha\)-pair.

Alice must now respond with a different pair \((a',b')\) that is also an \(\alpha\)-pair.

Bob accepts Alice's response only if \((a',b')\) is indeed an \(\alpha\)-pair. (As he knows \(\alpha\) he can check if \(b'=\alpha\cdot a'.)\)

Now, let's think how Alice could successfully respond to the challenge.
Let's assume for a second that she knew \(\alpha.\)
In that case, she could simply choose any \(a'\) in \(G,\)
and compute \(b'=\alpha\cdot a';\) and return \((a',b')\) as her new \(\alpha\)-pair.

However, as the only information about \(\alpha\) she has is \(\alpha\cdot a\) and \(G\) has a hard discrete log problem,
we expect that Alice cannot find \(\alpha.\)

So how can she successfully respond to the challenge without knowing \(\alpha?\)

Here's the natural way to do it:
Alice simply chooses some \(\gamma\in\mathbb{F}_p^*,\) and responds with \((a',b')=(\gamma\cdot a,\gamma\cdot b).\)

Note that if Alice responds using this strategy, she knows the ratio between \(a\) and \(a'\).
That is, she knows the coefficient \(\gamma\) such that \(a'=\gamma\cdot a.\)

The Knowledge of Coefficient Assumption [2] (KCA) states that this is always the case, namely:

KCA: If Alice returns a valid response \((a',b')\) to Bob's challenge \((a,b)\) with non-negligible probability over Bob's choices of \(a,\alpha\),
then she knows \(\gamma\) such that \(a'=\gamma\cdot a.\)

The KC Test and Assumption will be important tools in Part IV.

What does "Alice knows" mean exactly?

You may wonder how we can phrase the KCA in precise mathematical terms; specifically,
how do we formalize the notion that "Alice knows \(\gamma\)" in a mathematical definition?

This is done roughly as follows:
We say that, in addition to Alice, we have another party which we call Alice's Extractor.
Alice's Extractor has access to Alice's inner state.

We then formulate the KCA as saying that: whenever Alice successfully responds with an \(\alpha\)-pair \((a',b'),\)
Alice's Extractor outputs \(\gamma\) such that \(a'=\gamma\cdot a.\) [3]

\(\mathbb{F}_p^*\) denotes the non-zero elements of \(\mathbb{F}_p\). It is the same as \(\mathbb{Z}_p^*\) described in Part I.

[1]

This is typically called the Knowledge of Exponent Assumption in the literature, as traditionally it was used for groups written multiplicatively.

[2]

[3]The fully formal definition needs to give the Extractor "a little slack" and states instead that the probability that Alice responds successfully but the Extractor does not output such \(\gamma\) is negligible.

Author,

Ariel Gabizon

BIP199 for Hashed Timelocked Contracts

Hashed Timelocked Contracts (HTLC) are a well-known and simple
technique for building protocols for atomic swaps. They allow you to pay
another party for some information (generally, a key) with a condition
that allows you to receive your money back if the party does not
cooperate.

HTLCs are a fundamental tool in the Lightning network, in zero-knowledge contingent payments (ZKCP) like the one we performed last yearthat we announced last month. One of the first steps forward is the inclusion of general HTLC functionality in the Bitcoin Core wallet.

This week, our submitted BIP199 draft was merged. We also have a work-in-progress reference implementation
in the Bitcoin Core wallet. HTLCs can be used today without any changes
to the Bitcoin protocol, so these proposals and implementations are for
standardizing best practices and ecosystem compatibility.

HASHOP is a hashing algorithm (RIPEMD,
SHA256), and TIMEOUTOP is either OP_CHECKLOCKTIMEVERIFY or
OP_CHECKSEQUENCEVERIFY. This script allows the "buyer" to purchase the
preimage to <digest> by forcing the seller to reveal it when they
claim their funds. If the seller doesn't reveal it, the buyer can get
their money back after the timeout period.

It's easy to see how cross-chain atomic swaps can be built with this mechanism:

Alice randomly samples K, the key. She hashes it, producing X.

Alice creates a transaction paying Bob 1 BTC, with a timeout of 1 day, to produce the preimage of X.

Bob waits for Alice's transaction to appear in the Bitcoin
blockchain, and then submits an HTLC transaction paying Alice 0.02 ZEC
for the preimage of X with a smaller timeout of half a day.

Once Bob's transaction appears in the Zcash blockchain, Alice can obtain her ZEC. The script forces her to reveal K.

Once Bob sees Alice's reveal of K, he can obtain his BTC.

The timeouts are selected so that Bob always has an opportunity to
obtain a refund before Alice. Otherwise, Alice could wait to obtain her
refund, and then claim Bob's money by revealing K.

Having contracts like HTLCs standardized and included in Bitcoin and
Zcash will help both of our communities build exciting technologies like
decentralized exchanges.

Author,

Sean Bowe

March 31, 2017 - Dev update

This week saw the release of 1.0.8,
so update your nodes if you haven’t yet! The release includes support
not mentioned in previous updates: Tor ephemeral hidden services (PR 2177) which makes it easier for users to run nodes over Tor.

In preparation for a Payment Offloading
proof of concept, we started work on a Javascript implementation of
Zcash which will be available upon completion. This work is being based
off of BitcoinJS and beyond the
primary goal of moving towards a payment offloading PoC, will offer
applications an officially supported JS library for Zcash integration.

We also have plans for reworking some of the website including the new Privacy & Security Recommendations page after receiving some great feedback and improved funneling for new users looking to get started with Zcash.

We’re also making some final touches on a new section of the website dedicated to a high-level overview of zk-SNARKs.

Zcash for Windows Beta v1.0.8 is now Available

I just uploaded the Beta of zcash4win, my all-in-one installer that bundles zcash 1.0.5, uses a fork of the SwingUIWallet by @vaklinov
for the GUI wallet, downloads the proving keys in the GUI, setups up
zcash.conf for a non-mining full node by default, and bundles the needed
java runtime.

BTC: 1H9AFcYdZb6mt3wDHg1hc2AjnqrXzmv4xo

ETH: 0x2587512b27867c2d466c02ccf11424002baac8b4

ZEC: t1RnYixipZn3LrDdXkdLnR7JUSrCxo26W97

Bellman: zk-SNARKs in Rust

Bellman is a Rust-language library for building zk-SNARKs small, cheap-to-verify zero-knowledge proofs of arbitrary computations. The goal of bellman is to make it easier for the general public to use and

experiment with zk-SNARKs, and also as a step forward for improving the security and performance of Zcash's next major release, Sapling.

Bellman contains an implementation of the BLS12-381 elliptic curve construction that we described scientists. This construction was designed specifically for efficientlybuilding zk-SNARKs, while maintaining a high security margin.

This week, I've added a primitive implementation of a new zk-SNARK proving system designed by Jens Groth. Secure in the generic group model, the new design produces smaller proofs that can be constructed faster and with less memory.

Overview of zk-SNARKs

If you're interested in how zk-SNARKs work internally, Ariel Gabizon has been writing a series of blog posts about the underlying math that you should check out! For now, we can understand them on a surface level.

zk-SNARKs are powerful proofs that, unlike other zero-knowledge
proving schemes, are very small (a couple hundred bytes) and cheap to
verify (several milliseconds), even if the statement being proven is
large and complicated. Their zero-knowledge property allows the prover
to hide details about the computation from the verifier in the process,
and so they are useful for both privacy and performance.

The only such schemes known to be efficient are preprocessing.
In a sense, this means that a kind of "environment" must be constructed
which allows the prover to evaluate the statement and produce a proof.
There is no known way to construct such an environment without
necessarily being temporarily in possession of information that would
allow you to construct false proofs.

Zcash, which uses zk-SNARKs for its shielded transactions, uses
parameters that were constructed in a sophisticated multi-party
computation ceremony that you can read about here.
zk-SNARKs are also useful in the designated verifier model, where the
verifier itself constructs the needed parameters, and so neither the
prover nor the verifier are concerned about its integrity.

In many zk-SNARK schemes, the statement being proven is reduced to
what is called a rank-1 quadratic constraint system, or R1CS. In this
system, the prover is given a system of arithmetic constraints over a
set of variables (elements in a large prime field Fr" role="presentation">Fr

), and asked to produce an assignment to the variables which satisfies the constraints.

Overview of Bellman

Bellman is currently in its infancy, but we can already use it to
construct these kinds of proofs. Currently, only a very low level API is
available, upon which we can construct DSLs and various abstractions
for synthesizing circuits. If you want to experiment with it, grab the bellman crate from crates.io.

All of our circuit abstractions are written generically over an
Engine trait that handles the elliptic curve and finite field
arithmetic. Central to circuit synthesis is the ConstraintSystem trait:

All variable allocation, assignment, and constraint enforcement is
done over the same code path. This differs from the design of libsnark’s
gadgetlib, for which it was too easy to potentially forget a constraint
or notice bugs in existing abstractions because of the separation. This
approach makes it easier to write abstractions and perform code review.

All variable allocation and assignment are done simultaneously, and
the existing assignments cannot be queried or modified. This encourages
better gadget design, and prevents gadgets from accidentally using the
assignments to “communicate” with each other. This also has a
performance benefit: since all variables are already assigned,
constraint enforcement during proving is directly synthesized into the
underlying witnesses to avoid having to keep a constraint system in
memory at all.

As an example of a kind of gadget implementation, here's how a
boolean constrained variable could be implemented, along with XOR:

This design splits up circuits into a Circuit implementation, which provers instantiate to construct proofs, and a Input
implementation, which provers and verifiers use to perform input
allocation and related circuit synthesis. This differs from libsnark,
where these code paths are redundant, use different utility functions
and require careful code review to ensure consistency.

Once we actually do have an implementation of Circuit and Input, we can use the functions provided in the groth16 module: create a keypair (with some randomly selected trapdoors), construct a proof, and perform verifications:

Future work

These lower level foundations are all that is available in Bellman
right now. In the future we will be writing tools which allow us to
build things like hash functions and stream ciphers.

Bellman is still under development and shouldn’t be used in
production software yet. In fact, its API deliberately does not expose
anything that would allow you to actually use it! It currently serves as
an excellent learning opportunity for constructing zk-SNARKs safely and
efficiently, and the lessons we learn from building it will shape the
future of Zcash.

We’re also excited to be writing Bellman in Rust! If you’re a Rustacean and you’re interested in zk-SNARKs or Zcash, we invite you to check out our project

Zcash (ZEC) New mining pool (0% fees)

We are a completely costumer centric multiple algorithm mining pool
offering our services at 0% fees until we go public. We are currently in
beta phase and we are calling all miners to test out our pool.

Salient features of the pool :
1) 0% fees in beta phase.
2) after the beta phase a minimal 2% fees will be applied.
3) 10% of the fees will go to charity
4) one of the only pools with nicehash integration.
5) integrated custom built pool chat.
6) Ssl integration on all the algorithms.
7) shapeshift integration under development.
8) vardiff available on all pools.
9) dedicated unix systems engineer
10) MRR integration under development.