You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Whitepaper, section 7.2 talks about the minimal packet size. Smallest possible packet is
20 byte (160 bit) last valid hash counter (ripemd of the sha)
8 byte counter
2 byte flags and payload size
20 byte to address (ripemd(sha256(public key)))
8 byte amount
8 byte fee
32 byte public key used to sign
https://github.com/solana-labs/solana/blob/master/src/signature.rs#L10
64 byte signature
20 + 8 + 2 + 20 + 8 + 8 + 32 + 64 162 bytes.
14 left over bytes. Realistically we will likely keep the hash counter to 32 bytes, just to speed up processing, so thats 2 left over bytes + ethernet framing etc... We may or may not need a dynamically sized counter for how long this transaction is valid for (or fixed amount from last valid hash)
——————————————
Theoretically we could shrink it further
20 byte (160 bit) last valid hash counter (ripemd of the sha)
1 byte flag
20 byte to address (ripemd(sha256(public key)))
1 byte amount, depends on flag
1 byte fee, depends of flag
32 byte public key used to sign
64 byte signature
——————————-
Basically keep the amounts dynamically sized based on flags and drop the counters. I think the gains are minimal, but increases the format complexity
ideally just keep them in sync with what we have in the code
The text was updated successfully, but these errors were encountered:
section 7.2 the table is out of sync
ideally just keep them in sync with what we have in the code
The text was updated successfully, but these errors were encountered: