Alt-BN128 Little Endian compatibility

I guess the reason why we went with the BE route for bn128 syscalls was to conform to the Ethereum precompiles. So including the Eth compatibility issues here might not make that much sense. Maybe we can do things more iteratively as @jacobcreech mentioned. But I actually can't think of a definite argument against why we can have an intermediate sdk that wraps the curve syscalls and does the translations for consumers. If the sdk is well-documented and we encourage all the big projects to use them instead of the syscalls directly, then this may quickly become a standard? In this case, we may not need all these iterations of simds to modify the runtime.

@samkim-crypto I also like the sdk idea. and good to do iterations as @jacobcreech recommends. @deanmlittle for context, this was an inspiration: https://docs.succinct.xyz/docs/sp1/optimizing-programs/precompiles in time this solana crypto sdk can become a transparent replacement for common rust crypto libs that uses the right syscalls at the right time.

Yeah I am okay with this as well. If we move forward with this, then as @0x0ece mentioned, we should take care of all the Eth compatibility issues together. For example, maybe we can include a fix to this issue(https://github.com/anza-xyz/agave/issues/3379) in the simd as well. An alternative would be to leave the syscall the same and then create something like a solana-curve-sdk that contain syscall wrapper functions (wrappers to solaltbn128groupop, solaltbn128compression) that does the encoding (endianness) translation before invoking the relevant syscalls. The translations should be executable as BPF instructions. If we have a single curve sdk that can be consumed commonly by downstream p

Right, the flags are only used during serialization/deserialization. We just ignore the flags in Solana while on Ethereum, the precompile functions error out when the flags are set. So if we follow the Ethereum convention, then we are indeed making the syscall functions more restrictive. I think the main philosophical decision we have to make is whether we should follow the Ethereum convention or have our own conventions for the curve syscalls. The main argument for the former is that it would minimize confusion for projects that are migrating from Ethereum to Solana. The choice of big-endian encoding stemmed from following the Ethereum convention as well. But like you said, I think it makes

@samkim-crypto An alternative would be to leave the syscall the same and then create something like a solana-curve-sdk that contain syscall wrapper functions (wrappers to solaltbn128groupop, solaltbn128compression) that does the encoding (endianness) translation before invoking the relevant syscalls. My only concern with that approach is that it requires SBPF programs to spend their cycles on inverting bytes. Especially if we leave syscall as BE, then practically the most of consumers would end up doing that conversion... That's the reason why I added an explicit argument to the Poseidon syscall - to appease both native arkworks users and Ethereum bridges while not forcing people to spend CU

the main philosophical decision we have to make is whether we should follow the Ethereum convention or have our own conventions for the curve syscalls I'm on the side that we learn from Ethereum conventions but build what makes sense for Solana. Sometimes that means the same convention, but in cases like this SIMD it means being different. an explicit enum argument for determining endiannes, which I added to appease both arkworks users and Ethereum-related projects This is actually a pretty elegant solution that supports both camps here.

My only concern with that approach is that it requires SBPF programs to spend their cycles on inverting bytes. Especially if we leave syscall as BE, then practically the most of consumers would end up doing that conversion... That's the reason why I added an explicit argument to the Poseidon syscall - to appease both native arkworks users and Ethereum bridges while not forcing people to spend CU in either case. +1. I also like the approach you took with Poseidon and think the bitmask approach in this case is the most analogous and least invasive way to go about it. I would like to think that we care more about improving the real devex issues that our own developers are facing today over the

I see mostly agreement from the relevant stakeholders and no major pushbacks. Can we go ahead and merge this one?