Reference client for NEAR Protocol

Overview




Reference implementation of NEAR Protocol

Build Status Stable Status Prerelease Status codecov Discord chat Telegram Group

About NEAR

NEAR's purpose is to enable community-driven innovation to benefit people around the world.

To achieve this purpose, NEAR provides a developer platform where developers and entrepreneurs can create apps that put users back in control of their data and assets, which is the foundation of "Open Web" movement.

One of the components of NEAR is the NEAR Protocol, an infrastructure for server-less applications and smart contracts powered by a blockchain. NEAR Protocol is built to deliver usability and scalability of modern PaaS like Firebase at fraction of the prices that blockchains like Ethereum charge.

Overall, NEAR provides a wide range of tools for developers to easily build applications:

Join the Network

The easiest way to join the network, is by using the nearup command, which you can install as follows:

pip3 install --user nearup

You can join all the active networks:

  • TestNet: nearup run testnet
  • BetaNet: nearup run betanet

Check the nearup repository for more details how to run with or without docker.

To learn how to become validator, checkout documentation.

Development Status

We are using ZenHub to manage the development process. You can either login on their website or install ZenHub extension to see additional information right on Github.

For the high-level roadmap, checkout Chain&Middleware's roadmap.

Contributing

The workflow and details of setup to contribute are described in CONTRIBUTING.md, and security policy is described in SECURITY.md. To propose new protocol changes or standards use Specification & Standards repository.

Comments
  • Runtime hits unknown perfomance cliff in the estimator

    Runtime hits unknown perfomance cliff in the estimator

    See

    https://github.com/matklad/nearcore/commit/80b44a877a1d2de76b4adcf63567984d615e7c36

    In that commit, I add a benchmark which sends 150 blocks, where each block contains 100 deploy code transaction.

    EDIT: https://github.com/near/nearcore/issues/4771#issuecomment-933347496 is modernized version.

    The benchmark is implemented in two ways:

    • on top of parameter estimator testbed
    • on top of runtime tester

    In the first case, I observe a very stage behavior, where at some point block processsing times severely degrades.

    To reproduce, checkout this commit and run

     $ cargo test --release --package runtime-params-estimator --lib --features required – v2::fast --exact --nocapture
     $ cargo test --release --package runtime-params-estimator --lib --features required – v2::slow --exact --nocapture
    

    Look for Runtime::apply lines in the output, they they tell you how long it takes to process one apply.

    In the fast case, every apply takes about 16ms for me. In the slow case, apply start at about 30ms, but then abruptly go to 600ms.

    Would be great to understand why the time suddenly balloons!

    A-transaction-runtime 
    opened by matklad 43
  • NumBlocks, NumShards, NumSeats, HeightDelta and _seats

    NumBlocks, NumShards, NumSeats, HeightDelta and _seats

    1. Using NumBlocks and BlockHeightDelta in a proper way.
    2. Correct naming in Epoch Manager.
    3. Fixed https://github.com/nearprotocol/nearcore/issues/1855.
    4. Unification of BlockHeight naming.

    Set of apples in not an apple. Size of set of apples is not an apple either.

    Size of string is not a string. Number of strings is not a string either.

    num_shards() shouldn't return a ShardId. Number of validators is not a ValidatorId. Vector of number of validators shouldn't be Vec<ValidatorId>. Applying .iter().sum() to Vec<ValidatorId> shouldn't make any sense.

    I expect mixing types leads to errors like https://github.com/nearprotocol/nearcore/issues/1855.

    S-automerge 
    opened by Kouprin 40
  • State dump and verification

    State dump and verification

    Currently when we dump the state from a node, we always dump state as of the last block that the node has. @ailisp points out that this block might be on a fork that is not canonical. I think there are two related problems here:

    • From which block should we dump state?
    • How do we set the genesis height of the new network?

    I think before we figure out upgradability, it is fine that when we do hard fork, the NEAR team proposes a new state from the current network that other validators can verify. In order to do this, I think we should dump the state as of the last final block. Since for a block to be final, it needs to go through pre-vote and pre-commit with 2/3 stake approval, it is safe to assume that this block is known by the majority of the validators and they can run the same state dump & migration script to reach the same state as proposed.

    Since we would like to avoid potential double signing, I think it is best to not reusable a height for the new network that has appeared in the old network. However, when the state dump happens, there might still be blocks that are inflight in the network, which makes it hard to determine the latest height. I think for the genesis height of the new network, it might be reasonable to use latest height from current node + some constant (like 10 for example) and it is fine if some heights are skipped.

    To summarize, I propose that we:

    • dump state as of the last final block and publish the hash of the block from which we dump the state, together with the new state itself.
    • set the genesis height of the new network to be the latest height from the node + some constant.
    A-build 
    opened by bowenwang1996 36
  • Investigate too many open files error

    Investigate too many open files error

    Sometimes after running for a while, a node would stops working because of some too many files open error. We need to investigate the cause and see whether we need to increase the limit for the number of file descriptors allowed.

    opened by bowenwang1996 36
  • Error messages refactoring

    Error messages refactoring

    Fixes: #978 and #1813

    Overview

    As discussed with @vgrichina @evgenykuzyakov @frol @fckt @janedegtiareva , we want the node RPC to return structured error messages, e.g. like these:

    {"InvalidTx": {"NotEnoughBalance": {"signer_id": "alice_near", "signer_balance": 1000000000000000000000000, "total_cost": 1000000000000924119500000}} }
    

    And we want the front-end and the Applayer to implement the conversion of the structured error messages to human-readable error messages, like these:

    Sender alice_near does not have enough balance 1000000000000000000000000 for operation costing 1000000000000924119500000
    

    More specifically we want nearlib to implement this conversion, which is predicated on having a detailed and exhaustive error specification.

    Properties

    There are two major differences with how error messages are currently returned by RPC:

    1. We are decoupling a human-readable error message from the node code. This is not expected to have a downside since the software developer that will be interacting with the node directly and not through nearshell/nearlib is expected to be qualified enough to understand the JSON format. The upsides are:
      • We can iterate on error message description independently from the node releases;
      • Localization;
      • We are motivating dApp developers to have dApp-specific error descriptions instead of relying on the system errors, promoting better UX. E.g. "The character cannot be created because there is not enough gold" is better than "Sender alice_near does not have enough balance ... ".
    2. We are using JSON (it seems like people are either indifferent on whether we use JSON vs our own format or are leaning towards JSON) for structured errors returned by the node. The upsides:
      • We can get rid this code by decorating error types with serde: https://github.com/nearprotocol/nearcore/blob/d869465f0400678b5df9e29d3bd926e8887d2337/core/primitives/src/views.rs#L677
      • We can now have error parameters, see signer_id, signer_balance, total_cost in the above example.

    Implementation steps

    • [x] Get rid of the places where we are prematurely converting error to string, instead of using error hierarchy, e.g. here: https://github.com/nearprotocol/nearcore/blob/f93e13c0be52b8069a98de4792b861f07787f003/core/primitives/src/errors.rs#L67
    • [x] Also make sure we are not using boxed errors;
    • [x] Add a detailed rustdoc for every error message exposed through RPC. Generate the rustdoc and refer to it as error message spec (maybe even extract all errors into near-vm-errors);
    • [x] Replace error_type: String in ExecutionErrorView with error_type: ExecutionError and use simultaneously switch to using JSON in nearlib in places that rely on old format of error_type, e.g.: https://github.com/nearprotocol/nearlib/pull/87/files?file-filters%5B%5D=.js&file-filters%5B%5D=.json&file-filters%5B%5D=.ts#diff-52776b8b9355ae3e46add4ae6ac70c2eR47
    • [x] Implement the above error spec in the nearlib to produce human-readable error messages from structured error messages;
    • [x] Replace ExecutionErrorView with ExecutionError in nearcore, and simultaneously remove usage of .type field in nearlib, e.g.: https://github.com/nearprotocol/nearlib/pull/87/files?file-filters%5B%5D=.js&file-filters%5B%5D=.json&file-filters%5B%5D=.ts#diff-52776b8b9355ae3e46add4ae6ac70c2eR47
    P-critical A-transaction-runtime C-epic A-RPC 
    opened by nearmax 35
  • nearcore doesn't return structured errors for most use cases of API

    nearcore doesn't return structured errors for most use cases of API

    Structured errors work (https://github.com/nearprotocol/nearcore/issues/1839) is not complete and it's hard to know what to expect.

    Example of error from nearcore:

        response.error {
          code: -32000,
          message: 'Server error',
          data: 'Other Error: block DtdfWgnt3QDEjoeARUK25vg8qh31kc3Lrg6qREsoJsST is ahead of head block 34eT8dRWfDPhZBiRGYvkHDj65ThaXCBTrnM4LQjn2Zab \n' +
            ' Cause: Unknown \n' +
            ' Backtrace:    0: failure::backtrace::Backtrace::new\n' +
            '   1: <actix::address::envelope::SyncEnvelopeProxy<A,M> as actix::address::envelope::EnvelopeProxy>::handle\n' +
            '   2: <actix::contextimpl::ContextFut<A,C> as core::future::future::Future>::poll\n' +
            '   3: tokio::runtime::task::raw::poll\n' +
            '   4: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll\n' +
            '   5: actix_rt::runtime::Runtime::block_on\n' +
            '   6: near::main\n' +
            '   7: std::rt::lang_start_internal::{{closure}}::{{closure}}\n' +
            '             at rustc/a74d1862d4d87a56244958416fd05976c58ca1a8/src/libstd/rt.rs:52\n' +
            '      std::sys_common::backtrace::__rust_begin_short_backtrace\n' +
            '             at rustc/a74d1862d4d87a56244958416fd05976c58ca1a8/src/libstd/sys_common/backtrace.rs:130\n' +
            '   8: main\n' +
            '   9: __libc_start_main\n' +
            '  10: _start\n'
        }
    

    Note that even actual error message Other Error: block DtdfWgnt3QDEjoeARUK25vg8qh31kc3Lrg6qREsoJsST is ahead of head block 34eT8dRWfDPhZBiRGYvkHDj65ThaXCBTrnM4LQjn2Zab doesn't go into proper place in message.

    This effectively makes current error message strings part of API, which is very suboptimal.

    Here's how we have to handle errors because of this:

    near-api-js

    src/account.ts
    120:                if (!error.message.match(/Transaction \w+ doesn't exist/)) {
    205:            if (e.message.includes('does not exist while viewing')) {
    
    src/wallet-account.ts
    193:                if (e.message.includes('does not have enough balance')) {
    

    near-wallet

    src/actions/account.js
    78:            if (error.message.indexOf('does not exist while viewing') !== -1) {
    
    src/reducers/allAccounts.js
    16:        if (payload.message.match('does not exist')) {
    

    Note that we also handle errors explicitly only in few cases (degrading user experience) because we want to avoid depending on error messages in this way. This problem also degrades quality of every app built on NEAR, as everybody has same problem.

    P-high A-RPC 
    opened by vgrichina 31
  • Fully switch to wasmer 1 by default

    Fully switch to wasmer 1 by default

    In https://github.com/near/nearcore/pull/3799, @ailisp implementing support for wasmer 1.0 :tada:

    However, we are still using wasmer 0.17 by default -- major upgrade of vm version is not a laughing matter, we must make sure that the two behave identically. This issue exists to track our progress on switching to wasmer 1.0 by default, and eventual removal of support for wasemer 0.17 from the tree.

    The next step in transition is to deploy a fraction of nodes with wasmer1 to the beta net.

    T-SRE 
    opened by matklad 28
  • Extend the Math API with EVM precompiles

    Extend the Math API with EVM precompiles

    To speed up performance and lower the cost of EVM-as-a-contract, this adds several functions to the contract runtime Math API in order to support implementing the standard EVM precompiled contracts:

    • #3922 ripemd160() (RIPEMD-160 hash function)
    • #3953 blake2b() (BLAKE2b hash function)
    • #3921 ecrecover() (ECRecover ECDSA signer recovery)

    References:

    • https://ethereum.stackexchange.com/questions/15479/list-of-pre-compiled-contracts/15483#15483
    • https://docs.soliditylang.org/en/latest/units-and-global-variables.html#mathematical-and-cryptographic-functions
    • https://en.wikipedia.org/wiki/RIPEMD
    • https://en.wikipedia.org/wiki/BLAKE_(hash_function)
    • https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/cryptography/ECDSA.sol
    C-enhancement A-transaction-runtime A-cryptography A-EVM T-public-interfaces 
    opened by artob 27
  • Incompatible with Macs based on the Apple M1 chip

    Incompatible with Macs based on the Apple M1 chip

    I'm recording this as a current known limitation: nearcore currently requires an x86 host which supports the AVX extensions.

    https://github.com/near/nearcore/blob/daad871d042a838220ce5823d12844e94ce3af1f/runtime/near-vm-runner/src/wasmer_runner.rs#L191-L196

    Apple's Rosetta does not support AVX as of macOS 11.1 (Big Sur):

    Rosetta translates all x86_64 instructions, but it doesn’t support the execution of some newer instruction sets and processor features, such as AVX, AVX2, and AVX512 vector instructions. If you include these newer instructions in your code, execute them only after verifying that they are available.

    This effectively precludes running nearcore on Apple Silicon, such as the initial Apple M1 chip found in the new 2020 MacBook Pro, MacBook Air, and Mac Mini. While that's unlikely to be an issue for any production deployments, it will increasingly hamper our development as developers switch to new Macs.

    The future is NEAR and the future is ARM (on Macs, at least), so we better figure out how to reconcile the two before too long.

    C-bug C-discussion A-contract-runtime 
    opened by artob 26
  • rpc requests interfere with block production

    rpc requests interfere with block production

    We have seen multiple times now that on testnet even a moderate amount of rpc requests can cause block production to slow down, which is quite undesirable. We need to understand the root cause and whether it is easily solvable. The last resort would be to disable rpc on block producing nodes.

    C-enhancement P-low A-network A-RPC T-node 
    opened by bowenwang1996 25
  • refactor(neard): switch to derive clap

    refactor(neard): switch to derive clap

    • Refactors CLI to use the derive flavour of clap (which is basically just structopt)
    • Separates subcommand into separate modules (to keep main concise and allow cleaner expansion on the CLI)

    I will decide now whether or not to

    • Move some of the validation logic into these new structures, to avoid passing strings and parsing later

    Any input would be appreciated what is ideal :)

    I wrote a script to run on all sub-commands, and although testing functionality would be tedious, here is their outputs if anyone wants to diff:

    Before
    NEAR Protocol Node 1.2.0 (build 07b4fd45) (protocol 45) (db 23)
    
    USAGE:
        neard [OPTIONS] <SUBCOMMAND>
    
    FLAGS:
        -h, --help       Prints help information
        -V, --version    Prints version information
    
    OPTIONS:
            --home <home>          Directory for config and data (default "~/.near") [default: /home/austinabell/.near]
            --verbose <verbose>    Verbose logging
    
    SUBCOMMANDS:
        help                 Prints this message or the help of the given subcommand(s)
        init                 Initializes NEAR configuration
        run                  Runs NEAR node
        testnet              Setups testnet configuration with all necessary files (validator key, node key, genesis and
                             config)
        unsafe_reset_all     (unsafe) Remove all the config, keys, data and effectively removing all information about
                             the network
        unsafe_reset_data    (unsafe) Remove all the data, effectively resetting node to genesis state (keeps genesis
                             and config)
    neard-init 
    Initializes NEAR configuration
    
    USAGE:
        neard init [FLAGS] [OPTIONS]
    
    FLAGS:
            --download-genesis    Download the verified NEAR genesis file automatically.
            --fast                Makes block production fast (TESTING ONLY)
        -h, --help                Prints help information
        -V, --version             Prints version information
    
    OPTIONS:
            --account-id <account-id>                        Account ID for the validator key
            --chain-id <chain-id>                            Chain ID, by default creates new random
            --download-genesis-url <download-genesis-url>    Specify a custom download URL for the genesis-file.
            --genesis <genesis>
                Genesis file to use when initialize testnet (including downloading)
    
            --num-shards <num-shards>                        Number of shards to initialize the chain with
            --test-seed <test-seed>                          Specify private key generated from seed (TESTING ONLY)
    neard-testnet 
    Setups testnet configuration with all necessary files (validator key, node key, genesis and config)
    
    USAGE:
        neard testnet [OPTIONS]
    
    FLAGS:
        -h, --help       Prints help information
        -V, --version    Prints version information
    
    OPTIONS:
            --n <n>              Number of non-validators to initialize the testnet with (default 0)
            --prefix <prefix>    Prefix the directory name for each node with (node results in node0, node1, ...) (default
                                 "node")
            --shards <s>         Number of shards to initialize the testnet with (default 4)
            --v <v>              Number of validators to initialize the testnet with (default 4)
    neard-run 
    Runs NEAR node
    
    USAGE:
        neard run [FLAGS] [OPTIONS]
    
    FLAGS:
            --archive    Keep old blocks in the storage (default false)
        -h, --help       Prints help information
        -V, --version    Prints version information
    
    OPTIONS:
            --boot-nodes <boot-nodes>                        Set the boot nodes to bootstrap network from
            --min-peers <min-peers>                          Minimum number of peers to start syncing / producing blocks
            --network-addr <network-addr>
                Customize network listening address (useful for running multiple nodes on the same machine)
    
            --produce-empty-blocks <produce-empty-blocks>
                Set this to false to only produce blocks when there are txs or receipts (default true)
    
            --rpc-addr <rpc-addr>
                Customize RPC listening address (useful for running multiple nodes on the same machine)
    
            --telemetry-url <telemetry-url>                  Customize telemetry url
    neard-unsafe_reset_data 
    (unsafe) Remove all the data, effectively resetting node to genesis state (keeps genesis and config)
    
    USAGE:
        neard unsafe_reset_data
    
    FLAGS:
        -h, --help       Prints help information
        -V, --version    Prints version information
    neard-unsafe_reset_all 
    (unsafe) Remove all the config, keys, data and effectively removing all information about the network
    
    USAGE:
        neard unsafe_reset_all
    
    FLAGS:
        -h, --help       Prints help information
        -V, --version    Prints version information
    
    After
    neard 1.2.0 (build 6ee4308a) (protocol 45) (db 23)
    NEAR Protocol Node
    
    USAGE:
        neard [OPTIONS] <SUBCOMMAND>
    
    FLAGS:
        -h, --help       Prints help information
        -V, --version    Prints version information
    
    OPTIONS:
            --home <home>          Directory for config and data (default "~/.near")
            --verbose <verbose>    Verbose logging
    
    SUBCOMMANDS:
        help                 Prints this message or the help of the given subcommand(s)
        init                 Initializes NEAR configuration
        run                  Runs NEAR node
        testnet              Sets up testnet configuration with all necessary files (validator key,
                             node key, genesis and config)
        unsafe_reset_all     (unsafe) Remove all the config, keys, data and effectively removing all
                             information about the network
        unsafe_reset_data    (unsafe) Remove all the data, effectively resetting node to the genesis
                             state (keeps genesis and config)
    neard-init 
    Initializes NEAR configuration
    
    USAGE:
        neard init [FLAGS] [OPTIONS]
    
    FLAGS:
            --download-genesis    Download the verified NEAR genesis file automatically
            --fast                Makes block production fast (TESTING ONLY)
        -h, --help                Prints help information
        -V, --version             Prints version information
    
    OPTIONS:
            --account-id <account-id>                        Account ID for the validator key
            --chain-id <chain-id>                            Chain ID, by default creates new random
            --download-genesis-url <download-genesis-url>
                Specify a custom download URL for the genesis-file
    
            --genesis <genesis>
                Genesis file to use when initializing testnet (including downloading)
    
            --num-shards <num-shards>
                Number of shards to initialize the chain with [default: 1]
    
            --test-seed <test-seed>
                Specify private key generated from seed (TESTING ONLY)
    
    neard-testnet 
    Sets up testnet configuration with all necessary files (validator key, node key, genesis and config)
    
    USAGE:
        neard testnet [OPTIONS]
    
    FLAGS:
        -h, --help       Prints help information
        -V, --version    Prints version information
    
    OPTIONS:
            --n <non-validators>    Number of non-validators to initialize the testnet with [default: 0]
            --prefix <prefix>       Prefix the directory name for each node with (node results in node0,
                                    node1, ...) [default: node]
            --shards <shards>       Number of shards to initialize the testnet with [default: 4]
            --v <validators>        Number of validators to initialize the testnet with [default: 4]
    neard-run 
    Runs NEAR node
    
    USAGE:
        neard run [FLAGS] [OPTIONS]
    
    FLAGS:
            --archive    Keep old blocks in the storage (default false)
        -h, --help       Prints help information
        -V, --version    Prints version information
    
    OPTIONS:
            --boot-nodes <boot-nodes>
                Set the boot nodes to bootstrap network from
    
            --min-peers <min-peers>
                Minimum number of peers to start syncing/producing blocks
    
            --network-addr <network-addr>
                Customize network listening address (useful for running multiple nodes on the same
                machine)
    
            --produce-empty-blocks <produce-empty-blocks>
                Set this to false to only produce blocks when there are txs or receipts (default true)
    
            --rpc-addr <rpc-addr>
                Customize RPC listening address (useful for running multiple nodes on the same machine)
    
            --telemetry-url <telemetry-url>                  Customize telemetry url
    neard-unsafe_reset_data 
    (unsafe) Remove all the data, effectively resetting node to the genesis state (keeps genesis and
    config)
    
    USAGE:
        neard unsafe_reset_data
    
    FLAGS:
        -h, --help       Prints help information
        -V, --version    Prints version information
    neard-unsafe_reset_all 
    (unsafe) Remove all the config, keys, data and effectively removing all information about the
    network
    
    USAGE:
        neard unsafe_reset_all
    
    FLAGS:
        -h, --help       Prints help information
        -V, --version    Prints version information
    

    Closes #4347

    S-automerge 
    opened by austinabell 24
  • 1.31.0-rc.1 - SIGTERM bug

    1.31.0-rc.1 - SIGTERM bug

    Saw this while upgrading testnet to 1.31.0-rc.1 The node restarted and recovered. It says "bug detected", so letting the team know about it.

    2023-01-04T17:06:45.517603Z  INFO neard: version="1.31.0-rc.1" build="1.31.0-rc.1" latest_protocol=57
    2023-01-04T17:08:37.275282Z  INFO stats: #111558947 Downloading blocks 52.59% (339 left; at 111558947) 24 peers ⬇ 4.08 MB/s ⬆ 2.82 MB/s 12.11 bps 111 Tgas/s CPU: 279%, Mem: 2.16 GB
    2023-01-04T17:08:38.339374Z  WARN neard: SIGTERM, stopping... this may take a few minutes.
    thread '<unnamed>' panicked at 'bug detected: OutboundHandshakePermit dropped before calling Pool.insert_ready()', chain/network/src/peer_manager/connection/mod.rs:323:25
    2023-01-04T17:08:38.344593Z  INFO neard: Waiting for RocksDB to gracefully shutdown
    2023-01-04T17:08:38.344602Z  INFO db: Waiting for remaining RocksDB instances to shut down num_instances=1
    stack backtrace:
       0: rust_begin_unwind
                 at ./rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:584:5
       1: core::panicking::panic_fmt
                 at ./rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/panicking.rs:142:14
       2: near_network::peer_manager::connection::Pool::insert_ready
       3: tokio::runtime::task::harness::poll_future
       4: tokio::runtime::task::raw::poll
    note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
    

    when I first deployed the upgrade, I got an error message saying my ulimit was too low and it needed to be updated to 65535. I did that and restarted the node and then I got the above message.

    I also run 2 other nodes, I applied the ulimit changes to those first and never saw the panic above.

    opened by nick-u410 0
  • chore: remove outdated constant ATTO_NEAR

    chore: remove outdated constant ATTO_NEAR

    This constant is:

    • wrong: it should be yocto near (10^-24) and not atto (10^-18)
    • outdated: we haven't used atto near since 2019 (#1827)
    • unused: there are no code references to it

    Better we get rid of it.

    opened by jakmeier 0
  • Regression for Tier1 public addresses in 1.31.0-rc.1

    Regression for Tier1 public addresses in 1.31.0-rc.1

    Describe the bug

    In neard 1.30 we were able to specify in addition to our ip address also an legacy ipv4 address like this:

     "network": {
        "public_addrs": [
           "ed25519:AtHDrCYckKmhJKqzX94mKHtshWC3VSkEsDa3tBVvEkj@[2001:41d0:800:3f9a::1]:24567",
           "ed25519:[email protected]:24567"
        ],
     }
    

    With neard 1.31.0-rc.1 however we get the following error message:

    thread 'main' panicked at 'Error loading config: public_addrs: found multiple entries with peer_id ed25519:ydgzeXHJ5Xyt7M1gXLxqLBW1Ejx6scNV5Nx2pxFM8su. Only 1 entry per peer_id is supported.', neard/src/cli.rs:397:33
    

    Expected behavior

    neard accepts at least two addresses so that we can also support ipv4 in addition to ipv6. Otherwise people that do not have ipv6 yet, won't be able to connect to our nodes.

    opened by Mic92 0
  • chore: upgrade rust-version to 1.66.0

    chore: upgrade rust-version to 1.66.0

    https://blog.rust-lang.org/2022/12/15/Rust-1.66.0.html

    Updated the same files as in the previous version bump: https://github.com/near/nearcore/pull/7993

    This enables https://github.com/near/nearcore/issues/7650 (see this comment).

    Also includes fixes for the following warning:

    warning: for loop over an `Option`. This is more readably written as an `if let` statement
         ...
         = note: `#[warn(for_loops_over_fallibles)]` on by default
    
    opened by pugachAG 1
  • Dynamic Chunk Gas Limit (only in discussion)

    Dynamic Chunk Gas Limit (only in discussion)

    There have been discussions around adjusting gas limits per chunk dynamically, in an effort to automatically resolve undercharging that negatively impacts block production time. Let's track the facts around that here so it does not get lost.

    How it Works Without a Protocol Upgrade

    The chunk header has a field called gas_limit which is initialized to the constant 1000 Tgas in the genesis configuration. When producing a new chunk, we always set it to the new limit to the old value. (See pub fn produce_chunk)

    However, it seems that adjusting the limit by less than 1 / GAS_LIMIT_ADJUSTMENT_FACTOR = 0.1% will pass chunk header validation. This means, AFAIU, we could implement a change where a chunk producer (single-handedly) decides to increase or decrease the value based on its local "measurement of undercharging" without violating the protocol. This adjustment does not need to be deterministic, the chunk producer has the freedom to decide this value.

    What we could do

    We could continuously measure the chunk production time in nearcore clients and compare it to the gas burnt. If the chunk producer observes undercharging, it decreases the limit. If there is overcharging, the limit can be increased up to a limit of at most 1000 Tgas.

    To avoid volatility, I suggest to use a moving average of observed under/overcharging. And we might want to limit how much a single validator adjusts the value, especially if it is the only one observing the undercharging. For example, if a chunk producer has decreased the limit already in the previous chunk it produced, it would only decrease again if another chunk producer has also decreased the limit at least once in the meantime.

    Pros and Cons

    Good:

    • Prevent moderate undercharging from stalling the network.
    • No protocol change necessary, we could easily experiment and revert if it does not work well.

    Bad:

    • Very broad granularity. (Undercharging in one parameter affects all users, even those that never use the undercharged parts.)
    • Dependence on validator hardware. (Someone running overspecced hardware will continuously want to increase the limit, others might run with underspecced hardware and continuously want to decrease the limit.)
    • Malicious undercharging attacks are unlikely to be prevented by this. (A single 10x undercharged receipt still needs to be processed using the old limit. Adjusting 0.1% per block means 100 chunks can only change by a maximum of 1.1x and 1000 chunks could do a factor of 2.7).
    • Conflict with transaction & receipt limit. A transaction or receipt can (today) use up to 300Tgas. The effective limit per chunk is gas_limit + 300Tgas since receipts are added to a chunk until one exceeds the limit and the last receipt is not removed. Thus a gas limit of 0gas only reduces the effective limit from 1300Tgas to 300Tgas, which means undercharging of > 4.33x is not covered.
    C-discussion A-transaction-runtime 
    opened by jakmeier 1
Releases(1.31.0-rc.1)
  • 1.31.0-rc.1(Jan 3, 2023)

    Non-protocol changes

    • Enable TIER1 network. Participants of the BFT consensus (block & chunk producers) now can establish direct TIER1 connections between each other, which will optimize the communication latency and minimize the number of dropped chunks. To configure this feature, see advanced_configuration/networking. #8141, #8085, #7759
    • /status response has now two more fields: node_public_key and validator_public_key. The node_key field is now deprecated and should not be used since it confusingly holds validator key. #7828
    • Added near_node_protocol_upgrade_voting_start Prometheus metric whose value is timestamp when voting for the next protocol version starts. #7877
    • neard cmd can now verify proofs from JSON files. #7840
    • In storage configuration, the value trie_cache_capacities now is no longer a hard limit but instead sets a memory consumption limit. For large trie nodes, the limits are close to equivalent. For small values, there can now fit more in the cache than previously. #7749
    • New options store.trie_cache and store.view_trie_cache in config.json to set limits on the trie cache. Deprecates the never announced store.trie_cache_capacities option which was mentioned in previous change. #7578
    • New option store.background_migration_threads in config.json. Defines number of threads to execute background migrations of storage. Currently used for flat storage migration. Set to 8 by default, can be reduced if it slows down block processing too much or increased if you want to speed up migration. #8088,
    • Tracing of work across actix workers within a process: #7866, #7819, #7773.
    • Scope of collected tracing information can be configured at run-time: #7701.
    • Attach node's chain_id, node_id, and account_id values to tracing information: #7711.
    • Change exporter of tracing information from opentelemetry-jaeger to opentelemetry-otlp: #7563.
    • Tracing of requests across processes: #8004.
    CODE_COLOR: CODE_GREEN_TESTNET
    RELEASE_VERSION: 1.31.0-rc.1
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: TRUE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.30.0(Dec 12, 2022)

    Features:

    Fixes

    CODE_COLOR: CODE_YELLOW_MAINNET
    RELEASE_VERSION: 1.30.0
    PROTOCOL_UPGRADE: TRUE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.29.3(Dec 5, 2022)

    Fixes

    • adjustments to gas computations
    CODE_COLOR: CODE_RED_MAINNET
    RELEASE_VERSION: 1.29.3
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: TRUE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.30.0-rc.6(Dec 5, 2022)

    Fixes

    • adjustments to gas computations
    CODE_COLOR: CODE_RED_TESTNET
    RELEASE_VERSION: 1.30.0-rc.6
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: TRUE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.29.2(Nov 29, 2022)

    Fixes:

    • Rosetta RPC predecessor_id is now set on each state change
    CODE_COLOR: CODE_GREEN_MAINNET
    RELEASE_VERSION: 1.29.2
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.29.1(Nov 16, 2022)

    Features:

    • The logic of handling old protocol versions is improved. Validator nodes will now exit if their protocol version doesn't match the current epoch's
    CODE_COLOR: CODE_GREEN_MAINNET
    RELEASE_VERSION: 1.29.1
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.30.0-rc.4(Oct 14, 2022)

    Fixes

    • Revert "json: remove deprecated old style path+data request format"
    • Add sync_height_threshold to config (#7805)
    • Move the check for is_height_processed forward before process_block_header (#7831)
    CODE_COLOR: CODE_YELLOW_TESTNET
    RELEASE_VERSION: 1.30.0-rc.4
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.30.0-rc.2(Oct 5, 2022)

    Fixes

    • Pushing the start of 57 protocol version voting to 10.10.2022
    CODE_COLOR: CODE_YELLOW_TESTNET
    RELEASE_VERSION: 1.30.0-rc.2
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.30.0-rc.1(Oct 3, 2022)

    Features

    • account_id_in_function_call_permission enforces that account id in function call permission is indeed a valid account id #7569
    • NEP-364 implements ed25519_verify host function #7165
    • Rust 1.63.0 #7434
    • Add proof to ViewState response and include_proof argument to ViewState request #7603 #7593
    • New metrics #7525 #7613

    Fixes

    • Deprecate GCCount column #7632
    • near-vm-runner: fix m1 build #7587
    CODE_COLOR: CODE_YELLOW_TESTNET
    RELEASE_VERSION: 1.30.0-rc.1
    PROTOCOL_UPGRADE: TRUE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.29.0(Sep 21, 2022)

    Protocol Changes

    • Voting for the protocol upgrade is scheduled to start at 2022-09-28 15:00:00 UTC.
    • Stabilized protocol_feature_chunk_only_producers. Validators will now be assigned to blocks and chunks separately.
    • The validator uptime kickout threshold has been reduced to 80%
    • Total stake of kicked out validators will not exceed 30% of total stake

    Features:

    • The logic around forwarding chunks to validators is improved
    • Approvals and partial encoded chunks are now sent multiple times, which should reduce stalls due to lost approvals when the network is under high load
    • We now keep a list of "TIER1" accounts (validators) for whom latency/reliability of messages routed through the network is critical
    • /debug HTTP page has been improved
    • Messages aren't routed through peers that are too far behind
    • network.external_address field in config.json file is deprecated.
    • More useful metrics around message handling have been added
    • Data from the DB is now prefetched while applying chunks

    Fixes:

    • Log lines printed every 10 seconds are now less expensive to compute
    • message broadcasts have been improved/optimized
    • Contention in the peer actor/networking code has been reduced.
    • A bug that made chain info unavailable to the client at startup has been fixed.
    • Improved shard cache for Trie nodes to put more nodes in memory. Requires additional RAM memory.
    • The logic involved in processing chunk parts that have been forwarded to a validator has been improved
    CODE_COLOR: CODE_YELLOW_MAINNET
    RELEASE_VERSION: 1.29.0
    PROTOCOL_UPGRADE: TRUE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    

    More Information

    Chunk-only producers

    The 1.29 release introduces Chunk-only producers, an important change in the protocol that improves NEAR’s sharding capabilities and contributes to further decentralization of the protocol.

    What chunk-only producers mean for validators? The number of mainnet validators will increase: currently mainnet has 100 validators, and after this protocol change, we’ll have 100 “block producers” and 200 “chunk-only producers”. In total, there will be up to 300 active participants in the blockchain.

    Role assignment is based on stake: the protocol will select the top 100 nodes (based on the stake) and assign them as “block producers”. The following 200 nodes (again, based on stake) are assigned as “chunk-only producers”.

    Each chunk in a block will be produced by a different producer - so there will be 5 independent producers participating in every block production (4 chunk producers and 1 block producer). This might increase the number of cases where a block is missing a few chunks. Currently (in 1.28) the same entity produces the block and all the chunks - so usually either the whole block is missing, or all chunks are present.

    Configuration Changes

    [MANDATORY] tracked_shards

    Make sure that you have "tracked_shards" set:

    "tracked_shards": [0],
    

    In your config.json. If you don’t - the new binary will probably panic on start ;-)

    The reason why this is needed is the following: with chunk-only producers, the algorithm itself no longer requires everyone to produce chunks from every shard. You’ll notice that most of the validators will be assigned to a single shard.

    But, for security reasons, we have to make sure that all the validators are tracking all the shards. This approach will be maintained until we complete Phase 2 of sharding (that includes Challenges, roll-back support, etc).

    [OPTIONAL / Will be mandatory in the future] Public IP addresses

    As a part of strengthening the network, we’ll slowly be moving towards requiring public IP addresses for the validators (or running a proxy node with public IPs).

    In the simplest setup, this will require you to set: public_addrs = [“ed25519:YOUR_NODE_KEY_JSON_PUBLIC_KEY:YOUR_IP_ADDRESS:PORT”] Within the network tuple in config.json.

    Example: ["ed25519:[email protected]:24567"]

    You can see more information about this config option here: https://github.com/near/nearcore/blob/a9405ce9e21a9c2f5ecd8cfb848234bedbea10bb/chain/network/src/config_json.rs#L146

    In this release, public IP addresses are still optional. Don’t hesitate to contact us if you have any questions about this.

    [OPTIONAL] Enable Debug RPC

    In this release we’ve added many debug features that will allow you to quickly see what’s happening with your node). You can find instructions about them here: https://nearinc.atlassian.net/wiki/spaces/DOCS/pages/139296992/Debug+RPC+and+debug+pages

    To enable the debug features, you have to set: "enable_debug_rpc": true

    in your config.json file.

    Note: This is also a great place where you can contribute to protocol development. If you see some more things that should be added to the debug pages, don’t hesitate to create a github issue and/or implement it yourself.

    [OPTIONAL] Sharing metrics with Pagoda

    This is very much optional, but we’d like to ask you to allow us to scrape the metrics from your validator node. Doing so would allow us to detect and debug mainnet issues a lot faster - and we’ll be able to share back some aggregated metrics back with the community.

    Metric sharing can be done by whitelisting 2 IP addresses that we’ll use for our prometheus scraper. More information in: https://nearinc.atlassian.net/wiki/spaces/DOCS/pages/149979169/Exposing+validators+metrics+to+Pagoda

    If you would like to enable sharing, please follow the steps in the link above, and fill-in this form: https://forms.gle/rQwwe9q4PKuUmGAx9

    [FYI] Changing log level at runtime

    Did you know that you can change the neard log level at runtime? This allows you to enable more detailed logging, whenever something bad/suspicious happens with your node, without having to do a restart.

    More info: https://nearinc.atlassian.net/wiki/spaces/DOCS/pages/149946369/Change+neard+log+level+at+runtime

    Source code(tar.gz)
    Source code(zip)
  • 1.29.0-rc.4(Sep 20, 2022)

    Fixes:

    • Reverts a change to compilation flags that caused a regression in database performance
    CODE_COLOR: CODE_GREEN_TESTNET
    RELEASE_VERSION: 1.29.0-rc.4
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.29.0-rc.3(Sep 15, 2022)

    Features:

    • data from the DB is now prefetched while applying chunks

    Fixes:

    • A slowdown due to recently added metrics has been fixed
    • The logic involved in processing chunk parts that have been forwarded to a validator has been improved
    CODE_COLOR: CODE_GREEN_TESTNET
    RELEASE_VERSION: 1.29.0-rc.3
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.28.1(Aug 30, 2022)

    Validators need to update before 9th of September or else they will start missing blocks.

    Note that the release will use 3 GB more memory.

    Fixes:

    • Improved shard cache for Trie nodes to put more nodes in memory.
    CODE_COLOR: CODE_YELLOW_MAINNET
    RELEASE_VERSION: 1.28.1
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.29.0-rc.2(Aug 26, 2022)

    Features:

    More useful metrics around message handling have been added.

    Fixes:

    Contention in the peer actor/networking code has been reduced. A bug that made chain info unavailable to the client at startup has been fixed. Improved shard cache for Trie nodes to put more nodes in memory. Requires 3 GB more RAM.

    CODE_COLOR: CODE_GREEN_TESTNET
    RELEASE_VERSION: 1.29.0-rc.2
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.29.0-rc.1(Aug 15, 2022)

    Protocol Changes

    • Voting for the protocol upgrade is scheduled to start at 2022-08-17 15:00:00 UTC.
    • Stabilized protocol_feature_chunk_only_producers. Validators will now be assigned to blocks and chunks separately.
    • The validator uptime kickout threshold has been reduced to 80%
    • Total stake of kicked out validators will not exceed 30% of total stake
    • Edge nonces between peers can now optionally indicate an expiration time

    Features:

    • The logic around forwarding chunks to validators is improved
    • Approvals and partial encoded chunks are now sent multiple times, which should reduce stalls due to lost approvals when the network is under high load
    • We now keep a list of "TIER1" accounts (validators) for whom latency/reliability of messages routed through the network is critical
    • /debug HTTP page has been improved
    • Messages aren't routed through peers that are too far behind
    • network.external_address field in config.json file is deprecated. In fact it has never been used and only served to confuse everyone #7300

    Fixes:

    • Log lines printed every 10 seconds are now less expensive to compute
    • message broadcasts have been improved/optimized
    CODE_COLOR: CODE_YELLOW_TESTNET
    RELEASE_VERSION: 1.29.0-rc.1
    PROTOCOL_UPGRADE: TRUE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.28.0(Jul 27, 2022)

    1.28.0

    Protocol changes

    • Voting for the protocol upgrade is scheduled to start at 2022-08-01 15:00:00 UTC.
    • Stabilised alt_bn128_g1_multiexp, alt_bn128_g1_sum and alt_bn128_pairing_check host functions. This is a protocol change #6813.

    Features

    • Added path option to store configuration which makes location of the RocksDB database customisable via config.json file (at store.path path). #6938
    • Added single-letter -v, -n and -s switches to localnet command. #6808
    • Key files can use private_key field instead of secret_key now. This improves interoperability with near cli which uses the former name. #7030
    • Added Prometheus metrics related to state of the chain, namely: near_balance_burnt, near_blocks_processed, near_chunks_processed, near_final_block_height, near_final_doomslug_block_height, near_gas_price, near_gas_used, near_node_protocol_version and near_total_supply. #6861
    • Deprecated some Prometheus metrics which performed aggregation in process (rather than leaving it to monitoring system to do) Specifically: near_blocks_per_minute, near_chunk_tgas_used and near_chunks_per_block_millis. #6861
    • Added network latency measurements. #7050
    • Rosetta RPC account balance request now accepts public keys in metadata and returns corresponding nonces #7186

    Fixes

    • Limited Rosetta API to return information about finalised blocks only. #6457

    Removed features

    • Removed testnet alias for localnet command; it’s been deprecated since 1.24 release. (The localnet command itself is still available of course). #7033
    • Removed unsafe_reset_all and unsafe_reset_data commands; they’ve been deprecated since 1.25 release. #7026
    CODE_COLOR: CODE_YELLOW_MAINNET
    RELEASE_VERSION: 1.28.0
    PROTOCOL_UPGRADE: TRUE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.28.0-rc.3(Jul 15, 2022)

    The release improves stability of the executable and fixes Rosetta RPC interface.

    Non-protocol Changes

    • Rosetta RPC account balance request now accepts public keys in metadata and returns corresponding nonces #7186

    Fixes

    • Fixed tracing span leakage causing stack overflow errors. This was supposed to be fixed by -rc.2 but due to incorrect backport it didn’t quite happen #7172 #7188
    CODE_COLOR: CODE_GREEN_TESTNET
    RELEASE_VERSION: 1.28.0-rc.3
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.28.0-rc.2(Jul 13, 2022)

    The release improves stability of the executable.

    Fixes

    • Fixed tracing span leakage causing stack overflow errors #7172
    CODE_COLOR: CODE_GREEN_TESTNET
    RELEASE_VERSION: 1.28.0-rc.2
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.28.0-rc.1(Jun 29, 2022)

    1.28.0-rc.1

    Protocol changes

    • Voting for the testnet protocol upgrade is scheduled to start at 2022-07-04 15:00:00 UTC.
    • Stabilised alt_bn128_g1_multiexp, alt_bn128_g1_sum and alt_bn128_pairing_check host functions. This is a protocol change #6813.

    Features

    • Added path option to store configuration which makes location of the RocksDB database customisable via config.json file (at store.path path). #6938
    • Added single-letter -v, -n and -s switches to localnet command. #6808
    • Key files can use private_key field instead of secret_key now. This improves interoperability with near cli which uses the former name. #7030
    • Added Prometheus metrics related to state of the chain, namely: near_balance_burnt, near_blocks_processed, near_chunks_processed, near_final_block_height, near_final_doomslug_block_height, near_gas_price, near_gas_used, near_node_protocol_version and near_total_supply. #6861
    • Deprecated some Prometheus metrics which performed aggregation in process (rather than leaving it to monitoring system to do) Specifically: near_blocks_per_minute, near_chunk_tgas_used and near_chunks_per_block_millis. #6861
    • Added network latency measurements. #7050

    Fixes

    • Limited Rosetta API to return information about finalised blocks only. #6457

    Removed features

    • Removed testnet alias for localnet command; it’s been deprecated since 1.24 release. (The localnet command itself is still available of course). #7033
    • Removed unsafe_reset_all and unsafe_reset_data commands; they’ve been deprecated since 1.25 release. #7026
    CODE_COLOR: CODE_YELLOW_TESTNET
    RELEASE_VERSION: 1.28.0-rc.1
    PROTOCOL_UPGRADE: TRUE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.27.0(Jun 22, 2022)

    Voting for the mainnet protocol upgrade is scheduled to start at 2022-06-27 15:00:00 UTC.

    Features

    • Introduced protobuf encoding as the new network protocol. Borsh support will be removed in two releases as per normal protocol upgrade policies https://github.com/near/nearcore/pull/6672
    • Added near_peer_message_received_by_type_bytes https://github.com/near/nearcore/pull/6661 and near_dropped_message_by_type_and_reason_count https://github.com/near/nearcore/pull/6678 metrics.
    • Removed near_{total,bytes} https://github.com/near/nearcore/pull/6661, near_dropped, near_drop_message_unknown_account and near_dropped_messages_count https://github.com/near/nearcore/pull/6678 metrics.
    • Added near_action_called_count metric https://github.com/near/nearcore/pull/6679
    • Removed near_action__total metrics https://github.com/near/nearcore/pull/6679
    • Added near_build_info metric which exports neard’s build information https://github.com/near/nearcore/pull/6680
    • Make it possible to update logging at runtime: https://github.com/near/nearcore/issues/6665
    • Added a command-line flag to disable colored log output: https://github.com/near/nearcore/pull/6779

    Fixes

    • Use correct cost in gas profile for adding function call key https://github.com/near/nearcore/pull/6749
    • Add Empty enum to OperationStatusKind https://github.com/near/nearcore/pull/6952
    CODE_COLOR: CODE_YELLOW_MAINNET
    RELEASE_VERSION: 1.27.0
    PROTOCOL_UPGRADE: TRUE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.27.0-rc.5(Jun 20, 2022)

    Features

    Revert: Trie cache factory to allow variable cache sizes https://github.com/near/nearcore/pull/7022

    CODE_COLOR: CODE_GREEN_TESTNET
    RELEASE_VERSION: 1.27.0-rc.5
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.27.0-rc.4(Jun 16, 2022)

    Features

    • Trie cache factory to allow variable cache sizes #7022

    Fixes

    • Add Empty enum to OperationStatusKind #6952
    CODE_COLOR: CODE_GREEN_TESTNET
    RELEASE_VERSION: 1.27.0-rc.4
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.27.0-rc.3(Jun 7, 2022)

    Fixes

    • Fix telemetry SSL issue: #6925
    CODE_COLOR: CODE_GREEN_TESTNET
    RELEASE_VERSION: 1.27.0-rc.3
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.27.0-rc.2(May 30, 2022)

    Fixes

    • Upgrade wasmer to 2.4.0 to fix a security issue
    CODE_COLOR: CODE_RED_TESTNET
    RELEASE_VERSION: 1.27.0-rc.2
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: TRUE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.26.1(May 30, 2022)

    Fixes

    • Upgrade wasmer to 2.2.3 to fix a security issue
    CODE_COLOR: CODE_RED_MAINNET
    RELEASE_VERSION: 1.26.1
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: TRUE
    Source code(tar.gz)
    Source code(zip)
  • 1.27.0-rc.1(May 25, 2022)

    Voting for the testnet protocol upgrade is scheduled to start at 2022-05-30 15:00:00 UTC.

    Features

    • Introduced protobuf encoding as the new network protocol. Borsh support will be removed in two releases as per normal protocol upgrade policies https://github.com/near/nearcore/pull/6672
    • Added near_peer_message_received_by_type_bytes https://github.com/near/nearcore/pull/6661 and near_dropped_message_by_type_and_reason_count https://github.com/near/nearcore/pull/6678 metrics.
    • Removed near_<msg-type>_{total,bytes} https://github.com/near/nearcore/pull/6661, near_<msg-type>_dropped, near_drop_message_unknown_account and near_dropped_messages_count https://github.com/near/nearcore/pull/6678 metrics.
    • Added near_action_called_count metric https://github.com/near/nearcore/pull/6679
    • Removed near_action_<action-type>_total metrics https://github.com/near/nearcore/pull/6679
    • Added near_build_info metric which exports neard’s build information https://github.com/near/nearcore/pull/6680
    • Make it possible to update logging at runtime: https://github.com/near/nearcore/pull/6666
    • Added a command-line flag to disable colored log output: https://github.com/near/nearcore/pull/6779

    Fixes

    • Use correct cost in gas profile for adding function call key https://github.com/near/nearcore/pull/6749
    CODE_COLOR: CODE_YELLOW_TESTNET
    RELEASE_VERSION: 1.27.0-rc.1
    PROTOCOL_UPGRADE: TRUE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.26.0(May 18, 2022)

    Protocol Upgrade Voting Start

    • Version 53 voting begins at 2022-05-23 15:00:00 UTC - validators will not indicate intent to upgrade to version 53 in blocks they produce until this time

    Features

    • Include promise_batch_action_function_call_weight host function on the runtime #6285 #6536
    • Switch to LZ4+ZSTD compression from Snappy in RocksDB #6365
    • Safe DB migrations using RocksDB checkpoints #6282
    • NEP205: Configurable start of protocol upgrade voting #6309.
    • Make max_open_files, col_state_cache_size and RocksDB block_size configurable parameters #6584 #6631
    • Use kebab-case names for neard subcommands to make them consistent with flag names. snake_case names are still valid for existing subcommands but kebab-case will be used for new commands.

    Fixes

    • Increase deployment cost #6397
    • Limit the number of locals per contract to 1_000_000
    • Ensure caching all nodes in the chunk for which touching trie node cost was charged, reduce cost of future reads in a chunk #6628
    • Lower storage key limit to 2 KiB
    • Moved Client Actor to separate thread - should improve performance #6333
    • Changes the gc_fork_clean_step config field default from 1000 to 100, which should reduce garbage collection related slowdowns.
    • Fixes an issue where blocks containing challenges aren't rejected by the chain, leading to crashes
    • Avoids an expensive calculation during sync that leads to an unresponsive /status page

    New config.json fields (non-breaking)

    • use_db_migration_snapshot - Enables checkpoints that let the user recover from interrupted DB migrations.
    • gc_fork_clean_step - Maximum blocks to go through at each garbage collection step when cleaning forks.
    • gc_num_epochs_to_keep - Number of epochs for which we keep store data
    • store.enable_statistics - Re-export storage layer statistics as prometheus metrics. Minor performance impact is expected.
    • store.max_open_files - Maximum number of store files being opened simultaneously.
    • store.col_state_cache_size - Cache size for ColState column.
    • store.block_size - Block size used internally in RocksDB.
    CODE_COLOR: CODE_YELLOW_MAINNET
    RELEASE_VERSION: 1.26.0
    PROTOCOL_UPGRADE: TRUE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: TRUE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.26.0-rc.3(May 11, 2022)

    Fixes

    • Fixes an issue where blocks containing challenges aren't rejected by the chain, leading to crashes
    • Avoids an expensive calculation during sync that leads to an unresponsive /status page
    CODE_COLOR: CODE_YELLOW_TESTNET
    RELEASE_VERSION: 1.26.0-rc.3
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: TRUE
    
    Source code(tar.gz)
    Source code(zip)
  • 1.26.0-rc.2(May 4, 2022)

    Features

    • Changes the gc_fork_clean_step config field default from 1000 to 100, which should reduce garbage collection related slowdowns.
    • Add a gc_num_epochs_to_keep config option

    Fixes

    • Count function imports towards the function limit, which fixes a regression introduced in -rc1
    CODE_COLOR: CODE_YELLOW_TESTNET
    RELEASE_VERSION: 1.26.0-rc.2
    PROTOCOL_UPGRADE: FALSE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: FALSE
    
    Source code(tar.gz)
    Source code(zip)
Owner
NEAR
Developer platform to create apps that put users back in control of their data and assets.
NEAR
A PoC backbone for NFT Marketplaces on NEAR Protocol

NFT Market Reference Implementation A PoC backbone for NFT Marketplaces on NEAR Protocol. Reference Changelog Changelog Progress: basic purchase of NF

null 9 May 26, 2022
A tutorial for an NFT Market Place Built with Near Protocol and React.js

nft-marketplace-part-1 A tutorial for an NFT Market Place built using Near Protocol and React.js. Preview To run this app locally, follow below steps:

Kohwo Orien 5 Jun 29, 2022
Durudex Near Protocol Token.

Durudex Near Token ?? Prerequisites Rust Near CLI ⚙️ Build To build a token you will need to use this: cargo build --all --target wasm32-unknown-unkno

Durudex 2 May 31, 2022
Helpful functions and macros for developing smart contracts on NEAR Protocol.

near-contract-tools Helpful functions and macros for developing smart contracts on NEAR Protocol. This package is a collection of common tools and pat

Jacob 27 Dec 17, 2022
Helpful functions and macros for developing smart contracts on NEAR Protocol.

near-contract-tools Helpful functions and macros for developing smart contracts on NEAR Protocol. This package is a collection of common tools and pat

NEARFoundation 9 Aug 3, 2022
Confidential credit scores and loan disbursal, powered by zkSNARKs and NEAR Protocol

zkLoans zkLoans brings confidential Credit Scores. It proves to a counterparty if you meet threshold requirements for a credit score without revealing

Anirudha Bose 2 Sep 13, 2022
Lesson 1 - Fundamental structure of smartcontract of near protocol

NEAR CONTRACT dev-1672293046853-49717456344735 pnpm run deploy > [email protected] deploy /Users/vudangquang/Courses/VBI-Courses/rs-contract > cd co

Dang Quang Vu 3 Jan 7, 2023
A reference NFT Staking Program & Client for Solana NFTs

This is a reference NFT Staking Program & Client for Solana NFTs. This program is compatible with both Candy Machine v1 and Candy Machine v2 NFTs.

Tracy Adams 73 Dec 19, 2022
Reference library that implements all the necessary functionality for developing a client that is compatible with TAPLE's DLT network.

⚠️ TAPLE is in early development and should not be used in production ⚠️ TAPLE Core TAPLE (pronounced T+ ?? ['tapəl]) stands for Tracking (Autonomous)

Open Canarias 6 Jan 25, 2023
Near contract collection for story-arc.io

arc-near-contracts TBD Development Setup Make sure to format code using defaults before every commit or set up the environment to handle this for you.

null 2 Mar 14, 2022
USN - the first NEAR-native stablecoin

USN USN is a NEAR-native USD stable coin. The contract implements fungible token API according to the following standards: NEP-141 (ERC-20 fashioned)

DecentralBank 52 Nov 2, 2022
A tool to help with estimating NEAR gas spent by transactions on Aurora.

Aurora Gas Estimator A tool to help with estimating NEAR gas spent by transactions on Aurora. Building from source Prerequisites Rust GNU Make (3.81+)

Michael Birch 4 Aug 23, 2022
evm2near compiles Solidity contracts into NEAR WebAssembly contracts.

EVM → NEAR evm2near is a project for compiling EVM bytecode into wasm bytecode, with the particular goal of having that wasm artifact be executable on

Aurora 125 Dec 3, 2022
Reference implementation for the Poseidon Snark-friendly Hash algorithm.

Dusk-Poseidon Reference implementation for the Poseidon Hashing algorithm. Reference Starkad and Poseidon: New Hash Functions for Zero Knowledge Proof

Dusk Network 96 Jan 2, 2023
Twinsies is a specialized reference-counting pointer where the item is jointly owned in 2 places

twinsies Twinsies is a special shared pointer, similar to an Arc, where two specific objects (called [Joint]) share joint ownership of the underlying

Nathan West 17 Feb 1, 2023
Reference application for connecting to the TAPLE DLT network.

⚠️ TAPLE is in early development and should not be used in production ⚠️ TAPLE Client TAPLE (pronounced T+ ?? ['tapəl]) stands for Tracking (Autonomou

Open Canarias 8 Feb 15, 2023
In addition to encryption library, pure RUST implementation of SSH-2.0 client protocol

In addition to encryption library, pure RUST implementation of SSH-2.0 client protocol

陈年旧事。 73 Jan 1, 2023
Next-generation implementation of Ethereum protocol ("client") written in Rust, based on Erigon architecture.

?? Martinez ?? Next-generation implementation of Ethereum protocol ("client") written in Rust, based on Erigon architecture. Why run Martinez? Look at

Arthur·Thomas 23 Jul 3, 2022
A crate for working with Ethereum beacon chain light client protocol messages. `no_std` friendly!

eth-lightclient-rs A crate for working with Ethereum beacon chain light client protocol messages. no_std friendly! !! For hacking and experimentation

Willem Olding 12 Jan 6, 2023