As a developer working with Rust on Cipher, I’ve encountered limitations when using storage cells, specifically with the get and set commands. The current implementation requires downloading the entirety of a list (Vec, Hashmap, etc.) as well as uploading it in its entirety after modifications. I find the limited availability of options in this regard to be very inefficient.
To enhance the SDK’s efficiency, I suggest adding more functionality to storage cells, allowing on-chain parsing and data manipulation. This would enable developers to access and modify specific indexes or keys directly, without having to handle the entire dataset.
This is unfortunate as Oasis is currently the only blockchain I have discovered that has enough promise to allow developers to create sophisticated applications. But as it stands this lack of functionality is insurmountable for my current project. These improvements would make Oasis a more robust and efficient platform for developers and I look forward to discussing this further with the community and the Oasis team.
Thanks for trying out Cipher. Yes, the raw storage cell type is backed by a single key/value pair in the storage trie so using a single cell to store larger collections is not the most efficient (as you mentioned due to the entire value being serialized/deserialized on each read/write).
If you want to store maps, there is already a PublicMap/ConfidentialMap type available in the oasis_contract_sdk_storage crate. There is currently no equivalent for lists/vectors but it shouldn’t be that hard to add.
Unfortunatley there is currently not a lot of documentation for the contract SDK, but until this is improved, you can look at the hello contract example from the SDK test suite for some examples.
Also note that some of the contract SDK APIs are currently a bit rough and need to be improved, especially those around cross-contract calls. Further improvement suggestions are obviously very welcome!
Thank you for the reply and for pointing out the map. That will definitely solve the issue I was having with map inefficiency. It would still be great to handle lists/vectors more efficiently. However, this map might be enough for me to continue in my project with a few workarounds of my storage types. I look forward to seeing the future developments of Oasis!
This would provide developers with more flexibility to access and modify specific indexes or keys directly, without the need to handle the entire dataset, which can improve performance and reduce unnecessary data transfers. Oasis’ blog can also keep you up-to-date with news, so keep an eye out.
I completely agree that the availability of options for storage cells is essential for efficient development, and your suggestion to add more functionality to storage cells is a step in the right direction. The ability to parse data directly on-chain will undoubtedly enhance the efficiency of the SDK and enable developers to access specific indexes or keys without downloading the entire dataset.
I encourage everyone to continue sharing thoughts and suggestions with the Oasis community and the team. Your input and feedback will help shape the future of Oasis, making it a more robust and efficient platform for developers.
Yes, it is possible to access some information about the environment throught the Context which is usually available as ctx on the various contract methods. To get the environment use ctx.env() (see the example hello contract), specifically for the round/epoch/timestamp you can do something like:
match ctx.env().query(QueryRequest::BlockInfo) {
QueryResponse::BlockInfo {
round,
epoch,
timestamp,
..
} => { /* do something with round, epoch, timestamp */ },
_ => { /* query failed */ },
}