---
# System prepended metadata

title: Starter Task Q's and Status

---

# Starter Task Q's and Status

## Proof Input
The [provided pastebin code](https://pastebin.com/16D4Qc0p) uses a proof shaped like the following:
```solidity
struct SignatureProof {
    Pairing.G1Point A;
    Pairing.G2Point B; 
    Pairing.G1Point C;
}

```
``G1Point`` and ``G2Point`` are defined (in Verifier.sol outputted by snarkjs):
```solidity
struct G1Point {
    uint X;
    uint Y;
}
struct G2Point {
    uint[2] X;
    uint[2] Y;
}
```
However, the sample proof input pi_b has 3 points (the last being ``[1,0]``), and the sample input `pi_a` and `pi_c` are 3-dimensional points (the "Z" coord being a 1). Do I just cut off these values? No groth implementation I've seen uses points with that shape

## Custom Crate
To perform the verification, I was trying to follow the Verifier.sol contract outputted by snarkjs. However, this makes use of [precompiled contracts](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-197.md) on Ethereum to do the addition/scalar multiplication on the bn curve and the pairing operation. ZCash had made available thier Rust implementations of these precomiled funtions in crates(packages you can import) on crates.io, but haven't maintained it since 2017. The old version makes use of an old Encoding/Decoding trait that happens to be not compatible with CosmWasm. Conveniently enough, ParityLabs and Aztec Protocol forked it and refactored to remove that dependency. It didn't seem to be published as a crate and have read that the random number generator packages still used are also not compatible with CosmWasm, so I will likely need to remove/refactor those dependencies as well. To do this, (sadly) I concluded that I need to maintain my own copy of the [bn crate](https://crates.io/crates/fork-of-zcash-bn)   so it can be modified as needed.

## uint256's
This is a pain (lol) bc [cosmos supports u32 and u64's](https://arxiv.org/pdf/2012.01032.pdf) (see page 3 of linked pdf), while EVM supports uint's 8-256. Rust only natively supports up to uint128 primitives also. Looking into several workarounds, one using a datatype in the aforementioned crate I uploaded to crates.io (pretty much concatenating either 4 uint64's or 2 uint128's). This just takes some time (and makes the delaration of the base/scalar fields annoying)
