From 3c852efb514a04a04bf64015ec3a06bc712bf921 Mon Sep 17 00:00:00 2001 From: "Nathan H. Leung" Date: Mon, 20 Feb 2023 17:22:29 -0800 Subject: [PATCH] [TODO: Nate] --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 505e34c..91db03e 100644 --- a/README.md +++ b/README.md @@ -17,7 +17,7 @@ To verify these signatures, we can again fit the lowest degree polynomial over t That's how we implement accountable threshold BLS signatures. Now for proactive refresh. Every 30 seconds, all N parties are required to sample a new T-1 degree polynomial that passes through the origin. Every party then needs to add the corresponding point from all N-1 other polynomials to their local secret key. This completely changes what they secret key is, but notice that since all the new polynomials pass through the origin, all collective signatures at f(0) are still the same (read: vault kept intact). What's more, each party contributed equally to the update process, so there's no single point of failure. A key that is compromised in one update round by an adversary is now useless in the following updated round since the joint polynomial is completely different. Mission accomplished. -To demonstrate how powerful this primitive is, we also deployed our own vault on ZetaChain off of a Gnosis Safe fork. [TODO: Nate adds implementation details] +To demonstrate how powerful this primitive is, we deployed an asset vault on ZetaChain based on a [custom fork of Gnosis Safe](https://github.com/nathanhleung/ats-pr-bls-contracts). We modified the `isValidSignature` function and the signature verification logic in the `execTransaction` method of the Safe to instead rely on an on-chain ZK proof of a valid BLS signature generated using this signature scheme. Beyond modifying the signature scheme, we also took advantage of ZetaChain's zEVM features: the vault can accept messages from any blockchain supported by ZetaChain. To demonstrate this capability, we wrote a [GnosisSafeZetaChainClient](https://goerli.etherscan.io/address/0x34e2cd2967bbe834a41dde368ad2b239d765f378#code) contract which we deployed to Goerli. A call to `execTransaction` on this Goerli contract which contains a valid signature parameter will trigger a transaction on the main ZetaChain vault using ZetaChain's cross-chain messaging. This simplifies multisig management as now there is a single source of truth for managing the assets and signature verification of the vault — the Safe instance on ZetaChain. ## Challenges we ran into Implementing the scheme was pretty difficult. It's elegant and doable to understand from a high level, but the nitty gritty lost us a good bit of sleep: @@ -26,7 +26,7 @@ Implementing the scheme was pretty difficult. It's elegant and doable to underst 2) Needed zkSNARKs. ZetaChain (& EVM) doesn't have the BLS precompile, so verifying the signature on-chain would've costed an ungodly amount of gas. We remedied this by instead sending a SNARK proof on-chain and verifying that. In other words, instead of checking the BLS signature on chain, we check it in a circuit and verify the proof on chain. This was a hefty engineering lift since the computational model in circuits fairly different than what we did in rust. It was especially difficult because we needed to do complex field arithmetic (pairings) that doesn't play well with the field that bn128 (the main zkSNARK elliptic curve) provides. We built this on the circom/snarkjs stack and used groth16 as our proving system. NOTE: The correct circuit is still compiling here, so the vault we have live right now can be spoofed by a well-informed adversary. -3) [TODO: Nate talks about challenges with deploying to ZetaChain] +3) The default Gnosis Safe deployment process recommended by the Gnosis Safe team relies on presigned transactions generated from a key that only the Gnosis Safe team controls. These presigned transactions only work for deployment on certain whitelisted chains. Unfortunately, ZetaChain was not on the whitelist, so we had to make significant modifications to the Safe's constructor and deployment scripts in order to get a working Safe instance on ZetaChain. After getting the Safe working on ZetaChain, we spent extensive time digging into Solidity abi-coding and memory vs. calldata nuances to make sure data was passed in the correct encoding and format from Goerli to ZetaChain (e.g. we needed to calculate the correct offset to slice a calldata byte array by to get calldata bytes instead of memory bytes). We also ran into some contract size ceilings that we ended up mitigating by deleting legacy signature verification code used by the default Gnosis Safe verification algorithm that wasn't necessary under the new BLS signature scheme. ## Accomplishments that we're proud of 1) Rust crate that's the first working example of proactive refresh for accountable threshold signatures.