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
Currently storage price: 1N for 10kb. Average contracts 300kb that requires 30N
The suggestion to reduce storage fee by 10x: 100kb for 1N => making average contracts 3N
Reasoning: storage right now ends up being very expensive for contracts like multisig and we want to reduce it to manageable. In Ethereum contract byte code is usually 10x smaller.
For comparison with Ethereum:
Current prices are 40-70 GWei
Current ETH price ~$240
Storage price (spent): 6,400,000 gas per 10 kb. At current prices: 0.256 - 0.448 ETH. $61.44 - $107.52
Storage price (spent) for contract byte code: 200 gas per byte, 2,048,000 gas per 10kb. At current prices: 0.08192 - 0.14336 ETH. $19.66 - $34.40
Currently our storage will need to lock 1N at $0.4, but if NEAR price appreciates 100x it will be: $40
Proposed cost will 0.1N at $0.04, and if appreciates 100x it will be $4.
Given our contracts are 10x larger in bytecode, we currently 50x cheaper and will be roughly the same price if price grows.
Note, that even though this locks NEAR instead of burning it when storing - in many cases the NEAR won't ever be returned to the payer because it will be securing data going forward.
Ref #92 for transaction pricing changes and original discussion.
The text was updated successfully, but these errors were encountered:
Currently storage price: 1N for 10kb. Average contracts 300kb that requires 30N
The suggestion to reduce storage fee by 10x: 100kb for 1N => making average contracts 3N
Reasoning: storage right now ends up being very expensive for contracts like multisig and we want to reduce it to manageable. In Ethereum contract byte code is usually 10x smaller.
For comparison with Ethereum:
Note, that even though this locks NEAR instead of burning it when storing - in many cases the NEAR won't ever be returned to the payer because it will be securing data going forward.
Ref #92 for transaction pricing changes and original discussion.
The text was updated successfully, but these errors were encountered: