# EPF - Week 11
This week I looked into why the proofs were bigger than I expected [from last week](https://hackmd.io/@2xic/H1VIbSqKlg#That-is-one-large-proof). I also started to write about the proof assumptions, but I was sadly sick this week so the document is very much WIP and not as complete as I had hoped.

## Thinking about the proof assumptions
Started to write a document (very much WIP) on some notes for how we might support the [state transition function](https://hackmd.io/@2xic/SJstINCKxx).

## Follow up on the large proofs
Last week I noticed the proofs were big so wanted to understand why.

### `.app.proof`
Stores the [following struct](https://github.com/openvm-org/openvm/blob/fd362bc9/crates/cli/src/commands/prove.rs#L124-L137)

pub struct ContinuationVmProof<SC: StarkGenericConfig> {
    pub per_segment: Vec<Proof<SC>>,
    pub user_public_values: UserPublicValuesProof<{ CHUNK }, Val<SC>>,
}

The proofs are generated in [segments](https://github.com/openvm-org/openvm/blob/fd362bc9eafef5c7a3f9f7b37170dc0558df0de0/crates/vm/src/arch/vm.rs#L960-L1007). `user_public_values` contains [the public values](https://github.com/openvm-org/openvm/blob/f0f7ec7f6cff61d646dd26286afaaed5a9fbd1df/crates/vm/src/system/memory/merkle/public_values.rs#L18-L33). So the reason things are big is that we do proofs per segment, although each proof is small things add up.

The savior is `cargo openvm prove stark` which aggregates all of these, but sadly I cannot run it because it needs [~70GB of RAM](https://github.com/openvm-org/openvm/blob/f0f7ec7f6cff61d646dd26286afaaed5a9fbd1df/docs/vocs/docs/pages/book/writing-apps/generating-proofs.mdx?plain=1#L121) for the setup (see warning section [here](https://github.com/openvm-org/openvm/blob/f0f7ec7f6cff61d646dd26286afaaed5a9fbd1df/docs/vocs/docs/pages/book/writing-apps/generating-proofs.mdx#stark-and-evm-key-generation)).

The expected output size of stark proof would be a static size though and match my original thinking.

#[derive(Derivative)]
#[derivative(Clone(bound = "Com<SC>: Clone"))]
pub struct VmStarkProof<SC: StarkGenericConfig> {
    /// STARK backend proof
    pub inner: Proof<SC>,
    pub user_public_values: Vec<Val<SC>>,
}

So I guess we will stick with the app proofs for now, but stark proofs would be more useful in a production setting to lower the proof size.

## Next week
I want to continue to write up some thoughts on the proof assumptions as I wasn't able to do as much as I had hoped since I was sick this week.

I'll also start on the [next milestone](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/erigon_riscv_proof_sourcing.md#stabilizing-the-transpilation-module-weeks-11-17) by starting to look at supporting Uniswap V2.