Smaller integer types for storage

[dmgr]

What is the smallest amount of bits FATE/Sophia needs to reserve for int type? I couldn't find the answer here:

• https://aeternity.com/aesophia/master/sophia_features.html#types
• https://github.com/aeternity/aesophia/blob/lima/docs/sophia.md

If the answer is 256-bit, would it be possible to introduce smaller integer data types? So additionaly to the current int (256-bit with an arbitrary-size I guess) we could have for example those types:

• tiny - 8-bit integer
• short - 16-bit integer
• vint/varint/bigint - 16-bit? 32-bit?, 64-bit? (whatever you think is appropriate here) with an arbitrary-size

As we know, both computation and data storage blockchains is an oil digital economy and its costs for will skyrocket.

Just to give you an example why it is important, in Decentraland you can be an owner of LAND. If you bundle your lands together, you will form an ESTATE. The function declaration that creates the estate in Solidity is:

Function: createEstateWithMetadata(int256[] x, int256[] y, address beneficiary, string metadata) ***

The coordinates are 256-bit integers, but could easly be 16-bit integers. Why? Because Decentraland coordinates x or y are between -150 and +150. NB they could be 8-bit if the map were 256 LANDS wide and long.

You can inspect data call to the aforementioned function here: https://etherscan.io/tx/0xfebf5061308a13434df10047e40429c6c913d63e2561648137492853307d9e6b Note, that the transaction cost that bundles 20 LANDs together was around 355 USD on that time.

Reference and inspiration: https://twitter.com/VitalikButerin/status/1433255593683259398

[UlfNorell]

The answer is 8 bits. See here: https://github.com/aeternity/aebytecode/blob/master/src/aeb_fate_encoding.erl#L60

[dmgr]

OK, that is interesting. So following that definition:

-define(SMALL_INT , 2#0). %% sxxxxxx 0 - 6 bit integer with sign bit

FATE/Sophia will use:

• 1 byte to hold an integer between <-64, 63>
• 2 bytes to hold an integer between <-8192, 8191> (and ouside the above range)
• 3 bytes to hold an integer between <-1048576, 1048575> (and ouside the above range)
• 4 bytes to hold an integer between <-134217728, 134217727> (and ouside the above range)

Is that correct?

[hanssv]

The FATE serialization is also described (outside code!) here: https://github.com/aeternity/protocol/blob/master/serializations.md#integer

So, 1 byte for integers [-63 ... 63], and for larger integers it is one byte plus the RLP encoding of that integer. Code is here: https://github.com/aeternity/aebytecode/blob/05dfd7ffc7fb1e07ecc0b1e516da571f56d7dc8f/src/aeb_fate_encoding.erl#L329

FATE have arbitrary precision integers and the serialization matches that.

[dmgr]

@hanssv Right, I have corrected my previous commment according to your note. Personally in general purpose language I would prefer more efficient coding using at least 16-bit (probably 64-bit) with an arbitrary-size integers. In terms of specialized blockchain purpose language the 8-bit or 16-bit integers with an arbitrary-size are the best fit IMO. The FATE integer implementation is certainly more appropriate than what we have in Ethereum's Solidity currently.

[hanssv]

I can't remember how RLP works, but some quick tests suggests that:

• 1 byte [-63 .. 63]
• 2 bytes [-191 .. 191]
• 3 bytes [-319 .. 319]
• 4 bytes [-65599 .. 65599]
• 5 bytes [-16777279 .. 16777279]
• ...

Yes, it is a reasonable tradeoff, I think.

[UlfNorell]

Note that this is the storage format, not the in-memory representation during execution. During execution numbers are represented by the Erlang runtime, which (of course) uses 64-bit words for numbers (see http://erlang.org/doc/efficiency_guide/advanced.html).

[dmgr]

Good point @UlfNorell. This was also something I wondered about.

If that is a storage format, is there a theoretical possibility to change it in the future? Or FATE/Sophia smart contracts might be affected by that change? Do the smart contracts have a direct access to the RLP encoded binary representation of integers? If not, that should be a thrivial to change that storage format if such requirement arise in the future. Or for example when the protocol would be reimplemented in another language and somebody decides to use different storage format.

Can we say that the storage representation is something that FATE/Sophia has no access to and is a level of abstraction that can be implemented differently in another protocol implementation?

I am just courious ;)

[dmgr]

I thought about my question, and I think the FATE/Sophia is aware of storage format because it probably is used to prepare a functions (entrypoints) call data and functions (entrypoints) return data.