Byzantine-Fault Tolerant State Machines. Or Blockchain, for short.
TxFlow Core is asynchronous Byzantine Fault Tolerant (aBFT) middleware that takes a state transition machine - written in any programming language - and securely replicates it on many machines.
TxFlow is designed for responsiveness. Instead of blocks, transactions are confirmed in realtime asynchronously. When a transaction is received, validators sign and create a TxVote. These are again asynchronously broadcasted out. There are no view changes.
The process flow is as follows
- Transaction payload received via client RPC
- Transactions are broadcast via p2p (no synchrony)
- Validator signs transaction
- Voted Transactions are broadcast via p2p (no synchrony)
- When 2n/3 stake from votes are collected the transaction is committed to the state
The above allows for transactional responsiveness
Blocks are still produced as a ticker to allow for a time based ordering (similar to BFT lamport timestamps)
Transactions potentially not confirmed within a block proposal are included in the block proposal to allow a fallback for responsiveness
NOTE: The master branch is now an active development branch (starting with v0.1.0). Please, do not depend on it and
use releases instead.
In any case, if you intend to run TxFlow in production, please contact us.
| Requirement | Notes |
|---|---|
| Go version | Go1.11.4 or higher |
Please abide by the Code of Conduct in all interactions, and the contributing guidelines when submitting code.
TxFlow uses Semantic Versioning to determine when and how the version changes. According to SemVer, anything in the public API can change at any time before version 1.0.0
To provide some stability to Tendermint users in these 0.X.X days, the MINOR version is used to signal breaking changes across a subset of the total public API. This subset includes all interfaces exposed to other processes (cli, rpc, p2p, etc.), but does not include the in-process Go APIs.
That said, breaking changes in the following packages will be documented in the CHANGELOG even if they don't lead to MINOR version bumps:
- crypto
- types
- rpc/client
- config
- node
- libs
- bech32
- common
- db
- errors
- log
Exported objects in these packages that are not covered by the versioning scheme
are explicitly marked by // UNSTABLE in their go doc comment and may change at any
time without notice. Functions, types, and values in any other package may also change at any time.
In an effort to avoid accumulating technical debt prior to 1.0.0, we do not guarantee that breaking changes (ie. bumps in the MINOR version) will work with existing tendermint blockchains. In these cases you will have to start a new blockchain, or write something custom to get the old data into the new chain.