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.
...
Day 1: Location 3 - Namespaces (Greg, Kent, Joe, Ian, Nash, Eitan)
- 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 1: Rholang Lab (Greg, Timm, Ian, Navneet, MedhaEitan)
- TBD
Day 2 : Location 2 - Block formats, types and messaging (Mike, Chris, Griff, Vlad, Kent, Rolland)
...
Day 2 Location 3: Business Requirements (Ed, Lawrence, Nash, Joe, Medha)
- Are there special requirements for the wallet application 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)
...
- 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)
Day 3: Location 3: Type Checker Design (Mike, Kent, Griff, JoeEitan, Timm)
- Michael Stay (Unlicensed) - Please list any subtopics to guide the session
...
Day 4: Location 1: Rholang Lab (Greg, Mike, Kent, Griff, Timm)
- TBD
...
Day 4: Location 2: Documentation (Timm, Mike, Joe, Kent, Navneet, Eitan)
- Who will need documentation
- What portions of the system need documentation
- Who will complete the documentation, what is the timeline.
...
How do we address double spend?