neo
neo copied to clipboard
Add a notary service
Summary or problem description This is a summary , discussed in detail is in issue #1573 In the current system, if a multi-signature operation needs to be completed, manual or third-party websites are required. There is no mechanism in the system that can automatically complete the collection and distribution of multi-signature signatures. So the purpose of this proposal is to add a multi-signature signature automatic collection and sending mechanism to neo.
Structure
The design mainly involves changes to the following components: Core
- Add a new native contract: NotaryContract
- Add a new message type: NotaryRequest
- Add 3 new transaction attributes: NotValidBefore, Notary assisted, Conflict
- Add a new role: Notary
Plugin
- Add a new plug-in: NotaryService plugin
Details
NotaryContract
Contains the following methods:
-
deposit Parameters: uint160(from), uint160(to), integer(amount), integer(till)
The deposit method. User needs to deposit the prepayment first when using the notary service. You can specify the address, amount, and validity period. It cannot be withdrawn before the expiration date. The minimum deposit amount is 2.
-
withdraw Parameters: uint160(from), uint160(to)
The withdraw method, after the validity period of the deposit amount expires, the remaining funds can be withdraw.
-
balanceOf Parameters: uint160(addr) Query the balance
-
expirationOf Parameters: uint160(addr) Query the validity period
-
verify
To verify the validity of the multi-signature transaction using the notary service.Use the notary contract as the signer, which must include one of the signatures of the specified notarynode node, so as to achieve the effect of 1/n
-
onPersist
Execute when the block is persisted, and distribute the service fee of all legal transactions using the "Notary assisted" attribute to the notary node
NotaryRequest
P2P message type, 2 incomplete transactions are encapsulated inside
-
mainTx
Contains the "Notary assisted" attribute and the number of corresponding NKEYS. It is the actual multi-signature transaction, but does not contain the complete multi-signature signature
-
fallbackTx
Contains the "NotValidBefore" attribute and the number of NKEYS with a value of 0, includes the "Conflict" attribute and the corresponding mainTx hash, and includes the "NotValidBefore" attribute and the corresponding transaction effective height
Message verification
- The prepayment amount of the sender deposited of this payload must be greater than the sum of the service fees of the fallback transaction related to the sender
- The valid block height of 2 transactions in this payload must match
- The "Conflict" attribute of the fallback transaction in this payload must match the hash of mainTx
- The sum of the validity period and the maximum transaction validity period corresponding to the "NotValidBefore" attribute of the fallback transaction in this payload must be less than the deposit validity period
Role
Notary nodes, all nodes that have the NotaryService plugin installed and authorized by the governance committee
NotaryService plugin
The plugin installed by the Notary node will actively monitor and collect NotaryRequest requests in the network, and actively send multi-signature transactions that have collected enough signatures within the validity period, and send the corresponding fallback transaction after the validity period
Process
- Any multi-signature participant first invokes the deposit function of the NotaryService contract.
- The multi-signature participants build a multi-signature transaction and add their own signatures, and encapsulate them in the P2P message body of the NotaryRequest type, and then send them to the neo's P2P network. After the nodes are forwarded, they are accepted by NotaryNode and cached. When enough signatures are collected by NotaryNode, NotaryNode will assemble the transaction encapsulated in NotaryRequest and the collected signatures into a complete transaction and send it to the network.
- If NotaryNode cannot collect enough signatures within the validity period, it will send the fallback transaction encapsulated in NotaryRequest after the validity period expires
Incentives
If NotaryNode does not work properly, it will not get incentives. If it works normally, it will receive (NKEYS+1)×FEE amount of gas as a service fee. Even if due to certain circumstances, it is not possible to collect enough signatures within the validity period, NotaryNode can also receive a service fee by sending a fallback transaction
Attack
Malicious multi-sign user
Because the user needs to deposit some gas to the multi-signature address first, and this part of the gas is locked, it can only be withdraw after the validity period expires, and each transaction will be charged a service fee regardless of whether it is successful or not, so it can prevent malicious users from sending spam transactions block the network
Malicious notary node
If the malicious notary node does nothing, it will not receive any incentives. When the signature is collected correctly, the incentive obtained is greater than the incentive obtained when the transaction is deliberately delayed,.And we only need one node in Notary node is normal to complete the entire work. In addition, due to the "conflicting" attribute of the transaction, the malicious NotaryNode cannot send main transaction and fallback transactions at the same time to collect excess incentives.
For more detailed instructions, please refer to the issue https://github.com/neo-project/neo/issues/1573
Neo Version
- Neo 3
Where in the software does this update applies to?
- Plugins
- Ledger
- Network Policy
- P2P (TCP)
- Other:
My questions:
- Can
NotaryContractbe a non-native contract? - Can
NotaryRequestuse theExtensiblemessage?
1. Can `NotaryContract` be a non-native contract?
https://github.com/neo-project/neo/pull/2425#issuecomment-816484492
2. Can `NotaryRequest` use the `Extensible` message?
https://github.com/neo-project/neo/pull/2425#issuecomment-823594129
- Can
NotaryContractbe a non-native contract?
I think it is possible to allow non-native contracts to have onPersist.
- Can
NotaryContractbe a non-native contract?I think it is possible to allow non-native contracts to have
onPersist.
A new interoperable function?
- Can
NotaryContractbe a non-native contract?I think it is possible to allow non-native contracts to have
onPersist.
NotaryContract should be able to mint GAS to designated Notary nodes during onPersist (to reward them for completed notary requests, it's similar to the way how designated Oracle nodes are being rewarded). I'm afraid this rewarding scheme won't be possible with non-native NotaryContract.
- Can
NotaryContractbe a non-native contract?I think it is possible to allow non-native contracts to have
onPersist.
Non-native contracts can't be executed safely unless they're limited in GAS. And onPersist can't fail, that's something we can't guarantee for non-native contracts too.
I think it is a feature that could be native, @doubiliu.
Maybe it is time to move forward with this issue. It can also help with the #2818 PR.