You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Look, I'm going through NEAR for the first time and kindly request an update to the following claim from your docs as the logic argument is fundamentally flawed:
"If you’re familiar with Ethereum’s pricing model, you may know that, like NEAR, the protocol charges a fee (called "gas") for each transaction. Unlike NEAR, Ethereum's gas fee accounts for the amount of data stored via that transaction. This essentially means that anyone can pay once to store permanent data on-chain. This is a poor economic design for at least two reasons: 1. The people running the network (miners, in the case of Ethereum 1) are not appropriately incentivized to store large amounts of data, since a gas fee far charged in the distant past can increase storage costs forever, and 2. The users of a smart contract are charged for the data they send to store in it, rather than charging the owner of the smart contract."
How can there be a claim of something being better when the "solution" introduces several critical issues:
Created an obvious DoS attack surface by making contract deployers responsible for storage costs
Completely ignored the concept of public goods - smart contracts that intentionally have no owner
Prioritizing miners/validators over actual users. How exactly does the NEAR ecosystem grow with this model?
Near claims to be a developer-friendly network, but that's far from reality. For perspective: I'm an Ethereum dev, and it's taking me more than 24 hours to get FastAuth working due to incomplete docs. Meanwhile, Aptos has implemented keyless login and other developer-centric features that put them far ahead and now I have to bother about paying contract storage.
Describe the solution you'd like
The current storage model and documentation need revision. Simply remove the Ethereum storage model comparison and focus on explaining NEAR's storage staking mechanism on its own merits - criticizing Ethereum's model while describing a DOS vulnerability in your system isn't the best look. Instead, revise the documentation to emphasize user-paid storage as a usable pattern, with contract-paid storage presented by the side. This would better align with NEAR's storage staking mechanism, promote more sustainable protocol design, and better support the claim of being "developer-friendly."
Is your feature request related to a problem? Please describe.
Look, I'm going through NEAR for the first time and kindly request an update to the following claim from your docs as the logic argument is fundamentally flawed:
"If you’re familiar with Ethereum’s pricing model, you may know that, like NEAR, the protocol charges a fee (called "gas") for each transaction. Unlike NEAR, Ethereum's gas fee accounts for the amount of data stored via that transaction. This essentially means that anyone can pay once to store permanent data on-chain. This is a poor economic design for at least two reasons: 1. The people running the network (miners, in the case of Ethereum 1) are not appropriately incentivized to store large amounts of data, since a gas fee far charged in the distant past can increase storage costs forever, and 2. The users of a smart contract are charged for the data they send to store in it, rather than charging the owner of the smart contract."
How can there be a claim of something being better when the "solution" introduces several critical issues:
Describe the solution you'd like
The current storage model and documentation need revision. Simply remove the Ethereum storage model comparison and focus on explaining NEAR's storage staking mechanism on its own merits - criticizing Ethereum's model while describing a DOS vulnerability in your system isn't the best look. Instead, revise the documentation to emphasize user-paid storage as a usable pattern, with contract-paid storage presented by the side. This would better align with NEAR's storage staking mechanism, promote more sustainable protocol design, and better support the claim of being "developer-friendly."
Additional context
Storage staking docs.
The text was updated successfully, but these errors were encountered: