Merge pull request #8 from Jaak/master

Fix a couple of typos in the specification.

spec/r1cs-def.tex

@@ -83,7 +83,7 @@ \section{R1CS Definition}\label{sec:r1cs-def}
   \end{equation*}
   }
 
-When we prove this NP statement using zk-SNARK, the instance will be the public input that is visible to the verifer, and the witness will be the additional data that is known only to the prover, and used in the construction of the proof, but whose privacy is protected by the zero-knowledge property.
+When we prove this NP statement using zk-SNARK, the instance will be the public input that is visible to the verifier, and the witness will be the additional data that is known only to the prover, and used in the construction of the proof, but whose privacy is protected by the zero-knowledge property.
 
 \parhead{Complexity measure}
 For backends that consume R1CS natively, the cost of producing the zk-SNARK proofs (in time and memory) typically depends mostly on the \textbf{number of constraints}, $\NumConstr$.

spec/zkinterop.tex

@@ -205,7 +205,7 @@ \subsection{Goals}
 Given the typical complexity level of today’s constraint systems, it is often acceptable to handle all of the above manually, by fresh re-implementation based on informal specifications and inspection of prior implementation. Our goal, however, is for the interface to handle the semantics of the gadgets, reducing the predisposition to error as application complexity grows. The following paragraphs expand on how the semantics should be considered for interoperability of gadgets.
 
 \parhead{Witness reduction}
-Similar considerations arise for the witness reduction, mapping a high-level witness representation for a given statement into the assignment to witness variables (as defined by the instance). For example, a high-level protocol may use Merkle trees of particular depth with a particular hash function, and a high-level instance may include a Merkle authentication path. The witness reduction would need to convert these into witness variables, that contain all of the Merkle authentication path data encoded by some particular convention into field elements and assigned in some particular order. Moreover, it would also need to convert the numerous additional witness variables that occur in the constraints that evaluate the hash function, ensure consistency and Booleanity, amonh others.
+Similar considerations arise for the witness reduction, mapping a high-level witness representation for a given statement into the assignment to witness variables (as defined by the instance). For example, a high-level protocol may use Merkle trees of particular depth with a particular hash function, and a high-level instance may include a Merkle authentication path. The witness reduction would need to convert these into witness variables, that contain all of the Merkle authentication path data encoded by some particular convention into field elements and assigned in some particular order. Moreover, it would also need to convert the numerous additional witness variables that occur in the constraints that evaluate the hash function, ensure consistency and Booleanity, among others.
 
 \parhead{Gadgets interoperability}
 Beyond using fixed, monolithic constraint systems and their assignments, there is a need for sharing subcircuits and gadgets. For example, libsnark offers a rich library of R1CS gadgets, which developers of several front-end compilers would like to reuse in the context of their own constraint-system construction framework.