> For the complete documentation index, see [llms.txt](https://futaba.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://futaba.gitbook.io/docs/protocol/konoha.md).

# Konoha

<figure><img src="/files/kMAlsIaFPCFKzLUNWAbo" alt=""><figcaption></figcaption></figure>

### Motivation

Although this mechanism is scalable, its security is entirely dependent on a single network. Futaba always requires a block header (state root) to verify storage proof. In other words, the problem is how to get the block header to the trustless network to verify the proof, which is not optimized in the existing single network.&#x20;

And now, with the spread of Modular blockchain, Layer 2 with various combinations has appeared. For example, some have the Data Availability Layer as Celestia and the Settlement Layer as Ethereum, some have both the Data Availability Layer and the Settlement Layer as Ethereum, and some have both the Sovereign Rollups with Celestia as the Data Availability Layer have also appeared. Under such circumstances, it is necessary to provide a trustless block header based on the common part (Data Availability Layer and Settlement Layer) to achieve more optimal data acquisition and thus interoperability. Interoperability is achieved.

### Solution - Konoha

For this reason, Futaba offers Konoha as a Modular block header provider, which can be customized to any to retrieve block headers. This allows for the acquisition of block headers that are optimal for each ecosystem and application. This allows for quicker adoption of more optimal cryptographic technologies as they become available in the future.

### How to implement

Currently, Futaba provides a way to access its block headers as part of connecting to the LightClient Contract and adding its verification method. Therefore, it is necessary to implement proof verification and block header access in the same module. However, in the future, a more flexible data retrieval experience can be achieved by separating the verification method (general storage proof or proof in zkp) and the module for block header retrieval. And the current default is to use Chainlink Oracle.

Also, for Relayer, if there are partial modifications such as additional Proof by Konoha, it is necessary to implement Relayer on your own.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://futaba.gitbook.io/docs/protocol/konoha.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.