You are viewing a single comment's thread from:
RE: Steem 19.10 Officially Released: AppBase, RocksDB, Unlimited Content Editing, and More!
Sounds like it will be pretty weighty on the db, except the previous transaction is deleted (to avoid redundancy) and mapped on to the new block. The exception means details of old transaction will have to be watched for consistency and relationship with the new post (to avoid crazy hacks, eg someone getting an unfair reward or bugs like losing rewards or unfair reward distribution).
Well, I'm only thinking my stupidity out loud, I know the Steem engineers have it all in control (hopefully).
I was just breaking down how the process worked clearly, for explanation's sake. To do the same with these concerns in a way that will hopefully help:
Bloat is real. Multiple edit transactions can certainly add up. So do the thousands of tiny transfers with memos, or ten times a day auto-posting of 'different' content... to the blockchain, ten edits to an old post and ten similar length new posts look basically the same. This is where we need to be cognizant of how we're using the chain and the outcome of our actions — that's the user end of the scaling!
Since each edit is considered authoring, it's important to note that bandwidth restrictions and resource credits come into play. For example, when bandwidth was strained earlier this year, people would edit and then not be able to post again for the day. They were not realizing that their bandwidth was re-balancing as if they had posted multiple blogs... many people don't understand that each edit is an authored post and then run into trouble with their resource allocation. This does show that the chain has some considerations for this situation. You can find out more in a previous blog, here: https://steemit.com/bandwidth/@steemitblog/blockchain-update-2-hf20-progress-and-bandwidth-changes