The original size of the white paper is 43 pages. A summary has been created upon request by Binance-User-Criptogranjero. You can reply with any summary you want, and I will work on it as soon as possible.
Market cap data NEAR Protocol
Volume/Market cap (24h) 3.74%
Circulating supply 930,171,918 NEAR
Total supply 1,000,000,000 NEAR
Max. supply --
Fully diluted market cap $1,300,123,772
Introduction
NEAR is a decentralized platform that aims to enable the creation of scalable and usable applications that can benefit from the security and openness of the blockchain. NEAR is designed to address the challenges of usability, scalability and security that limit the adoption of existing platforms. NEAR uses a novel consensus mechanism called Nightshade, which splits the network into multiple shards that process transactions in parallel. NEAR also introduces a dynamic runtime that adapts to the changing needs of the applications and the network. NEAR leverages a human-readable account model that simplifies the user experience and enables cross-contract calls. NEAR also supports a rich developer ecosystem with various tools and languages.
Background
The blockchain technology has the potential to revolutionize many industries and domains by enabling trustless and transparent interactions among diverse participants. However, the current state of the art suffers from several limitations that hinder its mainstream adoption. These limitations include:
Usability: The user experience of blockchain applications is often complex and unintuitive, requiring users to manage cryptographic keys, deal with high latency and fees, and cope with poor performance and availability.
Scalability: The throughput and latency of blockchain networks are limited by the consensus protocol, which requires all nodes to process and validate all transactions. This creates a trade-off between security and scalability, as increasing the number of nodes or the size of the blocks reduces the efficiency and speed of the network.
Security: The security of blockchain networks depends on the assumptions and incentives of the participants, which may not always hold in practice. For example, rational actors may collude or censor transactions to maximize their profits, or malicious actors may launch attacks to disrupt or compromise the network.
Design Principles
NEAR is guided by four design principles that shape its vision and architecture:
Usability: NEAR aims to provide a seamless and intuitive user experience that abstracts away the complexity of the underlying technology. Users should be able to interact with applications using familiar interfaces and concepts, without worrying about keys, fees, or network issues.
Scalability: NEAR aims to achieve high scalability and performance by leveraging parallelism and sharding. Transactions should be processed quickly and cheaply, regardless of the network size or load.
Security: NEAR aims to ensure the security and integrity of the network and the applications by employing rigorous cryptography and economic incentives. Transactions should be final and immutable, and participants should be accountable for their actions.
Simplicity: NEAR aims to keep its design and implementation as simple as possible, avoiding unnecessary complexity or overhead. Simplicity enables easier development, testing, auditing, and maintenance of the system.
System Overview
NEAR consists of four main components:
Network: The network layer is responsible for peer-to-peer communication among nodes, as well as routing and broadcasting transactions and blocks.
Consensus: The consensus layer is responsible for reaching agreement on the state of the system among nodes, as well as producing and validating blocks. NEAR uses a variant of Nakamoto consensus called Nightshade, which enables sharding and fast finality.
Runtime: The runtime layer is responsible for executing transactions and smart contracts, as well as managing accounts, storage, and fees. NEAR uses a dynamic runtime that can evolve over time according to the governance decisions.
Developer Experience: The developer experience layer is responsible for providing tools and languages for building applications on NEAR. NEAR supports multiple programming languages, such as Rust, AssemblyScript, C#, etc., as well as various frameworks and libraries.
Network
The network layer consists of three types of nodes:
Validators: Validators are nodes that participate in the consensus protocol by producing and validating blocks. Validators are selected based on their stake (the amount of tokens they lock up) and their performance (the quality of their service). Validators are randomly assigned to different shards every epoch (a fixed period of time).
Fishermen: Fishermen are nodes that monitor the network for malicious behavior by validators or other nodes. Fishermen do not produce or validate blocks, but they can submit proofs of misbehavior to challenge invalid blocks or transactions. Fishermen are rewarded for their service with a fraction of the slashed stake of the offenders.
Light Clients: Light clients are nodes that do not store or process the full state of the system, but only verify block headers using cryptographic proofs. Light clients can interact with applications using remote procedure calls (RPCs) or query contracts using Merkle proofs.
Consensus
The consensus layer uses a sharded proof-of-stake (PoS) protocol called Nightshade, which combines the ideas of Nakamoto consensus and Byzantine fault tolerance (BFT). Nightshade consists of two main components:
Block Production: Block production is the process of creating new blocks by validators. Each shard has a leader who proposes a block for that shard, and other validators in that shard approve or reject the block. The leader is rotated every block using a verifiable random function (VRF). The block production is synchronized across shards using a beacon chain, which is a special shard that produces blocks at a higher frequency and serves as a source of randomness and time for the system.
Block Finalization: Block finalization is the process of reaching final agreement on the validity and order of blocks by validators. Each shard has a committee of validators who vote on the blocks for that shard, using a BFT protocol called Doomslug. The votes are aggregated using threshold signatures, which reduce the communication overhead and enable fast finality. The block finalization is coordinated across shards using a fork choice rule, which determines the canonical chain based on the weight of the blocks and the votes.
Runtime
The runtime layer consists of two main components:
State Transition: State transition is the process of applying transactions to the state of the system, resulting in a new state. Transactions are grouped into chunks, which are assigned to different shards based on the accounts they touch. Chunks are executed in parallel by validators in each shard, using a WebAssembly-based virtual machine called NEAR VM. The state transition is verified across shards using state receipts, which are cryptographic proofs of the outcomes and dependencies of the chunks.
State Storage: State storage is the process of storing and retrieving the state of the system, which consists of accounts, contracts, and data. The state is stored in a key-value store called Trie, which is partitioned across shards based on the account prefixes. The state storage is optimized across shards using rent, which is a fee that accounts pay for occupying storage space, and garbage collection, which is a mechanism that removes unused or expired data from the Trie.
Developer Experience
The developer experience layer consists of three main components:
Account Model: The account model is the abstraction that NEAR uses to represent users and contracts in the system. Accounts have human-readable names (e.g., alice.near) that can be registered and transferred using subdomains (e.g., bob.alice.near). Accounts can also make cross-contract calls using promises, which are asynchronous and composable operations that can handle success or failure callbacks.
Smart Contracts: Smart contracts are programs that run on NEAR and define the logic and data of applications. Smart contracts can be written in various languages, such as Rust, AssemblyScript, C#, etc., and compiled to WebAssembly bytecode that can run on NEAR VM. Smart contracts can also use standard libraries and interfaces, such as NEAR SDKs and NEP standards, to simplify development and interoperability.
Tools and Services: Tools and services are software components that facilitate the development, testing, deployment, and monitoring of applications on NEAR. Tools and services include IDEs, CLI tools, testing frameworks, code analysis tools, explorers, wallets, faucets, bridges, etc.
Conclusion
NEAR is a scalable and usable platform that enables developers to create applications that can benefit from the security and openness of the blockchain. NEAR achieves this by combining novel techniques and technologies, such as sharding, dynamic runtime, human-readable accounts, multiple languages, etc. NEAR also fosters a vibrant community and ecosystem that supports innovation and collaboration. NEAR aims to become a global public utility that empowers users and developers to create a more open, fair, and decentralized web.