Reference implementation of the Filecoin protocol, written in Go
b7fab5f937
Due to a (now consensus critical) bug in randomness selection, "beacon" randomness depends on whether the epoch in which the beacon occurred was a null block. Unfortunately, this means: 1. If a challenge lands on a non-null round but that non-null round gets re-orged to a null round, the randomness will change to the beacon in the first preceding non-null block. 2. If a challenge lands on a null round but that null round gets re-orged to a non-null round, the randomness will change to the beacon in the new non-null round. The correct solution is to change the way the beacon is selected: 1. Wait until a non-null round. 2. The block in this round will contain all beacons from the null rounds, select the beacon from the target epoch. Unfortunately, this requires a mandatory network upgrade. Instead, this patch just waits a bit before beginning to compute window post after passing the challenge round to wait-out any reorgs. |
||
|---|---|---|
| .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 | ||
| 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