zommuter
commented
1 month ago One option could be to go with an on-chain database but make committing there optional. It could be delegated to other users, who in exchange for their gas would receive e.g. an ERC-20 as compensation that non-committing users have to pay in exchange. Then we have to take care of tokenomics though and potentially end up with over-engineering a gas substitute that has no actual benefits but makes matters more complicated... But a donation/subscription/... system could be implemented that way :thinking:
When e.g. tagging other users or referring/reacting to other messages, the most gas efficient way is to store as little data as necessary on chain, e.g. just the
@usernamein the message itself. But since we want to be able to network things such as notifying mentioned users, linking to reactions etc. the client would have to crawl through all messages to rebuild this database locally, rendering the app tediously slow after long disconnects with high activity in between.Instead, such a database can be stored on a centralized server (or multiple independent providers), but that defeats the purpose of decentralization. Using a decentralized kind of storage such as IPFS instead requires a validation mechanism, and we basically end up with a side-chain / L2 or similar.
Finally, the database itself could also be stored on the chain directly. The smart contract itself could take care of validation, but depending on its (im)mutability bugs might become impossible to fix efficiently if at all. Even if designed properly, this would however increase the gas costs for the users since they'd directly update (technically redundant) database entries.