-
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 notary contract #2425
Add notary contract #2425
Conversation
UpdatePreview5
My primary concern about this PR is making sure it fits into the schedule. We are pretty late in the dev process for N3 - I'm not a fan of feature work after the RC portion of the release process. However, @roman-khimov and Stanislav made it pretty clear how important this feature is for NeoFS. |
@neo-project/ngd-shanghai could you give me rights to edit? |
FYI, I'm not sure I still believe this. Notary deals w/ "incomplete" transactions, but there really isn't vocabulary in Neo for incomplete transactions - at least, not that can be communicated to a non-native smart contract. So unless we add mechanisms to the core platform, any notary services would have to be completely off chain. That sounds like a lot of duplicate effort - both duplicating work that the core platform is already doing as well as duplicating code/infrastrucutre across separate dApp projects. There isn't really a mechanism in the platform to represent an inco |
What about we build a webapi, and setup the Uri on chain by the committee? I think this method is also decentralized and simpler and more efficient. More importantly, it does not need to modify the core protocol. |
Compare that to the Notary scheme:
The most important thing is that this subsystem with all of its features can be used by any dApp, the same set of problems we're solving for NeoFS is also relevant for any applications that have multiple parties interacting (like multiplayer games, for example). Modifying the core protocol is not easy, but there are cases that can't be reliably solved without doing that and I think we have a compelling reason here, we're enabling the network to do something that it couldn't do before. |
For me, this is the key point, as I said it could be done without extra nodes, but maybe this is worst, as you said, it could bring more nodes to the network, but this is an economic area where I am not expert |
I like the idea of notary node although it's not perfect, I think we need varied ecnomic models for different role mantainers. That give more senarios for gas and encourage people to come in to neo. We can do everything from centralized service, but it's no use for commity growth. I like neo, if neo could benifit people, people will benefit Neo Network much more. I also had a look of NeoFS, notary node is very important as a module for it's system. If you guys want to make it centralize, how could it be open source and when it will be set. I think you guys want it to be intergrated to RC2 right? |
@erikzhang said he will approve this solution only if we don't add new p2p message type and transaction attribute. |
Currently So it probably can be done, but we'll need to ensure that:
Which to me equals to rewriting As for attributes, I don't think we can do anything meaningful without them.
|
Meanwhile, @alexvanin is testing mainnet NeoFS contract with Notary subsystem enabled: nspcc-dev/neofs-contract#74. It simplifies the contract obviously, but there is even more interesting observation that directly affects future mainnet operations (where GAS costs something). NeoFS contract accepts GAS from data owners that over time gets transferred to storage node owners that then probably would like to withdraw this GAS from the contract to their accounts. Withdrawing requires BFT number of signatures from alphabet nodes and on-chain signature collection used by current NeoFS contract leads to a number of transactions (7 for 7 alphabet nodes) with a total cost of 2.8-7.0 GAS. So you just can't withdraw any GAS from NeoFS contract without paying this fee and this fee is quite huge. Notary-enabled contract allows to withdraw with just 0.2 GAS which seems to be reasonable. So it's not just the number of transactions problem that we're solving here, it's also critically important for mainnet NeoFS economics viability. |
Can we assume notary nodes are completely trustworthy, Since they are designated by committee? So we won't need |
I don't think we can assume this even for CNs (otherwise we don't need BFT consensus, there are simpler algorithms for trusted nodes). And notaries can misbehave in different ways, not just for malicious intent, but because of some bug for example. Removing these attributes is dangerous, one misbehaving node could ruin whole service then and I don't think we can accept this risk. |
/// <summary> | ||
/// Notary nodes | ||
/// </summary> | ||
Notary = 128 |
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.
I believe it is complex as discussed but may be worth because each time more we need services for multi-signatures aggregation.
We'd like to discuss some minor adjustments to the notary subsystem that can/should be done as a part of this PR. They're not critical, they don't change the logic, but still they can be considered for better future extensibility of the protocol.
Of course we'll also need to enable the new contract at the appropriate height for each network, but it should already be possible with NativeUpdateHistory. |
Close this because of #2661 . |
Close #1573
This is the C# version, and the original version refers to Neo-go.