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

Bumps ini from 1.3.5 to 1.3.8.

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.

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

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

Temp change to kube.py for testing- will revert back

Motivation

Migrate forge to new cloud- using this pr to test the backend. Currently set up to run in parallel to the jobs done on Novi servers.

Upgraded the following: regex, zeroize, nix, thread_local, tokio

Compiled with no issues (on linux vm- can't compile on M1 mac until rocksdb is updated per https://github.com/diem/diem/pull/10295) and fixes their respective RUSTSEC vulnerabilities thrown by cargo audit

Left out time crate because it is only used as a sub-dependency of chrono, which is already updated to latest version and seems to have no plans to upgrade the crate. However, per https://github.com/chronotope/chrono/pull/578#issuecomment-1075907329, it seems chrono is unaffected by the vulnerability.

Also left out scratchpad because it is a custom diem crate which cargo audit confuses with a different crate with the same name

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.

Bumps ssri from 6.0.1 to 6.0.2.

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.

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.

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

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.

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.

Motivation

Many types in the Move codebase are defined to operate upon a generic "source location" type, in order to operate on both OwnedLoc (a source location type that stores its file field as a String), and on Loc (a source location type that used to store its file field as a &str reference, and now stores it as a globally interned string Symbol).

Remove OwnedLoc, since it no longer provides functionality that differs from Loc. This allows the generic source map types to be transformed to simpler, concrete types.

In addition, helper functions implemented to map between types that use OwnedLoc and those that use Loc can also be deleted.

Test Plan

• CI/CD tests are covered

Add check to warn on unexpected behavior of non-phantom types.

• Non-phantom types parameters should be used at least once.
• Non-phantom types parameters shouldn't be used in phantom position.

Motivation

Any parameter not satisfying the above restrictions should be declared as phantom.

Test Plan

Checking the code in diem-framework and stdlib shouldn't raise any warning.

Motivation

To make way for state sync v2 development and deployment, this PR offers two commits:

1. Rename the current state-sync crate to state-sync-v1 and move it into its own directory: state-sync/state-sync-v1).
2. Create a new skeleton crate state-sync-v2 that lives in state-sync/state-sync-v2.

Other than modifications to the README files (e.g., adding a disclaimer), nothing changes logically.

Have you read the Contributing Guidelines on pull requests?

Yes.

Test Plan

None required -- existing tests will catch issues.

Related PRs

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

Motivation

There are two changes in the first commit:

1/ Current usage_analysis only records all (directly + transitively) used memory in a function, this commit additionally record the directly accessed memory into a separate set, in a similar spirit to how the modified / directly-modified sets are currently differentiated. This information will be useful later when we calculate how to defer invariants from a callee to its caller (by enlarging the set that represents callers' directly-accessed memory).

2/ Several bytecode that has a memory accessing/modifying semantic are not included in the analysis, namely OpaqueCallBegin/End and WriteBack to a GlobalRoot.

Not covering WriteBack is hardly an issue because we would not expect a WriteBack to a GlobalRoot without a BorrowGlobal somewhere, and the memory usage/modification info should already be captured in the BorrowGlobal instruction. Nevertheless, it does not hurt to re-add the same info again. Memory accesses in opaque functions are not captured previously which seems a bit weird. At least from the global invariant point of view, if a global invariant is applicable in an opaque function and that opaque function happens to defer the invariants to its caller, we should at least know which memories are accessed by the callee function in order to determine which invariants are applicable. The second commit adds memories mentioned in the assume and assert expressions to their respective sets as well.

The second commit also refactored the data structure behind the scene. The high-level structure include memory

• accessed
• modified
• assumed
• asserted

in a function. And each field has a direct / transitive field to annotate whether the memory is directly related to the function or transitively related.

Have you read the Contributing Guidelines on pull requests? Yes

Test Plan

CI/CD tests are covered

Motivation

Send NetworkIdentity events to a central event stream

Test Plan

• cargo test --package diem-framework --tests

• cargo test --package move-lang-functional-tests --tests

Bumps actions/cache from 2.1.6 to 3.2.1.

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.