Retreat Discussion Items

Owned by Medha Parlikar (Unlicensed)
Last updated: Dec 02, 2017
5 min read

Goals:  

  • Common understanding of Mercury and its requirements.  Every one of us should be able to answer "what about... " questions with respect to Mercury if cornered.
  • Identify major gaps in Documentation and make sure someone is assigned to resolve it.
  • Do some coding together in Rholang.  Write contracts.

Child Pages:


Breakout Session Topics

Day 1 : Location 3 - Block formats, types and messaging (Greg, Chris, Griff, Vlad, Michael, Dan, Navneet)

  • What hashes are there, and what do they look like?

  • What data is common to all blocks?

    • Are there types of blocks, if so, how many types, and what is the specification of each type?

  • What is the size of a block? Can block sizes vary?

  • Are there "light blocks" constructable for "light clients".


Day 1: Location 2: Compiler Design & Economics (Mike, Kent, Eitan, Timm, Joe, Kyle)

  • Limiting the resources that a contract can consume at compile time - how will we achive this if not via static analysis?
  • If we choose to implement static analysis, what can we commit to delivering?  What is the MVP?
  • Do we need Tuplespace (delimited continuations and Radix Tree/ Trie data structure) for Mercury?
  • What powers the Rev wallet contract?  Does Rev have to pay for itself?


Day 1: Location 4 - Namespaces (Greg, Kent, Joe, Ian, Nash, Dan, Kyle)

  • Lay out namespacing, How is the set of the namespaces going to be defined
  • Who gets to say what a valid url is
  • Is there a registry, what does it look like, when do we need to have it in place, how is it maintained
  • Can we specify statically the form of name in a namespace, so we can check it at compile time
  • How do we introduce new formats for names?  urls are great but dont cover everything we might want
  • How do we allow nodes to define their own grammar for names?


Day 2 Location 2: Rholang Lab (Greg, Timm, Ian, Navneet, Eitan, Kyle)

  • TBD


Day 2: Location 3: CASPER (Vlad, Mike, Chris, Joe, Michael, Dan, Kent, Griff)

  • Addressing shell games that amount to finding consensus assuming you have already got consensus...
    • Betting requires fungibility between forks. How do we solve this in POS Consensus - what is the asset external to the system to create consensus?
    • If we define consensus inductively, there is a time window over which a network split absolutely cannot happen. There is no value for this time window that makes network splits not happen.
    • What happens when a validator leaves for several months and then returns - how is trust re-established without opening the network to attack?
    • How do we address the problem with the first induction window, in which you cannot possibly have bonded validators, and you must fall back to centralized selection.
    • Will increasing the induction time to 7 days resolve the problem.
  • Do we have a solution to the Prisoner's dilemma?  reference:
    • Transaction receipts (in lieu of every validator validating every shard that shares cross-shard state) create a Prisoner’s dilemma. It doesn’t matter if you model the self-referential consensus-by-betting with the Pi calculus, because such a process model does not model such economically driven externalities.
  • How does one identify the list of validators at any given time? (It's not clear to it will work as described, may simply need clarification)

  • How do we address double spend?

  • For the Mercury release do we plan to have our staking token implemented "natively" - specifically, such that we can do the equivalent of msg.sender.send(amount) in Ethereum? Or are we just going to use the token.rho contract for our staking tokens too?



Day 2 Location 4: Business Requirements (Ed, Lawrence, Nash, Medha, Rolland)

  • Are there special requirements for the wallet application for Mercury?
  • Do we need MULTI-SIG support for Mercury
  • Based on the industries and applications from Day 1 - define business requirements for the applications.
  • Why do we want to integrate with BTC and ETH in time for Mercury (source: ECDSA Secp256k1 curve for BTC and ETH from WBS)
  • What is not part of Mercury?
  • What of Ethereum's road map? Do we address any of the items in Mercury?


Day 3: Location 2: Marketing Strategy (Ed, Lawrence, Nash, Medha, Rolland, Ian)

  • How will we reach our target Market?
  • What is the message?
  • What are we doing to create buzz?
  • What is the value prop?

Action Items:

  • Lawrence & Navneet: Provide a list of conferences that are targeted, dates and expected outcome
  • Lawrence: Timeline for blog posts that are needed from Development
  • Medha Parlikar (Unlicensed): Publish this information to the wiki


Day 3: Location 3 -Blockchain, Consensus, Cryptography and Networking (Chris, Griff, Mike, Vlad, Timm, Eitan, Michael)

  • Support for transactions taking place between contracts in different namespaces
  • How is the ledger maintained? reference: Blockmumble
  • What are the canonical set of blocks that a validator has to download?
  • CASPER  - When do expect to have working code? 
    • What is the data structure.
    • What are the networking requirements for the protocol?
    • Is there a critical mass of validators that is required in order for a contract to be viable? 
    • Can a smart contract operate with a single validator?
    • Do bounties need to be implemented in order to entice validators to come online?
  • Cryptography:
    • Identification of nodes by public key (or hash of public key (or hash of hash of . . .))
    • Exchange of keys at handshake time
    • Signing of messages
  • Timm Schäuble: Capture requirements for Crypto op code(s) for VM (work with Kyle)
  • Kyle Butt: Specify the Crypto that RChain will use. 


Day 3: Location 4 - Verticals, Industries and Applications (Medha, Lawrence, Ed, Rolland, Navneet)

  • Which industries are expressing interest & we should target?
  • What are the use cases that are the most compelling for these industries?
  • Which markets are we going to go after in these industries (Enterprise, mid-market, SMB, VSB)
  • What is the TAM (Total Addressable Market) 
  • What is the story we can tell if these industries solve the use cases with blockchain?
  • What are the applications do we see evolving as a result


Day 4: Location 2: Rholang Lab (Greg, Chris, Griff, Michael, Dan, Vlad) 

  • TBD


Day 4: Location 3: Documentation (Timm, Mike, Joe, Kent, Navneet, Eitan, Kyle)

  • Who will need documentation
  • What portions of the system need documentation
  • Who will complete the documentation, what is the timeline.

Action Items:


Day 4: Location 4: Release Management and Open Source Software Relations (Nash, Ian, Rolland, Medha)

  • Communicating releases to the Open Source Software Community

Action items: