nearcore Documentation

website·Indexed 30 days ago

https://near.github.io/near-api-js/

Technical documentation for core developers of the NEAR Protocol. It covers the high-level architecture of the node, including networking, storage (RocksDB and Merkle-Patricia Trie), and gas mechanics. The guide provides detailed instructions on building and running a node from source, implementing protocol upgrades, and development best practices for Rust, including code style, testing with Python, and OpenTelemetry tracing.

Tokens
249K
Snippets
1.2K
Records
1.9K
Agent score
74%

What's inside nearcore

  1. Overview of NEAR Meta Transactions (NEP-366)

    Meta transactions (introduced in NEP-366) allow users to execute actions on the NEAR Protocol without owning NEAR tokens for gas. This is achieved by constructing and signing a DelegateAction off-chain. A third party, known as a relayer, submits this signed action as part of a standard transaction, paying the gas fees on behalf of the user. The protocol verifies the user's signature and nonce on-chain before executing the inner actions.
  2. Overview of NEAR Receipts and Cross-Contract Communication

    All cross-contract communication in NEAR occurs through Receipts. Receipts are stateful messages between accounts that can be stored in account storage to await corresponding DataReceipts. There are two primary types of receipts:

    1. ActionReceipt: A request to apply specific actions (e.g., FunctionCall, Transfer) on the receiver_id side. These can be generated by a Transaction or another ActionReceipt.
    2. DataReceipt: The final result of a contract execution. It contains a unique data_id and an optional data field (bytes). If data is None, it indicates an execution error.
  3. Overview of Block and Chunk Producers in Simple Nightshade

    In the 'Simple Nightshade' phase of NEAR, the network distinguishes between two types of producers to balance decentralization and security:

    • Block Producers: Track all shards, validate all transactions, and produce blocks. They are a subset of chunk producers.
    • Chunk-only Producers: Track only a single shard and produce chunks for that shard. They never produce blocks.

    A block consists of one chunk for each shard. This design allows many participants to run chunk-only nodes (decentralization) while ensuring security via block producers who monitor the entire network.

  4. Overview of the nep413 module for message signing and verification

    The nep413 module provides the necessary functions and types to implement message signing and verification on the NEAR network. It includes tools to sign a message using a private key and verify that a message was signed by a specific account.
  5. Overview of the Routing Table Exchange Algorithm

    The Routing Graph Reconciliation algorithm uses Inverse Bloom Filters (IBFs) to synchronize routing tables between two nodes (A and B). Instead of exchanging the full routing table, nodes exchange IBFs to identify the set difference of edges. This process allows for partial synchronization, where bandwidth and processing time are proportional to the size of the data that needs to be exchanged. If IBF-based reconciliation fails to recover all edges, the system falls back to a full routing table exchange.
  6. Overview of the tokens/ft module

    The tokens/ft module in the NEAR API JS library provides the necessary abstractions for interacting with fungible tokens. It includes classes for general fungible tokens (FungibleToken) and the native NEAR token (NativeToken), as well as a reference to the NEAR token variable.
  7. Overview of the tokens/nft module

    The tokens/nft module in the NEAR API JS library provides the core classes for interacting with Non-Fungible Token (NFT) contracts on the NEAR blockchain. The primary entities in this module are NFTContract and NonFungibleToken.
  8. Overview of near-api-js library

    near-api-js is a backend-focused JavaScript library designed to allow developers to interact with the NEAR blockchain. It provides core functionality for managing accounts, signing transactions, and communicating with NEAR nodes via JSON-RPC.
  9. Overview of near-api-js

    near-api-js is a backend-focused JavaScript library designed to interact with the NEAR blockchain. It provides the necessary tools to connect to NEAR nodes, manage accounts, sign transactions, and handle cryptographic key pairs.
  10. Overview of NEAR Flat Storage

    Flat storage acts as a database index for values stored in the NEAR state trie. While the standard state trie is stored in RocksDB using DBCol::State (content-addressed via hash(borsh_encode(trie_node))), flat storage stores a copy of the data in a more accessible format to reduce lookup time.

    Algorithmically, it attempts to move lookup complexity from O(d) (where d is tree depth) to O(1). In practice, the performance gain comes primarily from better data layout and smaller column size in RocksDB (DBCol::FlatState), resulting in observed speedups of 100x or more for reading single values compared to the state trie.

  11. Overview of the crypto/public_key module

    The crypto/public_key module in the NEAR API JS library provides the PublicKey class for managing public keys and the keyToImplicitAddress function for converting public keys into their corresponding implicit account addresses.