HF21 Recommendation: Raising Custom JSON Limit
Hello Steemians, we would like to open up public discussion of another minor addition to HF21: removing the limit to the number of custom JSON operations that can be included in a block by a single account.
For App Developers
Many Steem developers have informed us that this limit is adversely impacting the user experience in their applications. We want to do everything we can to make sure that Steem is the best blockchain protocol for powering web applications with amazing user experiences, which is why we believe it is worth discussing this change.
We have attempted to keep private discussions of this change to a minimum and a final decision has not been made. We would like all discussions on this topic to occur in the comments section of this post, or in follow up posts where appropriate. This way Steem users can gain as much insight into the change, and the reasons for supporting or opposing it, as possible.
Why Limit Custom JSON ops?
When this limit was created Steem only had bandwidth to rate-limit transactions. The big cost of custom JSON is an undo state for the plugins that process custom JSON. Because the Resource Credit is more sophisticated than the original bandwidth system, it more accurately captures that cost, and is therefore much more effective at rate limiting excessive use of custom JSON ops. This makes the limit antiquated.
DOS?
The DOS attack that led to the introduction of this limit did not impact the reliability of the Steem Blockchain. All witnesses continued to produce blocks without interruption, but it did result in an outage on Steemit.com. There is still the opportunity for the operation to be sent in a burst which could result in a short hiccup for nodes processing custom JSON.
Increase to 5
After weighing the pros and cons of such a change, we would recommend increasing the limit to 5 custom JSON ops per block. This will greatly increase flexibility for DAPP developers while continuing to ensure the stability of said DAPPs. This would enable us to re-evaluate the change prior to the SMT hardfork and decide to either relax the limit further, remove it entirely, or keep it where it is based on usage by DAPP developers.
Feedback
We have done our best to ensure that private discussions of this change were kept to a minimum, and that no final decisions on this change were made. We invite those who support this change, and those who do not, to voice their opinions in the comments to this post. The goal is to give Steem users one place where they can come to learn about this change, understand the various sides, and voice their support or lack thereof.
The Steemit Team
You have our support for more custom json!
You have our support for more custom json!
You have our support for more custom json!
You have our support for more custom json!
You have our support for more custom json!
You have our support for more custom json!
Sincerely Team Booster
I would like to remove this limit as much as possible. We have been having to built big work arounds because of this limit.
Make app developers have proper amount of SP but limits per block make everything clunky and complex.
How much do you estimate 3speak would need to run smoothly? 10? 20?
If a limit of 5 is not enough for 3speak, how will this ever be enough for future DAPPs that we can't even dream about yet?
As a workaround you could create a number of accounts and split RC over them to create this.
This change is super important to steem-engine and steemmonsters so that user actions never conflict and stop something from happening. It gets more important as new apps and automation are added.
We also would be greatly benefited as well!
Also making the necesary node/jussi changes to allow more than 2000 characters would be amazing as well that way we would decrease number of json transactions on a daily basis.
What happens if USER A with 20 token X sends 20 to USER B and USER C in the same block? Who gets prioritized?
The transaction that gets included in the block earlier by the witness producing the block.
Really interesting question. My guess is that asset transfers would be limited to one per block. Maybe there are a sub-type of transactions that are easier to bundle. E.g. if you and I play a game that ends in the transfer of an asset, then maybe all of our moves within the game can be bundled into a single block, while the asset transfer operation is included in its own block.
Any chance STEEMIT will make it so that only 1 of each unique coustom_json id per block?
In the end it depends on the software hosted by the witness to order the transactions. Whichever it deems first will be the one to be executed. In terms of custom json token transfers, both will be included in the block but the API of the server will only accept the first tx in the block.
Any chance STEEMIT will make it so that only 1 of each unique coustom_json id per block?
If there is a quick way to limit it again in case of emergency, I am okay with removing the limit completely.
These are all great ideas, no just scrap that silly EIP. Everything else you are doing is good for the price of steem, that is likely going to hurt it, it likely already has.
I approve this change, because as you mentioned, it will increase flexibility for DAPP developers.
I fully agree with the limit increase, the flexibility/speed it will give apps is crucial. The onus on adjusting to the change is on the app devs.
There's also no need for it to be a witness parameter. If there's a reason to adjust it upwards or downwards in the future, that adjustment is unlikely to be critical enough to alone warrant a HF and will be part of the next logical HF regardless.
I don't object at all to this change, but I wanted to caution those using custom_json's for derived consensus data, that this may change how you interpret ordering.
You can no longer do async/parallel application of transactions within a block as the account would not be guaranteed unique.
In other words, right now one can shortcut ordering as blocks are clearly totally ordered. With this change, one needs to pay attention to the order of transactions within a block to ensure deterministic application across observers.
Good point but I'm pretty sure this limit was implemented in 'non-enforced soft fork' and can't be fully relied upon for any security purpose anyway. If anyone is doing that they are currently vulnerable.
Are there serious downsides to having it be a witness-configured limit instead of a hard-coded limit?
Letting witnesses configure it gives us flexibility so that if we want to adjust it later, we don't need a hardfork or replay.
A possible downside is that a witness decides to ignore the other witnesses and ends up bricking accounts. But I think that's a risk with almost any op, not just custom_json. A witness doing that has to modify steemd and explicitly attack the community, which is grounds for unapproving such a witness.
You can't unapprove a backup.
In this case, the account being bricked has to also participate in the attack upon itself by trying to get too many ops included in blocks.
Not really. It is perfectly okay to broadcast multiple transactions at one time, I believe? They'll just trickle in one per block unless some witness puts multiples in a block. But I'm not really sure how this ends up bricking the account though. It seems different than the overuse of RCs that we saw earlier, since that affected the RC balance. There is no balance here.
It is currently implemented entirely via soft consensus (plugins). The biggest downside currently would be developer time to reimplement the system to use witness voted limits.
Allowing more than 1 custom_json and rasing the size limit will be a great improvement for all steem bases apps. I support these changes.
Posted using Partiko Android