Jump to content
mDuo13

Primer: XRP Ledger Validators vs. Interledger Validators

Recommended Posts

1 hour ago, mDuo13 said:

And if you're going so far as to do that, you could also agree on any number of other modifications to the protocol, so honestly, it doesn't really make sense to define a standard that needs you to agree on some other stuff anyway. On the other hand, if you build a private network of banks and similar institutions, they are are absolutely loathe to accept the risk that some payments fail in the middle, and perfectly willing to define and abide by conventions for whose timepiece is authoritative. Thus, Ripple ended up in a situation where xCurrent uses a proprietary "atomic" variation of the Interledger Protocol (whose conventions are enforced in part by business contracts!) and the published Interledger standards have only the works-anywhere-with-risks Universal mode definition and the reductive-for-example-purposes Optimistic mode.

@mDuo13 This actually makes a lot of sense - thank you for taking the time to describe some of these points.  :viannen_89:

I think it's perfectly all right for there to be an ILP standard, and then also for there to be a "how it was actually implemented in our bank network" type of situation. 

1 hour ago, mDuo13 said:

For the record, RTXP's only "documentation" is the code itself.

Is there any plans in the works for a text-book like source to describe this process? 

I know Bitcoin Core has some books out there that do this.  (Andreas Antonopoulos wrote one)

Share this post


Link to post
Share on other sites
3 hours ago, mDuo13 said:

What may surprise you is that the public ILP specs don't define atomic mode; Stefan, Evan, et al. came to the conclusion that, in order to use Atomic mode, all the participants had to agree on a set of validators and how to choose them. And if you're going so far as to do that, you could also agree on any number of other modifications to the protocol, so honestly, it doesn't really make sense to define a standard that needs you to agree on some other stuff anyway.

 

I am a long way from an expert on this and I may be missing something important here, but with that said... Publishing a standard, even where it is fundamentally arbitrary and subject to elective modification by the participants could lower the transaction costs of establishing ILP connections. I see two basic benefits to providing a default standard here.  

The first is a simplification of contract negotiations between participants. If participants are able to incorporate a published set of standards by reference it could reduce the number of live issues that need to be discussed and thereby reduce the time and cost of establishing necessary legal relationships. There are a few analogous legal frameworks which help to lubricate international contract negotiations. For example, parties often incorporate complex arbitration procedures by reference through the name of an arbitral body.

Secondly, the mere existence of a standard can help avoid uncertainty where parties fail to provide sufficient details in a contract. If there is a standard or default set of rules in place when parties agree to set up an ILP connector but fail to set out the specific rules for how it will be done, the parties (and a court if necessary) will be able to draw on the standard to provide legal certainty. This may sound insignificant, but legal certainty is a valuable thing. Having a clear right answer can be more important than what the answer is.

Edited by Apollo

Share this post


Link to post
Share on other sites

@mDuo13 I have always imagined that the XRP Ledger validators set could eventually act as a public and distributed source of truth for ILP transactions, with all the advantages this entails over the use of "private" validators. Furthermore, in this scheme, XRP would be the native form of payment for access to this public validation service, which would give XRP a real use and would generate an organic demand, beyond the purely speculative demand. Could you clarify if this possibility is real, or am I totally wrong about this kind of use for XRP Ledger?

Share this post


Link to post
Share on other sites

Answering these two together:

21 hours ago, Hodor said:

Is there any plans in the works for a text-book like source to describe this process?

20 hours ago, Apollo said:

I am a long way from an expert on this and I may be missing something important here, but with that said... Publishing a standard, even where it is fundamentally arbitrary and subject to elective modification by the participants could lower the transaction costs of establishing ILP connections.

I agree with you. That said, both the published standard and the proprietary atomic variation are evolving, sometimes borrowing from each other and sometimes diverging. I suspect that we may one day publish a standard for the atomic one, but right now we have two different teams focusing on developing their Interledger variations for different use cases.

5 hours ago, xourexe said:

@mDuo13 I have always imagined that the XRP Ledger validators set could eventually act as a public and distributed source of truth for ILP transactions, with all the advantages this entails over the use of "private" validators. Furthermore, in this scheme, XRP would be the native form of payment for access to this public validation service, which would give XRP a real use and would generate an organic demand, beyond the purely speculative demand. Could you clarify if this possibility is real, or am I totally wrong about this kind of use for XRP Ledger?

You're spot-on. It's entirely possible (and maybe even a good idea) for some big groups of ILP transactions to choose the XRP Ledger as a source of truth for validation. That said, Universal Mode doesn't need validators and one of the great benefits of ILP is the whole idea of it working anywhere without having to rely on a particular source of truth, so I expect the slice of ILP transactions that would do this to be a substantial minority. In many cases, you want maximum privacy, you don't want to wait extra time for ledger confirmations (the XRP Ledger's 4-second confirmation times here are still way more than you need for some types of ILP transactions), or you may have other reasons for not doing so. But yes, I think it would be awesome, it would make sense, and it probably wouldn't even be that hard to set up. I know the Research Team also played around with an idea called "XRP Atomic Mode Auto-upgrading" or something like that (XAMA) where participants would recognize that their segment of a Universal-mode ILP payment could use the XRP Ledger for validation, and would do that so that the sub-section of the payment acted like an atomic-mode segment.

5 hours ago, Mercury said:

I guess those validators that act as a bridge between ILP and RCL would have to be notary?

I don't think I understand your question. For one thing, you don't need to "bridge" ILP and the XRP Ledger (formerly known as the RCL) because the XRP Ledger's Escrow feature gives native support for ILP. (PS: new doc page alert!)

23 hours ago, zerpdigger said:

Can you speak a little bit about how ILP/XRPL trustlines play into all of this? Thank you!

Good question! Trust lines are a really fascinating concept that really dig into the meaning of money itself. But if you ask our resident software engineer Bob Way, he'll say a "trust line" is just a really awkward term for an "account"—you know, a relationship between two parties where you have a balance, a transaction history, and some metadata.

The reason that the XRP Ledger has "trust lines" is that it provides an abstract way for parties to interact in any currency they want. Creating a trust line is sort of like opening an account directly with that person/entity. (The idea of who sets the limits feels "backwards" from what we're used to from banking, but that's mostly an artifact of who has the power to add money to the account.) If I owe my buddy 50 bucks, he puts it on my tab; now I have an "account" with him. And once you have an account, you can do net settlement. That is, if I cover him for $20, we can skip the effort of him pulling out a $20 bill, handing it to me, and me handing it back to cancel out $20 of my debt to him.

Interledger trust lines come from basically the idea that, hey, maybe if two parties want to interact with one another, they don't have to go through a central counterparty. And if they just open accounts with one another, they can do the accounting however they like, possibly using a really fast, really simple "ledger" that just records the balances between them and does net settlement automatically. And nobody but those two has to know about the transaction history in their accounts/trust lines with one another, so they get great privacy. The two have to trust each other, but they can set limits on their trust lines/accounts to indicate just how much they trust each other. And they can do Interledger payments between them, being part of bigger ILP payments, without needing to record all their individual transfers at the bank or on a public blockchain ledger or something.

 

Share this post


Link to post
Share on other sites

This whole way of doing business is truly fascinating. It bolsters my confidence in the company. I hope this gets adopted broadly and quickly - the global economy needs this kind of standard in place. Thanks for providing this detailed discussion.

Share this post


Link to post
Share on other sites
On 9/28/2017 at 5:32 PM, mDuo13 said:

This is no small amount of work, and the fact that the XRP Ledger closes 15,000+ times per day with most validators reaching the exact same conclusion over 90% of the time is pretty impressive

I would like to understand more about  what happens the 10% of the time or so that validators do not reach the same conclusion. Are these considered failures? If so, are they being addressed in any way? Is there a shortlist of possible reasons/causes and of modes in which these presumably undesirable  outcomes occur? Do you believe a higher 'consensus rate' would be preferred by customers, and that the current one may give them pause for thought instead and perhaps stand in the way of greater adoption, even if it is better than the legacy situation?  You mentioned the volume of XRP ledger closures per day. Do you think this is somehow correlated with the consensus percentage and would you expect the latter to be higher if the number of closures per day were lower? How are validators qualified as such, and is there a continuous assessment, a periodic one, or none to 'calibrate' their results? Again, when consensus is not reached, is it always/often/rarely the same validators? Are data being collected or logged to enable this sort of analysis?

Have I completely misunderstood what you said? If not, and you can point me to specific documentation as to process performance metrics, I would love to take a look. In any event, it is all quite interesting. Thank you for sharing!

Share this post


Link to post
Share on other sites
16 minutes ago, gomoku said:

I would like to understand more about  what happens the 10% of the time or so that validators do not reach the same conclusion. Are these considered failures? If so, are they being addressed in any way? Is there a shortlist of possible reasons/causes and of modes in which these presumably undesirable  outcomes occur? Do you believe a higher 'consensus rate' would be preferred by customers, and that the current one may give them pause for thought instead and perhaps stand in the way of greater adoption, even if it is better than the legacy situation?  You mentioned the volume of XRP ledger closures per day. Do you think this is somehow correlated with the consensus percentage and would you expect the latter to be higher if the number of closures per day were lower? How are validators qualified as such, and is there a continuous assessment, a periodic one, or none to 'calibrate' their results? Again, when consensus is not reached, is it always/often/rarely the same validators? Are data being collected or logged to enable this sort of analysis?

Have I completely misunderstood what you said? If not, and you can point me to specific documentation as to process performance metrics, I would love to take a look. In any event, it is all quite interesting. Thank you for sharing!

Watch this from 9:36 forward

Share this post


Link to post
Share on other sites

×