From 956e4c6fad779ef15eaa27702b26f05f65d31494 Mon Sep 17 00:00:00 2001 From: "Augusto F. Hack" Date: Wed, 1 Mar 2023 17:45:57 +0100 Subject: [PATCH] chore: initial run pre-commit --- .github/pull_request_template.md | 2 +- CONTRIBUTING.md | 2 +- benches/README.md | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 8dfedbe..ffd0f23 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -6,4 +6,4 @@ - Commit messages and codestyle follow [conventions](./CONTRIBUTING.md). - Relevant issues are linked in the PR description. - Tests added for new functionality. -- Documentation/comments updated according to changes. \ No newline at end of file +- Documentation/comments updated according to changes. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7c67357..47a46eb 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -17,7 +17,7 @@ We are using [Github Flow](https://docs.github.com/en/get-started/quickstart/git ### Branching - The current active branch is `next`. Every branch with a fix/feature must be forked from `next`. -- The branch name should contain a short issue/feature description separated with hyphens [(kebab-case)](https://en.wikipedia.org/wiki/Letter_case#Kebab_case). +- The branch name should contain a short issue/feature description separated with hyphens [(kebab-case)](https://en.wikipedia.org/wiki/Letter_case#Kebab_case). For example, if the issue title is `Fix functionality X in component Y` then the branch name will be something like: `fix-x-in-y`. diff --git a/benches/README.md b/benches/README.md index 059c392..9e14f78 100644 --- a/benches/README.md +++ b/benches/README.md @@ -1,4 +1,4 @@ -# Miden VM Hash Functions +# Miden VM Hash Functions In the Miden VM, we make use of different hash functions. Some of these are "traditional" hash functions, like `BLAKE3`, which are optimized for out-of-STARK performance, while others are algebraic hash functions, like `Rescue Prime`, and are more optimized for a better performance inside the STARK. In what follows, we benchmark several such hash functions and compare against other constructions that are used by other proving systems. More precisely, we benchmark: * **BLAKE3** as specified [here](https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf) and implemented [here](https://github.com/BLAKE3-team/BLAKE3) (with a wrapper exposed via this crate). @@ -13,7 +13,7 @@ In the Miden VM, we make use of different hash functions. Some of these are "tra We benchmark the above hash functions using two scenarios. The first is a 2-to-1 $(a,b)\mapsto h(a,b)$ hashing where both $a$, $b$ and $h(a,b)$ are the digests corresponding to each of the hash functions. The second scenario is that of sequential hashing where we take a sequence of length $100$ field elements and hash these to produce a single digest. The digests are $4$ field elements in a prime field with modulus $2^{64} - 2^{32} + 1$ (i.e., 32 bytes) for Poseidon, Rescue Prime and RPO, and an array `[u8; 32]` for SHA3 and BLAKE3. -#### Scenario 1: 2-to-1 hashing `h(a,b)` +#### Scenario 1: 2-to-1 hashing `h(a,b)` | Function | BLAKE3 | SHA3 | Poseidon | Rp64_256 | RPO_256 | | ------------------- | ------ | --------| --------- | --------- | ------- | @@ -46,4 +46,4 @@ To run the benchmarks for Rescue Prime, Poseidon and SHA3, clone the following [ ``` cargo bench hash -``` \ No newline at end of file +```