Roadmap meeting notes:

Owned by Rita Allen (Unlicensed)
Last updated: Dec 28, 2018
3 min read


Attendees:


Goals:

Review the proposed roadmap milestones & release dates & high level features: https://docs.google.com/spreadsheets/d/1SwHALHiP03Ocglom-HB3RlzZROHVYmhuLi6pECFVUBY/edit?usp=sharing


Notes:


Notes from meetingQuestionResponse

Hiring is a concern - given the current team size, the roadmap is probably not achievable.

Based on the roadmap, we need to focus our hiring on:

  • Web Developers - for web-based client UI
  • Consensus/EE
  • Metrics
  • Testing/Performance
  • Operations

Rita - ideas:

  • Move Jack to Node Client UI work, including Web work.  
  • Backfill Jack with Abner (he likes storage work)
  • Andreas can work on any formal verification work we want

Consensus & testing represents a huge chunk of work

  • PoS contract was not feature complete
  • It was not correct either

What features were not complete with RChain PoS?

What does "not correct" mean? What do we want to do about it?

Medha Parlikar

Change Data Retrieval to → Client API's

Can we say "node API"?

Need a row for Formal Verification in CON - (from   meeting notes)

  • Consensus needs to be formally verified.
  • Ideally have it formally verified by an external party (community) 
  • We have the safety proof.
  This row created a bit of confusion - what exactly are we verifying and who do we expect will do this work? 

Row in EE for formal verification (from   meeting notes)

  • Correctness of properties of the token contract
  • Semantics of WASM in K-Framework exists. 
  • Compile contracts to WASM & use K-framework to prove the correctness. In the K-framework repo in Github
 Again this row created a bit of confusion - who do we expect will do this work? 

What is the vision for DevNet?  We made this assumption: DevNet - supports demonstrable features from previous month, supports performance testing.  Given this, we removed the concepts of "internal" and "external" devnets. 



Virtual DNS/hiding IP addresses of validators - is this our responsibility or the app owner? 

 

Changes to Roadmap:

  • Move Contracts from Jan to Feb/March
  • hard code validator set for January & Token Contract for Jan.
  • What is 'createblockstatus'?
    • Comes from Mateusz's node architecture
    • Updated Roadmap
  • Change Data Retrieval to → Client API's
  • Pull in PR's from Daniyar in RChain repository
  • Metrics
  • Deploy gossiping
    • Comms specification
    • Consensus - how do we deal with overlapping deploys?  Need a specification
  • Added a column for stabilization, planning for likely learning that will happen when the features comes together.


 

VM will not care - executing contracts (token or not token); 

Blessed contracts - PoS, token, 

Consensus - requires a set of validators, can be static or dynamic.  Start with static, move to dynamic.  Tokens need to exist, but may not be exchanged.  

Parallelism: two levels, execution and DAG.  Can execute serially but build a DAG; Can execute in parallel but build a linear chain.  

Executes aggregates - user pays for execution (and it is persistent)

bonding - validators can join network

From Jack Mills:

axioms (let me know if you agree):

  • we are more likely to accurately predict the progression of feature sets than the timing of said progression.
  • there is an inverse correlation between level of detail and accuracy, i.e. the more detailed the projections the lower the accuracy.
  • there is a direct correlation between time and accuracy, i.e. the further out in time the lower the accuracy.


therefore I suggest:

  • first create a time-independent progression of macro feature sets (“macro” = treating the node mostly as a black box as seen by operators and dapp developers)
  • then use this to drive lower level feature progression
  • then map to time: do monthly increments for the first N months, then quarterly for the next M quarters, then (if necessary) feature set progression without time


my swag at macro node functions:

  • contracts
  • accept and execute new contracts from clients
  • validate and execute contracts from other nodes
  • query dag state
  • distinguish between different types/modes of contract, e.g. only changes its own persistent state vs. sends messages to other contracts?
  • other phases of contract lifecycle?
  • wallets
  • ?
  • distributed consensus
  • only applies to multi-node
  • storage
  • operational
  • single node
  • multi-node, no node failures, well-behaved peers
  • multi-node, node failures, well-behaved peers
  • multi-node, node failures, fallible and/or malicious peers


are there any implications of immediate fundraising on the roadmap?