Retreat Discussion Items
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.
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:
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
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: