Upcoming breaking changes on the ledger and versioning

[damip]

Intro

This document lists the upcoping breaking changes on the ledger, how to version it, and things that might hamper keeping the ledger from one testnet to the next.

Ledger entry versioning

All entries in the ledger should have a version field so that they can be versionned. That way, switching to native DNS in the future will be simpler.

Datastore/Bytecode unification

There is a lot of code duplication between datastore management and bytecode management in the ledger.
The idea is to remove the bytecode field in accounts and have only the datastore. For each datastore value, have:

• a flags byte with two bits for now:
  • immutable: if 1, this entry cannot be changed/deleted
  • executable: if 1, contains bytecode that can be executed within the context of the account by external callers

Bytecode versioning

Bytecode always starts with a version number indicating which virtual machine to use for execution

UPDATE: Decisions made

• bytecode / datastore unification will not be done now
• immutability flags on specific ledger entries will be implemented
• immutability flags on the bytecode will be implemented
• byecode versionning needs to be implemented

[AurelienFT]

So the unification datastore bytecode is decided and we will do it ? (in near future ? this month ?)

Very short term for having a persistent ledger by the end of the month:

• Version byte in front of each ledger_db entry.
• Version byte before the bytecode
  (Just to confirm)
  cc @Leo-Besancon and @sydhds

[damip]

So the unification datastore bytecode is decided and we will do it ?

It's a discussion that we need to settle :) what's your opinion about it ?

Good:

• a lot of code unification
• possible to host multiple bytecodes on the same account

Bad:

• Complexifies ABIs: calls have an extra "bytecode_key" parameter to know which bytecode to execute
• Needs a more complex as-sdk approach with a "protected" mechanism that prevents bytecode keys from being overwritten by someone registering while pretending to be named "_bytecode". Otherwise we will have security issues. Note that this protection is also a requirement for other entries like "_website".

Very short term for having a persistent ledger by the end of the month:

* Version byte in front of each ledger_db entry.

* Version byte before the bytecode
  (Just to confirm)
  cc @Leo-Besancon and @sydhds

Yes that's a requirement

[AurelienFT]

The discussion is already #2970 no ?

It will not break the ledger if we choose to fusion datastore and bytecode in the future ? (We could make some kind of migration). Because it will be nice that the next month ledger stay until the end of testnet

[damip]

It would be a breaking change but indeed we have two options:

• either use the acocunt's version number for the update (good test !)
• or make a migration script that converts the old ledger into the new one

[damip]

Decisions:

• bytecode / datastore unification will not be done now
• immutability flags on specific ledger entries will be implemented
• immutability flags on the bytecode will be implemented
• byecode versionning needs to be implemented

[sydhds]

I think this discussion is linked to this one: #2970 and there are some (maybe useful) comments...

[damip]

yes, it was taken into account :)