Tendermint 0.10.2
jepsen.io
jepsen.io
It would be interesting to hear from people who actually use (if there are any) Tendermint: * How easy/hard is it to create bindings to the blockchain from your own backend application (as I can see there is a GRPC option). * How many nodes you are running? * What's the use case?
Lots of people are using Tendermint. The biggest users would be Hyperledger Burrow (https://github.com/hyperledger/burrow) and our own Ethermint (https://github.com/tendermint/ethermint). We're also working on an SDK for building apps in Golang (github.com/cosmos/cosmos-sdk) but it won't be ready for another month or two. There are a variety of apps built by members of the community, and ABCI servers in different languages - you can see a somewhat up-to-date list here: https://tendermint.com/ecosystem
Private blockchains are incentivized to adopt public blockchain architectures because public blockchains are most economically vetted.
Regarding private blockchains growing to public trustless blockchains, that is not a trivial problem. There are new blockchain models that are being promoted (e.g. IOTA, EOS, NEM) which have not being studied enough by consensus researchers.
I don't know of anyone who really applied traditional BFT networks into public blockchain architecture, however, until Tendermint.
For example, who spoke or wrote of BFT fault accountability/attribution, and how it pertains to proof-of-stake models, before Tendermint?
There was also the 2011 paper that lamented the lack of good open-source middleware for BFT algos. Tendermint solves that engineering problem as well.
Looks pretty product-focused to me.
Using gRPC for Block Finance (http://block.finance).
I checked back in at the Cosmos fundraiser, and then again a few weeks ago and their documentation while still needing work, as well as their code quality is definitely improved. I like their idea and I want the project to succeed, and things like independent third party audits are the way that happens.
Kudos to the team for not being afraid to look for the warts, better to get them now then later.
If you have more specific issues/comments/suggestions, please open an issue! https://github.com/tendermint/tendermint/issues
And, if so, wouldn’t the market value of these tokens be limited to whatever it costs to bring 2n dishonest nodes, where n is the current number of nodes in the network (thus reaching 2/3 majority), and hereby allowing you to define the transaction history (and assigning all tokens to yourself and sell them in the open market — which will be profitable if the market value of the tokens exceeds the cost of bringing up the dishonest nodes)?
They would not be able to rewrite past history.
The only response to an attack would be hard fork.
In other words, the plan of attack wouldn’t be altering the current chain (which indeed would require owning coins on it, because of proof-of-stake), but rather presenting a completely different chain to new nodes with a 2/3 node majority.
Systems without a PKI like PoW or PoET can be rather centralized like Bitcoin today or decentralized like Bitcoin before the emergence of mining pools.
Systems with a PKI can have an onchain PKI like Cosmos. One of the challenges in an on chain PKI system is you need some of kind social pre-consensus on launch. The crowdfunding established an part of an initial pre-consensus but there are more moving pieces coming.
The greatest challenge, in my opinion, is that there’s a central point of failure: just compromise whichever device stores the private key for the genesis block and you get to redefine history as you please.
Compromising a Bitcoin mining pool cannot be compared to this, since it would just result in this pool’s miners losing their revenue and moving somewhere else (it can never enable rewriting the entire chain history).
I mean if you gotta trust a centralized authority anyway, ditch the blockchain and make it simple.
You can keep the validator set static all the time (use the ones from the genesis block), this might be useful for private chains. But Tendermint also allows for dynamic validator sets. This is useful for Proof of Stake, where validators can come and go, and their voting power can change in accordance with changes in their stake deposits.
In Bitcoin, just compromise the devices of mining pools that have atleast 50% of the hashing power, and reconstruct a chain that is longer than the current canonical chain, thus rewriting the chain history.
Rewriting the Bitcoin blockchain using 100% of the current hashing power would take an entire year. Thus, with 50% of it it would take two years, assuming the network hashrate doesn't increase (which it does).
Don’t you think someone would notice — over the course of two years — that their mining pool has been compromised and no longer extends the current best chain?
Compromising Bitcoin mining pools lets you move hashing power somewhere else, which is noticeable since the extension of the current best chain would slow down. Compromising the genesis keys in PoS system let’s you create as many valid chains as you want in little to no time.
Would you trust 100 validators with securing $10M? What about $100M or $1bn? The financial incentive to collude keeps increasing as the value increases.
If the system depends on a trusted source, why not just have this trusted source sign blocks, thus solving the double spend problem without further ado?
In the same way folks need to figure out which software to download when they join the Bitcoin network.
When you join the bitcoin blockchain, you need some trusted source to tell you the hash of the correct genesis block.
Also, if you want to follow a shorter fork chain like Ethereum Classic, you also need weak subjectivity to tell you the first block immediately after the fork, otherwise you might be tricked onto the longer malicious fork, Ethereum :P
No, you don’t. There’s nothing special about the Bitcoin genesis block, it’s a block like any other. Whether you follow a chain that builds on top of this block or some other block has no bearing on the security of the system. It contains no keys that get to decide anything later on.
Yes, 2/3 are expected to be honest.
Validator membership is established in the genesis state, shared by all participants, and can be updated in arbitrary ways, as determined by the particular application running above Tendermint.
Traditionally, these BFT algorithms did not work in public settings, and only worked with fixed validator sets. However, with the conceptual invention of Proof of Stake, we realized we can use cryptoeconomics to facilitate validator set changes in a public network.
And yes, 2/3 of nodes are set to be honest. However, just in case you weren't aware, it's pretty not well known, but Nakamoto consensus also has a 2/3 threshhold due to the game theoretical vulnerabilities caused by a process known as selfish mining.
1) What's your estimated time to be able to run in production?
2) What do you think of using something like PostgreSQL to keep the state?
3) Is it a good approach to write cron, for example, to recalculate some values once in awhile and update the state by sending transactions?
4) What is the best way to handle random numbers?
1) We're looking to get the Cosmos Hub up before the year is out, and to roll out production support in 2018.
2) Great, if you like. But if you want to support light clients you will need a scheme for producing Merkle proofs. Streaming data out of the app into Postgres to better serve clients, sure. But Postgres within the hot paths of your app? Not sure.
3) Sure. Or you can use BeginBlock or EndBlock messages to have the blockchain automatically run code even without transactions :)
4) We're still working on this. For now you can use an external random number oracle, or the block hash, which is available in the Header passed into BeginBlock. The block hash is currently highly manipulable.
I'm looking forward to see some Jepsen style testing of the different blockchain protocols, but doesn't seem to be anything out there that can model these aspects.
In building Tendermint, did you figure how to test and validate these aspects of blockchains ?
Tendermint, in contrast, provides deterministic safety, and serves as a building block for Proof of Stake networks.
Can you elaborate on this, as there is almost no mention of PoS in the post?
From a high level, your response to my previous comment can be interpreted as the validators being "hardcoded" upfront, which would be very different decentralization properties from PoW systems.
What assumptions does Tendermint make in contrast to PoW systems, and what applications do you see it being most useful for?
Validators can come and go as part of the protocol, so essentially the previous validator set signs on the next validator set. Also, more people can delegate stake to existing validators.
When a validator leaves, there is an unbonding period before they are allowed to withdraw their coins (this is the to put a minimum time length on a long-range attack). Tendermint also solves the nothing-at-stake problem because if a validator doubles signs on two competing blocks, this is byzantine behavior that is recognized and punished by slashing their staked coins on both forks (staked coins act as both weight for BFT voting power and as security deposits).
One assumption that Tendermint makes as opposed to Nakamoto Consensus systems is that at least 66% of validators have to be running in order for the system to make progress. In Nakamoto consensus, even if a lot of miners are down, the existing miners can still propose blocks. This is, however, a double edged sword, as what seems top be "down validators" might actually be a network partition. In Nakamoto consensus, even a temporary partition would lead to parallel forks, while in Tendermint, this would not happen, as the system will stall instead of forking. Nakamoto Consensus is availability favoring, while Tendermint is consistency favoring.
Tendermint works very well for both Proof of Stake and Proof of Authority systems, which is makes it particularly useful for both public and private settings, and deals with byzantine faults in both, as opposed to just crash faults as in protocols like Paxos and RAFT.
All Tendermint wants to know is an initial set, and leaves it up to the App to tell it how the validators should change with every block.
You can build PoS at the application level, if you need it. This is what we're doing with https://cosmos.network/. With every block, the application can decide, according to its particular PoS design, how the validators should change.
There's actually no reason you couldn't build a Tendermint app that determines who the next validators are based on PoW they did and submitted as a transaction. Not quite the PoW we're used to, but it shows Tendermint is quite flexible. That said, a 2/3 coalition of the current validator set always has complete control on what goes in the blockchain, and a 1/3 coalition can halt it - we can't bail out of that without a hard fork.
Note PoW is also only safe in a synchronous network, though it hedges this with an economic random lottery. Of course PoW guarantees a thermodynamic immutability that nothing else can.
Tendermint isn't inherently economic, and is safe so long as <1/3 of the validating power is malicious, even in asynchronous networks. That's what Jepsen shows here (well, fails to disprove).
Arguably, Tendermint is most useful as an analog of Paxos/Raft but in a multi-stakeholder, or otherwise more adversarial, setting.
We aim to prove it's also useful for structuring global financial systems and scaling cryptocurrencies :)
Proof of stake functionality is provided by the cosmos sdk which is under development.
From https://blog.ethereum.org/2017/08/23/roundup-5/
>Work has started on a “testing language” which can be used to quickly write and run tests for proof of work, Casper and sharding fork choice rules. This should substantially improve coverage and accelerate testing for both Casper and sharding.
This is super interesting stuff - obviously we all have a keen interest in Jepsen being able to do this for all blockchains - Jepsen inspires a lot more trust
java.lang.OutOfMemoryError: unable to create new native thread
Cached version: http://webcache.googleusercontent.com/search?q=cache:https:/...
what's "byzantine" mean in this context?
I recommend this: http://techtv.mit.edu/genres/19-engineering/videos/16444-pra... which helped me learn how it works ~6 years ago :)
"Lots of traffic" can be expected by any webserver software - handling "too much" of it in a not too painful way could be a design goal. Just spitting out an error on such a condition and making the site disappear is a little bit too simplistic for my taste.
I have seen this error on sites with java webservers many times - is this an accepted limitation in the java world?
I am not trying to be snarky here, I have lots of respect for aphyrs work, but I am really wondering about this "normal behaviour" of java webservers - how can an "enterprise platform" get away with this?
That said, it does push 50,000 reqs/sec on my local box, did just fine on an AWS m3.medium, then fell over today at 5 reqs/sec on a heroku "pro" dyno, so... this is something I'll have to address.
I mean, my question is - could you not have wrapped postgresql jsonb or redis using application logic to give you the same kind of semantics as Merkleeyes, yet not have to reinvent data storage ?
Would you not have to resolve all the problems that Redis has had to...Also that commercial infrastructure for Redis (e.g. Elasticache) is widely available.
The primary reason to use our own is to support Merkle proofs of the state. For the Jepsen tests, it wasn't really needed, and may have been smarter to just wrap something else. But we didn't really reinvent any data storage, we just used goleveldb.
It would be so great if you guys could use a datastore that is setup for scale from the get go.
> simple byzantine faults
means? Isn't "simple byzantine" an oxymoron?
We have a hubs in Toronto and Berlin, and we're building one out in the Bay Area.
If you have what it takes to design and implement protocol standards for the blockchain/cryptocurrency industry, reach out. We want to hire you!
If you have significant open-source software development experience in distributed systems design, operating systems design, database systems design, or language design, reach out. We want to hire you!
We're redefining the definition of money while we build our future's financial infrastructure.
email: careers@tendermint.com