RFC on-chain storage

[gregLibert]

On-chain storage

Normalization of binary storage in the Massa's datastore.

Introduction

Context

Storing data in the ledger for a given address is one of the functionalities proposed by the Massa blockchain.

Currently, the Massa's API exposes a key/value set by address where:

• keys are 256 bits hash value,
• values are byte arrays.

Motivation

Sharing the same convention to interact with stored data will make content rendering easier and reduce heterogeneity.

Scope

This RFC will only describe the storage envelope, not the content itself.

Storage conventions

Key

The following keys are reserved values:

key	hash	Content
Domain name resolution	4226d14bcb58e71c97b4ef6415c6b73471dfe40f42d42f13f72b4b3fedca4473	Used to resolve a domain name to a Massa address.
Proprietary	b904752a04b46e2865b8ea090d74154509bad4f2c84dde3326dc916efc2c58ad	Used to store data in a proprietary format.
Smart contract	f5674ec173cb2c99babcbf807a717dab78abd3e87f340d42bfd6bb73722c43ac	Used to store a smart contract. See #2642 for details.
Website	b5a229ac8becc6035511f432ca6018f581f0627233eada6ae8e12b505d44af7f	Used to store a web site on-chain.

Note: this list will be extended as the use cases evolve.

Value

Each value is structured as follows:

• Version
  This field (one byte) specifies which version of the storage convention is used to store the data. At the moment, 0x00 shall be used.
• Content
  Binary data (byte array). For more information, please refer to the RFC describing the format in question.

Note: When possible the TLV protocol, with the Type field encoded in 2 bytes and the Length one encoded in 3 bytes, should be used.

[sebastien-forestier]

I don't understand what "Domain name resolution" is used for

[gregLibert]

Instead of using DNS, which is a loaded term IMHO, I used Domaine name resolution to refer to a specific step of DNS process : address resolution.

The use cases that I have I mind are

• using friendly name in URL (e.g. massa://gol)
• using friendly name in credit transfer (e.g. I want to send massa to sebastien-forestier)

Without this kind of functionality, addresses must be used...

[damip]

the problem is that the "lookup" direction is not right: we need an index that matches a domain name to an address. In this proposal, it's the address that's matched to the domain name

[gregLibert]

OK, I just understood the source of the misunderstanding : this RFC is about describing storage envelope, not the content itself.

DNR and website are ones of many possible contents. I could have proposed media (video, image, sound), documents ... and reserve a specific key to identify each one.

So to answer your question @sebastien-forestier , DNR details should be defined in another RFC. This is also true for website by the way.

[sebastien-forestier]

Like this it seems like everyone can choose the same domain name

[damip]

One thing missing is the capability to store bytecode. See: #2642

[gregLibert]

Can you clarify bytecode ? Is it a smart contract executable by the node using CallSC or some random code that can be downloaded and executed in a browser ?

Should we differentiate programming language at this level (one key for WebAssembly, another for js...) or simply use executable at this level and use tags to differentiate them ? I do have a preference for option 2.

[gregLibert]

Description updated with the Smart contract key.

[gregLibert]

I try to clarify the scope of this RFC by adding:

• a scope
• a direct reference to additional RFC in Content field

@damip is it more intelligible?

[damip]

yes, it's clear to me now :)

So for info, the table in the "key" subsection is given only as a list of random examples of reserved keys, it has no face value