[vworld-tech] Ultimate MMO Platform

[Crosbie Fitch]

> From: J C Lawrence
> In what way is the following not a trust mechanic?
> 
>   NodeA receives a product from NodeB.  NodeA queries NodeC, NodeD, and
>   NodeE on the correctness of the product from NodeB.  If they all reply
>   that the product is reasonable, then NodeA accepts it.  If one demurs,
>   then the product is refused.
> 
> The core element of "well behaved" is that the described item 
> behaves in
> an expected manner.  What is left out is how the veracity of that
> expected behaviour is determined or what the expected behaviour is in
> cases of error or fraud.  (single and double entry bookkeeping make a
> decent parallel here).

Maybe we're just haggling over vocabulary here...

In my book 'trust' is the extent to which you will allow another entity to be responsible for something, or the extent to which you will take their word at face value, WITHOUT cross-checking its behaviour, or its word for accuracy.

Of course, you should continuously audit and cross-check, but only as an infrequent background mechanism for assuring the trust is well placed.

In your example no trust is involved because you are immediately checking correctness.

Even in human terms, we recognise that if A hands B a wodge of notes as payment of $100, that if B counts the notes A will often say "What? Don't you trust me?".

Trust is NOT CHECKING. It is taking a risk that an immediate check is not necessary, that any later check is balanced by the cost of the cheat's subsequent loss of reputation/trustworthiness.

Two strangers doing a deal will not trust each other. Two people that know each other and expect to have future dealings with each other or associates, will trust each other (to some extent).


> Isn't_that/couldn't_that_be just a hinting layer injected into the
> quorum mechanics?

Hmm. Not sure I'm with you there. ?:-/

>  Given sufficient volatility in the system it
> approaches a random function.

Yeah, if everyone is always a stranger there can be no trust.

Trust will only occur where there is a benefit to being trusted. In the system I propose, the benefit is higher fidelity modelling (less lag), given that your computer is more likely to be entrusted with modelling more of your environment.


> > But (assuming addressability) you should be able to detect the same
> > identity being used by two addresses.
> 
> Maybe, and only reliably to any extent if you either assume a central
> core, or require that all nodes maintain full knowledge of the entire
> population of nodes.  I've been assuming that both those 
> models were in direct contradiction to the peer-2-peer principle you wanted.

I'm not against central servers per se, just inflexible or non-scalable architectures.

I do believe it is possible to have a combination of peer-to-peer communication (as far as modelling and state change/distribution is concerned) and hierarchical communication (as far as distributing arbitration and identity registration is concerned), i.e. without the hierarchical channels being in danger of becoming bottlenecks (or achilles heels).

I may be wrong.


> Perhaps some definition is required here, both in terms of what the
> "system" is, and what the propagation methods are for data across that
> system.  My assumption has been that all nodes were first class nodes,
> varying only by local physical resources and transient data spool
> contents.

Well, the 'system' I've been talking in terms of is the one I think of as my 'ultimate MMO platform', i.e. the one I've proposed/conjectured about elsewhere.

In that system all nodes have a kind of duality of statuses, e.g. equal opportunity, but not equal in terms of performance/capacity/quality/reliability/reputation. They can all communicate as peers, but as far as arbitration goes, this is in accordance with a hierarchical determined in a meritocratic way (given merit can change, so can the hierarchy).

> > If there is a dynamic hierarchy of responsibility...
> 
> Single root, multiple roots, ad-hoc roots, indeterminate 
> roots, or lumpy mesh?

Single root. But can change.

> 
> There are some implications there for cache retention and 
> flushing which you may not like.

Sure.

But duplicate identity is just the warning light. One must still then perform a simultaneous identity verification on both addresses (just to rule out new address colliding with old address).

> How do you tell the difference?

Er... Difference between two nodes claiming the same identity, or the difference between one node on two addresses, and two nodes on two addresses?

> Who preserves the secrets/state, and is
> that preservation reliable across unreliably connected/running nodes?

All nodes can keep journals into which they log the secrets (random numbers) they exchanged. New nodes aren't trusted, so they're not a problem. Malicious nodes attempting to spoof trusted nodes are the problem. Trusted nodes will tend to have been relatively promiscuous, ipso facto there should be enough nodes to test shared memory in terms of secrets, e.g. "Does anyone remember dealing with NodeA?? If you did, can you give me a hash of the secrets you exchanged with NodeA? Thanks."

You know, I'm making all this up as I go along. ;-)



> Which means keys have a half life or ungraceful disconnects 
> are problem.

I was aware of the graceful/ungraceful issue when I used the term 'disconnect' without qualification. :)
If identity is invalidated on graceful disconnect it is invalidated on any disconnect. Disconnect is determined when a node's parent can no longer communicate with it.