Kakarot Indexer fits in the three-part architecture of the Kakarot zkEVM rollup (Kakarot EVM Cairo Programs, Kakarot RPC, Kakarot Indexer). It indexes the underlying CairoVM network on which Kakarot core is deployed in an Ethereum compatible format.
Why is an indexer needed?
- Because CairoVM chains (also called StarknetOS chains) have different data types, it is necessary to reformat the data in an Ethereum compatible way. We decided to perform this reformatting outside of the CairoVM chain, resulting in duplication of data, but more modularity. Note that this reformatting could've been done at runtime, at a high computational cost. Lastly, a third option would consist in forking a CairoVM client (e.g. Starknet) and change the data types directly within the storage of the full node.
Why not directly modify a CairoVM client?
- CairoVM chains are very novel and evolve quite fast. We are thus waiting for more stability to directly fork/modify a client. New engines, storage technologies and other innovations are being developed by talented teams (e.g. Starknet, Katana, Madara).
For reference, click to see how the above mentioned monolithic architecture would look like (note that it is not the current architecture of Kakarot zkEVM):
The Kakarot Indexer is based on the Apibara third-party service, an indexing product for StarknetOS chains. Apibara relies on Deno, a specific Javascript runtime. Follow the Deno installation requirements to be able to interact with the codebase.
Although this codebase is open-source, it relies on third-party software, the DNA protocol. One may read the code, run it locally, or self-host the indexer using Apibara's documentation and API keys.