Looks like these guys (Tendermint team) actually care about design, testing and scalability in their project compared to Ethereum where people are concentrating on hype rather than product (I am not rude, used Ethereum from the client's perspective) :)
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?
Thanks for the compliments! We do really care about quality software design and testing, and we're looking to hire folks that share our values: https://tendermint.com/careers
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
Good to have you here. What is your view around private blockchains and smart contracts regarding Hyperledger Fabric vs Ethereum based ones? I mean, in my perspective there is no need to have smart contracts ala Ethereum because in a private blockchain you can simplify the problem to a workflow with states where the parties sign the different transitions and the logic can be outside a VM. Since private blockchains rely on a lot of oracles, those oracles are the weakest link in the security chain and the VM does not add significant security like in a public blockchain.
I think it's still a big experiment and there's a lot to figure out around the right state machines and the right models for computation in these systems. We hope that Cosmos and Tendermint help that experiment along
No, private blockchains can scale better than public blockchains for obvious reasons: they are trustful.
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.
Tendermint works great for 4 to 300 validators, and with the Cosmos delegation model, many more stakers can participate. So yes, it's not a trivial problem, but Tendermint is solving it.
I am not talking about PoW specifically but about the new research that Bitcoin opened, including new consensus systems in trustless networks. The community knew how to build distributed systems in trusted networks before Bitcoin.
Hi there,
We've been using Tendermint over the past 3 months for our company's project and the experience has been very smooth so far. As a developer, I believe that tendermint embodies a very powerful way to start coding your blockchain in a very simple manner. The ABCI protocol is quite straigh forward and depending wether you want to create your own private blockchain or a sophisticated public one, it is already quite robust at this point. The range of things that you can do is pretty wide, you can digitalize your assets or setup a proof of existence blockchain for your documents. Definitely the best framework out there, I believe.
It means "arbitrary". Byzantine faults refer to "any arbitrary behaviour by the machine". The term was coined by Leslie Lamport in the early 80s when he defined the Byzantine Generals Problem
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.
Hi guys, I asked this question on Twitter as well. Is there a way to model proof of work vs proof of stake using something like Jepsen/Merkleeyes.
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 doesn't use Proof of Work (PoW). PoW is hard to test with Jepsen because it only supports probabilistic safety, which means the chain can constantly reorganize. If I'm not mistaken, Jepsen would consider PoW's routine reorgs as linearizeability failures. That said, Jepsen could potentially be modified to support this better, for instance only considering something accepted if its buried X blocks deep.
Tendermint, in contrast, provides deterministic safety, and serves as a building block for Proof of Stake networks.
> 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?
Unlike traditional BFT algorithms that have multiple validators with equal and static voting power, what
Tendermint does is each validator has coins staked to them. These coins can be either the validator operator's own coins or coins that are "delegated" to them by other users (think of these as Proof of Stake "mining pools"). Their "voting power" in the BFT consensus is weighted by their coin stake.
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.
Good points. Tendermint aims to be a general purpose consensus system - how the validators are actually chosen and changed is outside Tendermint's domain.
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 :)
>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
I first tried to use Tendermint a year ago and honestly it was rough. Their codebase had very few comments, including things a go linter would harass you endlessly for like function comments, and the docs were barely existent. The codebase was also not exactly what you would call "idiomatic" go.
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.
Thanks! A year ago we were just two guys working on this project on the side without any funding. Now we're a full time team of talented devs swinging in full force. The comments and docs continue to improve, and we're excited that folks like yourself continue to take a look.
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:714)
at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:950)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1368)
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134)
at clojure.core$future_call.invokeStatic(core.clj:6687)
at ring.middleware.gzip$compress_body.invokeStatic(gzip.clj:70)
at ring.middleware.gzip$compress_body.invoke(gzip.clj:70)
at clojure.lang.AFn.applyToHelper(AFn.java:154)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.core$apply.invokeStatic(core.clj:648)
at clojure.core$update_in.invokeStatic(core.clj:5950)
at clojure.core$update_in.doInvoke(core.clj:5939)
at clojure.lang.RestFn.invoke(RestFn.java:445)
at ring.middleware.gzip$gzip_response.invokeStatic(gzip.clj:87)
at ring.middleware.gzip$wrap_gzip$fn__12777.invoke(gzip.clj:95)
at aleph.http.server$handle_request$fn__9026$f__5083__auto____9027.invoke(server.clj:156)
at clojure.lang.AFn.run(AFn.java:22)
at io.aleph.dirigiste.Executor$Worker$1.run(Executor.java:62)
at manifold.executor$thread_factory$reify__4975$f__4976.invoke(executor.clj:44)
at clojure.lang.AFn.run(AFn.java:22)
at java.lang.Thread.run(Thread.java:745)
I had to migrate prod environments when Skyliner shut down; this is the first release I've done on Heroku. Clearly I should have provisioned more capacity. :) Should be back shortly.
This is something I do not understand with java as a webserver - doesn't such behavior show a major design problem?
"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?
The jepsen.io server is literally something I hacked together in a few weekends. I wouldn't really point to it as an exemplar of high quality production-facing engineering. :)
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.
You should switch over to using Hugo and generating static html for most of your site. Deploying it to Firebase CDN or Netlify should cost you a few dollars every month.
Pretty much no web servers or apps are tested to destruction probably because few tools can even generate good overload. It's just an industry in perpetual infancy.
How does Tendermint consensus compare to Nakamoto consensus? Are 2/3 of the nodes expected to be honest? How is validator membership established/enforced?
Tendermint consensus is more like classic BFT consensus than Nakamoto. It provides deterministic finality/safety with every block, unlike the probabilistic 6-block safety of Nakamoto.
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.
Adding on to what coinculture said, the traditional BFT nature of Tendermint consensus gives it a lot of benefits over Nakamoto consensus such as 1-block finality and safety guarantees in asynchronous environments.
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.
Great work! I just started using Tendermint to write a cryptocurrency for supporting open source development and have several simple questions. Would appreciate it if you could answer them:
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?
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.
Is the intended purpose of the Tendermint protocol to solve the double spend problem, thus allowing the creation of digital tokens?
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)?
In a BFT protocol based cryptocurrency, an attacker who acquired 2/3rds of the tokens in the network would be able to double spend at will and censor transactions to gain control of more of the network.
They would not be able to rewrite past history.
The only response to an attack would be hard fork.
If I want to bootstrap my node and I join a network where 2/3 of the nodes present a newly-created (false) transaction history, and the remaining nodes present the original transaction history, how would I be able to tell which chain to follow without trusted/special nodes?
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.
Because someone needs to show you a valid set of transitions in the PKI from the original keys in the genesis block to the current attacker controlled PKI.
If the corresponding private key of a public key in the genesis block defines the correct transaction history then this system is not decentralized, but controlled by whoever owns this private key. In which case this entity might as well just sign blocks to avoid the double spend problem in a much simpler (albeit centralized) way.
I prefer if people differentiate between systems with a PKI and systems without a PKI.
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.
> One of the challenges in an on chain PKI system is you need some of kind social pre-consensus on launch.
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).
If this system depends on trusting 2/3 of the keys in the genesis block, why not simply sign all individual transactions with keys in the genesis block, and unlock even higher transaction throughput?
I mean if you gotta trust a centralized authority anyway, ditch the blockchain and make it simple.
What centralized authority? The keys in the genesis block aren't owned by a single actor, but by multiple.
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.
You would have to compromise the devices of validators who have atleast 2/3 of the voting power.
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.
> 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.
It's not a single private key. There are a lot of validators, even in the genesis block, and we assume that at least 2/3 of these validators are honest.
It still puts an upper bound on the value of the underlying token, as the pressure for these validations to collude increases with the market value of the token in question. An outside attacker compromising keys isn’t the only way for the system to fail.
Would you trust 100 validators with securing $10M? What about $100M or $1bn? The financial incentive to collude keeps increasing as the value increases.
> You need to authenticate first against a trusted source.
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?
It's not some single centralized trusted source. It's a local trusted source. Like a friend or a shop or a website you make payments on that uses the network and has been keeping up to date. Ideally folks should check multiple sources to ensure they agree.
In the same way folks need to figure out which software to download when they join the Bitcoin network.
Also, two other comments regarding weak subjectivity:
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
> When you join the bitcoin blockchain, you need some trusted source to tell you the hash of the correct genesis block.
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.
Because it's much easier to find an arbitrary source to trust in a one off transaction than to find a source that has perfect reliability moving forward.
To be specific, our "byzantine" faults are limited to very specific types of behavior: running multiple copies of the same validator on different nodes, and modifying on-disk state of the validator. We make no changes to the validator source, don't inject arbitrary messages, don't attempt to invalidate already signed blocks, etc etc.
It means we simply give two different nodes the same signing key and get them to sign conflicting proposals and votes. A more complicated Byzantine fault would take into consideration the structure of the underlying protocol to try to thwart consensus safety in a more intelligent way.
So, to summarize, instead of trusting physical hardware owned by different people we are expected to trust that keys, that were used to sign genesis block will never leak?
Not quite - see other comments about needing a trusted local source the first time you sync up. Otherwise, forks are never tolerated. If the keys leak, and there's a new history, it will be ignored by all nodes who have been online.
Why did you create your own data store - Merkleeyes.
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.
Leveldb is great - but we are already seeing an explosion in system requirements of blockchains. For example, Monero is already at 25gb. What ends up happening is that people who are serious about this, end up having to port the data structures to a scalable solution.
For example take a look at all the questions around "how do I make Bitcoin work with MySQL for larger websites" - https://www.google.co.in/search?q=bitcoin+mysql+site:bitcoin...
It would be so great if you guys could use a datastore that is setup for scale from the get go.
75 comments
[ 2.9 ms ] story [ 114 ms ] threadIt 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).
what's "byzantine" mean in this context?
https://en.m.wikipedia.org/wiki/Byzantine_fault_tolerance
I recommend this: http://techtv.mit.edu/genres/19-engineering/videos/16444-pra... which helped me learn how it works ~6 years ago :)
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
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
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
"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.
java.lang.OutOfMemoryError: unable to create new native thread
Cached version: http://webcache.googleusercontent.com/search?q=cache:https:/...
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.
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.
> simple byzantine faults
means? Isn't "simple byzantine" an oxymoron?
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.