Quote from: Sukrim on April 13, 2013, 05:17:25 PM

Quote from: misterbigg on April 13, 2013, 04:53:52 PM

Quote

Also who is the one running the order book? The server?

There is no "server." All validating nodes process the order book using a deterministic algorithm. Since they all have the same ledger and set of proposed transactions, the application of outstanding orders is deterministic. All nodes come to the same conclusion regarding orders, since they began with the same state and use the same rules.

So in case node 1 gets offer 1 and then offer 2 with identical timestamps and node 2 the other way round, how is this resolved? Do they ask a third node?

(I'm assuming you mean these two offers both take the same crossing offer and therefore conflict. If they just place two offers, then both offers will just get placed, no problem. If they 'fully conflict' that means one transaction makes the other impossible. If they 'partially conflict' that means it matters which you execute first.)

First, it's important to see that all that is required is for the servers to agree on the ordering of these two transactions. So long as all servers agree which is "first", then there's no problem. The second transaction will fail or execute in some way that doesn't conflict with the first (if it can). And it doesn't matter which one they agree is first really, no outcome is "right" or "wrong". They must, however, agree or ledgers diverge.

Ripple servers have an "open ledger" and a "last closed ledger". Servers process live transactions against their open ledger and snapshot the open ledger when the ledger closes. So these two servers will have different and conflicting open ledgers when the ledger closes. (If they fully conflict, one will have one and one will have the other. If they partially conflict, one will have one first and one will have the other first with different results.)

When the ledger closes, each server proposes the set of transactions it thinks should go in the next ledger. An avalanche algorithm is then used to reach a consensus on what set of transactions should go in that ledger. See the wiki for details on how a consensus on the candidate transaction set is reached. There are three possibilities:

1) If they don't fully conflict, then the servers actually agree that both transactions should go in the ledger. In this case, a deterministic algorithm decides which one is applied first. All servers will agree on the new last closed ledger.

2) One transaction winds up in the consensus set and the other doesn't. In this case, all servers will agree on the new last closed ledger and will apply the other transaction. If it was only partially conflicted, they'll likely agree to apply the other transaction in the next consensus round.

3) Neither transaction winds up in the consensus set. In this case, a deterministic algorithm decides which one is applied first to each server's new open ledger. The other transaction will also get in if the first transaction only partially conflicts it. The servers will agree on the new last closed ledger with neither transaction and will all agree on one or both transactions in the next round.

In all cases, servers will agree on the new last closed ledger and any remaining conflict will be resolved by deterministic algorithms, possibly forcing one or both transactions to be delayed into the next consensus round.

If there are unconfirmed transactions left over, a new consensus round begins immediately. So this process will typically only take about 10 seconds.

The server never assumes that its open ledger is reliable in any way. It just uses it to screen transactions to decide if it thinks they might succeed and therefore should be forwarded and should be included in the server's initial proposal. It also uses it to help clients form chained transactions.