2019-04-29 Meeting notes: Rholang bloat in the tuplespace

Resources

• https://rchain.atlassian.net/browse/RCHAIN-3263

• Recording of this meeting

Overview

• Rholang generates a lot of data and it’s filling up the tuplespace

• Dom has started an investigation and it’s not done

  • Observes weird distribution in the trie related to blake

  • Observes Rholang filling up logs

  • Hunch there is not alignment on how the registry works
    
    

Rholang

• Observation that Rholang generates a lot of data in the tuplespace

  • Example of some of what’s seen in tuplespace

`WaitingContinuation(List(BindPattern(List(Par(List(),List(),List(),List(Expr(GString(getBalance))),List(),Vector(),List(),List(),AlwaysEqual(BitSet()),false), Par(List(),List(),List(),List(Expr(EVarBody(EVar(Var(FreeVar(0)))))),List(),Vector(),List(),List(),AlwaysEqual(BitSet()),true)),None,1)),TaggedContinuation(ParBody(ParWithRandom(Par(Vector(Send(Par(Vector(),Vector(),Vector(),List(),Vector(),Vector(),Vector(Bundle(Par(List(),List(),List(),List(),List(),Vector((4,-5,53,-69,-115,-112,104,-102,-87,29,-55,-27,105,-98,-49,-92,92,-45,-105,33,-2,-25,60,101,-6,-23,-42,-56,29,96,26,-33)),List(),List(),AlwaysEqual(BitSet()),false),true,false)),List(),AlwaysEqual(BitSet()),false),Vector(Par(Vector(),Vector(),Vector(),List(Expr(GString(value))),Vector(),Vector(),Vector(),List(),AlwaysEqual(BitSet()),false), Par(Vector(),Vector(),Vector(),List(Expr(EVarBody(EV`

• Rholang log entries

  • Observation for filling logs (70Kb)

  • Observation we don’t have a general purpose tool for measuring traffic on a channel. We rely on observing the outcome of contract deployments today.

• Concern about names created and then discarded

  • All contracts allocate new names

  • How much data then is required for the execution of contracts?

Ideas to address findings

• Figure out a better way to deliver data to users (pulling vs pushing)

  • A way to reduce putting data in the tuplespace and still provide communication to the user.

    • This would need further discussion related to the UX and implementation

• Figure out a better way to manage data in the tuplespace

• Optimize how the registry works with the tuplespace

  • Need to confirm consistency in how we use the registry

  • Concern about tech debt accrued for current implementation of the registry

  • Idea that implementation of peek could help address

• Optimize by determining when a contract is sequential and how a sequential contract is handled

  • For example if sequential, then delete something

  • Requires reviewing platform contracts to determine which are sequential

• Optimize the way we store unforgeable names

• Idea to split the sequences (and do what?)

• Idea to introduce compression

  • Will have a performance impact

  • The more we compress, the less we’ll be able to share/re-use data

  • Not a popular idea

  • TICKET compression idea

• It’s time to remove forgeable names

  • Consider adding a PO Box contract to support exchange of data

    • Isn’t this what the registry supports?

      • Requires knowing URI which is only available off-chain “you need to know the name to know the name”

• Implement SubscriptionAtName to replace current use of ListenAtName

  • Confirm ListenAtName does function as a subscription

• Redesign Rholang ASD

Ideas for investigation

Big question: What exactly contributes to the data growth? (Greg)

• Create tooling to measure what happens in contract execution

  • Measure throughput of bytes in a channel

    • Idea to use graphite (sp?)

  • Requires coming up with a way to aggregate and categorize

  • Dom has a sense of what values to measure based on investigation to-date

• Starting with a clean tuplespace, execute small contract chunks and observe

  • Doesn’t account for use of tuplespace + registry