[doc] Aggregate - pairing_mul_n

[mratsim]

Looking into aggregate.c it's clear what blst_pairing_aggregate_pk_in_g1 is for but blst_pairing_mul_n_aggregate_pk_in_g1 is not documented.

blst/src/aggregate.c

Lines 7 to 34 in 6d6dec3

	/*
	* Usage pattern on single-processor system is
	*
	* blst_pairing_init(ctx);
	* blst_pairing_aggregate_pk_in_g1(ctx, PK1, aggregated_signature, message1);
	* blst_pairing_aggregate_pk_in_g1(ctx, PK2, NULL, message2);
	* ...
	* blst_pairing_commit(ctx);
	* blst_pairing_finalverify(ctx, NULL);
	*
	***********************************************************************
	* Usage pattern on multi-processor system is
	*
	* blst_pairing_init(pk0);
	* blst_pairing_init(pk1);
	* ...
	* start threads each processing a slice of PKs and messages:
	* blst_pairing_aggregate_pk_in_g1(pkx, PK[], NULL, message[]);
	* blst_pairing_commit(pkx);
	* ...
	* blst_fp12 gtsig;
	* blst_aggregated_in_g2(&gtsig, aggregated_signature);
	* join threads and merge their contexts:
	* blst_pairing_merge(pk0, pk1);
	* blst_pairing_merge(pk0, pk2);
	* ...
	* blst_pairing_finalverify(pk0, gtsig);
	*/

It seems like it's computing λ0 e(PK0, H(msg0)) λ1 e(PK1, H(msg1)) ... with λi != 1

[Nashatyrev]

@mratsim I bet this is exactly what you've described. I think will check this shortly.
But, yep, would be nice to have some more docs

[dot-asm]

Yes, the subroutines in question facilitate multiple aggregated signature verifiction. Its usage pattern is not finalized, because straightforward/naive one is not optimal. In other words it will change.

As for documentation in more general sense. Does reference to commentary mean that you'd view it as adequate? I mean outlining the usage pattern. Next question would be what would you think if usage pattern was expressed in form of python script? Would it be valuable?

[vikulin]

@nano-o >because straightforward/naive one is not optimal
Could it cause the issue #66 ?

[mratsim]

As for documentation in more general sense. Does reference to commentary mean that you'd view it as adequate? I mean outlining the usage pattern. Next question would be what would you think if usage pattern was expressed in form of python script? Would it be valuable?

Sorry I missed your question. For me it's adequate but I know both the low-level details and what I want to achieve.
I assume going forward people would like more handholding and are more familiar with something like a gitbook (https://docs.gitbook.com/).

For starters, a couple of Python scripts would likely be helpful indeed or maybe a tutorial folder with:

• 01 - How to generate a keypair
• 02 - How to sign a message
• 03 - How to verify a message
• 04 - How to have multiple keys sign the same message and produce a "fast aggregated" signature
• 05 - How to verify a "fast aggregated" signature
• 06 - How to batch verify n signatures on n messages

And each folder would have your support languages: C, Go, Rust, Python as demo.

This would be similar to what Halide does with its lessons:

• https://github.com/halide/Halide/tree/master/tutorial
• https://halide-lang.org/docs/tutorial_2lesson_01_basics_8cpp-example.html