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


Apr 29, 2019


  • @Kelly Foster

  • @Dominik Zajkowski

  • @Artur Gajowy

  • @Chris Boscolo

  • @Lucius Meredith

  • @Łukasz Gołębiewski

  • @Timm Schäuble

  • @Pawel Szulc


We will use this time to hear an update from Dom on his investigation so far related to https://rchain.atlassian.net/browse/RCHAIN-3263 and start a next steps conversation that we will continue during our dev retreat. The goal of having this meeting before the retreat is to ensure group awareness of the issue and to provide time for people to do any investigation or thinking before we meet the next time.

Discussion topics







  • 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


  • 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

Action items

Ticket - Implement compression
Ticket - Update example Rholang contracts to not perpetuate use of demo channel
Prioritize - Removal of forgeable names
Ticket - PO Box contract
Ticket - SubscriptionAtName OR Ticket confirmation of how ListenAtName should and does work
@Dominik Zajkowski spend time on 4/30 considering how to add tooling and automation for measuring the outcomes of Rholang execution