This isn't an area I have much experience in, so please forgive me if my concern isn't valid: Could this lead to a "rich get richer" phenomenon? i.e. Is it possible that first ranked node gets a higher percentage of the traffic over time, i.e. traffic for some particular node -> 100% as t -> infinity?
Edit: I realize that you designed this in order that such centralization wouldn't happen, but I'm not completely convinced that this wouldn't occur - though I am open to being convinced.
Edit #2: I see that lennstar already raised a similar point to this.
These are good questions, the t is designed never to be an infinity in order to prevent this from happening. t could be a minute, or 10 minutes, but in implementation such as this one it's a hardcoded value. (unless we extend the algorithm further and make it dynamic too, but I was not going that deep).
On the other side, there needs to be a gap between percentage of the traffic so it never happens that single node get 100% from another one. Let's assume there is 10 connections, and most of the traffic (70%) goes via node with grade 1 (of that practical "client" let's say). One small latency increases in combination with another node performing well will lead into swap so the first one is not at the first place anymore. It should add much randomization due to factors difficult to predict.
Checkout my answer to @donkeykong9000, it explains a lot on how it would affect this as well.
To make things easier, I am not 100% convinced too, actually I never am until something is production. This is just a draft to be discussed.
As for my conversation with @lennstar, I was tired, so whole thing got into trolling :), but I tried to address that issues in response to @donkeykong9000.
Also, after days thinking of it, everything was looking very self-explanatory in my head, but now when I get back on how I started designing this, I totally understand is not as close as simple as it looks like.
If I manage to find a time, i'll try to run a simulation on how this would perform. But as most likely this is not going to happen till end of the march, is somebody could do it, I believe that would be the only approach to confirm or reject this as a possible solution.
I feel (at least about myself) it's a layman's discussion. There is no documentation and I would have to dig through the code to find out how the chain grows and how consensus is met.
There are several fixes for the current forking, what suggests nobody knows what is the real cause, or there are many. Network already has an inbuilt some form of Byzantine fault tolerance - so it is not working now as intended.
Deep theoretical analysis, implementation and testing would only answer whether your model is good. I think it's promising and worth further research.
I totally agree, it is a layman's discussion. The idea is to engage more people to think of problems and solution, even these who were not directly in touch with low level technicalities. If i throw a bunch of bayesian probabilities and calculations, it's unlikely for most of people to understand, unless they are from our niche.
On another side, making a full 'by the book' documentation would require a full time job. It's also no strange that even in my full time job, I do expose a draft models to layman's discussions, in order to pass or fail. If a draft model fails such one, then obviously thinking of it further is a waste of time. Sometimes, people who are not educated in niche could shows very high level of 'common logic' (even beyond the educated ones) as we are all sometimes vulnerable to 'thinking the right way'.
As for the understanding, I fully admit I am treating the symptoms, not the diagnosis :)
Fully agree, the first step towards making a model out of draft model is proper documentation and performing a deep theoretical analysis. (that should probably move to more specialized place such as github).
On the other side, if solutions that we have in place shows good enough, this shall only stay as 'to think of' once we encounter another problem.
While it is treating of symptoms, doing it systematically usually eliminate the root cause as well.
And if you ask me, the root cause is using boost libs and other third parity gigs of code that none of us understand. It was time saver at the beginning but it leads to effects such the ones we have. In my opinion, no good system was ever good enough unless it it uses no more then iosocket and stdout. :)
If you ask me, the root cause of forking is single threaded network stack, that increases latency, that leads to possibility for multiple node to generate the same block...and so on (among many other factors that I also don't understand, nor I would be able to without reading gigs of code).
I should have asked: it is possible that after every iteration of the loop, that a single node accumulates more and more traffic?
Are you saying that 1) there is already randomization inherent to the model, and/or 2) that randomization should be intentionally introduced?
No, with current topology it's not possible. The current principle we have in place is single threaded blocking FIFO, meaning more connections lead to higher latency. That's why this implies fair traffic distribution. The more traffic node accumulates, the latency will be higher, leading to getting lower rank, thus receiving less traffic.
What if the top node has no rejected blocks? Is that possible? What if the number of rejected blocks by other other nodes is so high that the top node remains the top node, even taking higher latency into account? Is there a guarantee that one node will never stay at the top? Could a malevolent coalition of nodes take advantage of this model?
Sorry if these questions are addressed by basic knowledge, again I have little experience here.
Under that condition, that node will start accumulating more connections then usual, that directly lead into much higher latency. While it's theoretically possible that it will survive few iterations, the probability drastically falls with each one. Latency takes important part here, and the number of connections increase latency exponentially, hence the drastic fall in probability that the node will keep on top and accumulate large number of connections at the same time.
The final result shall be that the nodes of zero rejected blocks gets approximate same number of connections.
Number of connections is also an important deterministic parameter in this model.
No problem for asking, the post was intentionally explained in common language and common logic so everyone can get involved.
In addition, for the purpose of better explanation, 10 of us communicate with the same node. In order for my packet to get an answer, assuming I'm the last one who sent it, the node needs to answer your first (with whole roundtrip). That's the key point of how latency caused by single threaded networking prevents the scenario you describe.
(of-course, it's possible that I am missing something), this is still at the level of theoretical discussion, so don't take anything 100% to be correct.
I understand better now. Thanks for the patience and explanations.