❓FLAG Network - Why?

A centralized database can replicate itself and maintain high availability without significantly compromising that transaction rate using the distributed system technique. This is known as Optimistic Concurrency Control [H.T.Kung, J.T.Robinson (1981)]. According to that, it is possible for a centralized database to process 781,000 transactions per second on a standard gigabit network if the transactions are, on average, no more than 193 bytes.
In FLAG Network, we are trying to prove that these above theoretical limits are also well-applied to blockchain on an adversarial network. So what are the major elements? It is to find a way in which we can share the time as nodes cannot rely upon one another. If we can find a way that can help nodes to rely upon the time, then the 40 years of distributed systems study will at once become applicable to blockchains!
In practice, we will have algorithms obtained by our method and ones based upon timeout. The most remarkable difference between these two may be that using timeout produces a traditional distributed algorithm. However, these processes operate asynchronously, while our method provides a globally synchronous. In this way, every process will do the same thing at (almost) the same time. At the first sight, our method seems to go against the entire idea of distributed processing, which is to authorize different processes to operate separately and execute various functions. However, if a distributed system is considered a single system, then all the processes must be somehow synchronized. In theory, getting all processes to do the same thing simultaneously is the easiest way to synchronize them. Following that mindset, we introduce a kernel that performs the necessary synchronization which we call a method. For example, when we can ensure that two different processes will not try to modify a file at once, processes might spend only a small fraction of their time executing the synchronizing kernel. For the rest of the time, they can still operate separately (such as accessing different files). Even when fault-tolerance is not needed, we are still eager to apply this strategy. The basis of this method is simplicity which makes it easier to read the precise properties of a system. It deems to be vital if you really want to know just how fault-tolerant the system is [L.Lamport (1984)].
Moreover, we are very astounded to know that it can be achieved by using a mechanism that has existed in Bitcoin since the day it was born. That Bitcoin feature is known as nLocktime and by using block height instead of timestamps, it can be applied to postdating transactions. As a client of Bitcoin, using block height instead of a timestamp is most preferable if you don't rely upon the network. Commonly, block height shows up to be an instance of what's being known as a Verifiable Delay Function in cryptography circles. As for confirming that the time has passed, it's a cryptographically secure method. In FLAG Network, a far more granular verifiable delay function is utilized. It is a SHA256 hash chain that is used to checkpoint the ledger and coordinate consensus. Using it, we operate Optimistic Concurrency Control to aim towards that theoretical limit of 781,000 transactions per second.