--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CAG4FKhwG9iDCT0oF4eTGe4OSc8jy_QVxBoXfvSbhXmiR10BA9g%40mail.gmail.com.
Hi Leigh,
1. This is an interesting question. I did consider mechanisms where the set of assets are derived from the transaction set. This approach doesn’t necessarily make it something that all validators decide on because, in practice, nominated values rarely get combined. This means that the transaction set nominated by the validator is likely to be chosen as is, and the validator can select whatever transaction set they want.
With that said, it’s still worth considering the merits of deriving the set of assets from the transaction set. This approach led me to some interesting challenges, but they might not be insurmountable. The main issue was that it’s not obvious to me how to actually construct the set of assets. Imagine a world with a few dominant assets (in the world of fiat currency this approximately translates to the basket of IMF special drawing rights currencies which are USD, EUR, CNY, JPY, and GBP). It is reasonable to guess that all of these assets would appear in SPEEDEX orders in every ledger. But these assets would also participate in liquidity pools for many other, less dominant assets. Those less dominant assets are less liquid, so we shouldn’t expect all of those assets to appear in SPEEDEX orders in every ledger (more generally, there will probably always be many more assets on the network than there is capacity for operations in a transaction set). So how do we choose among the less dominant assets? We can’t easily determine which ones will trade a lot, because doing so means computing the clearing prices for that larger set of assets… which is exactly what we are trying to avoid by limiting the set in the first place.
There might be reasonable heuristics for this problem. But it’s not obvious to me that a heuristic would consistently outperform a set of validators that are actually trying to steward the network.
2. I’ve given this some thought, but I don’t really have a particularly good answer at this point. I have already spoken to some people about this, and in general I’m very interested to hear what other people have to say on this topic.
My hope here is that validators would be open to adding high impact (in terms of value, utilization, or otherwise) assets regardless of region because it would support the network. If we find that there are more assets that validators want to include than the current implementation can support for performance reasons, then efforts can be made to optimize the implementation. It’s hard for me to predict whether this hope is reasonable or likely.
It’s also worth noting that other assets will still be just as usable on the network as they are today.
Thanks,
Jon
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CAG4FKhy45Enak%3DCdTMa2PLdZg20L3yeXN4H7OmGjhtVp1H%2BMHQ%40mail.gmail.com.
SpeedexConfigurationEntry
Need to expand on why it should be a ledger entry: until now, ledger wide settings are stored directly in the ledger header.
I think it's a combination of size and that it rarely changes, so storing it in the ledgerheader would be maybe wasteful.
If we think of this as a "ledger header extension", the ledger entry type that we're introducing should be aligned with that idea, and `SpeedexConfiguration` is just the first of its kind.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CAG4FKhyTajPDpHFih1YbTujL0QmLpCb25f9AaX2zEkbXdX9huw%40mail.gmail.com.
Interesting questions, as always.> Q: How can we expect validators to decide which asset to include in the set?
I think the answer to this question belongs in a SEP rather than a CAP, because the validators are in practice free to disregard the guidelines. With that said, let's focus on what those guidelines might actually be.
First, those guidelines probably should not be purely quantitative. There may be certain assets validators want to include as their presence may stimulate growth, stability, or development of the network. Perhaps there should be some small number of discretionary slots.
Second, what should the quantitative guidelines be. This is extremely tricky, because these may be both "gameable and transient" as noted in my previous correspondence. We can consider your proposal "total fees spent trading in the previous month" as an example. Right now, most operations execute at base fee. The highest fee bids we routinely see are about 100,000,000 stroops (10 lumens) which is 1,000,000 times the base fee. So a few trades executing at that fee bid would probably outweigh all other trading in the month. In other words, this proposal would mean that becoming a SPEEDEX asset could be bought for a few dollars or tens of dollars. This is not desirable. I'm very open to more proposals on quantitative guidelines, but I emphasize again that finding an approach that is hard to manipulate will likely be difficult.
> Q: How can users of the network know which assets are going to be usable in SPEEDEX for the upcoming ledger?
For the _next_ ledger, the SPEEDEX assets are exactly those SPEEDEX assets after upgrades were applied in the previous ledger. This is the case because upgrades are applied after transactions.
For ledgers beyond the next ledger, the SPEEDEX assets are approximately the current SPEEDEX assets. The maximum number of errors is linearly proportional to the number of ledgers in the future because the validators can only add and remove a single asset per ledger (multiple upgrades of the same type are invalid).
So Horizon can provide information about the present, and that information should be very helpful for the near future. The distant future, however, is almost impossible to predict.
The proposal you listed here about queuing up multiple upgrades is interesting. I could imagine this being useful in some scenarios, but it doesn't obviously solve any new problems with this proposal unless the validators actually engage in an externally governed, periodic update process. If validators are updated haphazardly, then I don't think this will help much. Regardless, it would be good for someone to write up a separate proposal about how this could work.
> Q: Should there be a way for some validators to "opt-out" of SPEEDEX governance?
This is an interesting question. In this context, "non-governing" basically means vote for any operations on the list of SPEEDEX assets that other validators vote for. This could be useful, although I'm not totally certain why a validator would choose to operate in this mode rather than the governing mode then just abstain. Do we have any evidence that validators on the network actually _want_ the non-governing behavior? If so, we should implement it. If not, we should hold off until it is desired.
> Should there be an explicit "maximum number of SPEEDEX assets" somewhere? Right now the CAP allows nodes to vote to add any number of assets in the set, and I *think* that this can result in a network to allow adding more assets than what any individual node would be configured for.
There could be such a limit, but I don't see much motivation for doing so. Given our lack of knowledge about future usage patterns, it is unlikely that we will set it just right. If we set the limit too low, then the network will have unused capacity until the next protocol upgrade. If we set the limit too high, then the limit will have no effect.
My general opinion is that the validators are responsible for the configuration of the network, and part of that responsibility is making sure that the network can handle the load permitted by that configuration. For example, the validators could just as well vote to raise the maximum transaction set size beyond what the network could handle but they do not. Given that history has shown the validators to be responsible, I'm not concerned that they will err here.