{"owner":"linera-io","repo":"linera-protocol","hasSkills":true,"totalSkillsCount":3,"totalTokensCount":4712,"categories":["plugin-manifest","root-instruction","project-spec"],"hasMcp":false,"mcpConfig":null,"found":["linera-indexer/plugins/README.md","docs/llms.txt","linera-views/DESIGN.md"],"skills":{"linera-indexer/plugins/README.md":"<!-- cargo-rdme start -->\n\nPlugins for Linera indexer.\n\n<!-- cargo-rdme end -->\n\n## Contributing\n\nSee the [CONTRIBUTING](../../CONTRIBUTING.md) file for how to help out.\n\n## License\n\nThis project is available under the terms of the [Apache 2.0 license](../../LICENSE).\n","docs/llms.txt":"# Linera Documentation\n\n> Linera is a decentralized protocol designed for highly scalable, low-latency Web3 applications using microchain architecture.\n\n## Protocol\n\n- [The Linera Manual](https://linera.dev/): Introduction to Linera and entry point for developer documentation.\n- [Overview](https://linera.dev/protocol/overview.html): How microchains work, what makes Linera real-time and agent-friendly, and comparison to traditional multi-chain protocols.\n- [Roadmap](https://linera.dev/protocol/roadmap.html): Technical development roadmap across four testnets (Archimedes, Babbage, Conway) and mainnet.\n\n## Getting Started\n\n- [Getting Started](https://linera.dev/developers/getting_started.html): Entry point for Linera developer documentation.\n- [Installation](https://linera.dev/developers/getting_started/installation.html): Install the Linera toolchain from crates.io or GitHub, including system requirements.\n- [Hello, Linera](https://linera.dev/developers/getting_started/hello_linera.html): Create a wallet, connect to the testnet or a local network, build and publish your first application.\n\n## Core Concepts\n\n- [Microchains](https://linera.dev/developers/core_concepts/microchains.html): Lightweight single-user blockchains that enable parallel execution, cross-chain messaging, and chain ownership semantics.\n- [Wallets](https://linera.dev/developers/core_concepts/wallets.html): Creating developer wallets, selecting wallets, managing chains, and opening multi-user chains.\n- [Node Service](https://linera.dev/developers/core_concepts/node_service.html): Running a local node service, GraphiQL IDE, system and application GraphQL APIs, and connecting AI agents via MCP.\n- [Applications](https://linera.dev/developers/core_concepts/applications.html): Application deployment lifecycle, anatomy (contract, service, state), operations, messages, and authentication.\n- [Common Design Patterns](https://linera.dev/developers/core_concepts/design_patterns.html): Five design patterns using microchains — user-chain apps, client/server, personal chains, temporary chains, and just-in-time oracles.\n\n## Writing Backends\n\n- [Writing Linera Applications](https://linera.dev/developers/backend.html): Guide to building Web3 applications using the Linera SDK with Rust smart contracts and GraphQL services.\n- [Creating a Linera Project](https://linera.dev/developers/backend/creating_a_project.html): Initialize a new project with `linera project new` and overview of scaffolded files.\n- [Creating the Application State](https://linera.dev/developers/backend/state.html): Define persistent application state using linera-views for on-chain storage.\n- [Defining the ABI](https://linera.dev/developers/backend/abi.html): Define the Application Binary Interface with marker structs, contract ABI, and service ABI.\n- [Writing the Contract Binary](https://linera.dev/developers/backend/contract.html): Implement the contract lifecycle, handle operations and messages, and declare the ABI.\n- [Writing the Service Binary](https://linera.dev/developers/backend/service.html): Implement the read-only service with GraphQL compatibility for querying application state.\n- [Deploying the Application](https://linera.dev/developers/backend/deploy.html): Deploy to local networks, devnets, and testnets, then interact with the application.\n- [Cross-Chain Messages](https://linera.dev/developers/backend/messages.html): Send and handle messages between microchains, with a fungible token example.\n- [Calling other Applications](https://linera.dev/developers/backend/composition.html): Cross-application calls using `call_application`, with a crowd-funding example.\n- [Using Data Blobs](https://linera.dev/developers/backend/blobs.html): Store and retrieve large data blobs in Linera applications.\n- [Printing Logs from an Application](https://linera.dev/developers/backend/logging.html): Add logging to Linera contracts and services for debugging.\n- [Writing Tests](https://linera.dev/developers/backend/testing.html): Unit tests with mock runtime and integration tests with simulated validators using `cargo test`.\n\n## Writing Frontends\n\n- [Writing Linera Application Frontends](https://linera.dev/developers/frontend.html): Build interactive web frontends using Linera's JavaScript API with push notifications.\n- [Frontend Architecture Overview](https://linera.dev/developers/frontend/overview.html): How the Rust client library compiles to WebAssembly and wraps with JavaScript APIs via wasm-bindgen.\n- [Setting up the Frontend Development Environment](https://linera.dev/developers/frontend/setup.html): Supported browsers, creating HTML pages, serving frontends, and getting the client library.\n- [Interacting with Linera](https://linera.dev/developers/frontend/interactivity.html): Import the client library, initialize wallets, communicate with applications, and handle notifications.\n- [External Wallets](https://linera.dev/developers/frontend/wallets.html): Integrating external wallet providers like MetaMask and Dynamic via the Signer interface.\n\n## Advanced Topics\n\n- [Advanced Topics](https://linera.dev/developers/advanced_topics.html): Supplementary topics for Linera protocol developers.\n- [Contract Finalization](https://linera.dev/developers/advanced_topics/contract_finalize.html): How contract finalization works and when to use it for cleanup operations.\n- [Validators](https://linera.dev/developers/advanced_topics/validators.html): Architecture of a validator, including workers, shards, and the consensus process.\n- [Creating New Blocks](https://linera.dev/developers/advanced_topics/block_creation.html): How blocks are created, proposed, and confirmed across microchains.\n- [Applications that Handle Assets](https://linera.dev/developers/advanced_topics/assets.html): Safely handle assets on temporary chains with ownership, permissions, and chain closure.\n\n## Experimental\n\n- [Experimental Topics](https://linera.dev/developers/experimental.html): Experimental features unavailable on testnet that require compiling from source with specific Cargo features.\n- [Machine Learning on Linera](https://linera.dev/developers/experimental/ml.html): Run ML models on the edge using the contract/service split for secure and efficient inference.\n- [Using EVM Smart Contracts on Linera](https://linera.dev/developers/experimental/ethereum.html): Run Ethereum Virtual Machine smart contracts within Linera microchains using Revm integration.\n\n## Operators\n\n- [Node Operators (moved)](https://linera.dev/operators.html): Validator deployment docs have moved to <https://docs.infra.linera.net/>; deployment artifacts live at <https://github.com/linera-io/linera-artifacts>.\n\n## Appendix\n\n- [Glossary](https://linera.dev/appendix/glossary.html): Definitions of 50+ technical terms including microchain, validator, view, epoch, certificate, and more.\n\n## API Reference\n\n- [Linera SDK (docs.rs)](https://docs.rs/linera-sdk/latest/linera_sdk/): Rust API reference for the Linera SDK crate — contracts, services, views, and runtime.\n- [Linera Views (docs.rs)](https://docs.rs/linera-views/latest/linera_views/): Rust API reference for linera-views — persistent storage with MapView, CollectionView, and more.\n\n## GitHub Repositories\n\n- [linera-protocol](https://github.com/linera-io/linera-protocol): Main Linera protocol repository — validator, client, SDK, views, and example applications.\n- [linera-agents](https://github.com/linera-io/linera-agents): AI agent skills for building on Linera and trading on Linera prediction markets.\n- [mcp-demo](https://github.com/linera-io/mcp-demo): Demo MCP server connecting Claude to a Linera counter application via GraphQL.\n- [linera-web](https://github.com/linera-io/linera-web): The Linera Web client for browser-based chain interaction.\n- [pm-app](https://github.com/linera-io/pm-app): Prediction market demo app — parimutuel contracts, fungible tokens, faucet, and oracle.\n\n## Example Applications\n\n- [Counter](https://github.com/linera-io/linera-protocol/tree/main/examples/counter): Minimal counter application demonstrating basic Linera SDK usage.\n- [Fungible Token](https://github.com/linera-io/linera-protocol/tree/main/examples/fungible): ERC-20-style fungible token with cross-chain transfers.\n- [Crowd Funding](https://github.com/linera-io/linera-protocol/tree/main/examples/crowd-funding): Campaign-based crowd funding with cross-application calls to fungible tokens.\n- [Social](https://github.com/linera-io/linera-protocol/tree/main/examples/social): Social media application with posts and subscriptions across microchains.\n- [AMM](https://github.com/linera-io/linera-protocol/tree/main/examples/amm): Automated market maker for token swaps.\n- [Matching Engine](https://github.com/linera-io/linera-protocol/tree/main/examples/matching-engine): Order book matching engine for trading.\n- [Non-Fungible Token](https://github.com/linera-io/linera-protocol/tree/main/examples/non-fungible): NFT application with minting and transfers.\n- [LLM](https://github.com/linera-io/linera-protocol/tree/main/examples/llm): On-chain LLM inference example.\n- [Agent](https://github.com/linera-io/linera-protocol/tree/main/examples/agent): AI agent integration example.\n- [Ethereum Tracker](https://github.com/linera-io/linera-protocol/tree/main/examples/ethereum-tracker): Track Ethereum state from within Linera.\n- [Hex Game](https://github.com/linera-io/linera-protocol/tree/main/examples/hex-game): Two-player hex board game on microchains.\n\n## AI Agent Skills\n\n- [Linera Dev Skill](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/SKILL.md): AI assistant skill for building Linera applications — SDK, views, cross-chain messaging, GraphQL, MCP, testing, and deployment.\n- [Linera Markets Skill](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/SKILL.md): AI assistant skill for interacting with Linera prediction markets — market queries, placing predictions, P&L tracking, and automated trading strategies.\n\n## AI Agent Skill References\n\n- [Cross-Chain Messaging Guide](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/cross-chain-messaging.md): Advanced cross-chain messaging patterns for Linera applications.\n- [Deployment Guide](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/deployment-guide.md): Testnet and production deployment guide for Linera applications.\n- [Linera Views Guide](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/linera-views-guide.md): Storage patterns and view types for persistent state.\n- [MCP Integration Guide](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/mcp-integration.md): Full MCP setup guide for connecting AI agents to Linera.\n- [Testing Patterns](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/testing-patterns.md): Unit and integration testing patterns for Linera applications.\n- [API Examples](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/api-examples.md): Full GraphQL query and mutation examples with sample responses for prediction markets.\n- [Faucet Claim Recipe](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/faucet-claim-recipe.md): Step-by-step recipe for claiming tokens from the Linera faucet.\n- [RocksDB Locking Patterns](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/rocksdb-locking.md): Workarounds for RocksDB single-process locking in multi-wallet setups.\n- [Resolution Timing](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/resolution-timing.md): Market resolution timing, oracle delay, and generation lifecycle.\n- [Multi-Wallet Setup](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/multi-wallet-setup.md): Running multiple Linera wallets and environments on one machine.\n\n## Community Demos\n\n- [Atoma Demo](https://github.com/linera-io/atoma-demo): Linera application demonstrating interaction with Atoma Network.\n- [Walrus Demo](https://github.com/linera-io/walrus-demo): Linera application demonstrating interaction with Walrus decentralized storage.\n- [DePIN Map-Reduce Demo](https://github.com/linera-io/depin-map-reduce-demo): Map-reduce computation across microchains example.\n- [Buildathon Template](https://github.com/linera-io/buildathon-template): Dockerized application template for Linera buildathon submissions.\n","linera-views/DESIGN.md":"This document collects some design choices that were made in the `linera-views`.\nFor an overview, see `README.md`.\n\n# Design\n\n## Key Value Database Clients\n\nWe have designed a `KeyValueDatabase` trait that represents the basic functionalities\nof a key-value store whose keys are `Vec<u8>` and whose values are `Vec<u8>`.\n\nWe provide an implementation of the trait `KeyValueDatabase` for the following key-value stores:\n* `MemoryDatabase` uses the memory (and uses internally a simple B-Tree map).\n* `RocksDbDatabase` is a disk-based key-value store\n* `ScyllaDbDatabase` is a cloud-based Cassandra-compatible database.\n\nThe trait `KeyValueDatabase` was designed so that more storage solutions can be easily added in the future.\n\nThe `KeyValueDatabase` trait is also implemented for several internal constructions of clients:\n* The `LruCachingDatabase<K>` client implements the Least Recently Used (LRU)\ncaching of reads into the client.\n* The `ViewContainer<C>` client implements a key-value store client from a context.\n* The `ValueSplittingDatabase<K>` implements a client for which the\nsize of the values is unbounded, on top of another client for which it is bounded.\n(Some databases have strict limitations on the value size.)\n\n## Views\n\nA view is a container that mimics some of the properties of classic containers such\nas `VecDeque`, `BTreeMap`, etc. with the following goals:\n* The data structure can be written to the key-value store and loaded from there.\n* The changes are first done in memory and accessed there. The changes can be committed\nto the key-value store client when adequate.\n\nThere are various views corresponding to several use cases. All of those are\nimplemented by mapping the values in their specific types to their serializations.\n\n## Allowed keys, base key and prefixes\n\nThe keys are constructed step by step from the prefix to the full key. So, whenever\nwe have a view or any other object then we have a `base_key` associated with it and\nwith no other objects. A view is associated with many keys, all of which share the same\n`base_key` as prefix.\nThis leads us to introduce a trait `Context` that can be implemented with a specific\n`KeyValueDatabase` client and a `base_key`.\n\nAnother issue to consider is that we do not want to just store the values, but we\nalso need to accommodate other features:\n* Administrative data (like journal) need to store some data starting from the `base_key`.\n* Some of the values need to be split into several smaller values.\n\nThe rules for constructing keys are the following:\n* For the construction of `struct` objects of associated base key `base_key` we do the\nfollowing: If the corresponding type has entries `entry_0`, ..., `entry_k` then the\nbase key of the object associated with the `k`-th entry is `[base_key * * * *]` where\n`[* * * *]` are the four bytes of `k` as a `u32`.\n* For each view type, we have some associated data. Some are the hash, others the counts\n(e.g. for `LogView` and `QueueView`) and some the index. The corresponding enum is\nnamed `KeyTag` for each of those containers. For the index, the values are serialized.\n* For a given base key `base_key` the keys of the form `[base_key tag]` with tags in\n`0..MIN_VIEW_TAG` are reserved for administrative data.\n\nThese constructions are done in order to satisfy the following property: The set of keys\nof a view is prefix-free. That is if a key is of the form `key = [a b]` then `a` is\nnot a key. This property is important for other functionalities.\nIf the user is using a single view then for whatever `base_key` is chosen, the set of keys\ncreated will be prefix-free. If several views are created then their base keys must be\nchosen to be prefix-free so that the whole set of keys is prefix-free.\n\n## API of the `KeyValueDatabase`\n\nThe design of the key-value store client is done in the following way:\n* We can put a `(key, value)` and delete a `key`.\n* We can delete keys having a specific prefix.\n* We can retrieve the list of keys having a specific prefix. Similarly, we can\nretrieve the list of `(key, value)` whose keys have a specific prefix.\n* Also, the list of the keys is provided in the lexicographic order.\n\n## Journaling\n\nWe want to make sure that all operations are done on the database in an atomic\nway. That is the operations have to be processed completely. The idea is to\nstore the journal in the `[base_key 0 * * * *]` keys with `[* * * *]` the\nserialization of an `u32` entry.\nThose keys are not colliding with the other keys since their value is of the\nform `[base_key tag *]` with `tag >= MIN_VIEW_TAG` and currently, we have\n`MIN_VIEW_TAG = 1`.\n\nThe journaling allows to have operations in an atomic way. It is done in the\nfollowing way:\n* When a `Batch` of operations needs to be processed, the operations are written\ninto blocks that can be processed atomically. All together the blocks for the\n\"journal\". When the journal has been written then the counter is written and\nonly at that point is the journal considered written.\n* Each block is then processed atomically. If an interruption occurs then\nthe block entries would be processed after accessing the database the next time.\n\n## Splitting large values across keys\n\nSome key-value store clients limit the size of the values (named `MAX_VALUE_SIZE`\nin the code). `ValueSplittingDatabase` is a wrapper that accepts values\nof any size. Internally, it splits them into smaller pieces and stores them\nusing a wrapped, possibly size-limited, client.\n\nThe built key-value store client has `MAX_VALUE_SIZE` set to its maximum possible\nvalue. This forces us to split the value into several smaller values. This is\nuseful for stores that impose a limit on their value size.\n\nDesign is the following:\n* For every `key` we build several corresponding keys `[key * * * *]` that contain\neach a piece of the full value.\nThe `[* * * *]` is the serialization of the index which is `u32` so that\nthe order of the serialization is the same as the order of the `u32` entries.\n* For the first key, that is `[key 0 0 0 0]` the corresponding value is `[* * * * value_0]`\nwith `[* * * *]` being the serialization of the `u32` count of the number of blocks\nand `value_0` the first block of the value. For the other keys `[key * * * *]` the\ncorresponding value is `value_k` with `value_k` the k-th entry in the value. The full\nvalue is reconstructed as `value = [value_0 value_1 .... value_N]`\nThe number of blocks is always non-zero, even if the value is empty.\n\nThe effective working of the system relies on several design choices.\n* In `find_keys_by_prefix` and similar, the keys are\nreturned in lexicographic order.\n* The count and indices are serialized as `u32` and the serialization is done\nso that the `u32` ordering is the same as the lexicographic ordering. So, we\nget first the first key (and so the count) and then the segment keys one by\none in the correct order.\n* Suppose that we have written a `(key, value_1)` with several segments and then\nwe replace by a `(key, value_2)` which has fewer segments.\nOur choice is to leave the old segments in the database. Same with delete:\nwe just delete the first key.\n* We avoid the overflowing of the system by the following trick: When we delete\na view, we do a delete by prefix, which thus deletes the old segments if present.\n* In order to delete all the unused segments when overwriting a value, every write\nwould need to have a read just before which is expensive.\n\nA key difficulty of this modelization is that we are using prefixes extensively\nand so by adding the index of the form `[* * * *]` we are potentially creating\nsome collisions. That is if we delete a key of the form `[key 0 0]` we would\nalso delete segments of the key of the form `key`. However, this cannot happen\nbecause the set of keys is prefix-free.\n"},"files":{"linera-indexer/plugins/README.md":"<!-- cargo-rdme start -->\n\nPlugins for Linera indexer.\n\n<!-- cargo-rdme end -->\n\n## Contributing\n\nSee the [CONTRIBUTING](../../CONTRIBUTING.md) file for how to help out.\n\n## License\n\nThis project is available under the terms of the [Apache 2.0 license](../../LICENSE).\n","docs/llms.txt":"# Linera Documentation\n\n> Linera is a decentralized protocol designed for highly scalable, low-latency Web3 applications using microchain architecture.\n\n## Protocol\n\n- [The Linera Manual](https://linera.dev/): Introduction to Linera and entry point for developer documentation.\n- [Overview](https://linera.dev/protocol/overview.html): How microchains work, what makes Linera real-time and agent-friendly, and comparison to traditional multi-chain protocols.\n- [Roadmap](https://linera.dev/protocol/roadmap.html): Technical development roadmap across four testnets (Archimedes, Babbage, Conway) and mainnet.\n\n## Getting Started\n\n- [Getting Started](https://linera.dev/developers/getting_started.html): Entry point for Linera developer documentation.\n- [Installation](https://linera.dev/developers/getting_started/installation.html): Install the Linera toolchain from crates.io or GitHub, including system requirements.\n- [Hello, Linera](https://linera.dev/developers/getting_started/hello_linera.html): Create a wallet, connect to the testnet or a local network, build and publish your first application.\n\n## Core Concepts\n\n- [Microchains](https://linera.dev/developers/core_concepts/microchains.html): Lightweight single-user blockchains that enable parallel execution, cross-chain messaging, and chain ownership semantics.\n- [Wallets](https://linera.dev/developers/core_concepts/wallets.html): Creating developer wallets, selecting wallets, managing chains, and opening multi-user chains.\n- [Node Service](https://linera.dev/developers/core_concepts/node_service.html): Running a local node service, GraphiQL IDE, system and application GraphQL APIs, and connecting AI agents via MCP.\n- [Applications](https://linera.dev/developers/core_concepts/applications.html): Application deployment lifecycle, anatomy (contract, service, state), operations, messages, and authentication.\n- [Common Design Patterns](https://linera.dev/developers/core_concepts/design_patterns.html): Five design patterns using microchains — user-chain apps, client/server, personal chains, temporary chains, and just-in-time oracles.\n\n## Writing Backends\n\n- [Writing Linera Applications](https://linera.dev/developers/backend.html): Guide to building Web3 applications using the Linera SDK with Rust smart contracts and GraphQL services.\n- [Creating a Linera Project](https://linera.dev/developers/backend/creating_a_project.html): Initialize a new project with `linera project new` and overview of scaffolded files.\n- [Creating the Application State](https://linera.dev/developers/backend/state.html): Define persistent application state using linera-views for on-chain storage.\n- [Defining the ABI](https://linera.dev/developers/backend/abi.html): Define the Application Binary Interface with marker structs, contract ABI, and service ABI.\n- [Writing the Contract Binary](https://linera.dev/developers/backend/contract.html): Implement the contract lifecycle, handle operations and messages, and declare the ABI.\n- [Writing the Service Binary](https://linera.dev/developers/backend/service.html): Implement the read-only service with GraphQL compatibility for querying application state.\n- [Deploying the Application](https://linera.dev/developers/backend/deploy.html): Deploy to local networks, devnets, and testnets, then interact with the application.\n- [Cross-Chain Messages](https://linera.dev/developers/backend/messages.html): Send and handle messages between microchains, with a fungible token example.\n- [Calling other Applications](https://linera.dev/developers/backend/composition.html): Cross-application calls using `call_application`, with a crowd-funding example.\n- [Using Data Blobs](https://linera.dev/developers/backend/blobs.html): Store and retrieve large data blobs in Linera applications.\n- [Printing Logs from an Application](https://linera.dev/developers/backend/logging.html): Add logging to Linera contracts and services for debugging.\n- [Writing Tests](https://linera.dev/developers/backend/testing.html): Unit tests with mock runtime and integration tests with simulated validators using `cargo test`.\n\n## Writing Frontends\n\n- [Writing Linera Application Frontends](https://linera.dev/developers/frontend.html): Build interactive web frontends using Linera's JavaScript API with push notifications.\n- [Frontend Architecture Overview](https://linera.dev/developers/frontend/overview.html): How the Rust client library compiles to WebAssembly and wraps with JavaScript APIs via wasm-bindgen.\n- [Setting up the Frontend Development Environment](https://linera.dev/developers/frontend/setup.html): Supported browsers, creating HTML pages, serving frontends, and getting the client library.\n- [Interacting with Linera](https://linera.dev/developers/frontend/interactivity.html): Import the client library, initialize wallets, communicate with applications, and handle notifications.\n- [External Wallets](https://linera.dev/developers/frontend/wallets.html): Integrating external wallet providers like MetaMask and Dynamic via the Signer interface.\n\n## Advanced Topics\n\n- [Advanced Topics](https://linera.dev/developers/advanced_topics.html): Supplementary topics for Linera protocol developers.\n- [Contract Finalization](https://linera.dev/developers/advanced_topics/contract_finalize.html): How contract finalization works and when to use it for cleanup operations.\n- [Validators](https://linera.dev/developers/advanced_topics/validators.html): Architecture of a validator, including workers, shards, and the consensus process.\n- [Creating New Blocks](https://linera.dev/developers/advanced_topics/block_creation.html): How blocks are created, proposed, and confirmed across microchains.\n- [Applications that Handle Assets](https://linera.dev/developers/advanced_topics/assets.html): Safely handle assets on temporary chains with ownership, permissions, and chain closure.\n\n## Experimental\n\n- [Experimental Topics](https://linera.dev/developers/experimental.html): Experimental features unavailable on testnet that require compiling from source with specific Cargo features.\n- [Machine Learning on Linera](https://linera.dev/developers/experimental/ml.html): Run ML models on the edge using the contract/service split for secure and efficient inference.\n- [Using EVM Smart Contracts on Linera](https://linera.dev/developers/experimental/ethereum.html): Run Ethereum Virtual Machine smart contracts within Linera microchains using Revm integration.\n\n## Operators\n\n- [Node Operators (moved)](https://linera.dev/operators.html): Validator deployment docs have moved to <https://docs.infra.linera.net/>; deployment artifacts live at <https://github.com/linera-io/linera-artifacts>.\n\n## Appendix\n\n- [Glossary](https://linera.dev/appendix/glossary.html): Definitions of 50+ technical terms including microchain, validator, view, epoch, certificate, and more.\n\n## API Reference\n\n- [Linera SDK (docs.rs)](https://docs.rs/linera-sdk/latest/linera_sdk/): Rust API reference for the Linera SDK crate — contracts, services, views, and runtime.\n- [Linera Views (docs.rs)](https://docs.rs/linera-views/latest/linera_views/): Rust API reference for linera-views — persistent storage with MapView, CollectionView, and more.\n\n## GitHub Repositories\n\n- [linera-protocol](https://github.com/linera-io/linera-protocol): Main Linera protocol repository — validator, client, SDK, views, and example applications.\n- [linera-agents](https://github.com/linera-io/linera-agents): AI agent skills for building on Linera and trading on Linera prediction markets.\n- [mcp-demo](https://github.com/linera-io/mcp-demo): Demo MCP server connecting Claude to a Linera counter application via GraphQL.\n- [linera-web](https://github.com/linera-io/linera-web): The Linera Web client for browser-based chain interaction.\n- [pm-app](https://github.com/linera-io/pm-app): Prediction market demo app — parimutuel contracts, fungible tokens, faucet, and oracle.\n\n## Example Applications\n\n- [Counter](https://github.com/linera-io/linera-protocol/tree/main/examples/counter): Minimal counter application demonstrating basic Linera SDK usage.\n- [Fungible Token](https://github.com/linera-io/linera-protocol/tree/main/examples/fungible): ERC-20-style fungible token with cross-chain transfers.\n- [Crowd Funding](https://github.com/linera-io/linera-protocol/tree/main/examples/crowd-funding): Campaign-based crowd funding with cross-application calls to fungible tokens.\n- [Social](https://github.com/linera-io/linera-protocol/tree/main/examples/social): Social media application with posts and subscriptions across microchains.\n- [AMM](https://github.com/linera-io/linera-protocol/tree/main/examples/amm): Automated market maker for token swaps.\n- [Matching Engine](https://github.com/linera-io/linera-protocol/tree/main/examples/matching-engine): Order book matching engine for trading.\n- [Non-Fungible Token](https://github.com/linera-io/linera-protocol/tree/main/examples/non-fungible): NFT application with minting and transfers.\n- [LLM](https://github.com/linera-io/linera-protocol/tree/main/examples/llm): On-chain LLM inference example.\n- [Agent](https://github.com/linera-io/linera-protocol/tree/main/examples/agent): AI agent integration example.\n- [Ethereum Tracker](https://github.com/linera-io/linera-protocol/tree/main/examples/ethereum-tracker): Track Ethereum state from within Linera.\n- [Hex Game](https://github.com/linera-io/linera-protocol/tree/main/examples/hex-game): Two-player hex board game on microchains.\n\n## AI Agent Skills\n\n- [Linera Dev Skill](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/SKILL.md): AI assistant skill for building Linera applications — SDK, views, cross-chain messaging, GraphQL, MCP, testing, and deployment.\n- [Linera Markets Skill](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/SKILL.md): AI assistant skill for interacting with Linera prediction markets — market queries, placing predictions, P&L tracking, and automated trading strategies.\n\n## AI Agent Skill References\n\n- [Cross-Chain Messaging Guide](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/cross-chain-messaging.md): Advanced cross-chain messaging patterns for Linera applications.\n- [Deployment Guide](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/deployment-guide.md): Testnet and production deployment guide for Linera applications.\n- [Linera Views Guide](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/linera-views-guide.md): Storage patterns and view types for persistent state.\n- [MCP Integration Guide](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/mcp-integration.md): Full MCP setup guide for connecting AI agents to Linera.\n- [Testing Patterns](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/testing-patterns.md): Unit and integration testing patterns for Linera applications.\n- [API Examples](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/api-examples.md): Full GraphQL query and mutation examples with sample responses for prediction markets.\n- [Faucet Claim Recipe](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/faucet-claim-recipe.md): Step-by-step recipe for claiming tokens from the Linera faucet.\n- [RocksDB Locking Patterns](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/rocksdb-locking.md): Workarounds for RocksDB single-process locking in multi-wallet setups.\n- [Resolution Timing](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/resolution-timing.md): Market resolution timing, oracle delay, and generation lifecycle.\n- [Multi-Wallet Setup](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/multi-wallet-setup.md): Running multiple Linera wallets and environments on one machine.\n\n## Community Demos\n\n- [Atoma Demo](https://github.com/linera-io/atoma-demo): Linera application demonstrating interaction with Atoma Network.\n- [Walrus Demo](https://github.com/linera-io/walrus-demo): Linera application demonstrating interaction with Walrus decentralized storage.\n- [DePIN Map-Reduce Demo](https://github.com/linera-io/depin-map-reduce-demo): Map-reduce computation across microchains example.\n- [Buildathon Template](https://github.com/linera-io/buildathon-template): Dockerized application template for Linera buildathon submissions.\n","linera-views/DESIGN.md":"This document collects some design choices that were made in the `linera-views`.\nFor an overview, see `README.md`.\n\n# Design\n\n## Key Value Database Clients\n\nWe have designed a `KeyValueDatabase` trait that represents the basic functionalities\nof a key-value store whose keys are `Vec<u8>` and whose values are `Vec<u8>`.\n\nWe provide an implementation of the trait `KeyValueDatabase` for the following key-value stores:\n* `MemoryDatabase` uses the memory (and uses internally a simple B-Tree map).\n* `RocksDbDatabase` is a disk-based key-value store\n* `ScyllaDbDatabase` is a cloud-based Cassandra-compatible database.\n\nThe trait `KeyValueDatabase` was designed so that more storage solutions can be easily added in the future.\n\nThe `KeyValueDatabase` trait is also implemented for several internal constructions of clients:\n* The `LruCachingDatabase<K>` client implements the Least Recently Used (LRU)\ncaching of reads into the client.\n* The `ViewContainer<C>` client implements a key-value store client from a context.\n* The `ValueSplittingDatabase<K>` implements a client for which the\nsize of the values is unbounded, on top of another client for which it is bounded.\n(Some databases have strict limitations on the value size.)\n\n## Views\n\nA view is a container that mimics some of the properties of classic containers such\nas `VecDeque`, `BTreeMap`, etc. with the following goals:\n* The data structure can be written to the key-value store and loaded from there.\n* The changes are first done in memory and accessed there. The changes can be committed\nto the key-value store client when adequate.\n\nThere are various views corresponding to several use cases. All of those are\nimplemented by mapping the values in their specific types to their serializations.\n\n## Allowed keys, base key and prefixes\n\nThe keys are constructed step by step from the prefix to the full key. So, whenever\nwe have a view or any other object then we have a `base_key` associated with it and\nwith no other objects. A view is associated with many keys, all of which share the same\n`base_key` as prefix.\nThis leads us to introduce a trait `Context` that can be implemented with a specific\n`KeyValueDatabase` client and a `base_key`.\n\nAnother issue to consider is that we do not want to just store the values, but we\nalso need to accommodate other features:\n* Administrative data (like journal) need to store some data starting from the `base_key`.\n* Some of the values need to be split into several smaller values.\n\nThe rules for constructing keys are the following:\n* For the construction of `struct` objects of associated base key `base_key` we do the\nfollowing: If the corresponding type has entries `entry_0`, ..., `entry_k` then the\nbase key of the object associated with the `k`-th entry is `[base_key * * * *]` where\n`[* * * *]` are the four bytes of `k` as a `u32`.\n* For each view type, we have some associated data. Some are the hash, others the counts\n(e.g. for `LogView` and `QueueView`) and some the index. The corresponding enum is\nnamed `KeyTag` for each of those containers. For the index, the values are serialized.\n* For a given base key `base_key` the keys of the form `[base_key tag]` with tags in\n`0..MIN_VIEW_TAG` are reserved for administrative data.\n\nThese constructions are done in order to satisfy the following property: The set of keys\nof a view is prefix-free. That is if a key is of the form `key = [a b]` then `a` is\nnot a key. This property is important for other functionalities.\nIf the user is using a single view then for whatever `base_key` is chosen, the set of keys\ncreated will be prefix-free. If several views are created then their base keys must be\nchosen to be prefix-free so that the whole set of keys is prefix-free.\n\n## API of the `KeyValueDatabase`\n\nThe design of the key-value store client is done in the following way:\n* We can put a `(key, value)` and delete a `key`.\n* We can delete keys having a specific prefix.\n* We can retrieve the list of keys having a specific prefix. Similarly, we can\nretrieve the list of `(key, value)` whose keys have a specific prefix.\n* Also, the list of the keys is provided in the lexicographic order.\n\n## Journaling\n\nWe want to make sure that all operations are done on the database in an atomic\nway. That is the operations have to be processed completely. The idea is to\nstore the journal in the `[base_key 0 * * * *]` keys with `[* * * *]` the\nserialization of an `u32` entry.\nThose keys are not colliding with the other keys since their value is of the\nform `[base_key tag *]` with `tag >= MIN_VIEW_TAG` and currently, we have\n`MIN_VIEW_TAG = 1`.\n\nThe journaling allows to have operations in an atomic way. It is done in the\nfollowing way:\n* When a `Batch` of operations needs to be processed, the operations are written\ninto blocks that can be processed atomically. All together the blocks for the\n\"journal\". When the journal has been written then the counter is written and\nonly at that point is the journal considered written.\n* Each block is then processed atomically. If an interruption occurs then\nthe block entries would be processed after accessing the database the next time.\n\n## Splitting large values across keys\n\nSome key-value store clients limit the size of the values (named `MAX_VALUE_SIZE`\nin the code). `ValueSplittingDatabase` is a wrapper that accepts values\nof any size. Internally, it splits them into smaller pieces and stores them\nusing a wrapped, possibly size-limited, client.\n\nThe built key-value store client has `MAX_VALUE_SIZE` set to its maximum possible\nvalue. This forces us to split the value into several smaller values. This is\nuseful for stores that impose a limit on their value size.\n\nDesign is the following:\n* For every `key` we build several corresponding keys `[key * * * *]` that contain\neach a piece of the full value.\nThe `[* * * *]` is the serialization of the index which is `u32` so that\nthe order of the serialization is the same as the order of the `u32` entries.\n* For the first key, that is `[key 0 0 0 0]` the corresponding value is `[* * * * value_0]`\nwith `[* * * *]` being the serialization of the `u32` count of the number of blocks\nand `value_0` the first block of the value. For the other keys `[key * * * *]` the\ncorresponding value is `value_k` with `value_k` the k-th entry in the value. The full\nvalue is reconstructed as `value = [value_0 value_1 .... value_N]`\nThe number of blocks is always non-zero, even if the value is empty.\n\nThe effective working of the system relies on several design choices.\n* In `find_keys_by_prefix` and similar, the keys are\nreturned in lexicographic order.\n* The count and indices are serialized as `u32` and the serialization is done\nso that the `u32` ordering is the same as the lexicographic ordering. So, we\nget first the first key (and so the count) and then the segment keys one by\none in the correct order.\n* Suppose that we have written a `(key, value_1)` with several segments and then\nwe replace by a `(key, value_2)` which has fewer segments.\nOur choice is to leave the old segments in the database. Same with delete:\nwe just delete the first key.\n* We avoid the overflowing of the system by the following trick: When we delete\na view, we do a delete by prefix, which thus deletes the old segments if present.\n* In order to delete all the unused segments when overwriting a value, every write\nwould need to have a read just before which is expensive.\n\nA key difficulty of this modelization is that we are using prefixes extensively\nand so by adding the index of the form `[* * * *]` we are potentially creating\nsome collisions. That is if we delete a key of the form `[key 0 0]` we would\nalso delete segments of the key of the form `key`. However, this cannot happen\nbecause the set of keys is prefix-free.\n"},"items":[{"name":"llms.txt","path":"docs/llms.txt","rawUrl":"https://raw.githubusercontent.com/linera-io/linera-protocol/HEAD/docs/llms.txt","title":"docs - LLM Index & Context Digest","category":"root-instruction","format":"text","content":"# Linera Documentation\n\n> Linera is a decentralized protocol designed for highly scalable, low-latency Web3 applications using microchain architecture.\n\n## Protocol\n\n- [The Linera Manual](https://linera.dev/): Introduction to Linera and entry point for developer documentation.\n- [Overview](https://linera.dev/protocol/overview.html): How microchains work, what makes Linera real-time and agent-friendly, and comparison to traditional multi-chain protocols.\n- [Roadmap](https://linera.dev/protocol/roadmap.html): Technical development roadmap across four testnets (Archimedes, Babbage, Conway) and mainnet.\n\n## Getting Started\n\n- [Getting Started](https://linera.dev/developers/getting_started.html): Entry point for Linera developer documentation.\n- [Installation](https://linera.dev/developers/getting_started/installation.html): Install the Linera toolchain from crates.io or GitHub, including system requirements.\n- [Hello, Linera](https://linera.dev/developers/getting_started/hello_linera.html): Create a wallet, connect to the testnet or a local network, build and publish your first application.\n\n## Core Concepts\n\n- [Microchains](https://linera.dev/developers/core_concepts/microchains.html): Lightweight single-user blockchains that enable parallel execution, cross-chain messaging, and chain ownership semantics.\n- [Wallets](https://linera.dev/developers/core_concepts/wallets.html): Creating developer wallets, selecting wallets, managing chains, and opening multi-user chains.\n- [Node Service](https://linera.dev/developers/core_concepts/node_service.html): Running a local node service, GraphiQL IDE, system and application GraphQL APIs, and connecting AI agents via MCP.\n- [Applications](https://linera.dev/developers/core_concepts/applications.html): Application deployment lifecycle, anatomy (contract, service, state), operations, messages, and authentication.\n- [Common Design Patterns](https://linera.dev/developers/core_concepts/design_patterns.html): Five design patterns using microchains — user-chain apps, client/server, personal chains, temporary chains, and just-in-time oracles.\n\n## Writing Backends\n\n- [Writing Linera Applications](https://linera.dev/developers/backend.html): Guide to building Web3 applications using the Linera SDK with Rust smart contracts and GraphQL services.\n- [Creating a Linera Project](https://linera.dev/developers/backend/creating_a_project.html): Initialize a new project with `linera project new` and overview of scaffolded files.\n- [Creating the Application State](https://linera.dev/developers/backend/state.html): Define persistent application state using linera-views for on-chain storage.\n- [Defining the ABI](https://linera.dev/developers/backend/abi.html): Define the Application Binary Interface with marker structs, contract ABI, and service ABI.\n- [Writing the Contract Binary](https://linera.dev/developers/backend/contract.html): Implement the contract lifecycle, handle operations and messages, and declare the ABI.\n- [Writing the Service Binary](https://linera.dev/developers/backend/service.html): Implement the read-only service with GraphQL compatibility for querying application state.\n- [Deploying the Application](https://linera.dev/developers/backend/deploy.html): Deploy to local networks, devnets, and testnets, then interact with the application.\n- [Cross-Chain Messages](https://linera.dev/developers/backend/messages.html): Send and handle messages between microchains, with a fungible token example.\n- [Calling other Applications](https://linera.dev/developers/backend/composition.html): Cross-application calls using `call_application`, with a crowd-funding example.\n- [Using Data Blobs](https://linera.dev/developers/backend/blobs.html): Store and retrieve large data blobs in Linera applications.\n- [Printing Logs from an Application](https://linera.dev/developers/backend/logging.html): Add logging to Linera contracts and services for debugging.\n- [Writing Tests](https://linera.dev/developers/backend/testing.html): Unit tests with mock runtime and integration tests with simulated validators using `cargo test`.\n\n## Writing Frontends\n\n- [Writing Linera Application Frontends](https://linera.dev/developers/frontend.html): Build interactive web frontends using Linera's JavaScript API with push notifications.\n- [Frontend Architecture Overview](https://linera.dev/developers/frontend/overview.html): How the Rust client library compiles to WebAssembly and wraps with JavaScript APIs via wasm-bindgen.\n- [Setting up the Frontend Development Environment](https://linera.dev/developers/frontend/setup.html): Supported browsers, creating HTML pages, serving frontends, and getting the client library.\n- [Interacting with Linera](https://linera.dev/developers/frontend/interactivity.html): Import the client library, initialize wallets, communicate with applications, and handle notifications.\n- [External Wallets](https://linera.dev/developers/frontend/wallets.html): Integrating external wallet providers like MetaMask and Dynamic via the Signer interface.\n\n## Advanced Topics\n\n- [Advanced Topics](https://linera.dev/developers/advanced_topics.html): Supplementary topics for Linera protocol developers.\n- [Contract Finalization](https://linera.dev/developers/advanced_topics/contract_finalize.html): How contract finalization works and when to use it for cleanup operations.\n- [Validators](https://linera.dev/developers/advanced_topics/validators.html): Architecture of a validator, including workers, shards, and the consensus process.\n- [Creating New Blocks](https://linera.dev/developers/advanced_topics/block_creation.html): How blocks are created, proposed, and confirmed across microchains.\n- [Applications that Handle Assets](https://linera.dev/developers/advanced_topics/assets.html): Safely handle assets on temporary chains with ownership, permissions, and chain closure.\n\n## Experimental\n\n- [Experimental Topics](https://linera.dev/developers/experimental.html): Experimental features unavailable on testnet that require compiling from source with specific Cargo features.\n- [Machine Learning on Linera](https://linera.dev/developers/experimental/ml.html): Run ML models on the edge using the contract/service split for secure and efficient inference.\n- [Using EVM Smart Contracts on Linera](https://linera.dev/developers/experimental/ethereum.html): Run Ethereum Virtual Machine smart contracts within Linera microchains using Revm integration.\n\n## Operators\n\n- [Node Operators (moved)](https://linera.dev/operators.html): Validator deployment docs have moved to <https://docs.infra.linera.net/>; deployment artifacts live at <https://github.com/linera-io/linera-artifacts>.\n\n## Appendix\n\n- [Glossary](https://linera.dev/appendix/glossary.html): Definitions of 50+ technical terms including microchain, validator, view, epoch, certificate, and more.\n\n## API Reference\n\n- [Linera SDK (docs.rs)](https://docs.rs/linera-sdk/latest/linera_sdk/): Rust API reference for the Linera SDK crate — contracts, services, views, and runtime.\n- [Linera Views (docs.rs)](https://docs.rs/linera-views/latest/linera_views/): Rust API reference for linera-views — persistent storage with MapView, CollectionView, and more.\n\n## GitHub Repositories\n\n- [linera-protocol](https://github.com/linera-io/linera-protocol): Main Linera protocol repository — validator, client, SDK, views, and example applications.\n- [linera-agents](https://github.com/linera-io/linera-agents): AI agent skills for building on Linera and trading on Linera prediction markets.\n- [mcp-demo](https://github.com/linera-io/mcp-demo): Demo MCP server connecting Claude to a Linera counter application via GraphQL.\n- [linera-web](https://github.com/linera-io/linera-web): The Linera Web client for browser-based chain interaction.\n- [pm-app](https://github.com/linera-io/pm-app): Prediction market demo app — parimutuel contracts, fungible tokens, faucet, and oracle.\n\n## Example Applications\n\n- [Counter](https://github.com/linera-io/linera-protocol/tree/main/examples/counter): Minimal counter application demonstrating basic Linera SDK usage.\n- [Fungible Token](https://github.com/linera-io/linera-protocol/tree/main/examples/fungible): ERC-20-style fungible token with cross-chain transfers.\n- [Crowd Funding](https://github.com/linera-io/linera-protocol/tree/main/examples/crowd-funding): Campaign-based crowd funding with cross-application calls to fungible tokens.\n- [Social](https://github.com/linera-io/linera-protocol/tree/main/examples/social): Social media application with posts and subscriptions across microchains.\n- [AMM](https://github.com/linera-io/linera-protocol/tree/main/examples/amm): Automated market maker for token swaps.\n- [Matching Engine](https://github.com/linera-io/linera-protocol/tree/main/examples/matching-engine): Order book matching engine for trading.\n- [Non-Fungible Token](https://github.com/linera-io/linera-protocol/tree/main/examples/non-fungible): NFT application with minting and transfers.\n- [LLM](https://github.com/linera-io/linera-protocol/tree/main/examples/llm): On-chain LLM inference example.\n- [Agent](https://github.com/linera-io/linera-protocol/tree/main/examples/agent): AI agent integration example.\n- [Ethereum Tracker](https://github.com/linera-io/linera-protocol/tree/main/examples/ethereum-tracker): Track Ethereum state from within Linera.\n- [Hex Game](https://github.com/linera-io/linera-protocol/tree/main/examples/hex-game): Two-player hex board game on microchains.\n\n## AI Agent Skills\n\n- [Linera Dev Skill](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/SKILL.md): AI assistant skill for building Linera applications — SDK, views, cross-chain messaging, GraphQL, MCP, testing, and deployment.\n- [Linera Markets Skill](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/SKILL.md): AI assistant skill for interacting with Linera prediction markets — market queries, placing predictions, P&L tracking, and automated trading strategies.\n\n## AI Agent Skill References\n\n- [Cross-Chain Messaging Guide](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/cross-chain-messaging.md): Advanced cross-chain messaging patterns for Linera applications.\n- [Deployment Guide](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/deployment-guide.md): Testnet and production deployment guide for Linera applications.\n- [Linera Views Guide](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/linera-views-guide.md): Storage patterns and view types for persistent state.\n- [MCP Integration Guide](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/mcp-integration.md): Full MCP setup guide for connecting AI agents to Linera.\n- [Testing Patterns](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/testing-patterns.md): Unit and integration testing patterns for Linera applications.\n- [API Examples](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/api-examples.md): Full GraphQL query and mutation examples with sample responses for prediction markets.\n- [Faucet Claim Recipe](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/faucet-claim-recipe.md): Step-by-step recipe for claiming tokens from the Linera faucet.\n- [RocksDB Locking Patterns](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/rocksdb-locking.md): Workarounds for RocksDB single-process locking in multi-wallet setups.\n- [Resolution Timing](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/resolution-timing.md): Market resolution timing, oracle delay, and generation lifecycle.\n- [Multi-Wallet Setup](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/multi-wallet-setup.md): Running multiple Linera wallets and environments on one machine.\n\n## Community Demos\n\n- [Atoma Demo](https://github.com/linera-io/atoma-demo): Linera application demonstrating interaction with Atoma Network.\n- [Walrus Demo](https://github.com/linera-io/walrus-demo): Linera application demonstrating interaction with Walrus decentralized storage.\n- [DePIN Map-Reduce Demo](https://github.com/linera-io/depin-map-reduce-demo): Map-reduce computation across microchains example.\n- [Buildathon Template](https://github.com/linera-io/buildathon-template): Dockerized application template for Linera buildathon submissions.\n","isInternal":false,"tokens":2801,"sizeBytes":12506},{"name":"DESIGN.md","path":"linera-views/DESIGN.md","rawUrl":"https://raw.githubusercontent.com/linera-io/linera-protocol/HEAD/linera-views/DESIGN.md","title":"linera-views - UI Design System & Style Tokens","category":"project-spec","format":"markdown","content":"This document collects some design choices that were made in the `linera-views`.\nFor an overview, see `README.md`.\n\n# Design\n\n## Key Value Database Clients\n\nWe have designed a `KeyValueDatabase` trait that represents the basic functionalities\nof a key-value store whose keys are `Vec<u8>` and whose values are `Vec<u8>`.\n\nWe provide an implementation of the trait `KeyValueDatabase` for the following key-value stores:\n* `MemoryDatabase` uses the memory (and uses internally a simple B-Tree map).\n* `RocksDbDatabase` is a disk-based key-value store\n* `ScyllaDbDatabase` is a cloud-based Cassandra-compatible database.\n\nThe trait `KeyValueDatabase` was designed so that more storage solutions can be easily added in the future.\n\nThe `KeyValueDatabase` trait is also implemented for several internal constructions of clients:\n* The `LruCachingDatabase<K>` client implements the Least Recently Used (LRU)\ncaching of reads into the client.\n* The `ViewContainer<C>` client implements a key-value store client from a context.\n* The `ValueSplittingDatabase<K>` implements a client for which the\nsize of the values is unbounded, on top of another client for which it is bounded.\n(Some databases have strict limitations on the value size.)\n\n## Views\n\nA view is a container that mimics some of the properties of classic containers such\nas `VecDeque`, `BTreeMap`, etc. with the following goals:\n* The data structure can be written to the key-value store and loaded from there.\n* The changes are first done in memory and accessed there. The changes can be committed\nto the key-value store client when adequate.\n\nThere are various views corresponding to several use cases. All of those are\nimplemented by mapping the values in their specific types to their serializations.\n\n## Allowed keys, base key and prefixes\n\nThe keys are constructed step by step from the prefix to the full key. So, whenever\nwe have a view or any other object then we have a `base_key` associated with it and\nwith no other objects. A view is associated with many keys, all of which share the same\n`base_key` as prefix.\nThis leads us to introduce a trait `Context` that can be implemented with a specific\n`KeyValueDatabase` client and a `base_key`.\n\nAnother issue to consider is that we do not want to just store the values, but we\nalso need to accommodate other features:\n* Administrative data (like journal) need to store some data starting from the `base_key`.\n* Some of the values need to be split into several smaller values.\n\nThe rules for constructing keys are the following:\n* For the construction of `struct` objects of associated base key `base_key` we do the\nfollowing: If the corresponding type has entries `entry_0`, ..., `entry_k` then the\nbase key of the object associated with the `k`-th entry is `[base_key * * * *]` where\n`[* * * *]` are the four bytes of `k` as a `u32`.\n* For each view type, we have some associated data. Some are the hash, others the counts\n(e.g. for `LogView` and `QueueView`) and some the index. The corresponding enum is\nnamed `KeyTag` for each of those containers. For the index, the values are serialized.\n* For a given base key `base_key` the keys of the form `[base_key tag]` with tags in\n`0..MIN_VIEW_TAG` are reserved for administrative data.\n\nThese constructions are done in order to satisfy the following property: The set of keys\nof a view is prefix-free. That is if a key is of the form `key = [a b]` then `a` is\nnot a key. This property is important for other functionalities.\nIf the user is using a single view then for whatever `base_key` is chosen, the set of keys\ncreated will be prefix-free. If several views are created then their base keys must be\nchosen to be prefix-free so that the whole set of keys is prefix-free.\n\n## API of the `KeyValueDatabase`\n\nThe design of the key-value store client is done in the following way:\n* We can put a `(key, value)` and delete a `key`.\n* We can delete keys having a specific prefix.\n* We can retrieve the list of keys having a specific prefix. Similarly, we can\nretrieve the list of `(key, value)` whose keys have a specific prefix.\n* Also, the list of the keys is provided in the lexicographic order.\n\n## Journaling\n\nWe want to make sure that all operations are done on the database in an atomic\nway. That is the operations have to be processed completely. The idea is to\nstore the journal in the `[base_key 0 * * * *]` keys with `[* * * *]` the\nserialization of an `u32` entry.\nThose keys are not colliding with the other keys since their value is of the\nform `[base_key tag *]` with `tag >= MIN_VIEW_TAG` and currently, we have\n`MIN_VIEW_TAG = 1`.\n\nThe journaling allows to have operations in an atomic way. It is done in the\nfollowing way:\n* When a `Batch` of operations needs to be processed, the operations are written\ninto blocks that can be processed atomically. All together the blocks for the\n\"journal\". When the journal has been written then the counter is written and\nonly at that point is the journal considered written.\n* Each block is then processed atomically. If an interruption occurs then\nthe block entries would be processed after accessing the database the next time.\n\n## Splitting large values across keys\n\nSome key-value store clients limit the size of the values (named `MAX_VALUE_SIZE`\nin the code). `ValueSplittingDatabase` is a wrapper that accepts values\nof any size. Internally, it splits them into smaller pieces and stores them\nusing a wrapped, possibly size-limited, client.\n\nThe built key-value store client has `MAX_VALUE_SIZE` set to its maximum possible\nvalue. This forces us to split the value into several smaller values. This is\nuseful for stores that impose a limit on their value size.\n\nDesign is the following:\n* For every `key` we build several corresponding keys `[key * * * *]` that contain\neach a piece of the full value.\nThe `[* * * *]` is the serialization of the index which is `u32` so that\nthe order of the serialization is the same as the order of the `u32` entries.\n* For the first key, that is `[key 0 0 0 0]` the corresponding value is `[* * * * value_0]`\nwith `[* * * *]` being the serialization of the `u32` count of the number of blocks\nand `value_0` the first block of the value. For the other keys `[key * * * *]` the\ncorresponding value is `value_k` with `value_k` the k-th entry in the value. The full\nvalue is reconstructed as `value = [value_0 value_1 .... value_N]`\nThe number of blocks is always non-zero, even if the value is empty.\n\nThe effective working of the system relies on several design choices.\n* In `find_keys_by_prefix` and similar, the keys are\nreturned in lexicographic order.\n* The count and indices are serialized as `u32` and the serialization is done\nso that the `u32` ordering is the same as the lexicographic ordering. So, we\nget first the first key (and so the count) and then the segment keys one by\none in the correct order.\n* Suppose that we have written a `(key, value_1)` with several segments and then\nwe replace by a `(key, value_2)` which has fewer segments.\nOur choice is to leave the old segments in the database. Same with delete:\nwe just delete the first key.\n* We avoid the overflowing of the system by the following trick: When we delete\na view, we do a delete by prefix, which thus deletes the old segments if present.\n* In order to delete all the unused segments when overwriting a value, every write\nwould need to have a read just before which is expensive.\n\nA key difficulty of this modelization is that we are using prefixes extensively\nand so by adding the index of the form `[* * * *]` we are potentially creating\nsome collisions. That is if we delete a key of the form `[key 0 0]` we would\nalso delete segments of the key of the form `key`. However, this cannot happen\nbecause the set of keys is prefix-free.\n","isInternal":false,"tokens":1842,"sizeBytes":7775},{"name":"README.md","path":"linera-indexer/plugins/README.md","rawUrl":"https://raw.githubusercontent.com/linera-io/linera-protocol/HEAD/linera-indexer/plugins/README.md","title":"plugins Documentation","category":"plugin-manifest","format":"markdown","content":"<!-- cargo-rdme start -->\n\nPlugins for Linera indexer.\n\n<!-- cargo-rdme end -->\n\n## Contributing\n\nSee the [CONTRIBUTING](../../CONTRIBUTING.md) file for how to help out.\n\n## License\n\nThis project is available under the terms of the [Apache 2.0 license](../../LICENSE).\n","isInternal":false,"tokens":69,"sizeBytes":269}],"systemPromptSnippet":"<yakaai_skills repo=\"linera-io/linera-protocol\">\n<!-- File: docs/llms.txt (Tokens: ~2801 | Category: root-instruction) -->\n# Linera Documentation\n\n> Linera is a decentralized protocol designed for highly scalable, low-latency Web3 applications using microchain architecture.\n\n## Protocol\n\n- [The Linera Manual](https://linera.dev/): Introduction to Linera and entry point for developer documentation.\n- [Overview](https://linera.dev/protocol/overview.html): How microchains work, what makes Linera real-time and agent-friendly, and comparison to traditional multi-chain protocols.\n- [Roadmap](https://linera.dev/protocol/roadmap.html): Technical development roadmap across four testnets (Archimedes, Babbage, Conway) and mainnet.\n\n## Getting Started\n\n- [Getting Started](https://linera.dev/developers/getting_started.html): Entry point for Linera developer documentation.\n- [Installation](https://linera.dev/developers/getting_started/installation.html): Install the Linera toolchain from crates.io or GitHub, including system requirements.\n- [Hello, Linera](https://linera.dev/developers/getting_started/hello_linera.html): Create a wallet, connect to the testnet or a local network, build and publish your first application.\n\n## Core Concepts\n\n- [Microchains](https://linera.dev/developers/core_concepts/microchains.html): Lightweight single-user blockchains that enable parallel execution, cross-chain messaging, and chain ownership semantics.\n- [Wallets](https://linera.dev/developers/core_concepts/wallets.html): Creating developer wallets, selecting wallets, managing chains, and opening multi-user chains.\n- [Node Service](https://linera.dev/developers/core_concepts/node_service.html): Running a local node service, GraphiQL IDE, system and application GraphQL APIs, and connecting AI agents via MCP.\n- [Applications](https://linera.dev/developers/core_concepts/applications.html): Application deployment lifecycle, anatomy (contract, service, state), operations, messages, and authentication.\n- [Common Design Patterns](https://linera.dev/developers/core_concepts/design_patterns.html): Five design patterns using microchains — user-chain apps, client/server, personal chains, temporary chains, and just-in-time oracles.\n\n## Writing Backends\n\n- [Writing Linera Applications](https://linera.dev/developers/backend.html): Guide to building Web3 applications using the Linera SDK with Rust smart contracts and GraphQL services.\n- [Creating a Linera Project](https://linera.dev/developers/backend/creating_a_project.html): Initialize a new project with `linera project new` and overview of scaffolded files.\n- [Creating the Application State](https://linera.dev/developers/backend/state.html): Define persistent application state using linera-views for on-chain storage.\n- [Defining the ABI](https://linera.dev/developers/backend/abi.html): Define the Application Binary Interface with marker structs, contract ABI, and service ABI.\n- [Writing the Contract Binary](https://linera.dev/developers/backend/contract.html): Implement the contract lifecycle, handle operations and messages, and declare the ABI.\n- [Writing the Service Binary](https://linera.dev/developers/backend/service.html): Implement the read-only service with GraphQL compatibility for querying application state.\n- [Deploying the Application](https://linera.dev/developers/backend/deploy.html): Deploy to local networks, devnets, and testnets, then interact with the application.\n- [Cross-Chain Messages](https://linera.dev/developers/backend/messages.html): Send and handle messages between microchains, with a fungible token example.\n- [Calling other Applications](https://linera.dev/developers/backend/composition.html): Cross-application calls using `call_application`, with a crowd-funding example.\n- [Using Data Blobs](https://linera.dev/developers/backend/blobs.html): Store and retrieve large data blobs in Linera applications.\n- [Printing Logs from an Application](https://linera.dev/developers/backend/logging.html): Add logging to Linera contracts and services for debugging.\n- [Writing Tests](https://linera.dev/developers/backend/testing.html): Unit tests with mock runtime and integration tests with simulated validators using `cargo test`.\n\n## Writing Frontends\n\n- [Writing Linera Application Frontends](https://linera.dev/developers/frontend.html): Build interactive web frontends using Linera's JavaScript API with push notifications.\n- [Frontend Architecture Overview](https://linera.dev/developers/frontend/overview.html): How the Rust client library compiles to WebAssembly and wraps with JavaScript APIs via wasm-bindgen.\n- [Setting up the Frontend Development Environment](https://linera.dev/developers/frontend/setup.html): Supported browsers, creating HTML pages, serving frontends, and getting the client library.\n- [Interacting with Linera](https://linera.dev/developers/frontend/interactivity.html): Import the client library, initialize wallets, communicate with applications, and handle notifications.\n- [External Wallets](https://linera.dev/developers/frontend/wallets.html): Integrating external wallet providers like MetaMask and Dynamic via the Signer interface.\n\n## Advanced Topics\n\n- [Advanced Topics](https://linera.dev/developers/advanced_topics.html): Supplementary topics for Linera protocol developers.\n- [Contract Finalization](https://linera.dev/developers/advanced_topics/contract_finalize.html): How contract finalization works and when to use it for cleanup operations.\n- [Validators](https://linera.dev/developers/advanced_topics/validators.html): Architecture of a validator, including workers, shards, and the consensus process.\n- [Creating New Blocks](https://linera.dev/developers/advanced_topics/block_creation.html): How blocks are created, proposed, and confirmed across microchains.\n- [Applications that Handle Assets](https://linera.dev/developers/advanced_topics/assets.html): Safely handle assets on temporary chains with ownership, permissions, and chain closure.\n\n## Experimental\n\n- [Experimental Topics](https://linera.dev/developers/experimental.html): Experimental features unavailable on testnet that require compiling from source with specific Cargo features.\n- [Machine Learning on Linera](https://linera.dev/developers/experimental/ml.html): Run ML models on the edge using the contract/service split for secure and efficient inference.\n- [Using EVM Smart Contracts on Linera](https://linera.dev/developers/experimental/ethereum.html): Run Ethereum Virtual Machine smart contracts within Linera microchains using Revm integration.\n\n## Operators\n\n- [Node Operators (moved)](https://linera.dev/operators.html): Validator deployment docs have moved to <https://docs.infra.linera.net/>; deployment artifacts live at <https://github.com/linera-io/linera-artifacts>.\n\n## Appendix\n\n- [Glossary](https://linera.dev/appendix/glossary.html): Definitions of 50+ technical terms including microchain, validator, view, epoch, certificate, and more.\n\n## API Reference\n\n- [Linera SDK (docs.rs)](https://docs.rs/linera-sdk/latest/linera_sdk/): Rust API reference for the Linera SDK crate — contracts, services, views, and runtime.\n- [Linera Views (docs.rs)](https://docs.rs/linera-views/latest/linera_views/): Rust API reference for linera-views — persistent storage with MapView, CollectionView, and more.\n\n## GitHub Repositories\n\n- [linera-protocol](https://github.com/linera-io/linera-protocol): Main Linera protocol repository — validator, client, SDK, views, and example applications.\n- [linera-agents](https://github.com/linera-io/linera-agents): AI agent skills for building on Linera and trading on Linera prediction markets.\n- [mcp-demo](https://github.com/linera-io/mcp-demo): Demo MCP server connecting Claude to a Linera counter application via GraphQL.\n- [linera-web](https://github.com/linera-io/linera-web): The Linera Web client for browser-based chain interaction.\n- [pm-app](https://github.com/linera-io/pm-app): Prediction market demo app — parimutuel contracts, fungible tokens, faucet, and oracle.\n\n## Example Applications\n\n- [Counter](https://github.com/linera-io/linera-protocol/tree/main/examples/counter): Minimal counter application demonstrating basic Linera SDK usage.\n- [Fungible Token](https://github.com/linera-io/linera-protocol/tree/main/examples/fungible): ERC-20-style fungible token with cross-chain transfers.\n- [Crowd Funding](https://github.com/linera-io/linera-protocol/tree/main/examples/crowd-funding): Campaign-based crowd funding with cross-application calls to fungible tokens.\n- [Social](https://github.com/linera-io/linera-protocol/tree/main/examples/social): Social media application with posts and subscriptions across microchains.\n- [AMM](https://github.com/linera-io/linera-protocol/tree/main/examples/amm): Automated market maker for token swaps.\n- [Matching Engine](https://github.com/linera-io/linera-protocol/tree/main/examples/matching-engine): Order book matching engine for trading.\n- [Non-Fungible Token](https://github.com/linera-io/linera-protocol/tree/main/examples/non-fungible): NFT application with minting and transfers.\n- [LLM](https://github.com/linera-io/linera-protocol/tree/main/examples/llm): On-chain LLM inference example.\n- [Agent](https://github.com/linera-io/linera-protocol/tree/main/examples/agent): AI agent integration example.\n- [Ethereum Tracker](https://github.com/linera-io/linera-protocol/tree/main/examples/ethereum-tracker): Track Ethereum state from within Linera.\n- [Hex Game](https://github.com/linera-io/linera-protocol/tree/main/examples/hex-game): Two-player hex board game on microchains.\n\n## AI Agent Skills\n\n- [Linera Dev Skill](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/SKILL.md): AI assistant skill for building Linera applications — SDK, views, cross-chain messaging, GraphQL, MCP, testing, and deployment.\n- [Linera Markets Skill](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/SKILL.md): AI assistant skill for interacting with Linera prediction markets — market queries, placing predictions, P&L tracking, and automated trading strategies.\n\n## AI Agent Skill References\n\n- [Cross-Chain Messaging Guide](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/cross-chain-messaging.md): Advanced cross-chain messaging patterns for Linera applications.\n- [Deployment Guide](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/deployment-guide.md): Testnet and production deployment guide for Linera applications.\n- [Linera Views Guide](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/linera-views-guide.md): Storage patterns and view types for persistent state.\n- [MCP Integration Guide](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/mcp-integration.md): Full MCP setup guide for connecting AI agents to Linera.\n- [Testing Patterns](https://github.com/linera-io/linera-agents/blob/main/skills/linera-dev/testing-patterns.md): Unit and integration testing patterns for Linera applications.\n- [API Examples](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/api-examples.md): Full GraphQL query and mutation examples with sample responses for prediction markets.\n- [Faucet Claim Recipe](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/faucet-claim-recipe.md): Step-by-step recipe for claiming tokens from the Linera faucet.\n- [RocksDB Locking Patterns](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/rocksdb-locking.md): Workarounds for RocksDB single-process locking in multi-wallet setups.\n- [Resolution Timing](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/resolution-timing.md): Market resolution timing, oracle delay, and generation lifecycle.\n- [Multi-Wallet Setup](https://github.com/linera-io/linera-agents/blob/main/skills/linera-markets/references/multi-wallet-setup.md): Running multiple Linera wallets and environments on one machine.\n\n## Community Demos\n\n- [Atoma Demo](https://github.com/linera-io/atoma-demo): Linera application demonstrating interaction with Atoma Network.\n- [Walrus Demo](https://github.com/linera-io/walrus-demo): Linera application demonstrating interaction with Walrus decentralized storage.\n- [DePIN Map-Reduce Demo](https://github.com/linera-io/depin-map-reduce-demo): Map-reduce computation across microchains example.\n- [Buildathon Template](https://github.com/linera-io/buildathon-template): Dockerized application template for Linera buildathon submissions.\n\n<!-- File: linera-views/DESIGN.md (Tokens: ~1842 | Category: project-spec) -->\nThis document collects some design choices that were made in the `linera-views`.\nFor an overview, see `README.md`.\n\n# Design\n\n## Key Value Database Clients\n\nWe have designed a `KeyValueDatabase` trait that represents the basic functionalities\nof a key-value store whose keys are `Vec<u8>` and whose values are `Vec<u8>`.\n\nWe provide an implementation of the trait `KeyValueDatabase` for the following key-value stores:\n* `MemoryDatabase` uses the memory (and uses internally a simple B-Tree map).\n* `RocksDbDatabase` is a disk-based key-value store\n* `ScyllaDbDatabase` is a cloud-based Cassandra-compatible database.\n\nThe trait `KeyValueDatabase` was designed so that more storage solutions can be easily added in the future.\n\nThe `KeyValueDatabase` trait is also implemented for several internal constructions of clients:\n* The `LruCachingDatabase<K>` client implements the Least Recently Used (LRU)\ncaching of reads into the client.\n* The `ViewContainer<C>` client implements a key-value store client from a context.\n* The `ValueSplittingDatabase<K>` implements a client for which the\nsize of the values is unbounded, on top of another client for which it is bounded.\n(Some databases have strict limitations on the value size.)\n\n## Views\n\nA view is a container that mimics some of the properties of classic containers such\nas `VecDeque`, `BTreeMap`, etc. with the following goals:\n* The data structure can be written to the key-value store and loaded from there.\n* The changes are first done in memory and accessed there. The changes can be committed\nto the key-value store client when adequate.\n\nThere are various views corresponding to several use cases. All of those are\nimplemented by mapping the values in their specific types to their serializations.\n\n## Allowed keys, base key and prefixes\n\nThe keys are constructed step by step from the prefix to the full key. So, whenever\nwe have a view or any other object then we have a `base_key` associated with it and\nwith no other objects. A view is associated with many keys, all of which share the same\n`base_key` as prefix.\nThis leads us to introduce a trait `Context` that can be implemented with a specific\n`KeyValueDatabase` client and a `base_key`.\n\nAnother issue to consider is that we do not want to just store the values, but we\nalso need to accommodate other features:\n* Administrative data (like journal) need to store some data starting from the `base_key`.\n* Some of the values need to be split into several smaller values.\n\nThe rules for constructing keys are the following:\n* For the construction of `struct` objects of associated base key `base_key` we do the\nfollowing: If the corresponding type has entries `entry_0`, ..., `entry_k` then the\nbase key of the object associated with the `k`-th entry is `[base_key * * * *]` where\n`[* * * *]` are the four bytes of `k` as a `u32`.\n* For each view type, we have some associated data. Some are the hash, others the counts\n(e.g. for `LogView` and `QueueView`) and some the index. The corresponding enum is\nnamed `KeyTag` for each of those containers. For the index, the values are serialized.\n* For a given base key `base_key` the keys of the form `[base_key tag]` with tags in\n`0..MIN_VIEW_TAG` are reserved for administrative data.\n\nThese constructions are done in order to satisfy the following property: The set of keys\nof a view is prefix-free. That is if a key is of the form `key = [a b]` then `a` is\nnot a key. This property is important for other functionalities.\nIf the user is using a single view then for whatever `base_key` is chosen, the set of keys\ncreated will be prefix-free. If several views are created then their base keys must be\nchosen to be prefix-free so that the whole set of keys is prefix-free.\n\n## API of the `KeyValueDatabase`\n\nThe design of the key-value store client is done in the following way:\n* We can put a `(key, value)` and delete a `key`.\n* We can delete keys having a specific prefix.\n* We can retrieve the list of keys having a specific prefix. Similarly, we can\nretrieve the list of `(key, value)` whose keys have a specific prefix.\n* Also, the list of the keys is provided in the lexicographic order.\n\n## Journaling\n\nWe want to make sure that all operations are done on the database in an atomic\nway. That is the operations have to be processed completely. The idea is to\nstore the journal in the `[base_key 0 * * * *]` keys with `[* * * *]` the\nserialization of an `u32` entry.\nThose keys are not colliding with the other keys since their value is of the\nform `[base_key tag *]` with `tag >= MIN_VIEW_TAG` and currently, we have\n`MIN_VIEW_TAG = 1`.\n\nThe journaling allows to have operations in an atomic way. It is done in the\nfollowing way:\n* When a `Batch` of operations needs to be processed, the operations are written\ninto blocks that can be processed atomically. All together the blocks for the\n\"journal\". When the journal has been written then the counter is written and\nonly at that point is the journal considered written.\n* Each block is then processed atomically. If an interruption occurs then\nthe block entries would be processed after accessing the database the next time.\n\n## Splitting large values across keys\n\nSome key-value store clients limit the size of the values (named `MAX_VALUE_SIZE`\nin the code). `ValueSplittingDatabase` is a wrapper that accepts values\nof any size. Internally, it splits them into smaller pieces and stores them\nusing a wrapped, possibly size-limited, client.\n\nThe built key-value store client has `MAX_VALUE_SIZE` set to its maximum possible\nvalue. This forces us to split the value into several smaller values. This is\nuseful for stores that impose a limit on their value size.\n\nDesign is the following:\n* For every `key` we build several corresponding keys `[key * * * *]` that contain\neach a piece of the full value.\nThe `[* * * *]` is the serialization of the index which is `u32` so that\nthe order of the serialization is the same as the order of the `u32` entries.\n* For the first key, that is `[key 0 0 0 0]` the corresponding value is `[* * * * value_0]`\nwith `[* * * *]` being the serialization of the `u32` count of the number of blocks\nand `value_0` the first block of the value. For the other keys `[key * * * *]` the\ncorresponding value is `value_k` with `value_k` the k-th entry in the value. The full\nvalue is reconstructed as `value = [value_0 value_1 .... value_N]`\nThe number of blocks is always non-zero, even if the value is empty.\n\nThe effective working of the system relies on several design choices.\n* In `find_keys_by_prefix` and similar, the keys are\nreturned in lexicographic order.\n* The count and indices are serialized as `u32` and the serialization is done\nso that the `u32` ordering is the same as the lexicographic ordering. So, we\nget first the first key (and so the count) and then the segment keys one by\none in the correct order.\n* Suppose that we have written a `(key, value_1)` with several segments and then\nwe replace by a `(key, value_2)` which has fewer segments.\nOur choice is to leave the old segments in the database. Same with delete:\nwe just delete the first key.\n* We avoid the overflowing of the system by the following trick: When we delete\na view, we do a delete by prefix, which thus deletes the old segments if present.\n* In order to delete all the unused segments when overwriting a value, every write\nwould need to have a read just before which is expensive.\n\nA key difficulty of this modelization is that we are using prefixes extensively\nand so by adding the index of the form `[* * * *]` we are potentially creating\nsome collisions. That is if we delete a key of the form `[key 0 0]` we would\nalso delete segments of the key of the form `key`. However, this cannot happen\nbecause the set of keys is prefix-free.\n\n<!-- File: linera-indexer/plugins/README.md (Tokens: ~69 | Category: plugin-manifest) -->\n<!-- cargo-rdme start -->\n\nPlugins for Linera indexer.\n\n<!-- cargo-rdme end -->\n\n## Contributing\n\nSee the [CONTRIBUTING](../../CONTRIBUTING.md) file for how to help out.\n\n## License\n\nThis project is available under the terms of the [Apache 2.0 license](../../LICENSE).\n</yakaai_skills>"}