/
2018-09-13 Rent Meeting notes

2018-09-13 Rent Meeting notes

Owned by Medha Parlikar (Unlicensed)
Last updated: Sept 13, 2018

Date

Attendees

Goals

  • Specify the details on storage and Rent

Discussion items

TimeItemWhoNotes
Rent for a unit of time → Mercury?
  • During deployment forgeable processes are tagged with a block height for when they 'expire'.
  • We process the trace log and mark those produces and consumes that only have forgeable payload - we need this because we are going to disallow sends on forgeable names.
    • Plan on computing this in advance that a given payload is forgeable. 

'Proof' of Storage
  • Owner can post a challenge (key)

Phlogiston for Storage
  • Second wallet in a deployment for rent.  
  • Putting a file inside the contract is horribly expensive.
  • Deploying a huge contract → pay for storage but not for rent.
    • This could encourage everyone to store their contracts as persistent sends.  May kill the notion of rent all together.
    • This would result in the contract being forgeable and persistent. 

Payment of rent/fees for storage
  • Need to think about what happens with wallets.  Is storage for wallets paid up front?  Does the wallet pay for it's own storage?

Removal
  • Can't be done until the nodes view of the history indicates that the payload will no longer be needed/used.

Outcome
  1. Add required crypto primitives 
    • keyed hash
  2. We should have a way of bringing in binary data - perhaps a binary deploy proto, that has a urn and a sequence of blobs (data, signature, etc.
    • We would allow you to look the urn up in the registry, and if what was returned was non-nil, we would send the blobs to the name that we looked up in the registry.
  3. Write up a description of the storage service so that we can give it as a bounty to someone in the community→ Rholang contract.
    • Storage can be completely separate from the network itself
    • It is a smart contract with an off chain service.  The service will provide verification that the payload was stored properly and can process the results on chain.  The payload itself will be stored off chain.
    • When one retrieves a file, it has to be signed by the user.
    • The equivocation logic is on chain.  The proof of storage is on chain.
    • The smart contract verifies that the storage provider continues to store the file.
      • User has to hash the file under a series of keys.  Create a pair of keys and key hashes, and send a challenge to the provider on a regular basis.  Provider returns back the file.

 Sidebar
  •  Discuss cost accounting in the face of parallel Rholang interpretation.
    • Make the Rholang interpreter run sequentially?
    • Synchronize on the phlo after every operation- which means we need to block.
  • What we have in dev now, accumulates the cost.  We have multiple branches of execution of the program, and at the end we combine the results at the end.
  • Option:
    • Split and recombine, and if it reaches 0, don't give up, but try to borrow.  
    • We don't need to stop immediately, we need to stop soon.
    • When the cost reaches a threshold, do an atomic operation.
      • Keep a local counter of the cost. When it reaches a threshold, deduct it from the phlo. 
    • for storage of files, we know the cost in advance.
  • Items we do not know the cost of apriori
    • matching


Raw notes:

Rent  - Need to specify.  Mateusz can work on.

  • Phlogiston for Storage
  • Notion of time - how long the item is stored.
  • How long before validator is paid for storage
  • Proof of storage - 
  • Update to deploy parameters.

Notes on Rent:

  • Storing data is different from storing something that conveys authority 
  • The Rent gives you a guarantee of ease of access.  Construct a Merkle tree of data, problem is that it is linear, and you can only restore it once.  Much harder for continuations because they are linear.
  • Accept that with respect to continuations it's going to cost them a lot.
  • Same thing happens with sends that convey authority.  A purely forgeable send would be cheaper to store. 
  • How do we measure time?
    • Longest chain?
    • There are timestamps - we could work around the jumanji problem. 
    • Accept fuzziness around timestamps - rent granularity would be in months not days.
    • Number of times content is accessed? A COMM event on the name.  However the content could be referenced without creating a comm event?
    • Forgeable content on a forgeable name that is part of the original deployment.
      • At the end of quiescence, some of the data is forgeable, and that portion is what is charged rent.
        • Requires a 3rd parameter which is the rent purse, deducting a certain amount per block height until it is empty
        • Create scavenging cycles & GC to clean up the content.
      • No separate notion of storage outside of the tuplespace.
      • Pricing - cost will not be linear, there will be separate pricing for storage.
    • Rent extension - Read it and re-deploy - the dApp will have to have the content at a name that they can get access to it.
    • Validators can choose to ignore blocks if they wish - but there is no censorship of content.  It's very hard to detect what kind of content is being uploaded.
    • Storage of files in the tuplespace will result in ejection of those validators that do not have enough RAM or storage capacity.

Side bar:


Action items

  •  

Related content