Slice command - Delete or overwrite a slice?

[michaelpiron]

Dear @MartinSchmidt ,

I have a question regarding the Slice command.

1/ Energy Track & Trace: implementation of CertificateQuantity

You might remember that last year, in the framework of Energy Track & Trace, we discussed about the implementation of a "partial ownership and transfer" process for granular certificates. I refer to following issue: https://github.com/Energy-Track-and-Trace/ett-documentation/issues/37

At that moment, you made following comment:

@michaelpiron My comment on the RFC would be not to delete the EnergyQuantity but overwrite it in an event store fashion, then the history would be preserved while still enabling part ownership transfer of a GC.

2/ Project Origin: Slices

In the meantime, with Project Origin, the concept of Slices is introduced, which basically supersedes the Certificate Quantity concept.

However, while reading the documentation, I noticed that the Slice command does the following:

The slice command enables the current owner to create new slices from an existing slice.
When the new slices are created, they become active, and the old slice becomes inactive and is removed.

Different approaches

If I'm not mistaken, these are two different approaches for slicing: overwriting the existing slices versus deleting the originating slice.

Could you elaborate on this?
I'd like to understand the rationale and why there's a change in vision.

Thanks

[wisbech]

Hi Michael.

I am also a bit add odds with the underlying function of the additional end state of the certificate - the removed part as described in the slice lifecycle documentation, after reading through the example code there is also a remainder which means no part of the slice is "removed".

This brings to question is this an endstate that will ever be used ? I think it is in place for interregistry transfers, so that a registry operator can ensure that their own registry is healthy by auditing their own transactions - interregistry depency would be a nightmare to handle IMHO - so I believe this is why the "removed" state is in place.

I will dig further into the code and will report any findings in this thread.

[michaelpiron]

Hi Thomas,
I also had a look at the example code you referred to. T
his code doesn’t explicitly reveal what happens to the original Slice after the execution of a slice command.

However, my interpretation of the example code is that in the SliceCollection, the user specifies a collection of new slices to be created, each with a specified quantity.
If the sum of all these quantities in the collection is less than the quantity of the original Slice, a remainder Slice will be made. This ensures that the sum of all quantities of the new Slices exactly equals the original Slice quantity.
This implies that the original Slice has to go into state “Removed”, otherwise each slice command would double the total quantity.

Therefore, each slice command leads to the removal of one Slice.

This approach is different than the approach we fixed earlier with the Certificate Quantities, where we resized the original CQ with each splitting command, and created a new CQ next to it.

The current approach of removing the original Slice also makes sense, I’d just like to understand the rationale behind this change in approach.

[wisbech]

From the paper we are currently writing:

A collection of slices. A GC is issued with 1 initial slice corresponding to the total amount of energy. This energy amount may be split in several parts (slices) each with potentially different owners under the constraint that the sum of all slices must equal the original amount of energy in the certificate. An active slice contains two values, the quantity of the slice, and the owner's public-key. Thus the owner is not identified by a name but by a public key which acts as a pseudonym.

As I understand it - and I might be wrong here. The removed part of the certificate is for transfer between registries, so that a slice is being removed in one registry it is issued in another with the same header and the sliced of volume.

[wisbech]

In addition from the paper:

Note also that a registry must be able to work with other registries. Most impor-
tantly, when a consumer belonging to one registry claims energy from a producer
belonging to another registry then the corresponding GC slices are in consumption
and production certificates issued by the two different registries. This means that
the process of claiming energy involves actions from each registry. This is performed
using a two-phase commit protocol in order to ensure that the two certificates end
up in consistent states.

[wisbech]

Starting with a production certificate we create a first slice as needed for claims of energy or transfer of parts of the certificate.
Then the next slice ``consumes" the remainder of the previous slice and so on.
So a sequence of updates to a production certificate is valid if the production slices form a chain (as forking corresponds to double spending) and their internal sums equal the amount from the previous certificate that was sliced.
Since a certificate refers to the previous version of the certificate a well-defined chain to the original production certificate issued by the registry can be validated.

[wisbech]

Proof of correctness for matching. When a consumer claims a certain amount of
produced energy, one needs to ensure that the claimed amount is the same in both
the production and the consumption slice.

[michaelpiron]

Hi @MartinSchmidt , could you have a look at this?
I'm trying to understand the rationale behind the change in approach wrt slicing.
Thank you.
Best, Michaël

[michaelpiron]

We discussed this matter during the offsite at Fredericia (20-21/Apr) between Energinet and Elia Group teams. @MartinSchmidt & @wisbech were present.

Answer:
Slicing up slices by removing of the original Slice & creation of new slices is the most straightforward and robust way in terms of management within the ProjectOrigin registry (events in the event store and pushing into the blockchain using merkle trees).
We'll follow this logic in Energy Track & Trace.