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
As discussed in #90 and this previous bug on geth, the message prefix should be encoded using a variable length integer.
I'm learning as I go, but as far as I understand, this is because ascii decimal encoding presents the issue that ...\n12... is ambiguous. Is it length 1 with value 2, or 12. And that using a varuint encoding fixes this.
our implementation in a sense uses this approach..
the parser reads the first digit and checks if it matches the remaining data len, if not, it moves to the next digit, and now reads both as a len, and check if it matches the remaining data len and so on.
but we can adjust to use this new approach, which is faster than read, check, advance and check again..
As discussed in #90 and this previous bug on geth, the message prefix should be encoded using a variable length integer.
I'm learning as I go, but as far as I understand, this is because ascii decimal encoding presents the issue that
...\n12...
is ambiguous. Is it length1
with value2
, or12
. And that using a varuint encoding fixes this.Stacks.js implementation using this encoding
🔗 zboto Link
The text was updated successfully, but these errors were encountered: