Add support for alt_bn128 syscalls (old)

[at5500]

Problem

Contracts written in the Solidity language cannot work in Solana if they contain calls to the following precompiled contracts:

bn256Add — Performs addition on the elliptic curve operations.
bn256ScalarMult — Performs scalar multiplication on the elliptic curve operations.
bn256Pairing — Elliptic curve pairing operations to perform zkSTARKs verification within the block gas limit.

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-196.md
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-197.md

The Neon EVM requires the implementation of system calls in Solana for these contracts.

Solution

In order for the precompiled contracts to be used in Solana, it is proposed to implement sys-calls inside the Solana core. That is, to perform an implementation similar to the erc-recover implementation.

Summary of Changes

This merge request adds implementation of bn256 (alt_bn128) precompiles.

About compute budget costs

We need to know, how much BPF instructions will be used for every operation on elliptic curves. We can't to know it directly, but we can compare the time needed for these operations and time, needed for Keccak hash for the same data.

We added benchmarks, that allow us to approximately define the amount of data in bytes for elliptic curves operations and Keccak hash and compare result times.

The repository with benchmarks is here: https://github.com/neonlabsorg/alt-bn128-bench

[samkim-crypto]

@Lichtso These are the crypto syscalls that I mentioned a couple weeks back. When you get a chance, can you help with computing the syscall compute budgets here? I am also curious to know what the process is for computing costs for syscalls.

These set of crypto operations are extremely useful/fundamental and should enable many advanced crypto operations on Solana.

[Lichtso]

We roughly charge one CU per byte copied (over the syscall interface edges) or CPU cycle used.

ALT_BN128_ADDITION_INPUT_LEN=128
ALT_BN128_ADDITION_OUTPUT_LEN=64
And at least 32 arithmetic operations (probably more, would have to benchmark), in total 128+64+32 = 224.

So you are currently more on the too cheap side I would say. Question is if this makes sense at all, because the data moved over the syscall boundary might out-weight the actual calculation.

@jackcmay Thoughts?

[at5500]

So you are currently more on the too cheap side I would say.

You're right! We are currently recalculating compute budget costs and will update them in code ASAP (today or tomorrow).

[Lichtso]

@samkim-crypto Quoting Tao on Discord we have a rough idea of how long 1 CU should take (about 33 ns):

However CU to micro-sec conversion rate of 30 CU per 1 us is a cluster average - it meant to be a generous one, it should allow most validators to replay 48MCu block within 400ms.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This stale pull request has been automatically closed. Thank you for your contributions.