This article was first published on RChain Cooperative - Medium
Greg Meredith continues the discussion on liveness with Isaac DeFrain and Christian Williams.
Greg: Today I want to talk about some practical things that have happened with the network dynamics and then talk about how the error-correcting code stuff directly addresses that. If you remember, several months ago we talked about error-correcting codes and how that gives us a way to deal with liveness issues.
Isaac: Could we revisit this stuff about error-correcting codes and how it relates to safety? It’s been a little while since I’ve thought about that, and maybe it’d be helpful for everybody else.
Greg: I’m going to do that for sure, but I’m going to do it in the context of this particular problem. First, I want to check in and see if you understand the problem.
Christian: What are we talking about?
Greg: What we’re seeing right now is a problem in network dynamic equilibria. The issue is that if you have a bunch of validators, all of whom are identical in spec, one validator can pull way ahead of the other validators. All the other validators are just processing blocks proposed by the initial validator. Some validator receives a deploy from a client, and then runs the contract associated with the deploy, and then does a replay as a part of the validation of that computation, and then forwards the proposal, the block, onto other validators.
At that point it’s checking of the block is in its past and it can go on to do other things. All the other validators have that block to deal with. Under certain kinds of conditions, with respect to network latency and things, that validator, even though they’re all equivalent in terms of network bandwidth and storage ...
To keep reading, please go to the original article at:
RChain Cooperative - Medium