* stake-pool: Add depositor key on init, required on deposit Some stake pools need to be private, and not allow outside depositors. Enhance the existing deposit authority in the stake pool be configurable on initialization, and then require its signature on deposit. The existing deposit authority is a program address, making deposits permissionless. This allows a pool creator to set their own deposit_authority on initialization. In a great turn of events, almost everything else works the same way! Here's the current workflow for deposit, where the user calls stake_program::authorize and stake_pool::deposit in the same transaction: * stake_program::authorize assigns staker and withdraw authority to the stake pool deposit authority * stake_pool::deposit - uses the deposit authority to assign authority on the deposited stake account to the stake pool withdraw authority - uses the withdraw authority to merge the deposited stake into the validator stake The deposit authority must "sign" the transaction in order to reassign authority to the withdraw authority. Currently, as a program address, it can just do that. With this change, if the deposit authority is set during initialization, then that deposit authority must sign the instruction. There's also a little update for ease-of-use to always do the stake_program::authorize in the same transaction as stake_pool::deposit. This way, in case someone tries to deposit into a forbidden stake pool, the whole transaction will bail and their stake will stay as theirs. * Address review feedback * Fix rebase issues |
||
---|---|---|
.github | ||
.travis | ||
associated-token-account/program | ||
binary-oracle-pair | ||
ci | ||
docs | ||
examples | ||
feature-proposal | ||
libraries/math | ||
memo | ||
record/program | ||
shared-memory | ||
stake-pool | ||
themis | ||
token | ||
token-lending | ||
token-swap | ||
utils | ||
.gitignore | ||
.mergify.yml | ||
.travis.yml | ||
Cargo.lock | ||
Cargo.toml | ||
LICENSE | ||
README.md | ||
cbindgen.sh | ||
coverage.sh | ||
patch.crates-io.sh | ||
update-solana-dependencies.sh |
README.md
Solana Program Library
The Solana Program Library (SPL) is a collection of on-chain programs targeting the Sealevel parallel runtime. These programs are tested against Solana's implementation of Sealevel, solana-runtime, and deployed to its mainnet. As others implement Sealevel, we will graciously accept patches to ensure the programs here are portable across all implementations.
Full documentation is available at https://spl.solana.com
Development
Environment Setup
- Install the latest Rust stable from https://rustup.rs/
- Install Solana v1.6.1 or later from https://docs.solana.com/cli/install-solana-cli-tools
- Install the
libudev
development package for your distribution (libudev-dev
on Debian-derived distros,libudev-devel
on Redhat-derived).
Build
The normal cargo build is available for building programs against your host machine:
$ cargo build
To build a specific program, such as SPL Token, for the Solana BPF target:
$ cd token/program
$ cargo build-bpf
Test
Unit tests contained within all projects can be run with:
$ cargo test # <-- runs host-based tests
$ cargo test-bpf # <-- runs BPF program tests
To run a specific program's tests, such as SPL Token:
$ cd token/program
$ cargo test # <-- runs host-based tests
$ cargo test-bpf # <-- runs BPF program tests
Integration testing may be performed via the per-project .js bindings. See the token program's js project for an example.
Clippy
$ cargo clippy
Coverage
$ ./coverage.sh # Please help! Coverage build currently fails on MacOS due to an XCode `grcov` mismatch...
Release Process
SPL programs are currently tagged and released manually. Each program is versioned independently of the others, with all new development occurring on master. Once a program is tested and deemed ready for release:
Bump Version
- Increment the version number in the program's Cargo.toml
- Generate a new program ID and replace in
<program>/program-id.md
and<program>/src/lib.rs
- Run
cargo build-bpf <program>
to update relevant C bindings. (Note the location of the generatedspl_<program>.so
for attaching to the Github release.) - Open a PR with these version changes and merge after passing CI.
Create Github tag
Program tags are of the form <program>-vX.Y.Z
.
Create the new tag at the version-bump commit and push to the
solana-program-library repository, eg:
$ git tag token-v1.0.0 b24bfe7
$ git push upstream --tags
Publish Github release
- Go to GitHub Releases UI
- Click "Draft new release", and enter the new tag in the "Tag version" box.
- Title the release "SPL vX.Y.Z", complete the description, and attach the
spl_<program>.so
binary - Click "Publish release"
Publish to Crates.io
Navigate to the program directory and run cargo package
to test the build. Then run cargo publish
.