#Alternatives to abi.encode()
12 messages · Page 1 of 1 (latest)
env.crypto().sha256() for hashing (keccak support is planned for the next release). not sure what is abi.encode
what about for dehashing?
not sure what is this
if you have some good descriptions of the use cases and pointers to to e.g. solidity docs, it would be useful to open issues requesting these fns here: https://github.com/stellar/rs-soroban-env/issues . our support for the crypto host functions is really limited now and it would be useful to gather requests, especially if there is some explanation for why is that important (e.g. sha256 is enough for most hashing-related tasks, but you may want keccak256 for eth bridging or a stronger algo)
@potent obsidian can you describe your use case for an encoder? Soroban doesn't (yet) have any host functions for encoding/decoding. For now, you can import a 3rd party rust library for that purpose (but it will have to play well with no_std).
@tiny spire experimented with using borsh here: https://github.com/stellar/rs-soroban-sdk/pull/791/files
I think that keccak is often used to transmit signed messages and not just hashing.
Abi.encode it the byte representation of the calls/interaction with the contract, it could be represented by ScVal or RawVal in soroban.
There are some use case like for proxies or diamonds where you implement a fallback() function and directly read the calldata to perform contract call routing.
I think that keccak is often used to transmit signed messages
not sure what does this mean, keccak and sha256 have exactly the same interface, don't they? so the implementation difference would matter only if you work with systems that expect one or another, or if you care about a 'safer' algorithm (though stellar is already very sha256 dependent, so not sure if there are significant gains here; I'm not an expert here though)
in terms of proxies etc. I'd rather look at the needs opn per-use case basis then, since these concepts don't really apply to soroban
right sorry, I confused it with the ethereum signature...
I feel safer in soroban thanks to the fact that those concept of memory manipulation and assembly where you can mess up with the data