Merge pull request #43 from aragonzkresearch/ax0/corrections

Corrections

blogo-input/posts/poseidon-noir.md

@@ -30,7 +30,7 @@ $$\pi(\mathfrak{P})=\rho_{f}(\mathfrak{P})_{R_{p}+R_{f}}\circ\dots\circ \rho_{f}
 
 In words, it subjects its input to a total of $R_{f} + R_{p}$ *rounds* of function applications, the first $R_{f}/2$ being *full rounds*, the next $R_{p}$ *partial rounds* and the last $R_{f}/2$ full rounds again.
 
-One possible definition of the Poseidon *hash* function is then the projection of the Poseidon *permutation* function onto its first component. However, this is not the only hash function used in practice (see the following section).
+One possible definition of the Poseidon *hash* function is then the projection of the Poseidon *permutation* function onto its first component. However, this is not the only function used in practice (see the following section), and its definition assumes a Poseidon permutation configuration for every possible width.
 
 While the definition above is fairly straightforward, it relies on a careful choice of the constants in $\mathfrak{P}$ to be useful in practice. In particular, they should be chosen in such a way that for a given input $x\in \mathbb{F}^{t}$, $\pi(\mathfrak{P})(x)$ should look more or less random. Briefly, $\alpha$ should be chosen such that $\textup{gcd}(\alpha,p-1)=1$ and the $\textup{mds}$ matrix and additive round keys (thus also the number of rounds) are chosen in such a way as to mitigate invariant subspace attacks. [Sage scripts](https://extgit.iaik.tugraz.at/krypto/hadeshash) are provided to generate appropriate constants so as to attain various levels of security and a discussion of this may be found in Appendix C  of the [paper](https://eprint.iacr.org/2019/458.pdf).
 
@@ -63,7 +63,7 @@ We have implemented the absorption phase in Noir as the function `absorb` [here]
 
 # Conclusions on Poseidon and ZK
 
-An comparison of the above expressions to those defining hash functions such as those in the SHA-2 family reveals that the computation of a Poseidon hash function requires far fewer multiplications due to the lack of bit manipulations, and this is reflected in our implementations in Noir. This is a key factor in choosing Poseidon over other families of hash functions, since in the context of ZK proofs, it results in smaller proof sizes, thus more efficient programs. In fact, the above formulation may be optimised further by appropriately swapping the order of operations in the partial rounds and modifying the additive round keys appropriately. Details may be found in Appendix B of the [paper](https://eprint.iacr.org/2019/458.pdf).
+A comparison of the above expressions to those defining hash functions such as those in the SHA-2 family reveals that the computation of a Poseidon hash function requires far fewer multiplications due to the lack of bit manipulations, and this is reflected in our implementations in Noir. This is a key factor in choosing Poseidon over other families of hash functions, since in the context of ZK proofs, it results in smaller circuits, thus faster proof generation. In fact, the above formulation may be optimised further by appropriately swapping the order of operations in the partial rounds and modifying the additive round keys appropriately. Details may be found in Appendix B of the [paper](https://eprint.iacr.org/2019/458.pdf).
 
 In our own ZK applications, we have employed the Poseidon hash function in the [circuits](https://github.com/aragonzkresearch/ovote/blob/main/circuits) underlying [OVOTE](https://forum.aragon.org/t/we-present-ovote-offchain-voting-with-onchain-trustless-execution/3603). Moreover, we have submitted our [implementation](https://github.com/noir-lang/noir/pull/768) of the Poseidon family of hash functions to Aztec's Noir project for inclusion in the Noir standard library and hope to make use of it in our future projects.