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
  • runtime: introduce PublicKeyBuffer to avoid memory allocation

    runtime: introduce PublicKeyBuffer to avoid memory allocation

    Currently when public key is read it’s unnecessarily copied into a temporary vector. The copy is necessary because otherwise public key data would hold a shared reference on self.registers which prevents any methods which take exclusive reference to self to be called.

    However, if we decode the public key immediately after reading it, we can deal with sized objects which can be stored on stack. This is perfect except because we cannot change when errors are reported we have to postpone returning of the deserialisation errors.

    Introduce PublicKeyBuffer which facilitates that. It hides from the users the fact that deserialisation happens immediately as soon as the data is read providing an interface which looks as if deserialisation was happening separately from reading.

    An alternative would be to use a fixed-size 65-byte array and separate reading the data from deserialisation just like it’s happening now. A minor downside of that is hard-coding the 65-byte size. We’d probably want PublicKey::MAX_LEN but even then having such a constant doesn’t seem too clean of a solution to me.

    opened by mina86 0
  • runtime: introduce MemoryLike::view_memory to avoid memcpy

    runtime: introduce MemoryLike::view_memory to avoid memcpy

    Add a view_memory method to MemoryLike trait which returns a view of the guest memory. This allows caller to read data directly from guest memory instead of using read_memory to first copy it into a vector.

    To accommodate implementations which cannot support borrowing the memory, the method returns a Cow which allows such implementations to return a copy of the memory. WasmerMemory doesn’t support it because its memory is made of Cells and transmuting &[Cell<u8>] to &[u8] is probably not sound. Importantly though, Wasmer2Memory supports returning the view.

    Also introduce a simple MemSlice structure which combines guest memory pointer and slice length in a single object. This avoids confusing when function accepts two u64 arguments and caller just needs to know which is the pointer and which is the length.

    opened by mina86 0
  • refactor: fix clippy issues in near-vm-errors

    refactor: fix clippy issues in near-vm-errors

    Part of https://github.com/near/nearcore/issues/8145

    Fixed issues
    warning: you are deriving `PartialEq` and can implement `Eq`
       --> runtime/near-vm-errors/src/lib.rs:292:17
        |
    292 | #[derive(Debug, PartialEq)]
        |                 ^^^^^^^^^ help: consider deriving `Eq` as well: `PartialEq, Eq`
        |
        = note: `#[warn(clippy::derive_partial_eq_without_eq)]` on by default
        = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#derive_partial_eq_without_eq
    
    warning: this returns a `Result<_, ()>`
       --> runtime/near-vm-errors/src/lib.rs:512:5
        |
    512 |     pub fn downcast<E: Any + Eq + Send + Sync + 'static>(self) -> Result<E, ()> {
        |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        |
        = note: `#[warn(clippy::result_unit_err)]` on by default
        = help: use a custom `Error` type instead
        = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#result_unit_err
    
    warning: deref on an immutable reference
       --> runtime/near-vm-errors/src/lib.rs:548:9
        |
    548 |         &*self
        |         ^^^^^^ help: if you would like to reborrow, try removing `&*`: `self`
        |
        = note: `#[warn(clippy::borrow_deref_ref)]` on by default
        = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#borrow_deref_ref
    
    warning: `near-vm-errors` (lib test) generated 3 warnings
    
    opened by pugachAG 0
  • Pass `tracked-shards` to localnet in pytest correctly

    Pass `tracked-shards` to localnet in pytest correctly

    https://github.com/near/nearcore/pull/8187 introduces tracked-shards for localnet and makes it "all" by default. However, pytest also uses localnet option, and in most of places it assumes that tracked-shards is "none". In some test, it even overrides tracked shards in client_config_changes.

    It breaks at least one test (repro_2916.py) - we can't tell more because nayduck is broken. We need to find a way to pass this argument to pytest correctly. cc @wacban

    opened by Longarithm 0
  • Change signed delegate action format to avoid confusing it with other things that might be signed by an account key

    Change signed delegate action format to avoid confusing it with other things that might be signed by an account key

    Signing a meta transaction using an account key can be problematic, as the signed message could be used in a different context where account keys are also used for signing. For now, only transactions are signed with the account key but that is likely to change in the future.

    T-integrations 
    opened by jakmeier 1
Releases(1.30.0)
  • 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)
  • 1.26.0-rc.1(Apr 20, 2022)

    Features

    • NEP205: Configurable start of protocol upgrade voting #6309. Protocol upgrade voting for protocol version 53 will begin at 2022-04-25 16:00:00 UTC
    • 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
    • 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

    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.
    • 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_TESTNET
    RELEASE_VERSION: 1.26.0-rc.1
    PROTOCOL_UPGRADE: TRUE
    DATABASE_UPGRADE: FALSE
    SECURITY_UPGRADE: TRUE
    
    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
Official Rust implementation of the Nimiq protocol

Nimiq Core implementation in Rust (core-rs) Rust implementation of the Nimiq Blockchain Core Nimiq is a frictionless payment protocol for the web. Thi

Nimiq 72 Sep 23, 2022
Rust implementation of Zcash protocol

The Parity Zcash client. Gitter Blog: Parity teams up with Zcash Foundation for Parity Zcash client Installing from source Installing the snap Running

Parity Technologies 183 Sep 8, 2022
Implementation of the Kademlia DHT protocol in Rust

kademlia-dht Simple implementation of the Kademlia DHT protocol in Rust with state dumping features for educational purposes (not production-ready). T

Leonardo Folgoni 18 Sep 24, 2022
Coinbase pro client for Rust

Coinbase pro client for Rust Supports SYNC/ASYNC/Websocket-feed data support Features private and public API sync and async support websocket-feed sup

null 126 Dec 30, 2022
Rust Ethereum 2.0 Client

Lighthouse: Ethereum 2.0 An open-source Ethereum 2.0 client, written in Rust and maintained by Sigma Prime. Documentation Overview Lighthouse is: Read

Sigma Prime 2.1k Jan 1, 2023
The Parity Bitcoin client

The Parity Bitcoin client. Gitter Installing from source Installing the snap Running tests Going online Importing bitcoind database Command line inter

Parity Technologies 714 Dec 21, 2022
The fast, light, and robust client for the Ethereum mainnet.

OpenEthereum Fast and feature-rich multi-network Ethereum client. » Download the latest release « Table of Contents Description Technical Overview Bui

OpenEthereum 1.6k Dec 28, 2022
rust client libraries to deal with the current cardano mainnet (byron / cardano-sl)

Rust implementation of Cardano primitives, helpers, and related applications Cardano Rust is a modular toolbox of Cardano’s cryptographic primitives,

Input Output 275 Oct 9, 2022
Reference client for NEAR Protocol

Reference implementation of NEAR Protocol About NEAR NEAR's purpose is to enable community-driven innovation to benefit people around the world. To ac

NEAR 2k Jan 3, 2023
Reference client for NEAR Protocol

Reference implementation of NEAR Protocol About NEAR NEAR's purpose is to enable community-driven innovation to benefit people around the world. To ac

NEAR 2k Dec 29, 2022
Reference client for NEAR Protocol

Reference implementation of NEAR Protocol About NEAR NEAR's purpose is to enable community-driven innovation to benefit people around the world. To ac

NEAR 2k Jan 4, 2023
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
This contract implements simple vote for the best coffe in indonesia using near protocol.

vote-coffe-near Description This contract implements simple vote for the best coffe in indonesia using near protocol. Contract in contract/src/lib.rs

RickhySis25 1 Nov 15, 2021
This is a smart contract running on NEAR Protocol. It could be used to run a token sale.

Token Sale This is a smart contract running on NEAR Protocol. It could be used to run a token sale. Sale rules There are 2 periods: Sale and Grace. In

Harry Nguyen 0 Dec 5, 2021
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