NEAR Data Flow
In this video we give a quick overview on the main concept of how the data flows across the NEAR Protocol blockchain.
NEAR Protocol blockchain data flow might be a bit tricky at a glance. But it is pretty straightforward and follows well-defined rules. In this article, we are going to have a closer look at how the data flows in NEAR Protocol blockchain.
In fact, any blockchain flow can be represented as an infinite timeline that has a start but has no end.
And a block appears on that timeline with some interval. Each of these blocks holds the information about the previous one, thus, creating a chain of blocks.
NEAR Protocol has a sharded nature, meaning that more than one parallel network, called a Shard, can be live at any moment. And each Shard produces a chunk of a block at a given interval. A Block in NEAR Blockchain is a collection of the block chunks from all shards. Block chunk is shortened to Chunk in NEAR Protocol documentation.
Returning to the data flow itself. The best we can do is to imagine tracks like we could see in audio/video editing apps. Each Shard has its own set of tracks. The top track is for Chunks. They appear no matter what at a given interval, for NEAR Blockchain the interval is about one second. Chunks are being produced even if nothing is happening on the blockchain.
But what do we mean by saying something is happening? We mean that something has triggered some changes in the blockchain. And the most well-known method to trigger any changes is to send a Transaction to the blockchain with instructions of what we want to change and who has requested those changes.
A transaction needs to be constructed, signed and sent to the blockchain. Once it is executed we expect to have a result - ExecutionOutcome. Oh, that is simple. But it’s not really accurate for NEAR Blockchain.
In the beginning there is a Transaction, it contains instructions we want to be executed on the blockchain. Transaction is sent to NEAR Blockchain.
And yes, it is executed there immediately BUT the immediate result of the transaction execution is always just an acknowledgment that it will be executed on the chain; this internal execution request is known as Receipt. You can think of the Receipt as an internal transaction that exists to pass information across shards.
Let’s get back to the tracks to look at the example.
Assuming we have two accounts living on different Shards alice.near and bob.near. alice.near creates a Transaction to send a few tokens to bob.near. The Transaction is immediately executed and the ExecutionOutcome for the Transaction is always a Receipt.
But this Receipt cannot be executed here, because bob.near doesn’t live on the same Shard as alice.near, so the Receipt must be executed on the receiver’s Shard. So the Receipt is moving to the Shard where bob.near belongs to.
On the destination Shard the Receipt is executed and the process is considered as done.
Please refer to the Token transfer flow article
So the final scheme will look like:
Summary​
We have learnt the main principles of how data is flowing in NEAR Protocol. We have found out that Transactions execute and the ExecutionOutcome of the Transaction is always a Receipt.
Now we know that Receipt is a main internal asset for NEAR Protocol blockchain and it has a power of traveling between Shards. We learnt the NEAR Data flow on a simple example. Of course in real life with more complex transactions that involve cross-contract calls, there will be more Receipts and ExecutionOutcomes.
We hope this article is useful and you will be able to build your dApps and indexers easily with the knowledge of how data if flowing in NEAR Protocol.
