"Cobalt" update to evolve XRP to 1 second transmissions?

[Guest]

22 minutes ago, Zerp_Legend said:

If they are right I am gonna give 20 zerps to charity, promised

Oh that's coincidental, I have my own charity! Feel free do donate to me -uhm- my charity* 

[Zerp_Legend]

29 minutes ago, RobinBaas said:

Oh that's coincidental, I have my own charity! Feel free do donate to me -uhm- my charity* 

Does it involve beer and beautiful ladies?

[Guest]

The only relevant possibility I can think of, is the two-second delayed hard coded into the XRP LCP (Ledger Consensus Protocol) to allow for proper synchrony. Perhaps with Cobalt that intentionally designed "pause" for the "weakest link in the chain" can be removed? From the paper:

Quote

Further, Cobalt always makes forward progress fully asynchronously. Similar to the well-known consensus algorithm PBFT, the previous algorithm, XRP LCP, required assuming a form of “weak asynchrony” where throughput could be dropped to 0 by slightly-higher-than-expected delays or a few faulty nodes. But in practice, it is difficult to quantify what level of delay is “expected” in a decentralized open setting, where nodes can be in arbitrary locations around the globe and have arbitrarily poor communication speed.

But in practice, it is difficult to quantify what level of delay is “expected” in a decentralized open setting, where nodes can be in arbitrary locations around the globe and have arbitrarily poor communication speed. With Cobalt however, performance simply degrades smoothly as the average message delay increases, even with the maximal number of tolerated faulty nodes and an actively adversarial network scheduler. In a live network, breaking forward progress could do a lot of damage to businesses that rely on being able to execute transactions on time, so this extra property is very valuable.

Probably totally off on that as not very technical, but thought it worth a pop.

EDIT: Wild guess, don't burn me!

Edited March 27, 2018 by Guest

[Guest]

47 minutes ago, Zerp_Legend said:

Does it involve beer and beautiful ladies?

That's the 40 XRP formula

[Ravell]

1 second ledger close time confirmed

[Guest]

3 hours ago, Crypt0nz said:

oracletimes, the same source who made up '50k tps - more than VISA' story...

Dont forget they also published the "Tencent story" as if it was real news backed by credible sources.

[Zerp_Legend]

Just now, Coretex said:

Dont forget they also published the "Tencent story" as if it was real news backed by credible sources.

Didnt ripplenews.tech start this rumour?

[Guest]

Just now, Zerp_Legend said:

Didnt ripplenews.tech start this rumour?

Possibly, but Oracle gladly took it from them.

[TexasHodlem]

9 hours ago, Apollo said:

Ripple hasn't started rewriting the code yet. Once they do ("very soon") it will probably take a couple yearsish to go live. 

It should be faster than XRP is now, although most of the latency is made up of simple TX processing so faster consensus won't help that. My uneducated guess is somewhere in 2.5-3.3 range. 

Only time will tell, but my impression is that Cobalt will be implemented in 2018. This is the year of focusing on decentralization, and I think that's going to require Cobalt. Recent changes to allow for more varied validator lists don't do much good if nodes require a 90% overlap. (see below)

Quote

We also show that under a more general fault model which was not considered in the original whitepaper but is canonically used in the research literature, the minimum overlap is actually roughly > 90% of the UNL.

https://arxiv.org/pdf/1802.07242.pdf

Quote

To solve these issues, this paper proposes a new consensus protocol called Cobalt, which can be used to power decentralized digital currencies such as XRP. Cobalt reduces the overlap bound to only > 60%, which gives much more flexibility to support painless decentralization without the fear of coming to an inconsistent ledger state.

https://arxiv.org/pdf/1802.07240.pdf

My theory is that we'll see it in the version 1 release. This month, the version was set to v1 (https://github.com/ripple/rippled/commit/9af994ceb45a82861205bb9d0b8d845cec950524), but without substantial changes that would warrant a major version change. Whatever is in v1, they're keeping it close to their chest. I recently ran across Stefan saying that they sat on ILP for a year before releasing it so that they could plan around it. This may have been a similar case where they've been working on it in the background for some time. The first paper cited notes that the initial overlap requirement was estimated at 20%, later 40%, and now >90%. This could be perceived as very negative, so perhaps they waited to release that news until a solution was very near.

 

Edit: The saga continues. I missed this update from Ethan, which may shoot holes in my 2018 theory. To be fair, he uses uncertain terms. ("Probably" *and* "who knows")

 

Edited March 27, 2018 by TexasHodlem

[Anakin_Jackson]

Without getting super deep into the technical side of this, would it be too far out in left field to think that aside from the obvious improvements in an already fast and scalable system, Ripple would be preparing their network for much higher volume then it currently sees. I would further speculate, key word being speculate, that with this they would be continuing to lay the ground work for when they have high volume partners going live with their products (namely xRapid). Having the added speed and scalability is what gives them the ability to be ready to face off with the big boys later down the road I would think.

 

[Apollo]

13 hours ago, TexasHodlem said:

Only time will tell, but my impression is that Cobalt will be implemented in 2018. This is the year of focusing on decentralization, and I think that's going to require Cobalt. Recent changes to allow for more varied validator lists don't do much good if nodes require a 90% overlap. (see below)

My theory is that we'll see it in the version 1 release. This month, the version was set to v1 (https://github.com/ripple/rippled/commit/9af994ceb45a82861205bb9d0b8d845cec950524), but without substantial changes that would warrant a major version change. Whatever is in v1, they're keeping it close to their chest. I recently ran across Stefan saying that they sat on ILP for a year before releasing it so that they could plan around it. This may have been a similar case where they've been working on it in the background for some time. The first paper cited notes that the initial overlap requirement was estimated at 20%, later 40%, and now >90%. This could be perceived as very negative, so perhaps they waited to release that news until a solution was very near.

 

Edit: The saga continues. I missed this update from Ethan, which may shoot holes in my 2018 theory. To be fair, he uses uncertain terms. ("Probably" *and* "who knows")

 

 

The bad topology news was already in a published paper. Although, Ripple didn't wave it around. 

Ethen said the idea of cobalt was conceived starting around December 2017, and they had not started rewriting code but will very soon. 

The consensus parts apparently have to be completely redone, but most of the transaction code (which is most of Rippled) stays as is. Still will be a very big project. Programming for decentralized open systems is very slow because of security issues. I would be surprised to see this released before 2020. But who knows. 

Also, looks like 1-1.5 sec TX range is, in fact, possible with Cobalt.

I think throughput might be somewhere in the 8-25K TPS ranger per transaction network and Cobalt can run multiple transaction networks. (a bit of guesswork for this number but I am pretty confident it is ballpark)