The example shows that the proover knows the solution of the cubic
equation: y = x^3 + x + 5. The example is constructed for BLS12-381
curve points using Groth-16 prooving algorithm. The example includes
everything that developer needs to start using ZKP on the NEO platform
with Go SDK:
1. The described cubic circuit implementation.
2. The off-chain proof generation with the help of gnark-crypto library.
3. Go verification contract generation and deployment with the help of
NeoGo libraries.
4. The on-chain proof verification for various sets of input data.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
It requires explicit signers, and we have a problem with the old code:
2023-09-12T18:42:00.063Z WARN failed to perform oracle request {"url": "neofs:FMDZvqUCqcduZa8HD6wJNsHWrJ6sqkgBveGuYuL38pvH/5DCg4wUgWuWN3zsF4P4HdAzY2iKvXcrZ8QBLYGd1D1g2", "error": "failed to create client: incorrect signer: expected ECDSA_DETERMINISTIC_SHA256 scheme"}
Signed-off-by: Roman Khimov <roman@nspcc.ru>
We were using _very_ old version, so there is a number of changes, including:
* fix for unlimited reads
* UTF-8 check for HTTP requests
Signed-off-by: Roman Khimov <roman@nspcc.ru>
There is a security issue found in github.com/btcsuite/btcd that we don't care
about (we're only using 256k1 implementation), but GitHub complains about
it. We could update to github.com/btcsuite/btcd/btcec/v2, but it's now just a
thin wrapper over github.com/decred/dcrd/dcrec/secp256k1/v4, so we better use
it directly.
It makes sense in general (further narrowing down the time window when
transactions are processed by consensus thread) and it improves block times a
little too, especially in the 7+2 scenario.
Related to #2744.
https://github.com/nspcc-dev/neo-go/pull/2435 breaks compatibility
between newer RPC clients and older RPC servers with the following
error:
```
failed to get network magic: json: cannot unmarshal string into Go struct field Protocol.protocol.initialgasdistribution of type int64
```
This behaviour is expected, but we can't allow this radical change.
Thus, the following solution is implemented:
1. RPC server responds with proper non-stringified
InitialGasDistribution value. The value represents an integral
of fixed8 multiplied by the decimals.
2. RPC client is able to distinguish older and newer responses. For
older one the stringified value without decimals part is
expected. For newer responses the int64 value with decimal part
is expected.
The cludge will be present in the code for a while until nodes of
version <=0.98.3 become completely absolete.
Allows to quickly find the bad block and compare application
logs. Theoretically could also walk through the MPT to find the difference
there, but it's not needed now.
Update includes:
1. New simple client mode that parses erroneous status codes as `error` and
returns them from the calls of the client methods.
2. `Client` is struct now, not an interface.
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Replace `neofs-api-go` module with `neofs-sdk-go`. Adapt to NeoFS
response statuses in the implementation of NeoFS oracle.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
It's very effective in avoiding allocations for big.Int, we don't have a
microbenchmark for memppol, but this improves TPS metrics by ~1-2%, so it's
noticeable.
Use circular buffer which is a bit more appropriate. The problem is that
priority queue accepts and stores equal items which wastes memory even in
normal usage scenario, but it's especially dangerous if the node is stuck for
some reason. In this case it'll accept from peers and put into queue the same
blocks again and again leaking memory up to OOM condition.
Notice that queue length calculation might be wrong in case circular buffer
wraps, but it's not very likely to happen (usually blocks not coming from the
queue are added by consensus and it's not very fast in doing so).
It supposedly fixes some Windows and Solaris problem, but this commit is
deliberately taken before the package switches to Go 1.17 (as we still need
older versions).
We were using some version from 2018 and there was a big number of fixes
and optimizations since then. It's not managed well though, current 1.0.0 tag
is 2019, so we're using latest and greatest here.
Prometheus is somehow better (isn't noticeably probably), but it also
wants at least 2.3.0 YAML package, so update it to 2.4.0 which fixes some
important bug wrt v2 line (maybe we need to migrate to v3 though)/
