**Created by Matteo on Feb 17th.**

**Notes from meeting Feb 17th. Matteo, Irene, Luca**

On Step 1

storingPerTime : \naturals \tiems \naturals → Dollars (CostDomain)

storingPerTime is heavily space-based (e.g. if you half the time you are storing, you roughly save 50%)

NB: S is linear-ish in d

**Eqn1 // sec tradeoffs**

for all N’

storingPerTime(d, N) < Regeneration cost(d,N’)

S(d,N) < R(d,N’) for all N’

**Eqn2 (The “trivial” tradeoff)**

for any d, for any space N’ ≤ N,

Regeneration(d, N’) ≤ Initialization(N, …) //d not a parameter

Put them together

storageperTime(d, N) ≤ Init

Claim: if I reduce d to its half then Init is being reduced by …?

Obs: **seems like Initialization has another parameter **that can adjust the cost (e.g. the degree of the graph)

Direction 2: What we seem to want is a family of PoS s.t. for (roughly) all parameters rho, N

TInit(rho, N) \approx R(rho)

(Possible problem: this ratio may depend on rho. Also, maybe there is an additional constraint, e.g. we don’t want T_init (in a new PoS) to **cost more than the current T_init**)

Possible direction 2bis: fix rho and find better R for that rho mathematically (i.e. a better bound)

- other possible assumption T_init is roughly linear in N
- this is to simplify and seems true in the intuitive constructions of PoS

On Step 3:

it may be more of an add on on top of the other directions. While the other two directions are more of a new PoS (with the exception of 2bis), the third is valid on any given PoS as a compiler.

We can see PoS as an optimization with constraints on parameters rho, etc. where some are fixed.