fix: add comm_rs to the aggregate/verify method signatures

FIPS/fip-0013.md

@@ -211,12 +211,13 @@ The proofs aggregation procedure expects the following inputs:
 pub fn aggregate_seal_commit_proofs(
     registered_proof: RegisteredSealProof,
     registered_aggregation: RegisteredAggregationProof,
+    comm_rs: &[Commitment],
     seeds: &[Ticket],
     commit_outputs: &[SealCommitPhase2Output],
 ) -> Result<AggregateSnarkProof>;
 ```
 
-The `seeds` are an ordered list of randomness used to generate seal proof challenges.  The `commit_outputs` are the objects returned from the seal commit phase2 API.  The idea is that multiple sectors have been properly committed, and those outputs are compiled into a list for aggregation at some point later in time.
+The `comm_rs` are an ordered list of public replica commitments and `seeds` are an ordered list of randomness used to generate seal proof challenges.  The `commit_outputs` are the objects returned from the seal commit phase2 API.  The idea is that multiple sectors have been properly committed, and those outputs are compiled into a list for aggregation at some point later in time.
 
 **Requirements**: The scheme can only aggregate a power of two number of proofs
 currently. Although there might be some ways to alleviate that requirement, we
@@ -234,14 +235,15 @@ pub fn verify_aggregate_seal_commit_proofs(
     registered_proof: RegisteredSealProof,
     registered_aggregation: RegisteredAggregationProof,
     aggregate_proof_bytes: AggregateSnarkProof,
+    comm_rs: &[Commitment],
     seeds: &[Ticket],
     commit_inputs: Vec<Vec<Fr>>,
 ) -> Result<bool>;
 ```
 
-The `seeds` are an ordered list of randomness used to generate seal proof challenges.
+The `comm_rs` are an ordered list of public replica commitments and the `seeds` are an ordered list of randomness used to generate seal proof challenges.
 
-The `commit_inputs` above have a specific order to them, which *must* match the order of the `commit_outputs` passed into `aggregate_seal_commit_proofs`, but in a flattened manner.  First, to retrieve the `commit_inputs` for a single sector, you can call this:
+The `commit_inputs` above also have a specific order to them, which *must* match the order of the `commit_outputs` passed into `aggregate_seal_commit_proofs`, but in a flattened manner.  First, to retrieve the `commit_inputs` for a single sector, you can call this:
 
 ```rust
 pub fn get_seal_inputs(