Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Send file uri as bytes32 instead of string? #29

Closed
greenlucid opened this issue May 29, 2022 · 1 comment
Closed

Send file uri as bytes32 instead of string? #29

greenlucid opened this issue May 29, 2022 · 1 comment

Comments

@greenlucid
Copy link
Contributor

Currently, stake-curate emits _fileUri according to the ethereum/EIPs#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.

@greenlucid
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant