Skip to content
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

[Validation] [Masternode] [Test] SDMN (Shield Deterministic Masternodes) #2876

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

panleone
Copy link

@panleone panleone commented Aug 1, 2023

The aim of this PR is adding the possibility to create Shield Deterministic Masternodes:
Note: a masternode is shielded if the collateral is pointing to a shielded note (Rewards are still normal utxos)

Validation rules:

  1. The ProRegTx version has been updated to 2;
  2. The ProRegTx has a new field shieldCollateral which contains the necessary info to prove the ownership and unspendness of the collateral;
  3. Shield Masternodes can be created only when legacy masternodes are obsolete (i.e. SPORK_21 is sent)
  4. For Shield Masternodes the ProRegTx field vchSig must be left empty since the proof of ownership is already contained in the new field.

RPC changes:

  1. RPCs protx_register and protx_register_prepare now take as third parameter the boolean transparent which is True for normal masternodes and False for shielded masternodes;
  2. the parameter sig in protx_register_submit is now optional (since it is required ONLY for transparent masternodes and not for shielded one);

Proof of Validity:

As collateral the masternode creator must provide a sapling nullifier nf (so peers can check that nf is unspent) and he also must provide a "proof" which is basically a fake transaction in which they de-shield the note (10000 shield PIVS -> 10000 transparent PIVS). From this proof peers can check that the creator has the authority to spend the collateral and the value of the note is the required one.

  • The "fake" transaction is basically stored in the ProRegTX field shieldCollateral
  • The word "fake" refers to the fact that the proof is not a real transaction (so for example a bad node cannot put the proof in a block to spend it)

Functional tests:

  • In all functional tests that involved the creation of quorums I transformed 2 DMNs in SDMNs so we are sure that chainlocks, signing sessions, quorums... work with a mix of normal and shield masternodes.
  • In tiertwo_deterministicmns I added a shield deterministic masternode in order to check basic properties like: collateral is locked, the SDMN gets rewards as expected, if the note is spent the masternode is removed from the list, a new ProRegTx pointing to the same collateral can replace the SDMN etc...

Governance and Vote system:

We currently map masternodes to their vote to a given proposal through their collateral outpoint, which is stored inside a CTxIn, see classes CBudgetVote and CFinalizedBudgetVote (I guess due to retro compatibility with an older system).
This map cannot be built for SDMNs since their (shield) collateral is private!
To overcome this problem I decided that this map will be done not with the collateral of the masternode but with the hash of the ProRegTx (which is enough since it uniquely identify a deterministic masternode). However to keep things compatible with the current system, we have still to provide a full outpoint to store a vote, so we can just pick a default nIn = 0, the full outpoint then becomes:
Coutpoint(ProRegTxHash, 0)

For future PRs:

Other special txs ProUpServTx, ProUpRegTx and ProUpRevTx will be added in a future PR since they are not mandatory: A user can get rid of his masternode simply by spending the SDMN collateral.

@panleone panleone self-assigned this Aug 1, 2023
@panleone panleone added this to the 6.0.0 milestone Aug 1, 2023
@panleone panleone marked this pull request as draft August 1, 2023 13:13
@panleone
Copy link
Author

panleone commented Aug 1, 2023

Note: this PR depends on #2870 which is not merged yet

@panleone
Copy link
Author

ready for review

@panleone panleone force-pushed the shield_dmns branch 3 times, most recently from 33a4d83 to 11c0550 Compare August 31, 2023 18:46
@panleone panleone force-pushed the shield_dmns branch 6 times, most recently from 7c87dfe to 1618dea Compare September 1, 2023 20:23
@panleone
Copy link
Author

panleone commented Sep 5, 2023

Update: Added 3 new commits that implement the voting system for SDMNs and the corresponding functional test coverage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In Progress
Development

Successfully merging this pull request may close these issues.

None yet

1 participant