Update REPORT.md for January:DAY4

navigator-reports/january-REPORT.md

@@ -41,7 +41,7 @@
   - A version of o1js SHA256 hash function optimized fully with native o1js gadgets is `10 times` faster that a hash function simulated to the implementation in circom!! -> command.ts log -> 1 iteration.
   - SHA256 Benchmarks -> also verified by the benchmark script -> 1000 iterations
     ├─o1js x 46 ops/sec @ 21ms/op
-    ├─o1jsOP x 388 ops/sec @ 2ms/op 
+    ├─o1jsOP x 388 ops/sec @ 2ms/op
   - The first SHA256 hash function was a combination of native o1js gadgets and simulated circom templated for other bitwise function
     - After the last release, the 32-bit bitwise functions are now available.
       - Adding the SHA256 function using purely the bitwise functions from the gadgets, it seems that it is worth comparing to the first hash function
@@ -50,11 +50,38 @@
         - The latest release included leftShift32 and not rightShift and a simulated implementation was incorrect because leftShift is based on multiplication and rightShift on division
           - division of field element give non-compliant results
           - the solution is to use `Gadgets.rotate64(field, bits, 'right')` function to shift the bits to the left i.e getting rid of them and then truncate the rotated bits using Gadgets.divMod32() function.
-           ```typescript
-          let { remainder: shifted } = Gadgets.divMod32(Gadgets.rotate64(field, bits, 'right'));
+          ```typescript
+          let { remainder: shifted } = Gadgets.divMod32(
+            Gadgets.rotate64(field, bits, 'right')
+          );
           ```
-          - See [benchnark results](../src/benchmarks.md) -> it is impressive that a SHA256 hash function is more than 50X faster than a circom-like implemented hash function
+          - See [benchnark results](../src/benchmarks/benchmarks.md) -> it is impressive that a SHA256 hash function is more than 50X faster than a circom-like implemented hash function
 - Improve benchmarks to be based on randomly generated inputs
 - Change format of the circuit stat logs in `command.ts`.
 - Add a seperate `benchmarks.md` file for time-consuming benchmark results.
-- Write a [tweet](https://x.com/KaffelMahmoud/status/1744805950114894129?s=20) about the fascinating results :)
+- Write a [tweet](https://x.com/KaffelMahmoud/status/1744805950114894129?s=20) about the fascinating results :)
+
+### DAY4: 13th January
+
+- Move TWO32 constant from function to the `constants.ts`
+- Now that the o1js sha256 is validated as more efficient than the circom implementation, the following changes are made:
+  - Create a new directory called `benchmarks`
+    - This directory contains the benchmarks code --> `benchmark.ts`
+    - The benchmarks report --> `benchmarks.md`
+  - Now the simulated circom implementation is moved inside a new directory called `comparator` because its only role is to track performance of the main operational function.
+    - **functions.ts** is renamed as `bitwise-functions.ts` and is now seperate for both circom and native implementations
+    - the comparator directory now contains the bitwise functions inspired from the sha256 circom template
+    - a hash function sha256 that uses the custom bitwise functions from the latter functions
+  - Destruct the function from the **o1jsBitwise** object after sha256 separation
+  - Adapt tests to the new optimize/native implementation
+    - Some tests failed at the beginning
+      - the direction of rotation should be explicit, that's why I wrapped it as a different function `rotateRight32`
+      - after debugging, I realized that native `Gadgets.rotate32` function doesn't support rotationBits=0 so the test case is skipped now 
+      - after checking --> all tests pass
+- Polish test-utils imports to reduce import redundancy(mainly from node crypto library)
+- Move all export objects from bottom to the top of files(all) for better readability.
+- **Note:** after separation, preprocessing function using native o1js bitwise gadgets are used in common for the native and circom implementation but it doesn't have effect on the performance because it is only called once
+  - this is verified by comparing old and new benchmark after restructuring of the project
+- Resturcturing and polishing the code took time and became a huge commit
+  - Improve readability and code quality --> the project will still get bigger
+  - This is crucial to separate operational code from other utility code