-
Notifications
You must be signed in to change notification settings - Fork 794
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Testnet Bootstrap and Resource Credits #3168
Labels
Comments
I would love it if this could be an option as runtime arguments: steem/libraries/plugins/rc/rc_plugin.cpp Line 1125 in 7e50f3e
|
2 tasks
mvandeberg
added a commit
that referenced
this issue
Mar 8, 2019
mvandeberg
pushed a commit
that referenced
this issue
Mar 8, 2019
Add RC start block and account whitelisting for test net #3168
Major improvement! Nice job!
See: gist:fc9f6bc |
vogel76
pushed a commit
to blocktradesdevs/steem
that referenced
this issue
Mar 11, 2019
bwsdeveloper
pushed a commit
to blocktradesdevs/steem
that referenced
this issue
Mar 11, 2019
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
As a developer, or an automatic process, I want to be able to reduce/bypass/eliminate/address the checks on resource credits in fastgen mode, so that I can bootstrap a new testnet without worrying too much about resource credits.
In a nutshell, some operations are being rejected during bootstrap. It's not a huge issue, but it's impacting the number of useful accounts being created/updated in testnet.
I realize this probably could be addressed by resource delegation pools, so I'm just trying to get ahead of this problem by looking into other alternatives and make sure we're aware of the issue.
Another way to address this would be to always bootstrap account creation and account updates in HF19 and then use "wait blocks" to reach the desired hardfork, but I think that might not be a good long term solution.
This is an example of what's happening at bootstrap of a testnet:
Example Broadcast
The reason we do
account_update_operation
in testnet bootstrap is to a) assigntnman
auths, and b) assign the original auths the account had on mainnet, since at this point, those accounts (now) all exist on testnet. The more any error occures, the less likely we will be able to assign any auths.Example Error
Steps to Recreate Issue
To recreate this issue before your very eyes, just launch a toy testnet:
This example launches a whole new private testnet but only tries to create about 2000 accounts. In doing so, 166 accounts could not be updated (and are therefore mostly useless for testing) due to limitations on resource credits:
The text was updated successfully, but these errors were encountered: