The Concept of Synchrony

Depending on how messages are received, decentralized networks can be in several different communication states. Depending on the network design and architecture, we can differentiate between asynchronous, synchronous, and semi-synchronous models. As outlined in this article, synchronous models are generally not possible within a decentralised environment. These models regulate the dynamics between participants and guide the implemented processes and protocols, ultimately by controlling the way nodes communicate.

Synchronous model
Synchronous computer processes rely on triggers to operate. These triggers can be the completion of other processes or machines handing off computational tasks. If applied to synchronous messaging, once a message has been sent from one node to another, it awaits a specific time to receive a response; only the response will trigger the processing of the next process. Synchronous processes designate a specific time-bound during which messages can be sent and received from one node to another. Since the network is built around the assumption that every sent message will be received, if the message is lost, the network comes to a halt. Ultimately, a synchronous system becomes stagnant if it either does not receive the required triggers, or it receives too many unexpected messages. The former can be caused by a node going offline or because it is intentionally not responding. Synchronous systems are also highly vulnerable to Distributed Denial of Service attacks (DDoS), whereby an attacker intentionally floods the network with messages. As a result of the mass messaging, the network can’t process all of the incoming messages and processes stagnate. Because decentralized networks face frequent scenarios where network messages are delayed – either as a result of attacks or simple node failure – synchronous systems are not considered plausible.

Asynchronous model
Asynchronous models describe objects or events which are not coordinated within defined time parameters. Synchronous systems support a timeline in which processes occur in response to other processes or triggers. In contrast, asynchronous computer programs allow processes to work independently of other processes. In other words, in synchronous systems, A can only happen if B happens. Asynchronous systems allow A to happen independently of B. (2) Sending a message from one node to another is not always instantaneous; delays frequently occur. This delay is not infinite but it can be unbounded. However, until the node receives the response, the node will be unable to determine the length of the delay. Resulting, it is unclear to the sending node whether the message was lost or is simply delayed. In such scenarios, the system loses the capability of ordering this messages. (1) A node might receive a message B before it receives A, even though B was generated after A. This is problematic in certain scenarios. For example, imagine that Node 1 submits two transactions A and B to a set of validators, whereby transaction B depends on transaction A. If the validators receive B before A, because the transaction A was delayed, then they will be unable to verify A nor B. “This model reflects worst-case communication, but it is simple and general.” As a result, synchronous systems collapse under such conditions and asynchronous systems need another method for ordering the messages rather than simple timestamps.

Semi-Synchronous model
A semi-synchronous system sets a fixed time frame during which messages can be received. After these messages have been received, there may be more unreceived messages to come, but semi-synchronous systems compromise as the network cannot wait an infinite amount of time to receive all messages. In comparison to synchronous models, semi-synchronous processes do not need to receive a trigger to execute processes; instead, processes are executed independently, similar to asynchronous models. In contrast to asynchronous systems, semi-synchronous models place restrictions, in the form of majority threshold or time limits, on participants to allow the system to evolve. Therefore, semi-synchronous systems strike a balance between security and efficiency.

Note. Semi-Synchronous models can shift between deterministic and non-deterministic states. In contrast, asynchronous models are always non-deterministic; if a model is deterministic, it cannot be asynchronous.

Determinism
Blockchain protocols implement sequential consensus rounds, meaning that one consensus round is held after the other and not in parallel. If the protocol is deterministic, it holds true that all honest nodes (i.e. nodes that are non-malicious and online) will reach consensus within a predefined number of consensus rounds. Resulting, messages in a semi-synchronous model will be delivered within a certain number of consensus rounds, known prior to its execution. In contrast, non-deterministic models are unable to determine when all honest nodes in the network have reached consensus. However, it is also true that as the number of consensus rounds approaches infinity, the probability that a subset of honest nodes remains undecided approaches zero. Non-deterministic networks will reach consensus eventually.

Any decentralised network must implement security parameters. For example, a network sets a time-frame or a predefined set of nodes, during which the network has to reach consensus. In the case of Byzantine fault tolerance consensus, this includes at least ⅔ of nodes in the network. Therefore, 66% of nodes have to respond and agree on the same value in order for the state of the network to evolve. The other 33% of nodes either find and agrees on a different value, are offline, or have succumbed to malicious behaviour or attacks. However, if the network does not have security parameters implemented and operates completely asynchronously, nodes will not share a common view of the network. Depending on the network design, this can result in orphaned nodes, whereby nodes have to wait a finite but undefined amount of time to be able to progress to the next consensus round. If any given consensus round has too many orphaned nodes, the network will halt until nodes are able to communicate on their current state.

A system that is said to be deterministic does not rely on the execution of processes to know the parameters by which the processes will be executed. Therefore, any situation that may occur is known prior to the execution of certain processes. In contrast, asynchronous models are non-deterministic. Processes are executed depending on the circumstances of each process; these vary greatly depending on the number of nodes participating, their response time, and the percentage of node failure. Therefore, asynchronous models do not have a predefined outcome.

“A node can fail in one of two ways:

  • Crash failure: it simply stops working, and never comes back on again.
  • Byzantine failure: it does not stop working, but it behaves arbitrarily. This model encompasses a wide range of misbehaviour, either due to unintended bugs or malice.” (1)

The main difference is, crash failure of the node can only be within one state; thus, it is clear what has happened to the node. However, within the Byzantine failure, the node can be in several states. Asynchronous models are not clear on the state that nodes are in. Therefore, a node would not know why its neighbouring nodes are not responding and the process outcome is uncertain for every node. Asynchronous systems have to limit and handle node failure by design.

Blockchains are based on the communication of transactions between nodes. Whether a blockchain platform chooses to implement asynchronous or semi-synchronous processes will have impacts on the communication flow within the system and on the interaction between nodes. Asynchronous systems generally sacrifice security to ensure that the network is always available. Semi-synchronous systems generally maintain safety but risk transitioning into “locked” phases where the network is inoperable.

Summary
The concepts outlined above will become relevant within this series on system designs and further extended on through the discussion of design theories and comparisons between projects. Single design choices can have wide effects on the network and the interaction between participants.

 

Sources

  • https://searchnetworking.techtarget.com/definition/asynchronous
  • https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf
  • https://pdfs.semanticscholar.org/2b2f/3e3228c3fe6bf5b0de5486dd25688beadf0d.pdf
  • https://legacy.gitbook.com/book/vugranam/cap-theorem-and-blockchain/details
  • https://news.ycombinator.com/item?id=1191314
  • https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
  • http://paulkernfeld.com/2016/01/15/bitcoin-cap-theorem.html
  • https://people.csail.mit.edu/nickolai/papers/gilad-algorand.pdf
  • https://medium.com/opentoken/hashgraph-a-whitepaper-review-f7dfe2b24647
  • https://medium.com/solana-labs/proof-of-history-a-clock-for-blockchain-cf47a61a9274
  • https://solana.io/solana-whitepaper.pdf

Leave a Reply

Your email address will not be published.

Share This

Copy Link to Clipboard

Copy