Versions Compared

Old Version 3

changes.mady.by.user Medha Parlikar

Saved on

compared with

New Version Current

changes.mady.by.user Rita Allen (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


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

...

  • Move Contracts from Jan to Feb/March
  • hard code validator set for January & Token Contract for Jan.

...

  • Comes from Mateusz's node architecture
  • Updated Roadmap

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?