Cross-chain as blockchains, Bridges as protocols.

Cross-Chains are a form of blockchain , with it’s own unique consensus mechanism whilst, bridges are protocols , mechanism crafted within a cross-chain using cryptographic schemes to make inter-chain transfer a possibility.

Ideally cross-chains should be trust-less , meaning the user has complete autonomy over his/her account with every transaction verified. Currently there are some cross-chain protocols inching toward trust-less cross-chain protocols.

Architectural flaws of current cross-chain bridges.

Messaging and inter-chain cryptocurrency transfers are the core objective of cross-chain bridges.A cross-chain bridge could either be Natively-Verified , Externally-Verified or Locally Verified. Their architectural make-up expose them to a lot of attack vectors , for example Externally-Verified bridges have a third party inter-linking two blockchains.

How they work.

This third-party inter-linking two chains may or may not be a blockchain that is it may be a centralize system. if it’s a blockchain what is it validator network mechanism , how does it work.

Secondly there are certain systems centralize by nature with such Multi-party Computation features , these systems entertain enormous attack vectors , multi-fold in nature existing at the DevOps level* , the smart contract level* concerns about the kind of library used in writing the smart contract if it has been audited or not.

In addition improper validator mechanism. For example a centralized validator nework mechanism have some form of inter-dependent relationship could lead to a validator network takeover in case of a private-key leakage from just one validator , leading to access control attacks.

In conclusion the architectural make-up of Externally Verified cross-chain bridges have the most attack vector surface with access control attacks most rampant.

Problem solved somehow:

Bridge agnostic design the ERC 5164 protocol involves two chains namely the sending and receiving chain and also a MessageDispatcher & Executor.

How ERC 5164 protoocol works .

Message from the sending chain include chain ID (a blockchain destination address). According to this protocol message(either text or money) from sendiing chain firstly goes through a MessageDispatcher functio**n.

When a MessageDispatcher recieves that message, it sends the message to a MessageExecutor on some recieving chain after that action the MessageExecutor emits a confirmation message sent back to the sendingcontract as a form of confirmation.

Imagine you want to deliever money or a cash bag to friend through delivery agent , you might have verified that delievery agent and have the assurance that he will deliever the item safely, Before sending a message in this protocol the Message Executor firstly verifies the the MessageDispatcher before the message is sent.The whole authentication process is described in EIP2771.

Then also remember that in this protocol a message can only be sent once in any other. In other words if you wish to create a system for yourself where messages could be sent more than once such as governance messages or text messages, you have to make that message different at the protocol level in order to get through more than once and if you want them ordered you would have to include your own nonce in the metadata and track them.