Claim by delivery point without specifying slice id

CharlesCheckley commented 2 months ago

Description

As a user I want to be able to transfer and claim certificate slices without having to specify the slice ids, instead specifying the assets, period start, source and destination wallets and quantity to be transferred.

The slices themselves are considered fungible to me (given they are from the same device, for a given period start) and having this endpoint significantly reduces development complexity.

Basic Example

This endpoint exists in the Energy Track and Trace v1 api as v1/claims/bydeliverypoint

Api Documentation

Example Call:

[
  {
    "productionAssetId": "string",
    "consumptionAssetId": "string",
    "productionCertificateAccount": "string",
    "consumptionCertificateAccount": "string",
    "periodStart": "2024-08-27T14:21:27.745Z",
    "periodEnd": "2024-08-27T14:21:27.745Z",
    "quantity": 0
  }
]

Drawbacks

No response

Unresolved questions

No response

wisbech commented 2 months ago

Thank you for reaching out @CharlesCheckley .

In order to claim production to consumption you first need to transfer the quantity to the wallet_owner in this case the consumer before you claim the quantity of production against the consumption. This is in order to make sure the data does not leak - https://project-origin.github.io/docs/concept/granular-certificates/transactions/slice.html and it is being used by the underlying cryptographic solution that is described thoroughly in the documentation, to ensure no sensitive data leaks to the public.

You could of course make a vanilla interface in your system that bundles these actions for ease of use but my two cents on it would be it is an externality for project origin - if you do this work feel free to share it, we are open for PR's :-).

MartinSchmidt commented 2 months ago

Hi @CharlesCheckley,

Looking at your request, I have a few questions and comments:

As @wisbech said, to claim certificates against each other, they are required to be in the same wallet. Cryptographically, there is no easy way around this in the current implementation, otherwise you would have to do your own wallet implementation, the underlying technology in the registries does not hinder this, but in the way the wallet was built, it is, it was chosen to be this way to simplify usage and to avoid security issues.

So I won't comment more on the Accounts part of your request.

In general, the the wallet aims to provide a minimum set of features to enable the core functionality, and all specific business logic should be implemented in ones own business logic layer on top of the wallet. It could be we could add a ability to query certificates based on a filter of the AssetId or other attributes, which one can then use to make the specific claims.

But to better understand your request, I would like to ask you a few questions:

Given the below data in the wallet

Period	asset1 quantity	asset2 quantity
2024-06-06T11:00-12:00	7	8
2024-06-06T12:00-13:00	10	10
2024-06-06T13:00-14:00	15	15
2024-06-06T14:00-15:00	5	15
2024-06-06T15:00-16:00	15	5
2024-06-06T16:00-17:00	10	5
2024-06-06T17:00-18:00	6	4

and a request in the format you specified

{
    "productionAssetId": "asset1",
    "consumptionAssetId": "asset2",
    "periodStart": "2024-06-06T12:00",
    "periodEnd": "2024-06-06T16:00",
    "quantity": 12
}

What would you expect the result to be?

because for the given data, there are multiple ways to fulfill the request, and I would like to understand what you would expect.

Should it claim the 12 from the first period that has enough certificates?
Should it only claim 12 for the entire period?
Should it claim 12 for each period that matches?
Should it fail if some periods are not fully claimable?
should it claim up to 12 for each period that matches?

Since the system is async in nature, how would you expect the system to handle the case where the request is partially fulfilled, and the rest is not?

It would potentially start a large group of transactions, where the result would be a list of transactions ids which you could then use to query the status of the transactions.

brunomenu commented 2 months ago

Hi Martin

Good spot, I don't know why Elia implemented a start AND end date in their API, but it was aimed to be used for a single interval of 15 minutes (as explained in their description of the API). Apologies, this was misleading in our previous message. I assume this answers your example questions.

The pain point for us is to require to provide slice IDs. Your suggestion of "we could add a ability to query certificates based on a filter of the AssetId or other attributes, which one can then use to make the specific claims." would be indeed useful. I think you understand our use case which is to make our life easier when making a claim, knowing that the info we have on our end to make a claim is ID of production device, ID of consumer/metering point, which 15 minute interval and the quantity. And currently it would be quite complicated from this info to make the claim: finding which slices, transferring the right slices to the right wallets, making the claim with the slice IDs, etc. So anything on your end that could simplify this use case (which is the typical "GO use case" for an energy supplier) would help.

Michaelgimm commented 2 weeks ago

Hi @brunomenu I noticed that this thread has been inactive for a while. As you may know, @MartinSchmidt is no longer actively involved in Project Origin, as it has now been transferred to my team. He is still our backup though.

My team is currently focusing on two upcoming pilot projects, the main goal of which is to finalize the technical aspects. One of the new features we are considering is enabling a producer to transfer only the certificates that a consumer needs.

As Martin mentioned in his response to your question, we aim to separate core functionality and business logic. A filtering function was also mentioned. If we were to implement such a feature, would it meet your needs? If so, what specific requirements should it fulfil?

project-origin / wallet