Updates #1021 * Implement a GetHeightBinarySearch method that looks for the height using the binary search algorithm guaranteeing worst case iteration time of O(log2(n)) whereas worst case iteration time of O(n) for the current linear search So if n we had 500 commits stored by height and sorted, to trigger the worst case scenario for each, pass in the most negative height you can find e.g. -1 Linear search: 500 iterations Binary search: 9 iterations with n=1000, qHeight = -1 Linear search: 1000 iterations Binary search: 10 iterations with n=1e6, qHeight = -1 Linear search: 1e6 iterations Binary search: 20 iterations Of course there are realistic expectations e.g. a max of commits that may be saved so linear search might be useful for very small size set because it has less preparing overhead and only ~2 types of comparisons, but nonetheless binary search shines as soon as we start to hit say 50 commits to search from as you can see below: ```shell $ go test -v -run=^$ -bench=MemStore goos: darwin goarch: amd64 pkg: github.com/tendermint/tendermint/lite BenchmarkMemStoreProviderGetByHeightLinearSearch5-4 300000 6491 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightLinearSearch50-4 200000 12064 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightLinearSearch100-4 50000 32987 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightLinearSearch500-4 5000 395521 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightLinearSearch1000-4 500 2940724 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightBinarySearch5-4 300000 6281 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightBinarySearch50-4 200000 10117 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightBinarySearch100-4 100000 18447 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightBinarySearch500-4 20000 89029 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightBinarySearch1000-4 5000 265719 ns/op 1600 B/op 15 allocs/op PASS ok github.com/tendermint/tendermint/lite 86.614s $ go test -v -run=^$ -bench=MemStore goos: darwin goarch: amd64 pkg: github.com/tendermint/tendermint/lite BenchmarkMemStoreProviderGetByHeightLinearSearch5-4 300000 6779 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightLinearSearch50-4 100000 12980 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightLinearSearch100-4 30000 43598 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightLinearSearch500-4 5000 377462 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightLinearSearch1000-4 500 3278122 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightBinarySearch5-4 300000 7084 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightBinarySearch50-4 200000 9852 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightBinarySearch100-4 100000 19020 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightBinarySearch500-4 20000 99463 ns/op 1600 B/op 15 allocs/op BenchmarkMemStoreProviderGetByHeightBinarySearch1000-4 5000 259293 ns/op 1600 B/op 15 allocs/op PASS ok github.com/tendermint/tendermint/lite 86.204s ``` which gives ```shell $ benchstat old.txt new.txt name old time/op new time/op delta MemStoreProviderGetByHeight5-4 6.63µs ± 2% 6.68µs ± 6% ~ (p=1.000 n=2+2) MemStoreProviderGetByHeight50-4 12.5µs ± 4% 10.0µs ± 1% ~ (p=0.333 n=2+2) MemStoreProviderGetByHeight100-4 38.3µs ±14% 18.7µs ± 2% ~ (p=0.333 n=2+2) MemStoreProviderGetByHeight500-4 386µs ± 2% 94µs ± 6% ~ (p=0.333 n=2+2) MemStoreProviderGetByHeight1000-4 3.11ms ± 5% 0.26ms ± 1% ~ (p=0.333 n=2+2) ``` If need be we can make a hybrid algorithm that switches between the linear and binary search depending on the number of items. This is reminiscent of Python's TimSort algorithm.
Tendermint
Byzantine-Fault Tolerant State Machine Replication. Or Blockchain for short.
| Branch | Tests | Coverage |
|---|---|---|
| master | ||
| develop |
NOTE: This is alpha software. Please contact us if you intend to run it in production.
Tendermint Core is Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine - written in any programming language - and securely replicates it on many machines.
For more information, from introduction to install to application development, Read The Docs.
Minimum requirements
| Requirement | Notes |
|---|---|
| Go version | Go1.9 or higher |
Install
To download pre-built binaries, see our downloads page.
To install from source, you should be able to:
go get -u github.com/tendermint/tendermint/cmd/tendermint
For more details (or if it fails), read the docs.
Resources
Tendermint Core
All resources involving the use of, building application on, or developing for, tendermint, can be found at Read The Docs. Additional information about some - and eventually all - of the sub-projects below, can be found at Read The Docs.
Sub-projects
- ABCI, the Application Blockchain Interface
- Go-Wire, a deterministic serialization library
- Go-Crypto, an elliptic curve cryptography library
- TmLibs, an assortment of Go libraries used internally
- IAVL, Merkleized IAVL+ Tree implementation
Tools
Applications
- Ethermint; Ethereum on Tendermint
- Cosmos SDK; a cryptocurrency application framework
- Many more
More
Contributing
Yay open source! Please see our contributing guidelines.
Versioning
SemVer
Tendermint uses SemVer 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.), as well as parts of the following packages:
- types
- rpc/client
- config
- node
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.
Functions, types, and values in any other package may also change at any time.
Upgrades
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.
However, any bump in the PATCH version should be compatible with existing histories (if not please open an issue).
Code of Conduct
Please read, understand and adhere to our code of conduct.