Ethereum Foundation 🛠️ Augment the Privacy & Scalability of YourHackathon Project With PSE

foreign [Applause] [Music] Global Paris hackers today we will be talking about how you can augment your hackathon projects with tools developed by the ethereum foundation's privacy and scalability Explorations team my name is Jack Gilchrist I'm a former PSE grantee and I'm focused on applying zero knowledge cryptography to Shield data and scale the centralized systems let's get into it PSE is a multi-disciplinary team supported by the ethereum foundation pse's mandate is to conduct open source research and development on applications of cryptography like zero knowledge zero knowledge is a powerful privacy preserving tool however as you may know from CK Roll-Ups a consequence of ZK proofs is compressing the cost of verifying code execution thus as the name suggests the privacy and scalability Explorations team is focused on integrating ZK Primitives that augment both privacy and scalability of decentralized applications first we'll run through a quick primer of the theoretical use case of zero knowledge proofs next we'll go through four of the most exciting projects PSE is incubating semaphore unirp rate limiting nullifier and end-to-end zkecdsa all offer novel tools that you can extend to hack on projects with Superior privacy preservation so let's start by talking about the basics of zero knowledge proofs now there are two sides to a zero knowledge proof there is a prover and there is a verifier the prover is often a client uh user at their computer but this could just as easily be a server that wants to convince a client or some other server that a computational is done correctly and the verifier could also be another client it could be a centralized server or it could even be a smart contract and generally the PSE applications that we will demonstrate in future slides have a user that will generate a proof and settle those proofs on a blockchain using a verifier smart contract breaking down these perspectives a bit more let's take a look at a simple example we as a prover want to prove that a times b equals c now A and C are values that should be publicly known and B is a value that is known only to us the prover and we want to build a proof that we know some value B that will cause the equation a times B to equal C and we want to do this without revealing B now as the verifier we have a verifying key which can take a proof and these public inputs and outputs to determine the veracity of the proof and notice that we don't actually need to know b as the verifier the zero knowledge proof with the public values the input and the output is sufficient to convince us that the prover knows the value of B that satisfies our computation now a times b equals c is a pretty simple example and obviously it's very easy to reverse that but you could substitute the private value for the pre-image and the public value for commitment or a hash and use a very similar expression to convince a verifier that some public value is the decipher text for a secret value that we don't want to reveal and this becomes a lot more useful and we'll see some of this in the next Demos in a couple of slides let's review the order of operations for using zero knowledge proofs first the prover gets the public and private inputs that they need to make some expression like a times b equals c the proverb generates a zero knowledge proof that demonstrates the Integrity of that statement second the prover transmits the zero knowledge proof to the verifier along with those public inputs only in the case of our smart contract verifier this would take the form of sending a transaction to an RPC for the evm to then verify finally the verifier uses the supply public inputs to check that a proof is valid returning either true or false here is a succinct version of that there is a lot that is not covered here we glossed over how the prover uses a zero knowledge circuit to compute a proof and how the verifier needs to use a verifying key to check the proof we skipped the math that makes zero knowledge possible and all of The cryptographic Primitives that one might use inside of a circuit to build effective tools we skipped The Trusted setup ceremony which is required in almost all proving schemes as well as talking about why they're even needed we skipped over the different proving schemes themselves and there's also the difference between snarks and Starks not covered similarly we didn't introduce the various ways that one can create a zero knowledge proof including domain-specific languages software development kits and virtual machines this is just a taste of what goes into zero knowledge proving but hopefully you've gotten the gist of what a zero knowledge proof is and how to use it in theory let's now talk about some of the applications PSE has been working on that you could build applications on top of semaphore is a gadget for preserving private identities within a public group the private identities can prove membership within the group then publicly send signals without revealing these individual identities signals are arbitrary actions such as votes endorsements or plain text messages to name a couple of possible examples semaphore is a fundamental primitive with wide-reaching applications in fact we will see with the Ron application in the next few slides it actually Builds on top of the semaphore Gadget there are many other examples of uses as well hey noun is a private message room where nouns nft holders can voice their opinions on proposals without reputational bias there's also World coin which has a semaphore group of verified humans and proving membership in the world coin group is a mechanism for proof of humanity you could even imagine a semaphore for individuals employed in a large company or government organization for the purpose of whistleblowing a whistleblower could provide strong evidence that they're an employee of say evil Corp with their identity shielded from retribution when they step forward to start let's look at the creation of a new sum of four identity we can randomly generate an identity as is shown here or we could provide a secret seed value to deterministically build the identity secret values the identity at its core is comprised of trapdoor and the nullifier for a given signal there's a public external nullifier and this is hashed together with an identity nullifier this is used then to prevent an identity from sending multiple signals it literally nullifies the identity from further actions the identity trap door simply provides a blinding factor that makes it impossible for an attacker to link signals back to an identity even if they manage to brute force a nullifier hash they would only obtain the nullifier and would not be able to actually figure out the identity commitment together the hash of the identity nullifier and the trapdoor make the identity commitment the identity commitment which is a public value is inserted into a Merkle tree that represents our semaphore group now given that we take the nullifier and the trapdoor and committed them into the semaphore group we can now use Merkel inclusion proofs to leverage our group identity a signal is an arbitrary message it could be a yes or no Vote or it could be some random text or really anything else that you could find a use for now as we mentioned there's an external nullifier and this is used to prevent double signaling for any topic we only want an identity to send a single signal and we can enforce this by publicly adding the external nullifier into our proof the hash of the external nullifier and the identity nullifier is going to be deterministic and we can prevent double signaling when an already seen nullifier hash is presented again finally we see the process of actually generating a zero knowledge proof using the circon DSL in JavaScript and this proof is generated via full proof and we could take this proof and we could put it on chain using the semaphore contract or we could locally verify it as is demonstrated below next we have uniro unirp is a protocol for private and non-repeatable reputation applications which are known as a testers assign positive or negative reputation and by using a common set of proofs reputation can even interoperate across different applications reputation is a widely used mechanic across applications for instance take gig economy and Contracting apps like uber doordash Airbnb and even upwork these types of applications which coordinate service suppliers with consumers require a reputation system to properly function social media apps are also right for integration applications like 4chan quickly become overrun with unsavory content but what if there was a way for anonymous communities to Target users posting undesirable content and exclude them from certain communities using reputation range proofs this is just one way you could use the anonymous reputation mechanic that you know rep provides in Anonymous social media though there are many other ways to explore how unirp can be used like a blockchain interrupt State changes occur over epochs epochs are configurable by the application or in this case the tester meaning that you can set the epoch length to be an hour or a day or anything else depending on the use case once a user is signed up epoc Keys serve as temporary pseudonyms that are publicly available for each of the epochs a user can have multiple Epoch keys in a given Epoch and use the nonce to specify each key here we see the generation of an Epoch key for a given Epoch a tester and identity as well as the knots next epoc keys are supplied to an application server generally a relay which can attest to data for a given Epoch key for the application the tester primarily this is used to drive the numerical reputation scores however there's also a field the replacement field which can hold arbitrary data and this can be completely replaced at any given point during an attestation once an attestation has been made for a given Epoch a user can call the user State transition both as a proof and then a contract call which is used to prove that for a given Epoch the state transitioned from one value to another for the user and this can be both the reputational score which is numerical and can go up and down additively or it could be a replacement of data once user state has transitions users can generate proofs that their reputation is in a given range so a user could have a reputation of five and want to prove that they had at least a reputation of three and this could be used to gate certain activities but this can be done without revealing the exact amount there's a lot more to you to wrap and you can look into some of the existing Integrations or you can look at create unirp app there's a lot in the documentation and the GitHub repo um but there's definitely more to explore and understand overall unirp is a very strong way to deal with reputation in a private and trustless way and there's a lot of different use cases that you can explore now we have rate limiting nullifier Ron is a novel mechanic for spam and DDOS prevention by using shamira's secret sharing clients submit shares of keys with their messages during a given period of time if too many messages are received in that period the secret can then be reconstructed and the offending message sender can be penalized by slashing Financial stake or revealing reputational identity as a side note perhaps this could even be combined with unit rep's reputation this has wide-ranging use cases in infrastructure of course chat applications are susceptible to spam and centralized services like Discord or telegram have message rate limiting features rln provides a mechanic for such rate limiting to be done in a trustless and Anonymous manner you could similarly Envision such functionality being quite useful at the blockchain infrastructure layer rpcs are susceptible to spam and a network could protect itself from denial of service attacks by requiring the use of rlat across communication mediums like unirp rln is built on top of semaphore to provide Anonymous identities within a group here the initial Ron JS object is constructed and built its own semaphore identity however you could Supply an existing one should you desire the rln identity must be added to the semaphore group just as with vanilla semaphore to leverage signaling via inclusion proofs once an identity is inside the group you can begin sending messages these messages are again sent with signaling proofs these proofs are added to the rln cache and this cache is responsible for tracking messages per epoch the circuit computes this equation y equals a0 plus x times A1 when making an rln proof users Supply two secret shares X and Y the user hashes the semaphore nullifier and trapdoor to get a0 then hashes a0 with the signaling external nullifier to get A1 if more than one pair of the XY Shares are used to send messages with the same external nullifier anyone can derive the value of a0 risking their identity to be revealed thus as the cash stores these messages if multiple messages from the same identity are received it can compute the secret value needed to Target and Slash the offending identity lastly we have end to end ZK ecdsa end to end ZK ecdsa verifies ethereum accounts directly and shields them in privacy sets now it may seem that e to e z k ecdsa is similar to semaphore in its use case and in theory this is true however semaphore creates a new identity with new secrets that a user must manage this is beneficial for certain use cases given that the cryptography is optimized for the efficiency in circuits however many use cases may be built on top of ethereum addresses or any secp-256k1 key pair for that matter end-to-end ZK ecdsa is uniquely secure in this case there's no need for users to manage new Secrets instead we can rely on metamask or even Hardware wallets further we can Shield public analytics from linking on-chain actions to the addresses that are permissioned to authorize them while some of 4 might be a better tool for off-chain Solutions end-to-end ZK ecdsa is uniquely qualified for on-chan privacy sets this includes private airdrops and even confidential governance in fact we've seen this pattern pursued in the non-style private voting r d where ZK ecdsa verification paired with storage proofs provide especially powerful and trustless private voting Solutions let's start by looking at the actual proof composition in end-to-end CK ecdsa as a precursor we need to import the dependencies for end-to-end ZK ecdsa proving we need to supply the addresses that will actually be used in the Privacy set and we need to instantiate our proving artifacts next we want to build a Merkle tree of all the addresses in the Privacy set by supplying the addresses we had in the last slide this incremental Merkle tree object handles the insertion of the leaves into the tree we're going to prove that the first address is a member of our privacy set so we go ahead and generate a miracle proof of inclusion for that leaf we can use an arbitrary message for the membership circuit the important part is that we can verify that a signature on that message is from an address that we want to prove inclusion for we do that with the private key here now we compute the proof the witness contains all of the data that our circuit constrains and is given to the proven key to generate our proof it's a little out of bounds of what we need to go into but just for some context now the membership circuit itself needs our message it needs the vector commitment of the Merkle proof which is the path elements path indices and the Marvel tree root it needs the public key that we're proving is included in the Merkle tree and finally it needs the signature that is made by this public key with the r and s elements the circuit will verify that we are authorized to prove inclusion of an address by checking that we supplied a valid signature for that address once the circuit has been convinced of the authority of the address it uses the Merkel proof to check inclusion in the Privacy set through these steps we're able to demonstrate that we control and address in the Privacy set without revealing which address it is we finally can check at least using a mock prover in this case that the proof is valid end to end ZK ecdsa demonstrates this use case with the Anon Club products their repository ships with a CLI that we can use to run a production grade privacy set membership group in this case we'll prove that we control an address that is in the set of holders of some erc20 token we can prompt the CLI to retrieve all of this information for us and it will automatically inject it into our proof as with the test case we can supply an arbitrary message we also need to supply the signature by the address we want to prove membership for on that message the CLI has a proving server running in a separate terminal and this will submit the private and public inputs to generate the proof as the output shows this computation is expensive and takes some time to generate but soon enough our proof is ready with that proof we can privately demonstrate our address is in the set of holders of more than a thousand of this erc20 token and that's it PSE has a Discord where each of these projects live so you'll find ample support for integrating with these projects here or just for general questions on hacking with the ZK Stacks so definitely go ahead and join thanks for listening I hope this has been informative and helps you win some of the prizes available for hacking with these projects and other ZK Solutions