Implement native Notary contract

[AnnaShaleva]

Description

Implement native Notary contract.

Close #2425. Depends on #3175 (will rebase this PR after #3175 merge). Tests are in progress, but the code is ready for review.

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• Native Gas contract unit tests;
• Native Notary contract unit tests.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules:
  • neo-modules update
  • neo-devpack-dotnet-update

[vncoelho]

Is this PR to be merged now or after next release?
I was planning to review current release and then merge these next feature.

[roman-khimov]

Is this PR to be merged now or after next release?

https://github.com/neo-project/neo/milestone/2

[dusmart]

This contract has a Verify method which is very dangerous.

neo/src/Neo/SmartContract/Native/Notary.cs

Line 95 in 77ffe09

private bool Verify(ApplicationEngine engine, byte[] sig)

In this method, we verify that tx.Signers[1] has enough balance stored in the contract. Plus, we verify that a signature from any notary is provided.

Here is an attack vector. A malicious notary can sign as many transactions as it wants and then publish at most 500 txs on chain while tx.Signers[1] has a little balance only sufficient for one tx.

If it's not a malicious notary, someone could still get a chance to make the notary sign something multiple times and cache them then publish them at once.

By the way, do you know how many core modules will be affected by this notary feature? Is this the last PR?

[vncoelho]

I am not seeing the part of the code we discussed on Discord, @AnnaShaleva, you mentioned about a delegated powered notary signing.
"The contract itself don't send the transactions. It's a designated Notary node who is powered to send transactions on behalf of notary service users. "

I want to check that because it should be, at least, similar to the oracles design.

[AnnaShaleva]

By the way, do you know how many core modules will be affected by this notary feature? Is this the last PR?

To be able to process existing NeoFS chains that use Notary - yes, it's the last PR. But ideally in future we'd like to implement P2PNotaryRequest payload with pool (ref. nspcc-dev/neo-go#1546) and Notary service plugin (ref. nspcc-dev/neo-go#1547). We'll add related issues to neo-project later.

"The contract itself don't send the transactions. It's a designated Notary node who is powered to send transactions on behalf of notary service users. "
I want to check that because it should be, at least, similar to the oracles design.

It's a part of Notary service plugin. See the example implementation in https://github.com/nspcc-dev/neo-go/blob/master/pkg/services/notary/notary.go.

[vang1ong7ang]

as @dusmart said , verify method should be used with extreme caution. and is there a fork introduced?

[roman-khimov]

verify method should be used with extreme caution

That's a valid concern, but there are multiple ways to handle it, we'll get to it after #3175 merge.

[AnnaShaleva]

Updated to fresh master, more tests added.

[AnnaShaleva]

@neo-project/core, a batch of tests is added, rebased onto fresh master and ready for review.

[vang1ong7ang]

me not in favor of this pr but me won't stop other people from liking it

however, at least, maintain it as a hardfork

same as #3175

[roman-khimov]

#3175 is HF-free to me (in that it can't be probed from contracts), but what I've said numerous times about these PRs (and the reason I wanted them in 3.7) is that we want to ensure C# node can process NeoFS chains. We've got two of them:

https://github.com/neo-project/neo/blob/master/src/Neo.CLI/config.fs.testnet.json
https://github.com/neo-project/neo/blob/master/src/Neo.CLI/config.fs.mainnet.json

And they can't be processed unless Notary is available (from the genesis for testnet and at some height around a year ago for mainnet). That's why I specifically wanted to have this contract enabled at the genesis block. However, testnet likely can survive another HF enabled at 0 (like it has all of A/B/C at 0 now and it's not a problem). I have an idea about mainnet FS chain as well, luckily it switches to the notary at some height after the Aspidochelone HF, so maybe we can move B/C HF heights retrospectively and if D is to be compatible with FS chain (likely it'll be) then we could arrange safe (for FS chain) enablement of this contract at D. No guarantees, but we'll try to check it.

[AnnaShaleva]

however, at least, maintain it as a hardfork

Good, then let us check if NeoFS networks are compatible with hardfork-dependent Notary contract. I'll write the results here and update this PR to enable Notary contract starting from the D hardfork.