Reference client for NEAR Protocol

Last update: May 24, 2022




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.

GitHub

https://github.com/near/nearcore
Comments
  • 1. 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.

    Reviewed by Kouprin at 2019-12-19 13:17
  • 2. 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.
    Reviewed by bowenwang1996 at 2020-03-20 22:32
  • 3. 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.

    Reviewed by bowenwang1996 at 2019-09-16 02:32
  • 4. 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
    Reviewed by nearmax at 2019-12-10 04:39
  • 5. 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.

    Reviewed by vgrichina at 2020-07-10 21:09
  • 6. 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.

    Reviewed by matklad at 2021-03-11 12:07
  • 7. 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
    Reviewed by artob at 2021-02-12 11:12
  • 8. 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.

    Reviewed by artob at 2021-01-13 21:42
  • 9. 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.

    Reviewed by bowenwang1996 at 2020-03-24 17:55
  • 10. 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

    Reviewed by austinabell at 2021-06-08 18:23
  • 11. Add precompiled contracts for alt_bn128 curve

    Reviewed by snjax at 2020-06-12 07:14
  • 12. fix: platform-compatibility bug in key_file

    Permissions::from_mode is portable across unixes and requires u32. But libc::mode_t isn't guaranteed to be u32, so the current code might break on non-Linux Unix.

    Instead of relying on platform-specific libc, just specify mode directly using traditional octals.

    Reviewed by matklad at 2022-05-25 15:57
  • 13. Compress check_triggers

    There's a lot of copy-paste in this function:

    https://github.com/near/nearcore/blob/a5203d757476510a7d0be0c37ee0d2939468a6d2/chain/client/src/client_actor.rs#L1173-L1258

    It feels this can be simplified a lot, probably down to something like

         fn check_triggers(&mut self, ctx: &mut Context<ClientActor>) -> Duration {
            self.doomslug_trigger.check(Self::try_doomslug_timer)?;
            self.block_production_trigger.check(Self::try_handle_block_production)?;
            self.log_summary_trigger.check(Self::log_summary)?;
    
            [self.doomslug_trigger.next_check(), self.block_production_trigger.next_check(), self.log_summary_trigger()].into_iter().min().unwrap()
         }
    

    where log_summary_trigger and such are a struct Trigger which tracks the state and the label.

    Reviewed by matklad at 2022-05-25 11:33
  • 14. Already existing implicit account still charges for create_account_cost transfer actions

    Currently, we charge an additional fee for implicit accounts when we are doing Action::Transfer to make sure that the account is created and we don't create it twice. The cost can be seen here: https://github.com/near/nearcore/blob/c1ab812cea6164ce9d5b6ded312866f0d7195081/core/primitives-core/src/runtime/fees.rs#L277-L290 And transfer action can be seen here: https://github.com/near/nearcore/blob/fa28aa89bcd331fa7039ccbc24e918dda3b17609/runtime/runtime/src/lib.rs#L373 Suggestion is that we refund these costs after making sure that the account exists.

    Reviewed by firatNEAR at 2022-05-25 11:18
  • 15. Configure opentelemetry data export as a command-line flag

    This change allows independent configuration of text logs and of data exported by opentelemetry. This is needed because opentelemetry data isn't useful without debug logs enabled, but enabling textual debug logs isn't always possible.

    Verified that disabled opentelemetry has no performance impact.

    Reviewed by nikurt at 2022-05-24 14:14
  • 16. feat: Lower min gas price on nightly

    This is an implementation of the community proposal to lower the gas floor price from 0.0001 N/TGas to 0.00001 N/TGas. This should be tested via a feature flag on nightly first.

    Test plan: cargo test --features nightly

    This is my first contribution to nearcore, please let me know if I'm missing something big here :)

    Reviewed by 0xbosnic at 2022-05-24 05:40
A PoC backbone for NFT Marketplaces on NEAR Protocol
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

May 6, 2022
A tutorial for an NFT Market Place Built with Near Protocol and React.js
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:

May 3, 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

May 23, 2022
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.

May 24, 2022
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.

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)

May 20, 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+)

May 13, 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

May 12, 2022
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

Apr 13, 2022
Next-generation implementation of Ethereum protocol ("client") written in Rust, based on Erigon architecture.
Next-generation implementation of Ethereum protocol (

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

Mar 13, 2022
Minimal implementation of the Mimblewimble protocol.

Grin Grin is an in-progress implementation of the Mimblewimble protocol. Many characteristics are still undefined but the following constitutes a firs

May 18, 2022
Official Rust implementation of the Nimiq protocol
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

Mar 2, 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

May 5, 2022
An implementation of the OPAQUE password-authenticated key exchange protocol

The OPAQUE key exchange protocol OPAQUE is an asymmetric password-authenticated key exchange protocol. It allows a client to authenticate to a server

May 13, 2022
Kerberos protocol attacker

Cerbero Kerberos protocol attacker. Tool to perform several tasks related with Kerberos protocol in an Active Directory pentest. Installation From cra

May 20, 2022
A prototype implementation of the Host Identity Protocol v2 for bare-metal systems, written in pure-rust.
A prototype implementation of the Host Identity Protocol v2 for bare-metal systems, written in pure-rust.

Host Identity Protocol for bare-metal systems, using Rust I've been evaluating TLS replacements in constrained environments for a while now. Embedded

May 26, 2022
A substrate pallet that enables Manta's decentialized anynonymous payment (DAP) protocol.
A substrate pallet that enables Manta's decentialized anynonymous payment (DAP) protocol.

This is a pallet that enables decentialized anynonymous payment (DAP) protocol. The best way to use this repo is to invoke it with a manta-runtime, available from either manta-node or cumulus.

Apr 13, 2022
Basilisk node - cross-chain liquidity protocol built on Substrate

Basilisk node Local Development Follow these steps to prepare a local Substrate development environment ??️ Simple Setup Install all the required depe

Apr 24, 2022
Metaplex is a protocol built on top of Solana that allows: Creating/Minting non-fungible tokens;
Metaplex is a protocol built on top of Solana that allows: Creating/Minting non-fungible tokens;

Metaplex is a protocol built on top of Solana that allows: Creating/Minting non-fungible tokens; Starting a variety of auctions for primary/secondary

May 24, 2022