Reference implementation of the Filecoin protocol, written in Go
308d1e9b7c
- A nil MiningBaseInfo is *NOT* unexpected: it happens when one is in penalty https://github.com/filecoin-project/lotus/blob/v1.9.0/chain/stmgr/utils.go#L500-L502 - Remove the log from IsRoundWinner(): all we care about is the randbase epoch |
||
|---|---|---|
| .circleci | ||
| .github | ||
| api | ||
| blockstore | ||
| build | ||
| chain | ||
| cli | ||
| cmd | ||
| conformance | ||
| documentation | ||
| extern | ||
| gateway | ||
| gen | ||
| genesis | ||
| journal | ||
| lib | ||
| lotuspond | ||
| markets | ||
| metrics | ||
| miner | ||
| node | ||
| paychmgr | ||
| scripts | ||
| snap | ||
| storage | ||
| system | ||
| testplans | ||
| tools | ||
| .codecov.yml | ||
| .dockerignore | ||
| .gitignore | ||
| .gitmodules | ||
| .golangci.yml | ||
| CHANGELOG.md | ||
| Dockerfile.lotus | ||
| 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