Currently, stake-curate emits _fileUri according to the https://github.com/ethereum/EIPs/issues/1497 that sends strings such as /ipfs/{hash}/{file}.
This is not efficient. Strings like this will usually take 4 32-byte slots of calldata, as they require to keep track of the length of the string, plus the string is long by itself, usually requiring 3 slots.
The Evidence standard will likely not be refactored any time soon. However, stake-curate off-chain item data handling doesn't necessarily require passing the _fileUri according to this standard, it could simply continue using ERC-1497 compliant strings for Evidence and MetaEvidence, but use a custom scheme for items.
The issue with this implementation is that, I haven't seen any examples of this in practice, and asking around IPFS I still got no guarantees it's even possible. Taking rollup cost reduction into account, this optimization may come in too early, so it could be kept around for a newer version. It is also possible that ERC-792 and ERC-1497 standards become refactored in the future for gas optimization.
If these standards worked like that, calldata would be cut by half, which may be the bottleneck in the next few years. So this should be kept in mind.
Might be in consideration for future versions of Stake Curate. For now, just discard the idea in its current state, since it's feasibility is unknown and the compressed ipfsUri could be acceptable
Currently, stake-curate emits
_fileUri
according to the https://github.com/ethereum/EIPs/issues/1497 that sends strings such as/ipfs/{hash}/{file}
. This is not efficient. Strings like this will usually take 4 32-byte slots of calldata, as they require to keep track of the length of the string, plus the string is long by itself, usually requiring 3 slots. The Evidence standard will likely not be refactored any time soon. However, stake-curate off-chain item data handling doesn't necessarily require passing the_fileUri
according to this standard, it could simply continue using ERC-1497 compliant strings forEvidence
andMetaEvidence
, but use a custom scheme for items.The issue with this implementation is that, I haven't seen any examples of this in practice, and asking around IPFS I still got no guarantees it's even possible. Taking rollup cost reduction into account, this optimization may come in too early, so it could be kept around for a newer version. It is also possible that ERC-792 and ERC-1497 standards become refactored in the future for gas optimization.
If these standards worked like that, calldata would be cut by half, which may be the bottleneck in the next few years. So this should be kept in mind.