Reference implementation of the Filecoin protocol, written in Go
5453e70cab
chore: export vm.ShouldBurn |
||
---|---|---|
.circleci | ||
.github | ||
api | ||
build | ||
chain | ||
cli | ||
cmd | ||
conformance | ||
documentation | ||
extern | ||
gen | ||
genesis | ||
journal | ||
lib | ||
lotuspond | ||
markets | ||
metrics | ||
miner | ||
node | ||
paychmgr | ||
scripts | ||
storage | ||
system | ||
testplans | ||
tools | ||
.codecov.yml | ||
.dockerignore | ||
.gitignore | ||
.gitmodules | ||
.golangci.yml | ||
CHANGELOG.md | ||
go.mod | ||
go.sum | ||
LICENSE-APACHE | ||
LICENSE-MIT | ||
Makefile | ||
README.md | ||
SECURITY.md |
Project Lotus - 莲
Lotus is an implementation of the Filecoin Distributed Storage Network. For more details about Filecoin, check out the Filecoin Spec.
Building & Documentation
For instructions on how to build, install and setup lotus, please visit https://docs.filecoin.io/get-started/lotus.
Reporting a Vulnerability
Please send an email to security@filecoin.org. See our security policy for more details.
Related packages
These repos are independent and reusable modules, but are tightly integrated into Lotus to make up a fully featured Filecoin implementation:
- go-fil-markets which has its own kanban work tracker available here
- specs-actors which has its own kanban work tracker available here
Contribute
Lotus is a universally open project and welcomes contributions of all kinds: code, docs, and more. However, before making a contribution, we ask you to heed these recommendations:
- If the proposal entails a protocol change, please first submit a Filecoin Improvement Proposal.
- If the change is complex and requires prior discussion, open an issue or a discussion to request feedback before you start working on a pull request. This is to avoid disappointment and sunk costs, in case the change is not actually needed or accepted.
- Please refrain from submitting PRs to adapt existing code to subjective preferences. The changeset should contain functional or technical improvements/enhancements, bug fixes, new features, or some other clear material contribution. Simple stylistic changes are likely to be rejected in order to reduce code churn.
When implementing a change:
- Adhere to the standard Go formatting guidelines, e.g. Effective Go. Run
go fmt
. - Stick to the idioms and patterns used in the codebase. Familiar-looking code has a higher chance of being accepted than eerie code. Pay attention to commonly used variable and parameter names, avoidance of naked returns, error handling patterns, etc.
- Comments: follow the advice on the Commentary section of Effective Go.
- Minimize code churn. Modify only what is strictly necessary. Well-encapsulated changesets will get a quicker response from maintainers.
- Lint your code with
golangci-lint
(CI will reject your PR if unlinted). - Add tests.
- Title the PR in a meaningful way and describe the rationale and the thought process in the PR description.
- Write clean, thoughtful, and detailed commit messages. This is even more important than the PR description, because commit messages are stored inside the Git history. One good rule is: if you are happy posting the commit message as the PR description, then it's a good commit message.
License
Dual-licensed under MIT + Apache 2.0