Remove order when constructing a SRS object

[bxue-l2]

Order seems unneeded. If the file size is smaller than requested number of srs points, it would just fail.

rust-kzg-bn254/prover/src/srs.rs

Line 16 in df1ac7a

pub order: u32,

[samlaf]

Don't understand this issue so I might be totally out of context. But isn't the point of order that you might want to load LESS point than what the file as? Like my idea is we can always point to our 8GiB file for eg, but just download the subset of points that we need (say 16MiB).

[samlaf]

EDIT after seeing your comment elsewhere. I totally missed that there's another parameter points_to_load

Now I totally agree with you, feels weird that we have both. Is order even used? What is its purpose? Seems like we're storing it inside the SRS struct but we're not even using it? Can't we just force order == points_to_load always?

[bxue-l2]

I don't think order is useful, probably just get rid of it

[anupsv]

EDIT after seeing your comment elsewhere. I totally missed that there's another parameter points_to_load

Now I totally agree with you, feels weird that we have both. Is `order` even used? What is its purpose? Seems like we're storing it inside the SRS struct but we're not even using it? Can't we just force `order == points_to_load` always?

So it's used in this check primarily https://github.com/Layr-Labs/rust-kzg-bn254/blob/master/prover/src/srs.rs#L32
We can make it into static value cause it doesn't really change. It was used in other places before but now all those are gone cause of the refactors. Right now only used to make sure that points to load doesn't exceed the order.

[anupsv]

I don't think order is useful, probably just get rid of it

I think we'll need to replace it with a check to make sure the points asked and size matters. This might involve disk ops which might be a problem for risczero VM's. Because i remember removing sysinfo cause of the problems compiling. Another option is we can store the max order for the file that we use.

[samlaf]

Not following. order and points_to_load literally mean the same thing. If you're asking for a huge number of points_to_load and your system or vm environment can't handle it.. then you're just dumb and can change that parameter.

[anupsv]

Not following. order and points_to_load literally mean the same thing. If you're asking for a huge number of points_to_load and your system or vm environment can't handle it.. then you're just dumb and can change that parameter.

Yea right now considering the usage it looks the same but originally "order" had more meaning and uses if memory serves. It's not the VM not being able to handle, if someone requests more than what's available right now, with no check of file size it'll fail with a non clear error something on the lines of "data not available for buffer" or something similar. So the suggestion is we check the size of file so we can fail cleanly.

Or we change the failing of the file reading function to differentiate between other errors and file not containing data.

[samlaf]

Or we change the failing of the file reading function to differentiate between other errors and file not containing data.

This is what makes the most sense to me. You request to read a number of points, and if you reach EOF while trying to read those points, you return an error.