# Transaction / Event / Chain state

Blockchain networks possess the characteristics of a distributed system. Their design primarily aims to maximize ***Consistency***. Therefore, any change within the state of the blockchain network always follows a specific process: someone initiates a transaction, it goes through ordering and validating, is submitted by validators or collators, and finally, it's packed into a block and gets finalized to ensure that no further changes occur, which reaches ***Finality***.

The term ***Consensus*** refers to a shared understanding or viewpoint by a group of nodes in a blockchain network. These nodes observe, supervise, and share a common "world view" (their version of reality). If any segment of these nodes has a differing world view, in a broader sense, it indicates that they are now part of different blockchain networks because a blockchain forking has occurred. And the common way to determine if the consensus is stable enough, is to check the finality.

Additionally, why a blockchain network keeps producing the empty blocks even there is no transaction? Because "**At the moment, there is no transaction!**" is also a ***Consensus***.

There are 3 kinds of information being used mostly during the integration with a blockchain system:

1. Transaction (a.k.a. Extrinsic in Substrate-based blockchain network)
2. Event
3. Chain state

### Transaction (Extrinsic)

Essentially, a Transaction is a ***Description how to modify the state of blockchain network***.

In usual case, a transaction is signed by the transaction origin (sender), containing the information:

* Target module information (a.k.a. Pallet in Substrate-based blockchain network)
  * For example, `balances` for transferring FT
* Invoking method and arguments
  * For example, `balances.transfer(receiver, value)`
* Nonce
  * Indicating this is ***n-th*** transaction of the sender, starting from `0`)
  * Supporting the transaction queueing
* Transaction Fee
  * Which is paid to the collators or validators

Whether a transaction is successful or failed, once it's finalized, it becomes part of consensus.

### Event

As a best practice, a method in a module should emit some Events to notify the external world what happened inside the transaction.

Sourcing the Events helps building a robust, error-tolerant system, but it is also more complicated than usual software pattern.

It is always helpful to wait for the block finalization, and then source the events again for the accurate business logic or computation outside the blockchain network (a.k.a. off-chain).

### Chain state

A Chain state is usually in a key-value form inside blockchain network storage.

With special trie structure, it is doable to fetch a state with a specific block number, for example, get FT balance of an address at block `100`, and get another one at block `200`, to see the FT balance under two different time context.


---

# 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://thxnet.gitbook.io/thxnet-developers-doc/concept/transaction-event-chain-state.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.