# Blockchain and Mining

The AIA Chain blockchain shares many similarities with the Bitcoin blockchain but also has some key differences. The main distinction between AIA Chain and Bitcoin lies in the structure of the blockchain: unlike Bitcoin, each block in AIA Chain contains a list of transactions as well as a copy of the latest state. Additionally, two other values—block number and difficulty—are stored in each block.

{% hint style="info" %}
Block Structure
{% endhint %}

<figure><img src="/files/3s4P2IqwWHBlhWSGqHfx" alt=""><figcaption></figcaption></figure>

The validation process for a block in AIA Chain follows these steps:

1. **Check the validity of the referenced previous block**: Ensure that the previous block exists and is valid.
2. **Check the block's timestamp**: Confirm that the timestamp of the block is later than the referenced previous block’s timestamp and that it falls within a 15-minute window.
3. **Check the block parameters**: Ensure that the block’s number, difficulty, transaction root, uncle root, and fuel limit (specific low-level AIA Chain concepts) are valid.
4. **Check Proof of Stake (PoS) validation**: Verify the validity of the PoS proof on the block.
5. **Initialize the state of the previous block**: Set the state at the end of the previous block as `S[0]`.
6. **Process the transactions in the block**: Let the transaction list for the block be denoted as `TX`, which contains `n` transactions. For each transaction `i` in the range of 0 to n-1, set `S[i+1] = APPLY(S[i], TX[i])`. If any transaction application returns an error or the total fuel consumption exceeds the block's fuel limit, return an error.
7. **Finalize the state**: Set `S_FINAL` as `S[n]`, adding the block reward for the miner.
8. **Verify the state root**: Check that the Merkle root of the final state `S_FINAL` matches the final state root provided in the block header. If they match, the block is valid; otherwise, it is invalid.

This approach may initially seem inefficient because it requires storing the full state of each block. However, in practice, the efficiency is comparable to Bitcoin. The reason is that the state is stored in a tree structure, and after adding each block, only a small part of the tree needs to be changed. Thus, for most adjacent blocks, the vast majority of the tree remains the same, and data can be stored once and referenced multiple times using pointers (i.e., hashes of subtrees).

A special type of tree, known as a **Patricia tree**, is used to implement this. It modifies the Merkle tree concept, allowing for efficient insertion and deletion of nodes, not just updates. Moreover, because all state information is contained within the last block, there is no need to store the entire blockchain history. If this approach were applied to Bitcoin, it could save between 5 to 20 times the space required.

A common question is where the contract code physically executes on hardware. The answer is simple: the execution process of the contract code is part of the state transition function, which is itself a component of the block validation algorithm. Therefore, when a transaction is added to block B, the code execution generated by that transaction will be executed by all nodes both now and in the future as they download and validate block B.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://aia-chain-1.gitbook.io/aialabs/technical-framework/core-architecture/blockchain-and-mining.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
