moved eip to erc

ERCS/erc-7524.md

@@ -90,9 +90,7 @@ The length of the input to $\mathsf{htc}$ is always 65 bytes.
 
 Note that in this scheme, we compute $h$ as the hash of the message and $pk$, not the message and $r$. This is to make our scheme deterministic.
 
-### Signature verification
-
-### Non-ZK
+### Signature verification (non-ZK)
 
 ********************Note: Non-ZK signature verification is not part of the proposal but relevant for an intuitive understanding of the ZK signature verification.********************
 
@@ -106,7 +104,9 @@ b. $h^s \cdot \mathsf{nul}^{-c} \stackrel{?}{=} z$
 c. $c \stackrel{?}{=} c'$
 4. Accept if all of the above is true.
 
-### In ZK
+Now we move onto the ZK signature verification specs.
+
+### Version 1: Verifier Optimized
 
 In a situation where there is a verifier who must *not* know the signer's $pk$, but the signer must nevertheless prove that they know $sk$ corresponding to the signature given $m$, a zero-knowledge proof is required.
 
@@ -130,9 +130,9 @@ It also establishes the following constraints:
 - $h^s \cdot \mathsf{nul}^{-c} = z$
 - $c = c'$
 
-### Version 2: Computing hashes outside the circuit
+### Version 2: Prover Optimized
 
-Currently, SHA-256 hashing operations are particularly expensive with groth16 proofs in the browser. In the context of PLUME, the computation of $c$ is a bottleneck for efficient proof times, so one modification suggested by the Poseidon team was to move this computation outside the circuit in the verifier.
+Currently, SHA-256 hashing operations are particularly expensive with zk proofs in the browser. In the context of PLUME, the computation of $c$ is a bottleneck for efficient proof times, so one modification suggested by the Poseidon team was to move this hash computation outside the circuit, into the verifier.
 
 To do this, we make $z$ and $g^r$ public signals in the circuit and update the definition of $c$ to $c = \text{sha256}([\text{nul}, g^r, z])$. The updated protocol is as follows.
 
@@ -160,7 +160,7 @@ Due to SHA-256 being a native precompile on Ethereum, this operation will still
 
 ### Version 3: 
 
-There may be a more efficient V3 in the future.
+There may be a more efficient V3 in the future, perhaps via removing indifferentiability from hash_to_curve.
 
 ## Rationale
 
@@ -185,7 +185,7 @@ For a few possible simpler algorithm designs that were considered, see blog.aayu
 
 ## Reference Implementation
 
-The GitHub repository `plume-sig/zk-nuliifier-sig` contains the reference implementation in several languages including Rust and Javascript. There is a sample PR to Metamask Core as well.
+The GitHub repository `plume-sig/zk-nuliifier-sig` contains the reference implementation in several languages including Rust and Javascript. There is a sample PR to Metamask Core as well, and a PR to Taho Core incoming.
 
 ## Security Considerations