Want Larger Custom JSON Payloads In Your Steem Operations?
For some of you, this is probably not new knowledge, but currently, if you're using the official Steemit API (https://api.steemit.com) or any of the others, there is a character limitation of 2000 characters for a custom JSON operation. If you're working with Steem Engine or any other dApp which uses custom JSON operations, you've probably encountered this issue before.
While the list of public Steem nodes has dwindled sadly in the last year or so, there is one being run by @anyx (who is an absolute legend and deserves a witness vote from you) which has a more generous character limitation in custom JSON operations of 8192 characters.
If you're using the steemit-js library you can set the API to the Anyx endpoint like so:
steem.api.setOptions({
url: 'https://anyx.io'
});
Recently, I did an airdrop for the @steemspeak token (you might have got some) it went out to over 15,000 users. Using the Steemit API, the airdrop could only drop tokens to approximately 6 users every three-seconds (as per Steem block time). Using the Anyx node, that number increased to approximately 28 users per three-second block. A four-and-a-half increase in the number of users that can be airdropped per block.
As always, never rely solely on only one node. Always have a few in a list you failover to incase one goes down. But the Anyx node has been incredibly reliable and an absolute lifesaver/timesaver.
Also, while I have your attention. Steemit recently published a post discussing changes to custom JSON operations in hard-fork 21 here. If you build dApps, please go leave a comment saying you support making the limits more generous. They're proposing five operations per block (which would help immensely).
How do these limits effect RPC node ram and witness consensus ram use? Is their any data about this or testing that was done?
Those are actually really good questions. I personally don't have the information on hand to answer them, but I would be interested in knowing as well what the difference is between 2000 and 8192. I am guessing @anyx might know.
The 2000 character limit is a seemingly arbitrary limit enforced by 'jussi', Steemit's API middleware. Most other node operators use this middleware.
Since I've been building my own middleware, I'm not restricted by Steemit's jussi implementation details, only by the blockchain limits.
custom_json ops don't affect the ram usage of consensus. These ops are simply validated and placed into the block log -- stored on disk. It's up to any second layer solution to determine what (if anything) to do with the data; the witnesses have only validated the account truly signed it and at what time, nothing about the content.
Depending on how the second layer (e.g. Steem engine) interprets the data, it could affect the ram usage of an operator in that layer. So they are the ones that must be careful with their design.