Are Blocks in blockchain are indexed ?

[r1s2g3]

When we do a transaction then it is made sure that whatever we are going to send to receiver are unspent outputs (UTXO). It means it need to be scanned in entire blockchain that it is not spent.
But I see that transaction are validated within a seconds (or few seconds). Since blockchain size is now is 170 GB plus so it look to me quite a fast speed to traverse all blocks in blockchain.

I understand each block has address of the previous block  so do it have kind of index to reach that last block and we traverse all block one by one?

[ABCbits]

Bitcoin core (other client might do things differently) build and use UTXO database which stored on storage (not RAM) which makes transaction verification is faster. The UTXO database updated every time node receive transaction/block or create and broadcast transaction.
Besides, AFAIK most transaction can be verified in hundred millisecond.

There's no way any developer would think scan entire database just to get a data. Indexing, database balancing, sorting or/and separate database for linking obviously used in here.

If you're curious with UTXO size/count, you can check https://statoshi.info/dashboard/db/unspent-transaction-output-set

[nc50lc]

-snip-

By saying "indexed" was it meant like index in books and file storage systems?
Then, by comparing the speed between (ex. not indexed Window Explorer) and Bitcoin's Blockchain, this question pops in to your mind?

Clients have a blockchain_headers which contains something similar (for indexing) that enables it to easily find the transaction hashes which have the accurate "links" to where the UTXOs are stored:

Code:

"inputs": [
        {
            "addresses": [
                "39EK***********************"
            ], 
            "age": 513486, 
            "output_index": 82, 
            "output_value": 10000, 
            "prev_hash": "24dc16f626085e7c75e6fbdbd2533f27d98d884fe73f58fed46a3e319157****", 
            "script": "160014d0ef607e4dc338d4dd67df92e2090b770a781***", 
            "script_type": "pay-to-script-hash", 
            "sequence": 4294967293, 
            "witness":

• prev_hash: the previous transaction where it belongs.
• output_index: where it sits between all of the other outputs of the particular transaction.

File explorers and Blockchain works differently, this is just "in-relation".

[Thirdspace]

It means it need to be scanned in entire blockchain that it is not spent.

chainstate/*: this is a LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions.

no it doesn't have to (re)scan the entire blockchain everytime,
wallet/node keeps track of current unspent transaction outputs in chainstate

I understand each block has address of the previous block  so do it have kind of index to reach that last block and we traverse all block one by one?

all databases always have indexes to make searching specific data faster
for bitcoin, metadata for blocks are stored under blocks/index/* directory
you can read more in details on bitcoin wiki Bitcoin Core 0.11 (ch 2): Data Storage

[r1s2g3]

There's no way any developer would think scan entire database just to get a data.

Then, by comparing the speed between (ex. not indexed Window Explorer) and Bitcoin's Blockchain, this question pops in to your mind?

I am a Performance DBA, I know even if the table size in a couple of GB and you have to do Full table scan to fetch the data ,required data cannot be fetched within the seconds . (Debarring parallel query operations).

you can read more in details on bitcoin wiki Bitcoin Core 0.11 (ch 2): Data Storage

That link perfectly satisfy my query.


Thanks  to you all. Slightly off topic question, I already gone through all the chapters of "Mastering Bitcoin" book and I do not remember if I have read anything about it.  Did I missed in reading or there are some other source/book from which I should start.