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
We have the following tuple examples in the LSP2 standard:
These examples are valid and work both ways - encoding and decoding.
But using tuples like (address,bytes,string) or (bytes,bytes,bytes8) or anything where we have a dynamic type in any but the last position will not work because values are just "glued together".
And even though we can make this (bytes,bytes8) work by taking last 8 bytes as bytes8 and the rest as bytes it doesn't make sense when it comes to implementation of deocding.
Example:
type = (bytes,string)
values1 = (0xcafe,"not really a cafe, is it?")
values2 = (0xbeeeeeeeeeeeeeef,"some people just love it")
... doing encoding ...
values1Encoded = 0xcafe6e6f74207265616c6c79206120636166652c2069732069743f
values2Encoded = 0xbeeeeeeeeeeeeeef736f6d652070656f706c65206a757374206c6f7665206974
/// ERROR: where in these long blobs the first values start and the second end?
decodeLsp2Values(type, values1Encoded)
decodeLsp2Values(type, values2Encoded)
I suggest we either fallback to using Solidity's way of encoding tuples or add the same 2 bytes for the length of each value (as we have in the CBAs) in the tuple, or even better we use the following idea suggested by @skimaharvey: #172 (comment)
The idea is to have 1 byte that will hold the length of the length of the element, the next 1 or more bytes that describe the length of the element and the next 1 or more bytes should be the element itself:
Using that idea tuples will be encoded in the following manner:
type = (bytes,string)
values1 = (0xcafe,"not really a cafe, is it?")
values2 = (0xbeeeeeeeeeeeeeef,"some people just love it")
... doing encoding ...
values1Encoded = 0x01 02 cafe 01 19 6e6f74207265616c6c79206120636166652c2069732069743f
values2Encoded = 0x01 08 beeeeeeeeeeeeeef 01 18 736f6d652070656f706c65206a757374206c6f7665206974
/// No errors as we know the length!
/// And it only takes in most cases `2 * tuple.countOfNestedTypes` bytes more per 1 tuple
/// Where `countOfNestedTypes` is the number of types you declare within parentheses `()`.
decodeLsp2Values(type, values1Encoded)
decodeLsp2Values(type, values2Encoded)
The text was updated successfully, but these errors were encountered:
We have the following tuple examples in the LSP2 standard:
These examples are valid and work both ways - encoding and decoding.
But using tuples like
(address,bytes,string)
or(bytes,bytes,bytes8)
or anything where we have a dynamic type in any but the last position will not work becausevalues are just "glued together"
.And even though we can make this
(bytes,bytes8)
work by taking last 8 bytes asbytes8
and the rest asbytes
it doesn't make sense when it comes to implementation of deocding.Example:
I suggest we either fallback to using Solidity's way of encoding tuples or add the same 2 bytes for the length of each value (as we have in the CBAs) in the tuple, or even better we use the following idea suggested by @skimaharvey: #172 (comment)
The idea is to have 1 byte that will hold the length of the length of the element, the next 1 or more bytes that describe the length of the element and the next 1 or more bytes should be the element itself:
Using that idea tuples will be encoded in the following manner:
The text was updated successfully, but these errors were encountered: