Closed dima74 closed 1 month ago
Does it mean that data required for key would be doubled?
Also why not use enum to represent key state?
struct PublicKeyLazyInner {
algorithm: Algorithm,
state: PublicKeyLazyInnerState,
}
enum PulicKeyLazyInnerState {
Uninit(Vector<u8>),
Init(KeyInner),
}
Would require some interior mutability to initialize in otherwise immutable methods.
Does it mean that data required for key would be doubled?
Also why not use enum to represent key state?
My original proposal is optimized for the assumption that PublicKey
inside WASM in almost all cases is used only for comparisons. So if we add Box
:
struct PublicKeyInnerLazy {
algorithm: Algorithm,
payload: Vec<u8>,
key: OnceCell<Box<PublicKeyInner>>,
}
then in case PublicKeyInner
is not needed, we will have even less memory consumption then now (unitialized OnceCell gives 8 bytes overhead). Do you know how often we need actual PublicKeyInner (that is some signing functionaligy) inside WASM?
Do you know how often we need actual PublicKeyInner (that is some signing functionaligy) inside WASM?
I'm not aware of such cases actually.
In case of single peer tps performance, >60% of time takes WASM call for transaction validation, and most of time inside WASM takes
PublicKey::decode
/PublicKey::from_bytes
(https://github.com/hyperledger/iroha/issues/4727#issuecomment-2329677940). However inside WASM public key is used mostly for comparison (==
). Comparision can be performed without deserialization, so I propose to make deserialization lazy inside WASM. In particular adding wrapper like this forPublicKeyInner
:Background: why
PublicKey::from_bytes
is slow. Consider call ofPublicKey::from_bytes
withAlgorithm::Ed25519
and 32 bytes payload. The result of this call will beed25519_dalek::VerifyingKey
:VerifyingKey::point
is obtained fromVerifyingKey::compressed
using operations likesquare
,pow2k
fromcurve25519
crate.cc @mversic @Erigara