Map Protocol - Near

The BLS signature scheme requires a cryptographic hash function that maps arbitrary data to a point in one of the two groups of the chosen elliptic curve. Such a function is also required to respect the properties of the Random Oracle Model. The `hash_to_g1` function at the pointed location maps arbitrary data to a point in the $G1$ group. Its implementation first performs a `sha256` on the input data and then ec-multiplies the resulting string with the generator of the $G1$ group. This is a known insecure manner to implement an hash-to-point function. In fact, the presence of the generator of the $G1$ group inside such expression allows, given a key pair (sk, PK) and a legitimate signature `S` of a message $m$ created by the user holding `sk`, an attacker to forge a signature `S'` of any arbitrary message `m'` such that `verify(S', m', PK) = true` having the sole knowledge of $S$ and $m$. In respect to the audited logic, this vulnerability allows an attacker to forge the aggregated signature carried by validated blocks. Indeed, each valid block, that is public, includes a signature and the date that the signature is supposed to authenticate. This means that any attacker, including malicious Map Relay Chain validator or Maintainers, can let the light client be updated with any fake block containing arbitrary data.

In Near, when a transaction causes a cross-contract call that requires an attached deposit, and the execution of the generated `Promise` fails, the attached deposit is not automatically refunded to the transaction caller. In the `MapCrossChainService`, a call to `transfer_in()` generates a `Promise` to verify the provided proof on the `MapLightClient`. The result of this `Promise` is handled in the `finish_verify_proof` that refunds the signer if the proof validation was not successful.\ In the case in which the supplied proof was correct, execution proceeds with the `process_transfer_in()` handler. However, since `process_transfer_in()` is also checking validity of other parameters, in the case in which any of the operation of `process_transfer_in()` fails, there is not any refund logic to give back the attached deposit to the `transfer_in` initiator. In practice, an example scenario would be the following. We know that the `order_id` of the event is 32 bytes and the price per 1 byte of storage is currently 1e-05 NEAR, so the storage deposit for `order_id` is at least 0.00032 NEAR. Let’s assume that Alice on the Map Relay Chain transfers 100 USDC to Bob on Near. Alice locks 100 USDC on the Map Relay Chain. Then, the `Messenger` will relay the event to the `MapCrossChainService` calling the `transfer_in()` and paying a storage deposit of 0.0002 NEAR in order to unlock 100 USDC to Bob.\ `transfer_in()` will create a `Promise` to asynchronously make a cross-contract call to verify the proof on the `MapLightClient` contract. Anyway, the `transfer_in` call will terminate and the 0.0002 NEAR deposit is transferred to the `MapCrossChainServices` contract account.\ Once the `verify_proof_data` `Promise` resolves with a successful outcome, the `process_transfer_in()` function would be called and the assertion on line 356 on the required deposit will fail because 0.0002 NEAR are not enough for recording the `order id` which needs 0.00032 NEAR.\ The execution of the `finish_verify_proof` fails but the storage deposit of 0.0002 NEAR remains in the `MapCrossChainService` account and the `transfer_in` initiator, i.e. the `Messenger`, can not redeem them in any way.

Calls to methods on smart contracts in Near are made through the serialization of method name and parameter in the JSON encoding format which assumes Javascript types. In particular, in Javascript numeric types are represented through the `number` type. In the case of integer parameters, the Javascript `number` type can only represent numbers on 53 bits, while parameters at the pointed locations express native Rust types `u64` and `u128`. Because of this mismatch in the maximum integers length, such parameters can incur in an overflow when serialized through the JSON encoding. The issue also affects returned values, even if returned in a `struct` like the case of `TransferOutEvent`.

The pseudocode in [EIP-3068](https://eips.ethereum.org/EIPS/eip-3068), reference for the `base_to_g1` function, uses constants that can be precomputed for efficiency. `constant2 = -3` is precomputed in function `hash_const_2()`. However the hardcoded value corresponds to `sqrt(-3)` instead of `-3` (inside the finite field over `p` hardcoded in `prime()`). Since cryptography algorithms are the result of dedicated security demonstrations, implementation should carefully follow the reference algorithm.

There is a `TODO` statement in the code. Such statements are used to identify incomplete functionality.

The pointed line initializes a struct field that was present in a previous development iteration. This prevents unit tests from compiling and running. The following integration tests (17 out of 24) fail their execution: - test_add_validator - test_get_header_height - test_remove_validator - test_update_block_header - test_update_block_header_38000 - test_update_block_header_93000 - test_update_block_header_bad_epoch - test_update_validator_for_20_epochs - test_update_validator_for_21_epochs - test_validator_remove_01 - test_validator_remove_02 - test_validator_remove_add - test_verify_proof_after_add_remove_validators_001 - test_verify_proof_after_add_remove_validators_002 - test_verify_proof_in_diff_epochs - test_verify_proof_multi_receipt - test_verify_proof_single_receipt

The functions `hash()` and `hash_without_seal()` from file `header.rs` are almost identical. The shared functionality can be placed into a separate `internal` or `private` function to improve the code's readability and to detect errors over subsequent development iterations.

The linked lines contain commented code with no explanation on its purpose.

The current error message does not give the accurate information to describe the error condition.\ According to the logic, the `cur` amount, representing the deposit attached to the `transfer_in` function not necessary to the `MapCrossChainService` contract, should be `ret_deposit` instead of the total deposit `cur_deposit`.

The comment above the function `deserialize()` from `serialization/bytes` states that the function will "Deserialize string into T" but the return type of the function is `Integer`.