safe-global / safe-modules / 8454662939

100%

master: 85%

push

github

Use assembly in WebAuthnVerifier for Base64 encoding (#318)

This PR implements #289 

The algorithm is implemented as a library instead of the suggested
in-place adjustment from the original issue. Akshay's original
implementation was doing it in-place (which can still be found in the
commit history). While it was efficient code size-wise, but gas-wise, it
consumed more gas than FCL's implementation, probably due to some
inefficient stack manipulations. I tested it with Solady's
[library](https://github.com/vectorized/solady/blob/main/src/utils/Base64.sol)
then, and it turned out to be much more efficient even though it wasn't
doing the encoding in place.

The implementation I'm proposing is based on Solady's efficient
algorithm. It seems to me that it's not adjustable to in-place encoding
due to the fact the algorithm takes advantage of optimizing stack
operations by writing X bytes to the scratch space and then writing them
to the string at position Y+(I*N) (I=Iteration, Y=start, N=bytes written
in an iteration) as a 32-byte word. Because it writes them as a 32-byte
word, it’s not suitable for modifying a string in place because it will
overwrite the existing string bytes with empty characters. (I'm happy if
I'm wrong though)

**Changes in PR**:
- Add `codesize` task
- Add a `Base64Url.sol` library with a Base64Url encoding algorithm that
is optimized for encoding `bytes32` data.
- Add tests for the base64 library
- Edit the typescript configuration to include the hardhat.config.ts so
all the type extensions are picked up. Necessary to get the project
compiled.

### Code size change

This PR:
`WebAuthnSigner 2693 bytes (limit is 24576)`

Default main branch:
`WebAuthnSigner 2817 bytes (limit is 24576)`

### Gas Usage - Needs additional test for benchmarking

**Solady**:
```
  Gas Benchmarking
    WebAuthnSigner
      ⛽ deployment: 550077
      ✔ Benchmark signer deployment cost
      ⛽ verification (Fr... (continued)

25 of 44 branches covered (56.82%)

Branch coverage included in aggregate %.

2 of 2 new or added lines in 2 files covered. (100.0%)

95 of 103 relevant lines covered (92.23%)

4.95 hits per line