Diem’s mission is to build a trusted and innovative financial network that empowers people and businesses around the world.

Related tags

blockchain
Overview

Note to readers: On December 1, 2020, the Libra Association was renamed to Diem Association. The project repos are in the process of being migrated. All projects will remain available for use here until the migration to a new GitHub Organization is complete.

Diem Logo

Diem Rust Crate Documentation (main) License grcov

Diem Core implements a decentralized, programmable database which provides a financial infrastructure that can empower billions of people.

Note to Developers

  • Diem Core is a prototype.
  • The APIs are constantly evolving and designed to demonstrate types of functionality. Expect substantial changes before the release.
  • We’ve launched a testnet that is a live demonstration of an early prototype of the Diem Blockchain software.

Contributing

To begin contributing, sign the CLA. You can learn more about contributing to the Diem project by reading our Contribution Guide and by viewing our Code of Conduct.

Getting Started

Learn About Diem

Try Diem Core

Technical Papers

Blog

Community

License

Diem Core is licensed as Apache 2.0.

Issues
  • Bump ini from 1.3.5 to 1.3.8 in /developers.libra.org/website

    Bump ini from 1.3.5 to 1.3.8 in /developers.libra.org/website

    Bumps ini from 1.3.5 to 1.3.8.

    Commits
    • a2c5da8 1.3.8
    • af5c6bb Do not use Object.create(null)
    • 8b648a1 don't test where our devdeps don't even work
    • c74c8af 1.3.7
    • 024b8b5 update deps, add linting
    • 032fbaf Use Object.create(null) to avoid default object property hazards
    • 2da9039 1.3.6
    • cfea636 better git push script, before publish instead of after
    • 56d2805 do not allow invalid hazardous string as section name
    • See full diff in compare view
    Maintainer changes

    This version was pushed to npm by isaacs, a new releaser for ini since your current version.


    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the Security Alerts page.
    cla-signed dependencies javascript 
    opened by dependabot[bot] 126
  • CRITICAL security vuln fixed

    CRITICAL security vuln fixed

    I've discovered an alarming vulnerability, but fortunately there's a really simple fix so I've sent a pull request to address it.

    In the current implementation, trusted 'validator nodes' are core to the security model. This means that hard power is centralised around these few entities. The protocol itself depends on these entities to (as the name suggests) validate the protocol. This means the protocol is whatever they decide it is. These entities can change the rules whenever they want. This means they can freeze your coins, take your coins, issue new coins, or really whatever they want - the sky is the limit.

    This problem can easily be solved by using a permissionless system where the hard power is decentralised across a very large number of participants in such a way that making changes to the protocol is impossible without near unanimous agreement by everyone involved.

    This pull request contains a patch to the existing codebase to resolve this issue.

    Edit: related issue: https://github.com/binance-chain/node-binary/issues/36

    opened by gazhayes 119
  • [cluster-test] Add experiment to automatically generate CPU FlameGraph

    [cluster-test] Add experiment to automatically generate CPU FlameGraph

    Summary

    • We generate load on the cluster and pick one validator and run perf against it to generate the FlameGraph
    • This FlameGraph is then copied locally to cluster-test.
    • The next step would be to upload this local file to S3

    Test Plan

    Tested on my cluster

    cluster_test cla-unsigned 
    opened by ankushagarwal 90
  • WIP

    WIP

    Motivation

    (Write your motivation for proposed changes here.)

    Have you read the Contributing Guidelines on pull requests?

    (Write your answer here.)

    Test Plan

    (Share your test plan here. If you changed code, please provide us with clear instructions for verifying that your changes work.)

    Related PRs

    (If this PR adds or changes functionality, please take some time to update the docs at https://github.com/diem/diem/tree/main/developers.diem.com, and link to your PR here.)

    If targeting a release branch, please fill the below out as well

    • Justification and breaking nature (who does it affect? validators, full nodes, tooling, operators, AOS, etc.)
    • Comprehensive test results that demonstrate the fix working and not breaking existing workflows.
    • Why we must have it for V1 launch.
    • What workarounds and alternative we have if we do not push the PR.
    cla-signed 
    opened by zihaoccc 72
  • build(deps): bump ssri from 6.0.1 to 6.0.2 in /developers.diem.com

    build(deps): bump ssri from 6.0.1 to 6.0.2 in /developers.diem.com

    Bumps ssri from 6.0.1 to 6.0.2.

    Changelog

    Sourced from ssri's changelog.

    6.0.2 (2021-04-07)

    Bug Fixes

    • backport regex change from 8.0.1 (b30dfdb), closes #19

    Commits
    Maintainer changes

    This version was pushed to npm by nlf, a new releaser for ssri since your current version.


    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the Security Alerts page.
    cla-signed dependencies javascript 
    opened by dependabot[bot] 70
  • [Forge] Add forge LBT in ci-test

    [Forge] Add forge LBT in ci-test

    Motivation

    (Write your motivation for proposed changes here.)

    Have you read the Contributing Guidelines on pull requests?

    (Write your answer here.)

    Test Plan

    (Share your test plan here. If you changed code, please provide us with clear instructions for verifying that your changes work.)

    Related PRs

    (If this PR adds or changes functionality, please take some time to update or suggest changes to the docs at https://developers.diem.com, and link to your PR here.)

    If targeting a release branch, please fill the below out as well

    • Justification and breaking nature (who does it affect? validators, full nodes, tooling, operators, AOS, etc.)
    • Comprehensive test results that demonstrate the fix working and not breaking existing workflows.
    • Why we must have it for V1 launch.
    • What workarounds and alternative we have if we do not push the PR.
    cla-signed 
    opened by zihaoccc 67
  • [language] Binary format changes

    [language] Binary format changes

    Here are the changes to the binary format. We have few things missing around Scripts vs Modules and around functions (native function flags and function signatures). However this works and it's the bulk of the changes. There is more to clean up and correct but this needs to go in asap and we can all iterate over

    breaking cla-signed 
    opened by dariorussi 66
  • [ci] fix script typos and debug image building

    [ci] fix script typos and debug image building

    Motivation

    Docker publish tests.

    Have you read the [Contributing Guidelines on pull requests]

    y

    Test Plan

    CI

    Related PRs

    None

    cla-signed 
    opened by rexhoffman 65
  • [bytecode-verifier] Implement phantom params in bytecode

    [bytecode-verifier] Implement phantom params in bytecode

    This PR implements phantom type parameters in the bytecode. A type argument instantiating a phantom type parameter is not considered when deriving the abilities for the struct instantiation. For this to be sound, in a struct declaration a phantom type parameter can only appear in phantom position (or not appear at all), i.e., as an argument to a phantom type parameter.

    Motivation

    Avoid spurious ability annotations for marker types like XUS.

    Have you read the Contributing Guidelines on pull requests?

    Yes

    Test Plan

    Tests will be coming in the next PR.

    cla-signed bors-high-priority 
    opened by nilehmann 56
  • Rename all the things from libra to diem

    Rename all the things from libra to diem

    Renames all occurrences of "libra" with "diem" (with casing preserved). Renames all occurrences of "lbr" with "XDX" (with casing preserved). Renames all occurences of "coin1" to "XUS" (with casing preserved).

    This PR is meant to be the bulk renaming, there will need to be smaller cleanup passes that we will want to do afterwards, but that can be done by folks in each area.

    breaking tcb-deps-changed deps-changed bors-high-priority 
    opened by tzakian 55
  • [forge] Always scale down cluster first before each test run

    [forge] Always scale down cluster first before each test run

    Sometimes, post test cleanup may accidentally get into faulty status. We should always scale down cluster first before test as well to prevent this case not affect subsequent test run

    Motivation

    (Write your motivation for proposed changes here.)

    Have you read the Contributing Guidelines on pull requests?

    (Write your answer here.)

    Test Plan

    (Share your test plan here. If you changed code, please provide us with clear instructions for verifying that your changes work.)

    Related PRs

    (If this PR adds or changes functionality, please take some time to update the docs at https://github.com/diem/diem/tree/main/developers.diem.com, and link to your PR here.)

    If targeting a release branch, please fill the below out as well

    • Justification and breaking nature (who does it affect? validators, full nodes, tooling, operators, AOS, etc.)
    • Comprehensive test results that demonstrate the fix working and not breaking existing workflows.
    • Why we must have it for V1 launch.
    • What workarounds and alternative we have if we do not push the PR.
    cla-signed 
    opened by zihaoccc 1
  • [api] add the api integration-tests

    [api] add the api integration-tests

    Add one simple api integration tests to ensure diem-node integration works as expected.

    see #9193 for more context of new api service.

    Related PRs

    #9144

    cla-signed 
    opened by xli 0
  • [move-prover] Do not generate or use inline attr for uninterpreted functions

    [move-prover] Do not generate or use inline attr for uninterpreted functions

    Both the code generator attached a {:inline} attribute to uninterpreted user spec functions, as well as the prelude declared is_txn_signer like this.

    Closes #8995.

    Motivation

    Bug fix

    Have you read the Contributing Guidelines on pull requests?

    Yes

    Test Plan

    Manual

    Related PRs

    NA

    cla-signed 
    opened by wrwg 1
  • [decoupled-execution] process_sync_req now tries to advance a buffer item to aggregated

    [decoupled-execution] process_sync_req now tries to advance a buffer item to aggregated

    process_sync_request now tries to advance a buffer item to aggregated

    Pop a prefix of buffer items if found an aggregated item.

    Motivation

    (Write your motivation for proposed changes here.)

    Have you read the Contributing Guidelines on pull requests?

    (Write your answer here.)

    Test Plan

    (Share your test plan here. If you changed code, please provide us with clear instructions for verifying that your changes work.)

    Related PRs

    (If this PR adds or changes functionality, please take some time to update the docs at https://github.com/diem/diem/tree/main/developers.diem.com, and link to your PR here.)

    If targeting a release branch, please fill the below out as well

    • Justification and breaking nature (who does it affect? validators, full nodes, tooling, operators, AOS, etc.)
    • Comprehensive test results that demonstrate the fix working and not breaking existing workflows.
    • Why we must have it for V1 launch.
    • What workarounds and alternative we have if we do not push the PR.
    cla-signed 
    opened by yuxiamit 0
  • [diemdb] add API get_transaction_by_hash

    [diemdb] add API get_transaction_by_hash

    Motivation

    Store the hash->version to db and add the API to get the transaction by hash.

    Have you read the Contributing Guidelines on pull requests?

    Y

    Test Plan

    current coverage.

    storage cla-signed 
    opened by lightmark 0
  • [diem-framework] Add force shift event to CRSNs, add gate

    [diem-framework] Add force shift event to CRSNs, add gate

    This PR updates CRSNs to:

    • Be able to be turned on after the new Diem Framework code is released
    • To emit a ForceShiftEvent whenever a force shift event occurs

    It also adds tests to make sure that the gating is respected in the Framework, and that ForceShiftEvents are emitted when force shifting.

    cla-signed 
    opened by tzakian 0
  • [network] Make NetworkId copyable

    [network] Make NetworkId copyable

    Motivation

    I made a mistake when I first created NetworkId, making it have to be cloned everywhere because of the contained string. This made it more unwieldy and a bunch of extra work around using the NetworkId.

    Now, we can copy and make everything much easier, no longer copying around the string "vfn". Additionally, cleans up some code and we will eventually be able to get rid of the Arc<NetworkContext> to just NetworkContext. But, to lower the churn on this PR, I've not done that yet.

    Migration Plan

    1. Deploy all validators and VFNs with this version (serializing to old format).
    2. Change code to output serialization to new format
    3. Remove old format compatibility (or even move to using the Invalid slot instead of the current Vfn slot for readability purposes

    Have you read the Contributing Guidelines on pull requests?

    Yes

    Test Plan

    Take a look at my backwards compatible tests for serialization. They cause some pain around having an unused value in the enum, but everything works outside of that!

    Related PRs

    Related to https://github.com/diem/diem/pull/9191 and thinking about how we can standardize identifiers across networks. This PR definitely is blocked on that one (due to the ton of merge conflicts that are going to happen

    network cla-signed 
    opened by gregnazario 2
  • [forge] change health check order for k8s nodes

    [forge] change health check order for k8s nodes

    Motivation

    (Write your motivation for proposed changes here.)

    Have you read the Contributing Guidelines on pull requests?

    (Write your answer here.)

    Test Plan

    (Share your test plan here. If you changed code, please provide us with clear instructions for verifying that your changes work.)

    Related PRs

    (If this PR adds or changes functionality, please take some time to update the docs at https://github.com/diem/diem/tree/main/developers.diem.com, and link to your PR here.)

    If targeting a release branch, please fill the below out as well

    • Justification and breaking nature (who does it affect? validators, full nodes, tooling, operators, AOS, etc.)
    • Comprehensive test results that demonstrate the fix working and not breaking existing workflows.
    • Why we must have it for V1 launch.
    • What workarounds and alternative we have if we do not push the PR.
    cla-signed 
    opened by zihaoccc 8
  • [WIP]Forge tx emitter

    [WIP]Forge tx emitter

    Motivation

    (Write your motivation for proposed changes here.)

    Have you read the Contributing Guidelines on pull requests?

    (Write your answer here.)

    Test Plan

    (Share your test plan here. If you changed code, please provide us with clear instructions for verifying that your changes work.)

    Related PRs

    (If this PR adds or changes functionality, please take some time to update the docs at https://github.com/diem/diem/tree/main/developers.diem.com, and link to your PR here.)

    If targeting a release branch, please fill the below out as well

    • Justification and breaking nature (who does it affect? validators, full nodes, tooling, operators, AOS, etc.)
    • Comprehensive test results that demonstrate the fix working and not breaking existing workflows.
    • Why we must have it for V1 launch.
    • What workarounds and alternative we have if we do not push the PR.
    cla-signed 
    opened by zihaoccc 0
  • [State Sync] Add a new Storage Service implementation (server-side)

    [State Sync] Add a new Storage Service implementation (server-side)

    Motivation

    This PR adds a new server-side implementation for the Storage Service. The Storage Service is an inter-node service allowing Diem nodes to request storage data (e.g., transactions and proofs) directly from other nodes over the Diem network. This PR sets up the framework (template) for this service by implementing the plumbing between request/response processing from the server-side, as well as outlines the required interface between the server and local Diem DB.

    To achieve this, the PR offers 2 commits:

    1. Add the new server implementation (as a library to later be exposed over the network)
    2. Add several (simple) tests for the server implementation. These will need to be improved and expanded in the future.

    Notes:

    • The implementation offered here is by no means complete (and you'll notice many TODOs). Instead, this PR is meant to set up the framework so that we can start building on the server-side implementation and make the Storage Service a living thing 😄

    Have you read the Contributing Guidelines on pull requests?

    Yes.

    Test Plan

    A set of simple unit tests have been added for this functionality.

    Related PRs

    None, but this PR relates to: https://github.com/diem/diem/issues/8906

    cla-signed 
    opened by JoshLind 0
A Rust library for generating cryptocurrency wallets

Table of Contents 1. Overview 2. Build Guide 2.1 Install Rust 2.2a Build from Homebrew 2.2b Build from Crates.io 2.2c Build from Source Code 3. Usage

Aleo 399 Sep 9, 2021
Nova: Recursive SNARKs without trusted setup

Nova: Recursive SNARKs without trusted setup Nova is a high-speed recursive SNARK (a SNARK is type cryptographic proof system that enables a prover to

Microsoft 37 Sep 4, 2021
Polkadot Node Implementation

Polkadot Implementation of a https://polkadot.network node in Rust based on the Substrate framework. NOTE: In 2018, we split our implementation of "Po

Parity Technologies 4.2k Sep 20, 2021
The Phala Network Blockchain, pRuntime and the bridge.

Phala Blockchain Phala Network is a TEE-Blockchain hybrid architecture implementing Confidential Contract. This repo includes: node/: the main blockch

Phala Network 198 Sep 18, 2021
Joystream Monorepo

Joystream This is the main code repository for all Joystream software. In this mono-repo you will find all the software required to run a Joystream ne

Joystream 92 Sep 8, 2021
Rust port of the Terry Davis' (RIP) "god says" program

RIP Terry A. Davis 1969-2018 god says Rust port of the programmer Terry Davis' "god says" (AKA GodSpeaks) program. Terrence Andrew Davis (December 15,

Orhun Parmaksız 31 Sep 7, 2021
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.1k Sep 19, 2021
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 682 Sep 6, 2021
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 1k Sep 14, 2021
The Nervos CKB is a public permissionless blockchain, and the layer 1 of Nervos network.

Nervos CKB - The Common Knowledge Base master develop About CKB CKB is the layer 1 of Nervos Network, a public/permissionless blockchain. CKB uses Pro

Nervos Network 871 Sep 11, 2021
A high performance blockchain kernel for enterprise users.

English | 简体中文 What is CITA CITA is a fast and scalable blockchain kernel for enterprises. CITA supports both native contract and EVM contract, by whi

CITAHub 1.2k Sep 10, 2021
rage is a simple, modern, and secure file encryption tool, using the age format

A simple, secure and modern encryption tool (and Rust library) with small explicit keys, no config options, and UNIX-style composability.

null 1.1k Sep 19, 2021
The new, performant, and simplified version of Holochain on Rust (sometimes called Holochain RSM for Refactored State Model)

Holochain License: This repository contains the core Holochain libraries and binaries. This is the most recent and well maintained version of Holochai

Holochain 437 Sep 14, 2021
The CLI to control StewardX

StewardX CLI Logo converted to ASCII via https://asciiart.club/ The CLI to control StewardX This is the official CLI to control StewardX. Made with #c

Gökay Okyay 5 May 25, 2021
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 158 Sep 11, 2021
Zcash - Internet Money

Zcash 4.4.0 What is Zcash? Zcash is an implementation of the "Zerocash" protocol. Based on Bitcoin's code, Zcash intends to offer a far higher standar

Zcash 4.5k Sep 10, 2021
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 1.3k Sep 14, 2021
Cross-chain hub for Crypto Asset on Polkadot

ChainX ChainX is a community-driven project built on the next-generation blockchain framework substrate, the largest Layer-2 network of Bitcoin using

ChainX 214 Sep 4, 2021
DEPRECATED. The Holochain framework implemented in rust with a redux style internal state-model.

Holochain-rust Travis: Circle CI: Codecov: License: This code is loosely based on the previous Golang prototype. Code Status: This Rust version is alp

Holochain 1k Sep 6, 2021