> For the complete documentation index, see [llms.txt](https://v1docs.kwil.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v1docs.kwil.com/architecture/block-index.md).

# Block Index

## Overview

Each data-moat has the ability to choose its own system of block index management.  A block index is simply a way of chronologically organizing and storing a data-moat's blocks.  These can be stored in really any conceivable way: a centralized, privately managed database, a publicly accessible smart contract, or even another Kwil DB!

## Current Implementations

### Arweave Gateway

The simplest method of block indexing is using regular Arweave Gateways.  Since each block bundle is its own Arweave Transaction, nodes can make a simple GraphQL query to find new blocks submitted for their data moat.  This method of block indexing requires virtually zero setup, maintenance, and overhead.

#### Pros:

* Can quickly identify un-synced bundles.
* Is highly customizable, allowing for the usage of custom Arweave tags to create complex logic for bundling (ex: Kwil DB sharding).
* Incurs no additional costs / effort to setup, maintain, and use.

#### Cons:

* Is somewhat difficult to remove verified node operators while keeping their data in the block index.

### EVM Smart Contract

Storing a block index in an EVM Smart Contract allows for more dynamic data-moat management.  Management and data-write permissions can be managed through NFT / Token-Ownership, or through a simple white-list system.

#### Pros:

* Advanced write permissions allow for data-moats to create custom syncing functionality and incentives.
* Dynamic management makes adding / removing verified node operators very easy.
* DAO's can vote to retroactively un-index blocks if content is submitted maliciously.

#### Cons:

* Incurs additional deployment and recurring use costs.
* Adds an additional attack vector for malicious actors.
* Can be prone to more bugs (depending on the blockchain).

## Future Implementations

### The Graph Protocol

Creating a data-moat specific subgraph on the Graph Protocol would be very easy to implement.  Such a subgraph could contain functionality for data sharding, as well as increased bundle scalability.

A Graph Protocol implementation could also provide the framework for moat cross-pollination, allowing for moats to selectively interact and query other moats.