Improved support for transaction fee estimation #3673
Assignees
Labels
f:fee-mechanism
Feature: Fee Mechanism
stale
To be closed due to a lack of activity
t:enhancement
Type: Feature, refactoring.
t:epic
Type: Epic
Comments
bors bot
added a commit
that referenced
this issue
Nov 10, 2022
3684: Improve support for cycles access r=zhangsoledad a=zhangsoledad <!-- Thank you for contributing to nervosnetwork/ckb! If you haven't already, please read [CONTRIBUTING](https://github.com/nervosnetwork/ckb/blob/develop/CONTRIBUTING.md) document. If you're unsure about anything, just ask; somebody should be along to answer within a day or two. PR Title Format: 1. module [, module2, module3]: what's changed 2. *: what's changed --> ### What problem does this PR solve? Improve ckb's support for recording and accessing cycles as described in [3613](#3673), while implementing the fee_rate estimate short-term scheme. ### What is changed and how it works? * For cycles and tx_size, the appending of records is done in a compatible way, so that when a new version of the node is run, new data is written, cycles and tx_size are appended, and old data is read in a compatible way. RPC returns data that is not recorded as `null`. * `get_block`/`get_block_by_number` adds a parameter `with_cycles` to choose whether to return cycles or not, mainly because some scenarios, such as indexer, do not need cycles and are performance sensitive, so an additional parameter is added to avoid the extra overhead needed to return cycles. ### Check List <!--REMOVE the items that are not applicable--> Tests <!-- At least one of them must be included. --> - Unit test - Integration test ### Release note <!-- Choose from None, Title Only and Note. Bugfixes or new features need a release note. --> ```release-note Title Only: Include only the PR title in the release note. ``` Co-authored-by: zhangsoledad <787953403@qq.com>
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
|
This issue was closed because it has been stalled for 5 days with no activity. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With the occurrence of ckb network congestion, a question has been more prominently exposed, how should ckb now go about setting transaction fees? Currently, the ckb nodes and the corresponding sdk do not have good support for transaction fee estimation, so this issue serves as a feature proposal to summarize and track the next actions.
Need an RPC that returns the cycles consumed by a transaction execution verification, although
dry_run_transactionexisted before, but its placement in the Experiment module needs some tweakingfeat: add rpc estimate_cycles #3669
Need an RPC to measure the fee_rate needed for a new transaction based on the fee_rate of the on-chain transaction. Here we need a solution that can be provided as soon as possible in the short term and a solution that is more optimal in the long term.
In the short term, provide an RPC that returns the average or median of the transaction fee_rates over a historical interval on the chain, Users can use this value according to their needs and experience (e.g. estimate_fee_rate * 1.2 / 1.5 / 2) Improve support for cycles access #3684
In the long term we need to provide better algorithms to measure the fee_rates required for new transactions to provide better guarantees, such as how much fee_rate can be used for new transactions to ensure that they can be confirmed within a certain time.
The text was updated successfully, but these errors were encountered: