/
2018-08-17 RCon3 Demos Meeting notes

2018-08-17 RCon3 Demos Meeting notes

Aug 17, 2018

Date

Attendees

Goals

  • Inform the dev leads of what demos we will be giving & what the demos look like.
  • Determine the 'demo task force' for RCon3
  • Determine the cadence of standups for the task force leading up to the conference

Discussion items

TimeItemWhoNotes
30 minutesReview the RCon3 AgendaKelly Foster
  • Locking down the schedule has taken time, program was finalized.  Recognize that this is late.  topics are not set in stone.  
  • We are launching the test net.  This is not up for debate.
    • Recommendation for speakers:
      • Day 1, slot 2 - Michael Birch and Kent
      • Day 1, slot 2 - Pawel's Lambda conf talk (Pawel)
      • Day 1, slot 4 - How to deploy and interact with it (Michael Birch & Kent) Kelly Foster follow up w/ Kent
      • Day 1, slot 6 - How to model standard concurrency primitives in Rholang
      • Day 2, slot 2 - Operational semantics (not K-framework)
      • Day 2, slot 3 - Academic details behind Rholang's implementation (what is the spatial matcher?) Unforgeable names and how they're computed (Kelly Foster follow up w/ Kyle on title
      • Day 2, slot 5 - Kelly Foster follow up w/ Pawel  on title and who
      • Day 2, slot 5 - add Sebastian to panel to speak to interacting with the gRPC API
    • Concern for flow in Track 2 on day 1
    • Team has concerns around time needed to prepare presentations.
15 minutesReview the Launch CeremonyMichael Birch 
  •  Reference:  RHOL-414 - Getting issue details... STATUS
  • There is code that runs during Genesis phase - and at the end of execution, the genesis block will be 'done'
  • Bonding Rev for the validators 'appears' will need intervention.  Will need to magic up Rev. 
  • Input to the Genesis block generation
    • Set of Validator id's & bond amounts.
  • Need the list of validators & their public keys Kelly Foster to provide.
  • We will create bond amounts.
    • DECISION: We will set the bonded wallets for the validators at this time.  
  • Each validator will generate the genesis block on their own in a manner that is similar but independent of the bootstrap node.
    • Each validator will have their own copy of the genesis block, which they will use to sign the block.
  • The nodes come up, make their own copy of the genesis block.
    • The bootstrap sends 'unapproved block messages'
    • Validator nodes receive the block, compare the block with their local copy, and add their signature to the block.
    • TODO: Determine the threshold for signatures → CoOperative should decide the threshold, depends on the number of validators.  Depends on the fault tolerance. We have about 23 for Testnet.  
      • Thinking that we need ~ 15 or so.  We can adjust it up until the process starts.  We need to make sure that everyone knows what the number IS.
    • The bootstrap will have a grace period where it will continue to accept signatures until the grace period is done.  We can also adjust this grace period. If the minimum number of signatures exist at the end of the grace period, then the block is marked as approved.
    • If the minimum isn't met during the grace period, the bootstrap will continue to wait until the minimum is reached. 
  • Presentation running up to the launch:
    • Wiki page that we have
    • Scripts to generate the Genesis block
    • List of addresses & Rev amounts in the Genesis block. → Kenny
      • Look on the ETH blockchain for an address, find it in the Genesis block by executing the local generation on a node.
    • The generated Genesis block from a validator
    • The node software will make a local copy of the genesis block.  → Kelly to inform Nash about this detail.
  • Launch of the Test Net
    • Mechanics of the launch itself
    • Demonstrate Rev at the address post launch. - a deploy to demonstrate the account balance.  Examine the state of the chain.
15 minutesReview the Performance DemoMedha Parlikar (Unlicensed)
10 minutesMeeting cadence & participantsEveryone

Action items

  •