- Node A with public state and private state A listening for A1 and A2.
- Node B with public state and private state B listening for B1 and B2.
A1 will send a
to: B1. Since it's private, it will hand the transaction to the transaction manager. The transaction manager will know that Node B listens for B1 and will hand it to the enclave for encryption. A signed message comes back. Transaction manager sends the signed message to node B which decrypts, acks and notes the hash of the transaction. Node A puts the hash of the transaction in the public state (a private transaction hash).
Now, node A and node B both have knowledge of a private transaction from A1 to B1 but it hasn't been included in the chain. They wait for the mined transaction with the transaction hash (that only they know about). This is to establish the private transaction's place in the overall network transaction order.
When they see the hash of the
privateFor: transaction they know about, they run the transaction and update their respective private states. There's one private state per node, and they are not expected to be uniform between nodes, because they have knowledge of different private transactions.
It is probably better to think about a private contract state rather than A1 talking to B1 - more like A1 deploys contract A1B1
privateFor [A1, B1]. It would start with a contract deployment transaction
privateFor A1 and B1. A1 and B1 would each send transactions to the private contract which has an internal private state. This lays out a partition of subject-matter that A1 and B1 will have knowledge of, and, by extension, Node A and Node B.
In my understanding, there is a strong assurance that Node C has no knowledge of that contract or its state.
Hope it helps.