Transaction processing flow on canton on fabric architecture
@Wayne_Collier
Can somebody share insights on how transactions are processed with canton on fabric network?
If any component/any node goes down in the middle of a transaction, or at the end of a transaction, and the records go out of sync, which record takes precedence?
Dear Prisha,
Can somebody share insights on how transactions are processed with canton on fabric network?
Fabric only handles the total-order of transactions and not the processing, so transaction processing in canton still works the same as it did before. Fabric only acts as a shared database with some added benefits that can be read about here
If any component/any node goes down in the middle of a transaction, or at the end of a transaction, and the records go out of sync, which record takes precedence?
If a component goes down for any reason, a connection will be re-established and the component will synchronize before committing any further. So in case it goes down in the middle of the transaction (depending on what kind of down cause we are working) the transaction will be send once the state is synced. If a component goes down at the end of a transaction, then the transaction has already been send and no problem here. In regards to which transaction takes precedence, it would depend in what time frame they are committed and if there is any dependency. Assuming the above example and no relationship between the transactions, and these two are committed from two different nodes with same hardware, then the secondary transaction comes first.
Hi, Prisha
Another note: Fabric’s role as a shared database is limited to storing a record of the transaction order and the metadata of each transaction. The transaction contents are still encrypted.
The state of the Canton blockchain that results from the transactions always resides only on the Participant nodes.
Thanks @Wayne_Collier .
Suppose if transaction from sender and recipient are successfully transmitted to the DAML layer and there is a successful Hyperledger Fabric transaction, what happens if one of the Hyperledger Fabric nodes go down before the mediator step?
Hi @Pris17 ,
Fabric is fork-free by design. An unavailable peer only falls behind and doesn’t desynchronize. Once a peer comes back online, it catches up.
That same statement is true for the sequencers connected to that peer.
Canton is agnostic with respect to which sequencers messages are read from or written to. What affects transaction processing are the timeouts that nodes (participants/mediator) have to respond to other messages.
So if a node (participant/mediator) gets disconnected by virtue of losing its sequencer/peer connection for long enough that it cannot read and respond in time, then a transaction will time out. If the sequencer/peer come back online fast enough or the node can fail over to another sequencer/peer, then transaction processing will resume.
Documentation on timeout parameters for the participant and mediator nodes:
https://docs.daml.com/canton/usermanual/performance.html#configuration
