/
Lexical Namespace Meeting notes

Lexical Namespace Meeting notes

Jan 26, 2018

Date

Attendees

Goals

Discussion items

TimeItemWhoNotes
talk about why we need to consider abienceMichael Stay (Unlicensed)
  • In order to have groups of validators that can mostly concentrate on their own stuff and have entry stakes be low enough so that people can get in for local things, but not so open so that anyone can claim to be running a namespace server (stuck on the back of a 56 modem - they will get kicked out but not slashed (Kyle) )
  • Greg - non response is a flushing status - Michael - you can't prove that it was their problem and not your problem.  Greg - you spread the pain to everyone, so everyone gets hurt

 The question of where a contract is running Michael Stay (Unlicensed)
  •  We don't want to have every contract run on every node.  We want some validator sets running some contracts that other ones are not running.  Problem is how do we obtain consensus on what messages are sent.  We would like to have a design like DNS.  

Work the problem via calculationGreg Meredith

The problem we hit.Michael
  • When you need to move up the tree, you want to bring as little up with you.   When moving up to a higher namespace, a race conditions will force all dependencies to come up to the higher namespace. Ultimately then everything will run at the top level.
  • Kyle asserts that we have a transitive closure problem.  Without a viewer that can see the sum of child namespaces you can't come to consensus on transactions that cross 2 namespaces. 


Greg
  • Namespaces separate only after finality.  There isn't another way to do that.  Kyle - asserts that we could make it work with Ambience.


Kyle
  • Namespace is an ambient.  In order to perform a transaction, contracts have to be in the same namespace.  A join across namespaces is a lot harder to get right.  We have to disallow joins across namespaces.
  • You have to declare a name and you have to declare what channel you want to listen on.  Kyle asserts that we need to know where the contract will run. 
  • Greg asserts that we cannot mix network topology and and application code.  Nodes sign up dynamically.  You can't count on any consistency on the number of nodes.
  • Casper needs to know what validators are coming to consensus.  
  • We have to account for people coming in and trashing any small namespace.  
  • Impose a discipline on ambients that will give us what we need.


Mike/Michael
  • The validator set is stored on the blockchain in the genesis block.  And the validators can set the criteria for the validator set.  
  • Greg: I agree that for all namespaces where you have com events (transactions) you must have a validator set.  
  • Michael - the proposal is that if you impose a structure for a validator set, and there is a tree structure for the namespaces, you can push a transaction up the tree.


Greg
  • We don't want to construct the power set of validators
  • what ever we construct will re configure
  • what ever is reconstructed depends on the economics- bonding and unbonding are economic events.
    • depends on the validators accepting the new validator.
    • Whenever it re-configures it will result in different transaction fees
    • if we don't do this, tree reconfiguration could be used as a DOS attacked.
      • Kyle - that was in our original proposal - the only way to reconfigure the tree is to add a sub node or remove a sub node.
    • Let's agree on the disserado(sp?)  Michael will write it down in the google doc.




Action items

  •