Transactions and CfA
CfA = Conversations for Action. See #131
These are some considerations about implementing CfA's.
By "transactions", in this issue, I mean in the distributed data sense, not in the economic sense. In the distributed data sense, a transaction is an agreement on a state change between 2 or more agents communicating from different systems on a distributed network.
Agreeing on state changes on a distributed network is tricky, as The 8 fallacies of distributed systems will explain.
Here I will talk about the first two fallacies:
- The network is reliable
- Latency is zero
Not only will the network and the devices fail, so will the people, sometimes deviously.
And you can't really tell how long it will take to get a response from another system.
Each of those state transitions requires agreement between each of the agents: sometimes just an acknowledgment, sometimes acceptance or rejection or some other meaningful response.
Thus, each of those state transitions requires a distributed transaction.
@fosterlynn and I put a lot of notes about two-agent distributed transactions in this google doc.
It gets pretty complicated. But the guts of what we need for a 2-agent conversation for action are probably in the section entitled "The BTP doc also allows an event simpler variation: One-phase confirmation".
That's the simplest distributed transaction protocol. But it has a hole, which our notes explain in terms of a simple mutual credit transfer:
Situation: transferring mutual credits from one agent/account to another, where the accounts are not in the same mutual credit network. The providing agent initiates the transfer. If the transfer is successful (accepted by the receiving agent), both accounts will be updated: the providing account will be decremented, and the receiving account will be incremented.
But what happens if the providing agent does not get any response - neither acceptance nor rejection? What should the providing agent (or the transferring software) do?
One possibility is to set a timeout for the response, and for the waiting agent to fail that particular transaction, and then try to communicate with the responding agent and restart the CfA from the previous state. If still no response, the whole conversation may fail.
Complication: mutual credit networks according to MatSlats have an invariant rule that the sum of all account balances must be zero. So that means the mutual credit network or networks are also a party, or parties, to this mutual credit transfer transaction. Which also means that neither of the agent account balances can be changed independently: they can only be changed when the mutual credit network or networks says it’s ok. So that makes it a 3 or 4 party consensus situation. Which means the coordinator, usually the provider in this case, needs to check also the decision or decisions of the network or networks. Here’s an example of a 3-party transaction: https://drive.google.com/open?id=1NkAY4QhI1ra2vjFvY1GzPPJXvYWJDgxg
Holochain validation might take care of that complication, or not. We still may need a designated coordinator, which is usually the originator of the transaction.