Proposal for State Blocks v7

[rkeene]

Currently state blocks have a prefix of ((uint256_t) 6), let's call them "State Blocks v6" for the purpose of this post.

I would like to propose an updated version of state blocks called "State Blocks v7" with a prefix of ((uint256_t) 7) that supports extensions -- similar to the difference between X.509v1 and X.509v3.

Similar to X.509v3 extensions, State Blocks v7 extensions should be either critical or not critical. Critical extensions will be validated and validation will be dependent upon their contents being verified. Non-critical extensions will be validated only as far as their syntax for that extension, but otherwise the block will be validated just as if the extension had not been present. Critical extensions are normative, while non-critical extensions are informative.

Extensions will be signed parts of the block.

A simple tag-length-value (TLV) encoding is proposed as follows:

struct extension_item {
        uint1_t critical;
        uint7_t tag;
        uint8_t length;
        bytes   value[length];
}

A maximum of 256 bytes should be available for all extensions in a given State Block v7.

[kayabaNerve]

Where would this be used?

How many extensions would be critical versus non-critical?

Isn't there a risk this becomes like XMPP, where the protocol is good but the extensions are out of hand?

Wouldn't this end up being used for raw data transmission, with tags just being a form of app ID?

Wouldn't the critical extensions break consensus often? If 30% of nodes don't recognize it, but 70% do, then 30% of nodes are out of the consensus unless they ask for a vote.

Just asking questions to try to further this idea ;)

[inkeliz]

If I understand correctly, each block will have 327 bytes for arbitrary data (link, representative, tag and value)? That is amazing. The size of the block will be 480 instead of 216, it's not a problem?

What's the point of "critical" and "not-critical"? What is the use cases of this extensions? In my mind it can be used to identify payment by id or use to set alias on "Open Block", that's the ideia?

[rkeene]

There would be 127 (0x7f) tags, all of which could be critical or not critical. I currently believe that given the constraints imposed on the extension system that extensions would be used sparingly in a fashion similar to X.509v3 extensions.

It would certainly be possible for tags to be used to transmit arbitrary data using a non-critical extension, however it will likely be the case that non-critical extensions will have further restrictions placed on them before this proposal is fully fleshed out.

Extensions in general are a way to expand the functionality beyond what was initially planned for. One such example is epoch blocks. An extension would have made more sense for epoch blocks, but no such mechanism was available.

Critical extensions are extensions which require adoption before being adopted by the network. If the majority of the weight of the network does not adopt these blocks they will not get confirmed by nodes nor inserted into ledgers. One example use case for a critical extension would be to handle spam in a different manner than proof of work (see #1064) or to specify that the proof of work algorithm has been altered (this one may also be non-critical, if you provided a proof of work that validates for both algorithms).

Non-critical extensions are extensions which can be adopted more quickly because they do not violate any existing semantics. An example of a non-critical extension usage would be to indicate a block's proof-of-work difficulty has been increased beyond the baseline, which could be used for prioritization in the case of a full or nearly full work queue.

Critical extensions work with the consensus algorithm just like any validation change the blocks must be validated by a majority of the network weight before they can be accepted.

Non-critical extensions are more likely to cause problems because their meaning may change over time -- a block submitted with an undefined extension may validate, and later that extension may be defined with semantics that do not comply with the data that was accepted in that block. Due to "bandwagon voting" this won't cause an immediate problem but over time the block may need to be re-validated by new representatives. This is why non-critical extensions may have more restrictions placed upon them, such that blocks that have been accepted into the ledger will always continue to be accepted.

[kayabaNerve]

Each block is currently 216 bytes and would be expanded 257 bytes by this to 473 bytes (for one extension). 255 bytes can be used for data, but data can be written to the value via stenography. You can also get bytes out of representative (IIRC), but I don't think you can out of the link field. Maybe...

A non critical is valid, one is invalid. I assume it's for on-chain extensions such as 'timelock'.

Wouldn't tags overlap quickly if used by apps?

Should Nano expand to handle data?

[rkeene]

Extension identifiers (tags) would be managed by the community and consensus would prevent using them incorrectly -- just as the rest of the block, for critical extensions.

For non-critical extensions there may be a mechanism for mapping an extension to its format, so that it nodes can verify their syntax, even if they cannot verify their semantics.

For example a timestamp extension could be created with the identifier 0. A State Block v7 that contained this extension as non-critical would be indicating the time-of-block-on-creator an informative manner. A State Block v7 that contained this extension as critical would be indicating the time-of-block-on-creator in a normative manner. In the non-critical case, the timestamp information would not be used for anything related to validation, while in the critical case a validator could look at the timestamp and do something related to it.

[rkeene]

I have updated the initial description to make this the distinction between Critical and Non-critical, which diverges from X.509v1/X.509v3 in exact meaning.

[kayabaNerve]

I think this complicates the protocol, could fragment consensus, and brings data into Nano when Nano focused on handling payments, and did that really well. I would like Nano to stay for payments only than experimentally branch out, lowering how well it handles existing parts.

[inkeliz]

I don't know if the extensions make sense, only the arbitrary data and similar uses can take real advantage. Because seems that the effort to support a new extension is higher (or equal) than create a new block with the same behavior.

If had some time-of-block-on-creator, it maybe can use a specific block with this field, say a “StateBlock with Time”, with other id rather than 6. So, only updated nodes will understand this block, but nodes that are bootstrapping will follow the rules of this block, without any conflict. The only situations when the extensions seem useful is when multiples extensions are used together, however the size became a problem.

[rkeene]

The advantage over creating a new block with the different behavior versus an extension is that the block parsing libraries would understand how to break down the block format for State Blocks v7, the same way X.509v3 parsing libraries do.

If a new block format were used for every extension, then parsing libraries would have to support these new versions ad-hoc, rather than allowing for a single parsing library to handle all extensions.

[kayabaNerve]

You'd still have to say what to do with the data. This means it doesn't throw a parsing error, but rather throws an error when it tries to handle it. Of course, I like the Universal setup and since there are non-critical extensions you don't always need to handle it. I'm just commenting this doesn't completely solve the issue.

[rkeene]

Extensible blocks could be also used for #1150

[dbohdan]

I come to this discussion from a very different angle: I am interested in decentralized means of exchanging messages between cryptographic identities. My knowledge of Nano is limited to reading the whitepaper and some discussions of it and asking @rkeene a few questions on #tcl, but perhaps my perspective will be useful.

If Nano had the ability to attach arbitrary data to a transaction, it could become a basis for distributed applications. Building on top of it would take care (at least in part) of two major difficulties associated with developing distributed applications: user identity and reliable P2P networking. Nano in particular is attractive because it has existing peers to route the messages for you. Most cryptocurrencies are not suited for this due to the scalable transaction costs. (Nobody wants their chat app suddenly to get expensive because Foocoin is soaring.) Messaging of this kind does not need a separate extension per application. It would be enough to let one user send raw bytes to another with a transaction and leave it up to the users' applications to interpret them.

However, implementing this may be contrary to Nano's goals as a cryptocurrency. If successful, it will create a large volume of low-amount transactions whose purpose is not the exchange of money, but of information. It may also attract malicious uses, such as botnet command and control. How it would affect the peer network requires economic analysis.