Currently we take int64 value from the Go parser and push it to the
stack. Using uint64 is not a common practice (usually we just use `int`),
but can be a problem while doing bit arithmetic and serializing numbers.
Signed-off-by: Evgenii Stratonikov <fyfyrchik@runbox.com>
And ignore on dependency checks, we update all the examples at once
anyway, so may safely skip the check for zkp folder.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
An upgrade from gnark v0.8.X to v0.9.0 changes serialization format of verifying/proving keys
and proofs. In neo-go zkpbinding package we have to support both at least for now, because
gnark@v0.9.0 requires minimum go 1.19.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
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>
Valid transactions can't use more than MaxVerificationGAS for script execution
and this applies to the whole set of signers, so use this value by default
unless local instance configuration suggests something lower for generic
invocations.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
We can ignore core.ErrInvalidSignature (which means that the script has
executed, but returned false), but we shouldn't ignore other errors which
likely mean that the script is incorrect (or hits some resource limits).
Use neorpc.ErrInvalidSignature as a return to separate this case from
contract-based verification.
Signed-off-by: Roman Khimov <roman@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>
Testnet doesn't need any (confirmed to have the same state for non-NEO
contracts) and can go with Basilisk from height 0.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
It can be non-zero even if VoteTo is NULL. Fixes state diff with 3.6.0:
block 41660: value mismatch for key +////xTrvgat3qG/w8hQoD/I4MgUz6rygA==: QQQhAS8hA7yiAAAhAA== vs QQQhAS8hA7yiAAAhB+POSWfBCAE=
Related to #2844.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
If the parameter in the opcode dump is a 20-byte value, the converted values,
such as the address and the swapped endianness, have been added.
Signed-off-by: Tatiana Nesterenko <tatiana@nspcc.io>
GetRawNotaryTransaction returns a fallback or main transaction that was
previously added to the memory pool by P2PNotaryRequest. This function
invokes the RPC server's `getrawnotarytransaction` method.
GetRawNotaryPool returns hashes from all the verified transactions,
including both main and fallback transactions. This function invokes
the RPC server's `getrawnotarypool` method.
Also, these functions were added to doc.go.
Signed-off-by: Tatiana Nesterenko <tatiana@nspcc.io>
`getrawnotarytransaction` takes a transaction hash and attempts to find
the corresponding transaction in the notary requests mempool. It searches
through all the verified main and fallback transactions.
`getrawnotarypool` returns hashes of all the verified transactions,
including both main and fallback transactions.
Additionally add struct result.RawNotaryPool.
Close https://github.com/nspcc-dev/neo-go/issues/2951
Signed-off-by: Tatiana Nesterenko <tatiana@nspcc.io>
IterateVerifiedTransactions iterates through verified transactions in
memory pool and invokes function cont. Where cont callback returns
whether we should continue with the traversal process.
Signed-off-by: Tatiana Nesterenko <tatiana@nspcc.io>
