|
2 gadi atpakaļ | |
---|---|---|
.github | 2 gadi atpakaļ | |
basics | 2 gadi atpakaļ | |
compression | 2 gadi atpakaļ | |
oracles | 2 gadi atpakaļ | |
tokens | 2 gadi atpakaļ | |
tools | 2 gadi atpakaļ | |
.gitignore | 2 gadi atpakaļ | |
Cargo.lock | 2 gadi atpakaļ | |
Cargo.toml | 2 gadi atpakaļ | |
README.md | 2 gadi atpakaļ |
New: Python examples using Seahorse and Anchor Py!
:file_folder: Each example contains two folders:
native
- Written using Solana's native Rust crates and vanilla Rust.anchor
- Written using Anchor's anchor_lang
Rust crate and the associated Anchor framework to build & deploy.seahorse
- Written using the Python framework Seahorse, which converts your Python code to Anchor Rust.:wrench: How to build & run:
yarn install
.native
- Use cicd.sh
to build & deploy the program. Run yarn run test
to test it.anchor
- Use anchor build && anchor deploy
to build & deploy the program. Run anchor run test
to test it.seahorse
- Use seahorse build && anchor deploy
to build & deploy the program. Run anchor run test
to test it.seahorse
folderMost system-level operations on Solana involve already-existing Solana programs.
For example, to create a system account you use the system program and to create a token mint you use the token program.
So, you'll notice that these operations are in fact conducting what's called a cross-program invocation - which is a fancy way of saying it calls other Solana programs to do business. You can see this in action whenever you see invoke
or invoke_signed
in the native
examples, or CpiContext
in the anchor
examples.
Deciding when to use cross-program invocation instead of invoking the programs directly from the client is completely up to you as the builder. It depends on how your application is designed.
pdas
folder to see why.