1 unstable release
0.62.2 | Feb 21, 2023 |
---|
#4 in #xand
435KB
10K
SLoC
XAND Ledger
This repo contains the code defining the processing and validation logic of our chain and the transactions that can be performed on it.
It is intentionally light on dependencies, and makes an effort to be reasonably agnostic of the underlying chain implementation (IE: Substrate). The crate should never depend on substrate crates directly, with the exception of the crate required for SCALE encoding, which is technically not a part of substrate, but is used by it.
Contributing
Add to changelog
When making changes to this repo, please make updates to the CHANGELOG.
Tagging
This repo uses tags to identify release versions at a repository level consistent with the version specified in Cargo.toml.
After the release's successful completed merge to master
, make the corresponding tag and push it.
For more info on tagging, see Git docs.
Version 0.1.0: tag "0.1.0"
Note: Git tags are global across branches
Fetch tags from remote:
git fetch --tags
List all tags:
git tag -l --sort=-creatordate
Add and push a tag matching the bumped version in Cargo.toml:
git tag -a "0.8.1" -m "Some info about this release"
git push origin --tags
This pushes any un-pushed tags to remote - to push a specific tag,
git push origin <tagname>
Usage
Please check out the rust docs! You can view them like so:
cargo doc --open
Structure
The model
module contains struct definitions representing the transactions and their
various constituent parts as well as traits defining how chain data is accessed.
The logic for building and validating transactions can be found in transactions
The core crypto logic is in zkplmt
(Zero knowledge proof of linear member tuple).
Our actual business logic that defines how a transaction is processed is located in
financial_impl
-- this is likely to be broken up / changed soon.
Protected legal text
Text in the src/legal_text/official_text/
directory is protected from changes without the MR approval of at least one member of the legal team.
This is done using the Codeowners feature of Gitlab.
See permissions in the CODEOWNERS file.
Preventing unauthorized changes
To prevent this text from being accidentally edited without the legal team's approval, the following safeguard is in place:
- The folder containing the text has legal team code-owners indicated in the
CODEOWNERS
file.
Note: In order for this safeguard to work as intended, this repo's Gitlab settings must: 1) indicate that the protected branch cannot be updated without at least one code-owner's approval and, 2) have the
CODEOWNERS
setting turned on for MRs/protected branches.
Making updates to legal text
When creating an MR with changes to protected legal text, it must be done via MR to merge to the protected branch.
- Notify legal: Add legal team code-owner(s) as "Reviewers" in the MR (or @ mention them) so that they will be email-notified of the MR.
- Get legal approval: At least one of these code-owners will need to approve the MR in order for it to be merged to the protected branch.
Note: Code-owners are not automatically notified of an MR requiring their review. Gitlab is aware of the issue but has de-prioritized it.
Adding protected legal text
Add a new subdirectory to src/legal_text/official_text
and place the legal text files there.
Adding code-owners
To add code-owner reviewers:
- Add the individual's Gitlab user handle to the appropriate definition in the CODEOWNERS file.
- Ensure that they have been added to our Transparent Inc. Gitlab project with at least "Developer" privileges.
References:
Dependencies
~4MB
~86K SLoC