rippled
rippled copied to clipboard
XRPLF
URI of list publisher wrong
The command rippled validators reports the "uri" as the peer from which it received the UNL over the network. The "uri" should always be that of the list provider, and if we want to report where the server got it from that should be a separate field.
example:
],
"pubkey_publisher" : "ED45D1840EE724BE327ABE9146503D5848EFD5F38B6D5FEDE71E80ACCE5E6E738B",
"seq" : 2021100701,
"uri" : "[::ffff:116.202.148.26]:56500",
"version" : 2
},
The "uri" value should be "https://vl.xrplf.org"
This was an intentional design decision.
The reasoning is that rippled doesn't actually know which list or lists to expect from each site. This is why [validator_list_sites] and [validator_list_keys] are separate stanzas. It's only after rippled downloads, for example, XRPLF's VL from XRPLF's server that XRPLF's server URL is associated with that VL in the uri field.
Thus, when a properly signed and updated VL is received from a peer on the network, that peer is effectively a canonical source. It's pretty unlikely because of runtime startup order, but depending on timing, rippled may never actually download the VL from the configured site.
All that said, this obviously isn't written in stone. Adding a field, and populating it depending on where the relevant function is called from can be done - if it's worth it. The only real risk is that uri could potentially be empty, which may cause confusion, so we'd have to be clear that this scenario is ok and normal.
It might be a good idea to expand the valid fields in a UNL to include an "authoritative URL" for a given list.
How about we create a new separate field for this? src or url seems like a great fit (src > url).
],
"pubkey_publisher" : "ED45D1840EE724BE327ABE9146503D5848EFD5F38B6D5FEDE71E80ACCE5E6E738B",
"seq" : 2021100701,
"uri" : "[::ffff:116.202.148.26]:56500",
"src" : "https://vl.xrplf.org",
"version" : 2
},
How about replacing the uri field with source_peer and source_url. The source_peer field would reference the peer that first provided the list, and the source_url field would be filled if the list had ever been downloaded.
edit: source_peer should reference the first peer rather than the most recent that provided the UNL.
@undertome I'd go with uri and url, validator maintainers can google up these terms if they don't know what they mean, source_peer and source_url are not easily searchable, I suppose it's not regularly used.
Oh, I thought you had a problem with the logic itself. I think the names are fine - the only difference between our name suggestions is that I'm using the term peer rather than uri which I'd say is an improvement since the term peer is used frequently in code and in the documentation. Googling uri doesn't make it clear that in this case we're referring to a peer since uri is an extremely broad term, which actually includes things like urls. Furthermore, anyone familiar with rippled should know what these terms mean, but for those who aren't, in addition to the code changes we would provide documentation for the new fields (hence the labels). As it stands, the field uri is not documented on xrpl.org.
How about replacing the
urifield withsource_peerandsource_url. Thesource_peerfield would reference the peer that first provided the list, and thesource_urlfield would be filled if the list had ever been downloaded.
@alloynetworks @WietseWind What do you think of this proposal?
