Carbon emissions updates about storj HOT 8 OPEN

Okay, so I think we should make an update to how we are getting the carbon saved values. For reference, this is where we are calculating the emission savings for a project. We are passing in:

• amount: total amount currently stored in TB for the project
• duration: time since creation of the project
• isTBDuration: false (due to the unit we pass in being TB, and not TB*hours)

Unfortunately, this results in the incorrect calculation. Let's say you create a project a year ago, and you have 1TB stored - the calculation will be for the carbon savings of storing 1TB for an entire year, even if you only uploaded that data recently.

Fortunately, the calculation for emission savings supports units already that allow us to fix this and make it accurate; by setting isTBDuration=true, we can pass in an accurate TB*hours value:

• amount: TB*hours stored for the project over some duration (we can decide a month, or since project creation, or whatever)
• duration: disregard; it isn't used in the calculation in this case
• isTBDuration: true

This should make the calculation accurate. I think for now, we could calculate savings over the past month or billing cycle. If it is not bad performance, we could do since project creation - and that would be a cooler number. But there is a risk that that query would be more intensive (not sure if it's something we need to be concerned about though)

from storj.

@boshevski - added this to capture the time period these numbers are for... @mobyvb - I assume this is month to date?

from storj.

@ferristocrat based on conversations with Vitalii, it is "cumulative". However, I think we should look into the math/whitepaper again to ensure that any timeline we put is accurate

from storj.

Thanks Moby. Ideal would be since project creation.

from storj.

We could also display the "Estimated annual carbon at current usage" or similar?

from storj.

Added info about time period:

from storj.

The stripecoinpayments_invoice_project_records table stores data in bytes, not byte-hours.
Also, using the bucket_storage_tallies table since project creation would be incorrect because there are projects created in 2020 that have more than 180,000 rows.

Additionally, using the bucket_storage_tallies table for annual calculations could be burdensome, as there might be more than 50,000 rows annually.

from storj.

@VitaliiShpital I think we still have a few options:

• bucket_storage_tallies has an index on project_id, interval_start, which means it should still be very fast to do summarization queries in SQL that are filtered based on these two columns, even with many rows. We may want to double check the performance, but it may be fine to do even with 100ks of rows (not completely sure - we can ask in the db performance channel)
• if for some reason it is unreasonable for us to sum all bucket_storage_tallies rows for a project, it should be fine for us to query a smaller and better defined range, e.g. 1 month. In fact, if we did some extra design work, we could connect it to the date selection for graphs on the project dashboard, which already have some limitations about what duration is selected
• I don't think we will end up needing to do this, but worst case scenario, we could try to do a conversion of stripecoinpayments_invoice_project_records from bytes to byte-hours, e.g. by multiplying each row by the number of hours in a month
  • on this point, I don't understand why we would even store bytes in this table - we are invoicing on byte-hours, so why is it that we are storing a bytes value in the table?

from storj.