-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a notary service #2661
base: notary
Are you sure you want to change the base?
Add a notary service #2661
Conversation
Suggestions about constant values by @roman-khimov #2425 (comment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Notary contract logic looks good to me except the #2661 (comment).
@doubiliu, could you, please, take a look at neo-project/neo-modules#691 (comment), I think that this PR is also affected and changes are needed.
After that we'll need to adjust a part of NotaryRequest
verification code.
@erikzhang @shargon @Liaojinghui Can you review this one? Especially the enum values we choose. |
|
||
public UInt160[] GetScriptHashesForVerifying(DataCache snapshot) | ||
{ | ||
return new UInt160[] { fallbackTransaction.Signers[1].Account }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what if teh Signers size is 1 here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fallback tx MUST have 2 signers. The check is here https://github.com/neo-ngd/neo/blob/4b10f64835eade8edb2005d9171cd2b839639f9a/src/neo/Network/P2P/Payloads/NotaryRequest.cs#L108
|
||
public bool VerifyStateDependent(ProtocolSettings settings, DataCache snapshot) | ||
{ | ||
var balance = NativeContract.Notary.BalanceOf(snapshot, fallbackTransaction.Signers[1].Account); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
var balance = NativeContract.Notary.BalanceOf(snapshot, fallbackTransaction.Signers[1].Account); | |
if (fallbackTransaction.Signers.Length != 2) return false; | |
var balance = NativeContract.Notary.BalanceOf(snapshot, fallbackTransaction.Signers[1].Account); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is checked in VerifyStateIndependent
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aren't they belong to different functionalities? Or they are supposed to be used together all the time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like transaction verification
Transaction.VerifyStateDependent
is supposed to call after Tansaction.VerifyStateIndependent
. So we don't verify signature in state dependent.
/// Sent to send an <see cref="NotaryRequest"/>. | ||
/// </summary> | ||
[ReflectionCache(typeof(NotaryRequest))] | ||
Notary = 0x50, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use Extensible
payload?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not everyone can send extansible paylaod. Users need this request to send their signature so that node with notary plugin can collect them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use
Extensible
payload?
Maybe difficult. Because RequestPayload
has a more complex verification logic, extansible paylaod
is not enough to support
public bool Verify(ProtocolSettings settings) { var nKeysMain = MainTransaction.GetAttributes<NotaryAssisted>(); if (!nKeysMain.Any()) return false; if (nKeysMain.ToArray()[0].NKeys == 0) return false; if (!fallbackTransaction.Script.SequenceEqual(FallbackFixedScript)) return false; if (FallbackTransaction.Signers.Length != 2) return false; if (fallbackTransaction.Signers[1].Scopes != WitnessScope.None) return false; if (FallbackTransaction.Witnesses[0].InvocationScript.Length != 66 || FallbackTransaction.Witnesses[0].VerificationScript.Length != 0 || (FallbackTransaction.Witnesses[0].InvocationScript[0] != (byte)OpCode.PUSHDATA1 && FallbackTransaction.Witnesses[0].InvocationScript[1] != 64)) return false; if (FallbackTransaction.GetAttribute<NotValidBefore>() is null) return false; var conflicts = FallbackTransaction.GetAttributes<ConflictAttribute>(); if (conflicts.Count() != 1) return false; if (conflicts.ToArray()[0].Hash != MainTransaction.Hash) return false; var nKeysFallback = FallbackTransaction.GetAttributes<NotaryAssisted>(); if (!nKeysFallback.Any()) return false; if (nKeysFallback.ToArray()[0].NKeys != 0) return false; if (MainTransaction.ValidUntilBlock != FallbackTransaction.ValidUntilBlock) return false; if (!fallbackTransaction.VerifyWitness(settings, null, fallbackTransaction.Signers[1].Account, fallbackTransaction.Witnesses[1], 0_02000000, out _)) return false; return this.VerifyWitnesses(settings, null, 0_02000000); }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
though i saw this before, but still, this logic is increadblly complex~~~
* Add ToJson overload (neo-project#2671) * Add ToJson overload * change * Update src/neo/VM/Helper.cs * Update src/neo/VM/Helper.cs * Update src/neo/VM/Helper.cs * Update src/neo/VM/Helper.cs Co-authored-by: Jinghui Liao <[email protected]> * Update src/neo/VM/Helper.cs Co-authored-by: Jinghui Liao <[email protected]> Co-authored-by: Shargon <[email protected]> Co-authored-by: Jinghui Liao <[email protected]> * Fix oom (neo-project#2665) * Fix oom * Revert reorder * parameters order Co-authored-by: Erik Zhang <[email protected]> * Optimize inventory (neo-project#2659) * add `murmur32` to crypto lib (neo-project#2604) * 3.2.0 * fix Co-authored-by: Shargon <[email protected]> Co-authored-by: Jinghui Liao <[email protected]>
* Devhawk/getAddressVersion2 (neo-project#2689) * Fix fee in NativeContract.Invoke (neo-project#2692) * GetTransaction signers (neo-project#2685) * Allow the committee to block a member from the committee (neo-project#2695)
* Fix * Fix * private * Check policy during deploy Co-authored-by: Erik Zhang <[email protected]>
Co-authored-by: Jinghui Liao <[email protected]>
Co-authored-by: Jinghui Liao <[email protected]>
Co-authored-by: Jinghui Liao <[email protected]>
Co-authored-by: Jinghui Liao <[email protected]>
Co-authored-by: Jinghui Liao <[email protected]>
Co-authored-by: Jinghui Liao <[email protected]>
11a7519
to
3359c0c
Compare
Why don't we move #1991 and #1992 implementations out of this PR and merge them into master? Both have some use even without notary subsystem, merging them will allow to properly review these parts and simplify this PR. #1992 is rather trivial and can be merged in a day probably, #1991 is a bit more involved, but we'll take a look at the specifics of it and it'll be done, allowing to concentrate on other notary details then. Just as a reminder, T5 NeoFS sidechain runs with notary enabled already, so I think we should move on with it and doing that in smaller steps is easier. |
This pr is too long and contains too many changes that is not actually part of this pr, is that possible to clean them up? @doubiliu |
@doubiliu please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement ( “Agreement” ) is agreed to by the party signing below ( “You” ), 1. Definitions. “Code” means the computer software code, whether in human-readable or machine-executable form, “Project” means any of the projects owned or managed by .NET Foundation and offered under a license “Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any “Submission” means the Code and any other copyrightable material Submitted by You, including any 2. Your Submission. You must agree to the terms of this Agreement before making a Submission to any 3. Originality of Work. You represent that each of Your Submissions is entirely Your 4. Your Employer. References to “employer” in this Agreement include Your employer or anyone else 5. Licenses. a. Copyright License. You grant .NET Foundation, and those who receive the Submission directly b. Patent License. You grant .NET Foundation, and those who receive the Submission directly or c. Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement. 6. Representations and Warranties. You represent that You are legally entitled to grant the above 7. Notice to .NET Foundation. You agree to notify .NET Foundation in writing of any facts or 8. Information about Submissions. You agree that contributions to Projects and information about 9. Governing Law/Jurisdiction. This Agreement is governed by the laws of the State of Washington, and 10. Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and .NET Foundation dedicates this Contribution License Agreement to the public domain according to the Creative Commons CC0 1. |
@Jim8y, @shargon and everyone interested: this PR has a large amount of code, and some of this code is out-of-date. It is hard to review and track changes in this PR, and thus we propose to go step-by-step on the path of Notary-related issues implementation (#2895, #2896 and #2897 are a must have). Based on this PR in the nearest future I'll create a set of PRs that solve mentioned issues. Some parts of the current PR don't work as expected, there is still the set of unresolved conversations, so I'll update the code and make it work properly. We propose to close this PR and start with a tiny fresh #3172. What do you think? |
close #2646