-
Notifications
You must be signed in to change notification settings - Fork 40
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
Checkpoint block validation docs #1319
Open
kpudlik
wants to merge
1
commit into
dev
Choose a base branch
from
cb-validation-docs
base: dev
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,42 @@ | ||
# CheckpointBlock Validation | ||
|
||
Each transaction sent to cluster needs to be validated before proposing it to block/consensus. | ||
Part of code responsible for validation is in `TransactionValidator.scala`. | ||
|
||
## Duplicated transaction validation | ||
Duplicated transaction can affect wallet balances so block which contains transaction with specific `hash` twice | ||
is incorrect and needs to be rejected. Method `validateDuplicatedTransactions` returns `DuplicatedTransaction` | ||
validation result if there are any duplicated transactions. | ||
|
||
![alt text](img/checkpoint-block-validation/duplicated-transaction.jpg "Duplicated transaction") | ||
|
||
## Signature validation and hash integrity | ||
Each block has its unique signature which is created by signing block by private key. | ||
Thanks to that we know that block was created for sure by known signer. | ||
Each block has also unique `hash` which is generated from the content of block so if someone malformed the content | ||
of block - the hash should be different. If hash is different or does not match the content of block then such block | ||
is rejected because is malformed. | ||
|
||
## Balance validation | ||
Balance validation checks if each of addresses could make transactions included in the block. | ||
Of course there is a transaction validator, but some things can't be validated on single transaction level | ||
so we need to validate whole block and all the transactions inside for specific address. | ||
|
||
### Insufficient balance validation (for regular wallets) | ||
First of all we must check if specific wallet has enough tokens to make all the transactions included in block. | ||
That being said balance left after executing transactions should be `>= 0` (so can't be negative). | ||
To do that `validateSourceAddressBalances` sums sent tokens for address and compares it with current balance. | ||
If sum is bigger than current balance then address has `InsufficientBalance` and block is incorrect because | ||
wallet has not enough tokens to send all the transactions from block. | ||
|
||
### Staking amount validation (for node wallets) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this check is not really working. I remember that it will only work if a node processes it's own transaction, so in most cases it will not get triggered. So i'm not sure we should put it in docs. |
||
Node wallets have slightly different rules of validating balance left after executing transactions. | ||
There is a minimal amount of tokens which needs to stay untouched called **staking amount** which is currently | ||
set to `250000` tokens (can be configured via `constellation.staking-amount`). That being said similarly to | ||
Insufficient balance validation, after executing all the transactions for node wallet there must be a **staking amount** | ||
of tokens left in the wallet. In case of failure it returns `InsufficientBalance`. | ||
|
||
## Transaction integrity | ||
Checking integrity of transactions in the block is just about validating each transaction separately in the same | ||
way as described in [Transaction Validation](transaction-validation.md) docs. | ||
|
Binary file added
BIN
+239 KB
docs-gh-pages/img/checkpoint-block-validation/duplicated-transaction.jpg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 think we should add info about double spend validation somewhere and a hint about blacklisting. If address performed a double spend it's actually being blacklisted forever (I think until rollback actually but Wyatt mentioned it was intended to be forever).
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'm not sure if double spend can be even performed at this point with checks we introduced in POST /transaction endpoint and pull for consensus logic. Still the check is there.
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.
But maybe that's not a part of checkpoint block validation, but rather docs for checkpointAcceptanceService