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
Looks pretty product-focused to me.
Using gRPC for Block Finance (http://block.finance).
"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.
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 :)
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?
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
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.
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.
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.
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 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?
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
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
java.lang.OutOfMemoryError: unable to create new native thread
Cached version: http://webcache.googleusercontent.com/search?q=cache:https:/...
