pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-06-13 15:11:03 +00:00
Code Issues Packages Projects Releases Wiki Activity

Markdown linter (#1309)

Browse Source 
* Add markdown linting

- add linter default rules
- adapt rules to current code
- fix the code for linting to pass
- add CI check

fix #1243

* Fix markdown for Substrate
* Fix tooling install
* Fix workflow
* Add documentation
* Remove trailing spaces
* Update .github/.markdownlint.yaml

Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Fix mangled markdown/lists
* Fix captalization issues on known words
This commit is contained in:
Chevdor
2023-09-04 11:02:32 +02:00
committed by GitHub
parent 830fde2a60
commit a30092ab42
271 changed files with 6289 additions and 4450 deletions
Download Patch File Download Diff File Expand all files Collapse all files
substrate/client/transaction-pool/README.md
+4 -4
View File
@@ -232,7 +232,7 @@ are interested in.
Since the pool is expected to store more transactions than what can fit
in a single block, validating the entire pool on every block might not be
feasible. This means that the actual implementation might need to take some
feasible. This means that the actual implementation might need to take some
shortcuts.
## Suggestions & caveats
@@ -255,7 +255,7 @@ shortcuts.
lot of re-orgs. Make sure that transactions are never lost.
1. The UTXO model is quite challenging. A transaction becomes valid right after
it's included in a block, however it is waiting for exactly the same inputs
it's included in a block, however it is waiting for exactly the same inputs
to be spent, so it will never really be included again.
1. Note that in a non-ideal implementation the state of the pool will most
@@ -278,7 +278,7 @@ shortcuts.
1. We periodically validate all transactions in the pool in batches.
1. To minimize runtime calls, we introduce the batch-verify call. Note it should
1. To minimize runtime calls, we introduce the batch-verify call. Note it should
reset the state (overlay) after every verification.
1. Consider leveraging finality. Maybe we could verify against latest finalised
@@ -355,7 +355,7 @@ figure out what tags were satisfied by a transaction in that block. For each blo
transaction we either call into the runtime to get it's `ValidTransaction` object,
or we check the pool if that transaction is already known to spare the runtime
call. From this we gather the full set of `provides` tags and perform pruning of
the `ready` pool based on that. Also, we promote all transactions from `future`
the `ready` pool based on that. Also, we promote all transactions from `future`
that have their tags satisfied.
In case we remove transactions that we are unsure if they were already included