This repository was archived by the owner on Apr 8, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 3
Do not merge: We need to make an approach to verification #80
Closed
Changes from all commits
Commits
Show all changes
14 commits
Select commit
Hold shift + click to select a range
89effd9
Removed the old header.rs, now TxOutputHeader turn into Enum
sinitcin f42ac62
Added possibility to create a NFT, and removed old TxHeader
sinitcin aad0bc3
RPC for reading a NFT has been added
sinitcin 9a10db2
Fixed compilation error
sinitcin 7e0cd95
Fixed test
sinitcin 9441a76
Added serialization of fields that related to NFT
sinitcin b3d4247
Removed unwraps from sr25519_sign fn
sinitcin 847bf4d
Removed RPC calls `tokens_list` and `nft_read`. TokenList now turned …
sinitcin 7e3afd1
Merge remote-tracking branch 'origin/staging' into nft
sinitcin fa89a24
Merge remote-tracking branch 'origin/staging' into nft
sinitcin 1a77c9c
Added the new data field
sinitcin 717600c
I've been making refactoring, removed TokenList, added a new storage …
sinitcin 216a5ee
Added draft of TransactionVerifier. Value in the PointerToIssueToken …
sinitcin e0e22e4
We need to make an approach to verification
sinitcin 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
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains hidden or 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,101 @@ | ||
| **This description is still approximate and not accurate, we need to define an approach and agree on checks.** | ||
|
|
||
| ## Draft TransactionVerifier | ||
|
|
||
| I suggest adding a structure that will contain: | ||
|
|
||
| ```rust | ||
| pub struct TransactionVerifier<'a, T: frame_system::Config> { | ||
| // Pointer to a tx that we have to check | ||
| tx: &'a TransactionFor<T>, | ||
| // All inputs, to avoid repeated search in the loop | ||
| all_inputs_map: BTreeMap<TokenId, TransactionOutputFor<T>>, | ||
| // All outputs, to avoid repeated search in the loop | ||
| all_outputs_map: BTreeMap<TokenId, TransactionOutputFor<T>>, | ||
| // Using TokenId, you can get the entire amount of this token in all inputs | ||
| total_value_of_input_tokens: BTreeMap<TokenId, TransactionOutputFor<T>>, | ||
| // Using TokenId, you can get the entire amount of this token in all outputs | ||
| total_value_of_output_tokens: BTreeMap<TokenId, TransactionOutputFor<T>>, | ||
| // A set of transaction verification functions, this approach will allow you to remove unnecessary cycles, which will speed up the function | ||
| set_of_checks: Vec<&'a mut FnMut(...)>, | ||
| // ... | ||
| // I may add a priority field to the set of checks. I'm still thinking here. | ||
| } | ||
| ``` | ||
|
|
||
| This struct we will use this way in the pallet utxo: | ||
|
|
||
| ```rust | ||
| pub fn validate_transaction<T: Config>( | ||
| tx: &TransactionFor<T>, | ||
| ) -> Result<ValidTransaction, &'static str> { | ||
| TransactionVerifier::<'_, T>::new(tx) | ||
| .checking_inputs() | ||
| .checking_outputs() | ||
| .checking_utxos_exists() | ||
| .checking_signatures() | ||
| .checking_tokens_transferring() | ||
| .checking_tokens_issued() | ||
| .checking_nft_mint() | ||
| .checking_assets_burn() | ||
| .calculating_reward() | ||
| .collect_result()? | ||
| } | ||
|
|
||
| ``` | ||
|
|
||
| When creating a new instance of this structure, we must initialize the fields. | ||
|
|
||
| Each subsequent check adds a new instance of the function to `set_of_checks`, which will be called in` collect_result`. | ||
|
|
||
| At the moment we can split the verification function for these parts: | ||
|
|
||
| * `checking_inputs` | ||
| * Checks that inputs exist in a transaction | ||
| * Checking that the number of inputs is not more than the maximum allowed number, now in the code I see that it is `u32::MAX` | ||
| * Ensure each input is used only a single time | ||
|
|
||
| * `checking_outputs` | ||
| * Checks that outputs exist in a transaction | ||
| * Checking that the number of outputs is not more than the maximum allowed number, now in the code I see that it is `u32::MAX` | ||
| * Ensure each output is unique | ||
| * Output value must be nonzero | ||
| * An output can't exist already in the UtxoStore | ||
|
|
||
| * `checking_utxos_exists` | ||
| * Resolve the transaction inputs by looking up UTXOs being spent by them. | ||
|
|
||
| * `checking_signatures` | ||
| * if all spent UTXOs are available, check the math and signatures | ||
|
|
||
| * `checking_tokens_transferring` | ||
| * We have to check that the total sum of input tokens is less or equal to output tokens. (Or just equal?) | ||
| * All inputs with such data code must be correctly mapped to outputs | ||
| * If NFT is sent we must not burn or lose data | ||
|
|
||
| * `checking_tokens_issued` | ||
| * We must check the correctness of the issued tokens | ||
| * We have to check the length of `metadata_uri` and` ticker` | ||
| * We must check the correctness of `value` and `decimal` | ||
|
|
||
| * `checking_nft_mint` | ||
| * We have to check the uniqueness of digital data, only one NFT can refer to one object | ||
| * We have to check the length of `metadata_uri` | ||
|
|
||
| * `checking_assets_burn` | ||
| * Is there burn more than possible? | ||
| * Is there tocken_id exist for the burn? | ||
|
|
||
| * `calculating_reward` | ||
| * Just collecting MLT for a transaction reward. | ||
|
|
||
| * `collect_result` | ||
| * Call all of these functions in one loop. | ||
|
|
||
| ## Questions | ||
| * Do we need other checks? | ||
| * What is we need for checking Bitcoin Script? | ||
| * What is we need for checking contracts? | ||
| * If we can check an output address here, and add a possibility to find in the UtxoStore by any address format, then we can remove `fn pick_utxo` and `fn send_to_address`. Isn't that? | ||
|
|
||
| I'm glad to see any suggestions or critics. | ||
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
Oops, something went wrong.
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've understood that the reward can be paid in any token, is that still correct or is that a different kind of reward?
Btw, how do the code changes you've introduced in this PR relate to this proposal?
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 last thing that I heard, for the test-net we should use only MLT as a reward.
Added the comment at the top. We need just discus over here.