Nano-node: Is epoch block required?

[rotilho]

Sorry for create this issue but I'm a little concerned about epoch block and I'm wondering if this is really required and I'm not sure if discord is the best place to address this.

One of the main reason to have a epoch blocks is to have the ability to provide pruning however isn't already possible?

If the database keep the track of all required information (representative and balance) isn't the pruning possible?

I.E.: I have a send as the latest block. Before pruning I can keep in the database information about this transaction plus representative and current balance, similar to state block. Knowing this I could just delete every transaction before.

Add epoch block it seems more work in development side than the opposite from my perspective.

Am I mistaken?

[clemahieu]

Epoch blocks are to deprecate the old block types.

[rotilho]

@clemahieu is it required? Won't the code stay forever there anyways to handle legacy blocks?

It's even possible to just make up-to-date nodes to reject legacy blocks not allowing them to be added to the ledge.

[clemahieu]

The problem is nodes get upgraded at different times. If some reject a block and some accept, which wins? Right now our election system has no ability to reject a transaction, it can only pick one answer within a fork. We like this property because there's no ability for a transaction to be rejected and we want to keep it that way.
So we're in a situation of
1) Wanting to allow graceful upgrades
2) Having a fully asynchronous system
3) Not wanting the ability to reject transactions

We came up with epoch blocks which is a way to solve this.

What problems do epoch blocks present to you?

[clemahieu]

Just to give some further clarification: All other cryptocurrencies out there have multiple keys per chain. In blockchain coins, all keys are in a single chain, in other DAGs, multiple keys are on a single chain. The concept of one signing key per chain is a performance optimization, it isn't a statement of ownership.

Private keys will always retain ownership of their balance and representative. Epoch blocks cannot modify either.

[rotilho]

Thanks for the clarification @clemahieu. My comment about reject blocks it was just one idea but my main concern is the real gain (maintenance and maybe security) from the epoch blocks.

Probably I can't see something obvious that you guys can see. I'll give more thoughts to that while working in jnano-node.

Thank again

[rotilho]

I gave more thoughts about it and I think I understood what you want to achieve.

But I'd like to hear your thoughts in a alternative idea: what if an new state block is introduced (i.e. 7) which also contain the version of the account. If an account want to receive a transfer from another account with higher version it should produce a state receive block with matching version or higher (if available).

Main advantages

• Decentralized
• Less complexity from code perspective (I think)
• Gradual upgrade
• Future-proof, if the number of the account explode

Disadvantage

• Lost seed accounts will never be upgraded
• An account will be never obligate to upgrade if they don't want to receive a block with a higher account

[rkeene]

One of the requirements for epoch blocks be that they completely sunset the era of old-style blocks. The old style blocks have complicated further developments because they do not completely specify the state of the account and thus if we can make plans where only they are used we are better able to implement features that bring the software and protocol forward.