LFT2
LFT2 is a new consensus algorithm inspired by PBFT. It improves TPS with reducing a pair of votes compared to PBFT when nodes make a consensus. A concept, 'Candidate' has been introduced for keeping safety.
This is implemented as a library. So not only blockchain but also any application which requires a byzantine fault tolerance consensus algorithm can integrate it.
This contains an example application for easy understanding. You can run it without integration. Also it composes multiple nodes in this single app. You can simulate byzantine node actions and observe how it tolerates the actions.
White paper [English] [Korean].
Example Application
You can run example app using this command.
$ lft
This command runs 4 nodes. They make data as results of consensus. If you want to run it with 10 nodes then run this command below.
$ lft -n 10
You can see a lot of event logs.
16:18:34,085 0xd32b RoundEndEvent(is_success=True,epoch_num=1,round_num=1,candidate_id=0xd4ad,commit_id=0x6765)
Event log consists of time, node id and event. This log means round 1 ends successfully with deciding a new candidate. Each round makes a consensus to determine one candidate. A candidate is committed after when next new candidate connected to the candidate is decided. In this case 0xd4ad is connected to 0x6765. 0x6765 has already been decided in previous round.
Replay
$ lft record
It records event logs for replaying. The log path is ./data. It contains all nodes' events.
$ lft replay -t 1abde1d6c2eb942df4686116d64f889d
The argument 1abde1d6c2eb942df4686116d64f889d is one of nodes' id located in log path after running with recording command.
Integration
Some components are provided for integration. Applications which want to use LFT have to customize abstract classes.
Data(Block), DataFactory(BlockFactory), Vote, VoteFactory, Epoch
The applications have to post the event.
RoundStart
The applications must listen the events.
RoundEnd, BroadcastData, BroadcastVote, ReceiveData, ReceiveVote
Note that LFT2 is not responsible for node communication, storing blocks and executing transactions. So the applications must implement them.
Metadata
Release files for LFT 0.1.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| LFT-0.1.1-py3-none-any.whl | Python 3 | none | any | Details |
Release files / LFT-0.1.1-py3-none-any.whl
| Download URL | LFT-0.1.1-py3-none-any.whl |
|---|---|
| Size | 41.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
cac345289796ec1fa8dcc0338f85db87f385f6f35b975025c1f420d6d4dddf28
|
|
BLAKE2b-256 checksum How to use checksums |
8690865ae50ce698576ed5b123d02c002bbec99fe09ae97b2bfbb6b0d0d28bed
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/3.1.1 pkginfo/1.5.0.1 requests/2.23.0 setuptools/46.0.0 requests-toolbelt/0.9.1 tqdm/4.46.1 CPython/3.7.4
|
Security for LFT 0.1.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.