Versions Compared

Key

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

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

Child pages (Children Display)
alltrue

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.

...

  • 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?

...