72 lines
5.8 KiB
HTML
72 lines
5.8 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE> [ZcF-general] Zcash Foundation Update Benedikt Bünz -- Scholarship Grant
|
|
</TITLE>
|
|
<LINK REL="Index" HREF="/pipermail/general/2019/index.html" >
|
|
<LINK REL="made" HREF="mailto:general%40lists.zfnd.org?Subject=Re%3A%20%5BZcF-general%5D%20%3D%3Futf-8%3Fq%3FZcash_Foundation_Update_Benedikt_B%3DC3%3DBC%3F%3D%0A%20%3D%3Futf-8%3Fq%3Fnz_--_Scholarship_Grant%3F%3D&In-Reply-To=%3C6E5DE052-2A14-4C42-B55A-E4816CFE05CB%40stanford.edu%3E">
|
|
<META NAME="robots" CONTENT="index,nofollow">
|
|
<style type="text/css">
|
|
pre {
|
|
white-space: pre-wrap; /* css-2.1, curent FF, Opera, Safari */
|
|
}
|
|
</style>
|
|
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
|
|
<LINK REL="Previous" HREF="000030.html">
|
|
<LINK REL="Next" HREF="000031.html">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#ffffff">
|
|
<H1>[ZcF-general] Zcash Foundation Update Benedikt Bünz -- Scholarship Grant</H1>
|
|
<B>Benedikt Bunz</B>
|
|
<A HREF="mailto:general%40lists.zfnd.org?Subject=Re%3A%20%5BZcF-general%5D%20%3D%3Futf-8%3Fq%3FZcash_Foundation_Update_Benedikt_B%3DC3%3DBC%3F%3D%0A%20%3D%3Futf-8%3Fq%3Fnz_--_Scholarship_Grant%3F%3D&In-Reply-To=%3C6E5DE052-2A14-4C42-B55A-E4816CFE05CB%40stanford.edu%3E"
|
|
TITLE="[ZcF-general] Zcash Foundation Update Benedikt Bünz -- Scholarship Grant">buenz at stanford.edu
|
|
</A><BR>
|
|
<I>Sun Jan 6 00:34:54 EST 2019</I>
|
|
<P><UL>
|
|
<LI>Previous message (by thread): <A HREF="000030.html">[ZcF-general] Grant Progress - paywithz.cash
|
|
</A></li>
|
|
<LI>Next message (by thread): <A HREF="000031.html">[ZcF-general] Grant project update - new PoW scheme
|
|
</A></li>
|
|
<LI> <B>Messages sorted by:</B>
|
|
<a href="date.html#34">[ date ]</a>
|
|
<a href="thread.html#34">[ thread ]</a>
|
|
<a href="subject.html#34">[ subject ]</a>
|
|
<a href="author.html#34">[ author ]</a>
|
|
</LI>
|
|
</UL>
|
|
<HR>
|
|
<!--beginarticle-->
|
|
<PRE>Dear all,
|
|
|
|
I want to use my first update to mostly talk about a recent paper that we recently published on eprint: <A HREF="https://eprint.iacr.org/2018/1188">https://eprint.iacr.org/2018/1188</A>
|
|
The paper presents new batching techniques for RSA accumulators and vector commitments. An accumulator is a short commitment to a set that supports efficient inclusion and optionally also exclusion proofs. The perhaps simplest accumulator is a Merkle Tree which is widely used in ZCash for example as a commitment to all of the coins. RSA accumulators have the advantage that their inclusion proofs are only a single element. In our work we show how many inclusion proofs can be non-interactively aggregated. Additionally we leverage some recent work on verifiable delay functions (<A HREF="https://eprint.iacr.org/2018/623">https://eprint.iacr.org/2018/623</A>) to make checking inclusion proofs much more efficient.
|
|
We also leverage the new batching techniques to build an efficient vector commitment scheme. Vector commitments are positional commitments that allow you to efficiently prove that the element at the ith index has a certain value. Again Merkle Trees can be used as vector commitments. Our new commitment, however, is much more efficient in terms of proof size and we propose using it to create significantly shorter STARKs. To maintain the setup-freeness of STARKs one would have to use so called class groups to instantiate the accumulator (which is entirely possible and feasible).
|
|
There are more tricks in the paper and you can watch this talk if you want to get a better overview (<A HREF="https://www.youtube.com/watch?v=IMzLa9B1_3E&feature=youtu.be&t=3515">https://www.youtube.com/watch?v=IMzLa9B1_3E&feature=youtu.be&t=3515</A>).
|
|
Accumulators for ZCash:
|
|
There are several places where accumulators could be useful for ZCash. One interesting application is to make mining/full nodes stateless. Consider the t-address/Bitcoin like part of ZCash. An accumulator can be used to commit to the entire UTXO set. Each transaction now creates a short proof that her coins are indeed unspent. With our new techniques these proofs can be aggregated and are efficient to check. The miner only needs the short accumulator value (~256 bytes) in order to verify transactions! It might be unrealistic that users store their own inclusion proofs and update them regularly but so called bridge nodes could provide them for users. In general this design achieves a separation of consensus and state. The miners don’t need to store the entire state to reach consensus on it. A small commitment to the consensus suffices! Additionally it reduces the cost of “UTXO dust” as it does not need to be stored in memory anymore.
|
|
Interestingly this design idea isn’t new and ZCash’s z-address system already uses such a design (using Merkle Trees + SNARKs instead of accumulators). Also ZeroCoin, ZeroCash’s predecessor, heavily relies on accumulators. An obvious question that we are investigating is whether and how efficient accumulators can be combined with SNARKs or other proof systems like Bulletproofs.
|
|
Best,
|
|
Benedikt
|
|
</PRE>
|
|
|
|
<!--endarticle-->
|
|
<HR>
|
|
<P><UL>
|
|
<!--threads-->
|
|
<LI>Previous message (by thread): <A HREF="000030.html">[ZcF-general] Grant Progress - paywithz.cash
|
|
</A></li>
|
|
<LI>Next message (by thread): <A HREF="000031.html">[ZcF-general] Grant project update - new PoW scheme
|
|
</A></li>
|
|
<LI> <B>Messages sorted by:</B>
|
|
<a href="date.html#34">[ date ]</a>
|
|
<a href="thread.html#34">[ thread ]</a>
|
|
<a href="subject.html#34">[ subject ]</a>
|
|
<a href="author.html#34">[ author ]</a>
|
|
</LI>
|
|
</UL>
|
|
|
|
<hr>
|
|
<a href="/mailman/listinfo/general">More information about the general
|
|
mailing list</a><br>
|
|
</body></html>
|