Chainport2023

A distinguishing characteristic of a distributed system running a Byzantine Fault Tolerant consensus algorithm is the possibility to tolerate malicious or, more generally, incorrect behaviors by a node or a subset of nodes which contribute in running the system. The amount of Byzantine nodes that can be tolerated varies system by system and is mostly influenced by the the adopted consensus algorithm. When interacting with such a system, users need to keep into account the Byzantine Fault Tolerant nature of the system. In particular, when reading from the state of the system, a user should ensure that the information it is gathering is effectively part of the state of the system, i.e.: 1. is not part of a transient or uncommitted state; 2. it was not forged or tampered by a malicious node. Such guarantees can be generally verified by contacting several nodes of the distributed system and by comparing the gathered information to check that they are consistent. The number of nodes to contact varies according to the consensus algorithm and it is greater than the number of tolerated Byzantine failures. If there are many general use cases where this practice is relaxed due to the relatively small impact of the performed operations, a sensitive and impactful case like a cross-chain bridge can not avoid to carefully ensure the truthfulness of the information it is relying on. In particular, the Chainport bridge, according to its architecture, triggers cross-chain transfers by listening events on both side of the bridge. When a new deposit is detected on one side, then a mint/withdraw is performed on the other side. So, the whole bridge correctness depends on the truthfulness of these events. The provided codebase detects new events and obtains Cardano information by contacting the `Blockfrost` service through its API. In this way the whole bridge correctness and reliability is directly tied to the correctness and the reliability of the `Blockfrost` service, making it a single point of trust and a single point of failure. The single point of trust problem brings the risk of the bridge misbehaving because of incorrect information gathered from the `Blockfrost` service. The service corruption or deliberate misbehavior, like reporting an uncommitted deposit transaction, could bring to an unwanted token mint/release. The single point of failure, meant from the availability point of view, directly affects the bridge since the `Blockfrost` unavailability directly means a bridge unavailability.