How do we address small ledgers/currencies? #132
Comments
|
I used to think that the issue of custom currencies would be addressed by TRTs (#77). One change I'd make to TRTs right now is to take out the curve. It's simpler and probably totally fine in practice just to recurse quoting all the way to the last connector. That said, due to quote recursion, there is an even simpler way to accommodate custom currencies which doesn't even require us to add any extra features (like TRTs). Key idea: The number of tier 1 systems doesn't necessarily have to be limited. In the IP world, it's limited more because of the size of IP address space than because of the size of routing tables. Prefixes pretty much allow you to have an arbitrary number of tier 1s as long as they share some prefix. Right now, we use ledger prefixes like In this scenario, I wouldn't face a trust issue because I can set up my peering relationship with This does lead to a bit more rigid routing structure, but I think that's fine. We can come up with more and more efficient routing in the future, securely detect shortcuts, etc. But for an MVP, we can live without that.
I don't see the rationale for adding a layer of indirection - ILP addresses are already schema-less, so if you wanted to come up with some class of address that has special meaning, just choose a prefix, e.g. (You can make an argument for saying that ILP addresses should just be URIs so that the identifiers inside and outside ILP are the same. But imo there is a very strong counter argument in that URIs aren't designed to be "liquidity-local" identifiers, i.e. ledgers with common liquidity wouldn't have much of a tendency to have common prefixes. So it wouldn't work nearly as well as a purpose-built address space.) Some assumptions I'm making:
|
|
I think that the separation between the "routing prefix" and the "ledger address" that you propose addresses my concern about being able to route to lesser-known ledgers. Am I right in thinking that the idea behind separating the technical specification of the address / protocol from the recommended connector behavior and address selection methods is to provide flexibility to change the connector behavior and address selection later? That might be a good idea but I will say that it makes understanding this standard more complicated. It also means that you can't assume that much about the layout of ledgers and accounts from looking at an address, because different parts are mixed together. Also, if all connectors end up being implemented with whatever behavior we say is the "norm" at the start, will there really be that much flexibility to change it later? Just to make sure we are on the same page, this is my understanding of the current addressing scheme: Technical Specification: Recommended Connector Behavior (Initially) Connectors should keep routing tables that store: 1) ILP address prefixes (e.g. To handle a quote request (e.g. that comes in on ledger
To handle a payment (e.g. sending
Recommended Address Selection Method (Initally) 1-4 apply to ledger addresses. 5-7 apply to accounts and subledgers.
For the record, here are some of my key ideas on this topic:
|
|
A few questions/comments:
(An additional note: We should really have some terminology for the "anatomy" of an ILP address, e.g. the routing prefix, the ledger prefix, the part between those two, and the sub-account stuff afterwards, the portion of the address where delivery occurs, etc.) |
|
I really like the recommendation of putting everything in the routing table 👍 (1+2)
I think trying to figure out someone else's address without asking them is always a bad idea. Even for non-interactive protocols you should probably have some communication (or out of band address discovery) before you start shooting payments off into the blue.
I don't see the purpose in this. Does anyone aside from the person setting up the ledger/address care about what that's called?
I don't see why not. You could set it up however you want.
This would mean that those advertising that they are connectors to
If routes are short-lived and addresses are thought of as temporary, you could wait until you really need this structure before setting it up. You could always probably add segments to your address later.
How about:
Note that all prefixes should end with |
|
For 3, I'm referring to the receiver not knowing their own address. If the receiver is running some software that takes the receiver's ILP address and appends subledger info (like the ILP receiver's payment identifier), the receiver's own software would have to look up the sub-account separator from the receiver's ledger metadata (that's a new field we'd need in there). If almost all ledgers used |
|
Note that the sub-account separator would be decided by the ledger plugin so that could just be a constant exported by the plugin. That said, I wouldn't mind making the |
|
Agreed. I think that even if it's a constant, it's a little strange, and mixing separators in an ILP address doesn't seem to have any benefit. |
Yes, certainly - the routing protocols used on the internet went through several iteration and continue to evolve today. There are some simple things where we can (and must) make decisions that will be difficult to change. For instance, the way that routing tables and quoting work. Even the smallest connector will have to have a routing table (think of your router at home which pretty much just contains a local route for your local network and a default route using your ISP as a gateway - but that's still a little routing table) and will have to quote. In other words, those functions will be everywhere and very sticky over time. Fortunately, they are also pretty simple. Our current implementation is already more or less correct, which some minor tweaks and syntactic improvements. However, how those routing tables get populated can get very, very complex. @momerath42 and I have more or less abandoned least-cost routing in favor of a mixed cost metric biased towards shorter routes instead of cheaper routes. Cheap, but long routes are hard to trust and converge slowly. HLP (a BGP successor proposed in a 2005 paper) actually sets a hard limit (4) on the maximum number of peer-to-peer routing hops for this very reason. Notably, they looked at real Internet routes and found that the number of peering hops is at most 2 for 99% of routes and <= 1 for 90% of routes. (A peering link would be any tier-1 to tier-1 connection, not counting any hops to get to tier-1.) On the Internet, routing protocols are still rapidly evolving and policies and practices are changing constantly. Our work on ILP interdomain routing so far is suggesting that it will be an ongoing effort for us as well.
Totally agree - I wasn't seriously suggesting that people should use different separators. Obviously, we should pick a separator and stick with it. I use the separator example when I'm explaining prefix routing, because in that context it's important to understand that the separator doesn't matter. You could have any separator or none at all, prefix routing tables still work. But this illustrative example took on somewhat of a life of its own. :)
That's because you're looking at it from your perspective instead of the users'. You're trying to understand the whole thing, so it seems easier to explain it all in one go. But in practice, the vast majority of ILP users will understand (and care about) only a tiny fraction of how ILP works. In particular, most won't know or care about how ILP addresses are chosen or how inter-domain routing works. How much did you know or care about BGP before you started working on ILP? Sure, to really understand all of ILP, I need to learn everything, but when writing our most fundamental standards documents, we should think about how we can abstract away advanced topics that the average user doesn't need to know - like how ILP addresses are assigned and how routing tables are populated. That should be in an RFC somewhere, but it shouldn't be in the ILP RFC any more than the IP Allocation Guidelines (RFC 1466) should have been part of the Internet Protocol (RFC 791) The other issue is that many of these advanced topics won't have a single answer across the whole system. Different protocols may be in use in different places and certainly different procedures. So we should think about which topics that applies to and exclude those topics from the more general specs.
Agreed, unless... ...maybe we can still get rid of the need for that segment. <crazy-theory-time> Suppose my ledger is What if we add a This does require that the last connector before reaching The only case where this breaks is if this payment is coming in from another connector on Initially, this idea seemed a very theoretical exercise. But it's actually making more and more sense... Getting rid of </crazy-theory-time>
Here's my suggestion:
So, the minimal address would be
|
|
👍 about separating the technical addressing standard from the convention, and about having the convention specify the period as the separator.
The perspective I'm trying to adopt is that of the developer who wants to wrap their head around what ILP is to determine whether they think it is a good idea and something they want to support or work on. I know that most users won't understand all the details, but I'd like to limit the number of places we give hand-wavey "it's complicated but you don't need to understand the details" explanations.
"Do not try and understand the Interledger. That's impossible. Instead... only try to realize the truth."
This might work for quotes, but how would you handle the actual payments? The delivery feature would mean you would try to deliver the final amount if your ledger prefix matches.
Isn't a subledger the same as an account group?
There's an argument to be made that these should go into protocol-specific headers rather than into the ILP address. In some protocols you might want to encrypt those details, and they only matter to the end applications anyway. |
|
The address convention could also include a version at the beginning. This would even be backwards compatible if the connectors that had updated were connected to one another, because the version would be part of the prefix and even connectors using the older scheme would properly forward packets to the updated ones. |
My argument against that is that the address should specify the ultimate destination and the transaction ID is a part of that. In TCP/IP ports are separate, but that distinction is really coming apart at the seams:
Having them handled separately does make one thing easier: If you have somebody's HTTP server and you want their FTP server, you can just change out the port. However, that is actually an anti-pattern: What if my FTP server is actually running on a different host? Rather than trying to make guesses at the low level, you should use a higher level mapping service like DNS to discover the true host and port values.
A subledger is a different physical system, e.g. a separate database on a separate hard drive. An account group is just a logical grouping of accounts within one physical ledger. At least that's what I'm proposing it could be.
No, you'd only deliver the final amount if the route was local. This route wouldn't be local, you would have received it from another connector. As a reminder: To determine how much money to forward, connectors could just use their internal rate. If they want to optimize their revenue and/or success rate beyond that, they can use cached quoting information, request a new quote or use other metrics to estimate whether they can get away with a bigger cut.
Good idea! Rather than having one global version I'd suggest that we just define the first thing in the address to be the address allocation scheme used, e.g. So, updating my example from earlier:
Here's my suggestion:
So, the minimal address would be
|
Good points, 👍
I don't think the address scheme necessarily says anything about whether components are running on one system or multiple. You could one machine running multiple logical ILP ledgers with different currencies or multiple machines hosting subledgers. I think what differentiates a subledger is that it breaks out the balance of a single account into some groups, all denoted in the same currency. I don't think we should distinguish between subledgers and account groups, because a ledger is just a group of accounts. We do need to distinguish between a ledger and a subledger, because this tells you something about the asset type.
👍
I think that makes sense, but I don't think I'll feel completely confident I'm on the same page until we agree on a full, step-by-step write-up like what I started above.
Does the subledger follow the account or is the account referencing an account on the subsubledger? Your suggestion seems to switch between the two. Is it |
|
I haven't read the whole discussion yet, but to answer the initial problem statement:
A connector could specialize in routing to small ledgers/currencies. Other connectors could have it as a low-priority catch-all for the empty prefix. This "connector for the unroutables" could advertise with "Having trouble being discovered? Announce yourself through us!" And once they become famous for having a huge routing table and delivering even to the most remote ledger, more and more other connectors could use it as a last resort when all other (cheaper/faster) routes fail. |
|
Responding to @sharafian's example: That strikes me as pretty ugly and the whole Connectors should accept route advertisements from Ledger should allow broadcasting a message (such as a route broadcast) to all users on the ledger who are listening to such global broadcasts. Both features carry DoS potential which could be mitigated using micropayments. What this does is make it very easy to create subledgers with other currencies. Say I'm This is safe, because you still can't send bogus routes like a full-on trusted peer can. Route broadcasts are local messages and ledger messages are authenticated, so when someone sees that Note that the broadcast feature would be ledger-local. Some ledgers may not (be able to) support it and that's fine. They can still use the And we wouldn't need addresses where every other segment is |
|
@justmoon I think that only applies to the subledger case, but not the 'addressing a small ledger in terms of a larger ledger' use case, which I think is going to be just as important. |
|
whoops |
I'm not talking about subledgers - I'm talking about ledgers with different currencies. |
|
Sorry, by subledger I meant a ledger that's addressed in terms of an account |
|
I'm still struggling to understand this. Does this make sense? Suppose The owner of Let's assume that Waygate is an exchange that happens to deal in a rare coin called Zerp, among other currencies; If this is in fact the scenario from #132, there are a couple clarifications that I think are in order:
|
Technically the receiver (or the server acting on their behalf) is the one that decides what address to advertise. They can get the address from their ledger plugin, which can get it from the ledger, have it hardcoded (e.g. in the case of Bitcoin), or something else. You would want to broadcast whatever address is most easily discovered by others.
It would not be a good idea to address your ledger in terms of a connector that won't rebroadcast your routes, unless quote requests always end up being relayed across the whole chain. In that case, as long as the quote request gets to you it would be okay.
This is definitely possible. We just haven't built such a protocol yet. We did decide though that the lowest level protocols should not support multihoming, because that makes them much more complicated. If a higher level protocol wanted to let you express multiple addresses for the same account and let the sender choose which one to use, that would be totally fine.
It doesn't guarantee it but it's quite likely. If the smaller connectors are peered with other connectors they could broadcast shortcut routes that go through them, which their peers could choose to honor. If you address yourself in terms of a larger ledger though, I think you're probably going to assume that most payments will be routed through that path and you're okay with that.
Right now the ILP client includes a Receiver ID in the address that has the Transport Protocol it's using and a random unlikely to collide with other receivers (e.g. |
|
Addressed by #154 |
Given our hierarchical address format and the assumption that the "Tier 1" connectors will need to limit the sizes of their routing tables, how are we going to address small ledgers or currencies?
If the small ledger uses the same currency as a larger one, this might be covered by the "subledger" concept (plus maybe some amount of source routing tags if there are fees collected in between the larger ledger and the small one).
What I don't see is how you make local currencies or ledgers discoverable using the current approach. If the Tier 1 connectors don't store routes to these smaller ledgers, it seems like that group could intentionally or unintentionally exclude smaller players.
This makes me wonder whether we should take some inspiration from IPFS'
multiaddrconcept.The text was updated successfully, but these errors were encountered: