# Fabric hardware acceleration
In order to take advantage of Fabric's VPU once it becomes available, we would like to explore the capabilities of the FC100 chip. To this end, we've outlined below several potential areas for collaboration between Fabric and Polygon.
## Hash functions
Miden is currently using the RPO hash function ([paper](https://eprint.iacr.org/2022/1577), [impl](https://github.com/0xPolygonMiden/crypto/blob/main/src/hash/rescue/rpo/mod.rs)) and we are investigating migration to the RPX hash function ([paper](https://eprint.iacr.org/2023/1045), [impl](https://github.com/0xPolygonMiden/crypto/blob/main/src/hash/rescue/rpx/mod.rs)). Both are defined over the Goldilocks field, with the main benefit of RPX being about 40% faster than RPO on CPUs.
We are interested in understanding how these hash functions would perform on Fabric's FC100 chip. Specifically, we are interested in:
- Understanding how RPO/RPX could perform relative to each other on FC100 (i.e., do we get the same 40% delta as on CPUs?).
- Understanding how RPO/RPX could perform relative to other popular arithmetization-friendly hashes (e.g., Poseidon 1/2) on FC100.
To this end, a potential project could consist of:
1. Modeling/analysis of RPX/RPO performance on FC100, specifically in the context of computing Merkle tree commitments to large matrixes (e.g., a matrix of $64$ columns and $2^{20}$ rows of Goldilocks field elements).
2. Depending on the results of the above, implementing FC100 kernel for RPO and/or RPX hash functions.
## Constraint evaluation
Currently, Miden AIR constraints (algebraic equations which define the circuit of Miden VM) are written in Rust. However, we are planning to transition to writing the constraints in [AirScript](https://github.com/0xPolygonMiden/air-script) which will make it both easier to define the constraints and to output constraint evaluation logic for various back-ends (e.g., Winterfell, Plonky3, recursive verifier, CUDA).
We are interested in investigating how translation of Miden VM constraints into an FC100 kernel can be automated.
Potential approaches include:
- Writing an FC100 kernel back-end for AirScript.
- Defining a simple intermediate representation for constraints evaluation logic into which AirScript code can be compiled and from which FC100 kernel can be instantiated.
The second approach is especially interesting as it could be used by various front-ends different from AirScript (e.g., [PIL](https://github.com/0xPolygonHermez/pilcom)). We already have a draft definition of what an IR could look like (see [here](https://github.com/0xPolygonMiden/air-script/issues/56)) and this format is very close to the one used by PIL (see [here](https://github.com/0xPolygonHermez/pilcom/blob/feature/pil2/src/pilout.proto)).
To this end, a potential project could consist of:
1. Defining an IR format for constraint evaluation logic which is suitable for FC100.
2. Implementing a tool which would be able to automatically translate logic defined in the above format into an F100 kernel.