Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by JoelKatz

  1. On 10/3/2019 at 11:40 PM, NightJanitor said:

    Are you guys envisioning the "layers" as flat and on top of one another (stacked) or as spheroidal, with one roughly encapsulating the other?

    I tend to envision them as stacked, but you could envision them as one encapsulating the other.


    On 10/3/2019 at 11:40 PM, NightJanitor said:

    (Why only two?  Seems arbitrary.)

    Two gets you a lot of benefit without getting absurdly complex. The key is to get the benefits of a fast, light algorithm to advance the ledger while still preserving a level of decentralization you can only get with a heavier, slower algorithm. I actually do have a design for a three-layer algorithm, but that's another story.


    On 10/3/2019 at 11:40 PM, NightJanitor said:

    (How do they stay in timephase?)

    If nothing goes wrong, the inner algorithm keeps advancing the ledger with the outer algorithm making adjustments that take place at particular ledger sequence numbers. The more complex (and hopefully very rare) case is when the inner algorithm becomes so dysfunctional that it can't make legal forward progress, in which case the outer algorithm agrees to suspend the inner algorithm and then resume at a particular point with a particular new list of inner validators. It's a bit complex.


  2. On 10/2/2019 at 8:41 AM, DutchBeetle said:

    I am wondering if there is a possibility that this higher fee is more or less 'optional' and is only used in cases where the ledger really is that full with transactions that it is needed? Wouldn't it be great that the ledger is smart enough to recognize whether this 'higher than minimum fee' is actually needed? And when this fee is excessive an unnecessary the ledger chooses to only 'take out' the necessary minimum? 

    I've thought about schemes like this. The problem is that they really only work if everyone participates in fee discovery.

    For example, one simple scheme is to include transactions in ledgers with the same rules we currently use but to only charge the lowest of these two rates:

    1. The fee level an additional transaction would have had to pay to get included in the ledger.

    2. The lowest fee level paid by any transaction in the ledger.

    This scheme works very well when the ledger is not "full", since everyone pays the minimum, which is good. And it works well when the ledger is "full" but people really put the maximum they're willing to pay in their transactions and there's a mix of prices. But it fails in two important cases:

    1. It doesn't do a good job of accommodating people willing to wait until the next ledger. You either have to choose between being charged a lot to get in the current ledger when you didn't really care about that or potentially not getting in at all.

    2. It doesn't work well if everyone just uses the same fee and doesn't think through what they're really willing to pay. For example, imagine if the system is busy and all transactions come from the same wallet software that uses a default maximum fee of 0.001 XRP. Everyone will pay 0.001 XRP. But if the default had been 0.0001 XRP, that would have been what everyone would pay and the same transactions would execute.

    So I'm not sure that it would be a significant improvement.

  3. 2 hours ago, zerpdigger said:

    could XRPL itself somehow be harnessed to get consensus on (price) data-sets similar to the way it processes/validates transactions ? 

    Yes, at least for prices of major currencies. The downside of this is that it would require validators to get a price feed from somewhere. We could use a system similar to what we use for fees where validators advertise in their validations what prices they want and then validators can combine information from other validators they trust to propose setting particular prices. The problem with this is that it will then be very hard to know where the prices are really coming from and validators might not use very high quality price sources because it takes effort on their part to do so.

    But we could add support to determine some prices by consensus and a stablecoin could be configured to use the consensus price. Then validator operators would have to choose to obtain prices from some source and vote them into the ledger.

    I'm not convinced this is worth doing, but others might disagree.

  4. 3 hours ago, tulo said:

    I really don't like the fact that the operator has to provide the price feed. And that if the price feed is not provided the redeem process stops.

    Imagine a bad gateway that closes the business (it already happened multiple times). If the coins were really pegged the users could always redeem the IOU for XRP. In this way the gateway can run away and don't pay it's debt. In every moment the operator can make the currency not "pegged" so it loses the only utility.

    Definitely not interested in this feature.

    Ideally, the operator would lock the price at some final value so that redemption could continue, though the asset would no longer be pegged to anything but the price of XRP itself. But there is always the possibility that the operator would stop providing a price feed.

    Note that while issuing and redemption would cease, the stablecoin could still be transferred and could be traded on the on-ledger decentralized exchange. People who had XRP locked up would still want the stablecoin and could place offers to buy it. So it's possible for the system to engage in an orderly wind down even if the price feed stops.

    A malicious price feed, however, would be a different story.

  5. 47 minutes ago, mrak said:

    So what is the status on coding this up and testing? Is this simply a proposal, or is it something we can expect to go live in 6 months?

    Just a proposal at this point. The design is more or less complete and it's definitely complete enough that people can decide whether it's something they'd be interested in participating in. As I said in the response above, if nobody is willing to provide price feeds and operate a stablecoin, there's probably not much point in continuing to implement it. I'm trying to make sure that there's enough information about the implementation out there that people can make an informed decision of whether they'd use this functionality.

  6. 1 minute ago, yxxyun said:

    The operator create the stablecoin, the issuer is create a position to issue the stablecoin, so a collateralized stablecoin will have multi issuer, is the trustline to operator or to the issuer?

    I may not have been consistent in my terminology. The operator creates the stablecoin, provides the price feed, and the trust line would be to their account. Anyone can issue the stablecoin by performing an issue operation on a position with sufficient collateral, but from the ledger's point of view, they're causing the issuer to issue the stablecoin to them. Though anyone can cause the stablecoin to issue, all the trustlines would be to the operator and all stablecoin balances in the same system are equivalent regardless of what position they came from.

  7. 20 minutes ago, yxxyun said:

    Did I need create trustline first to hold collateralized stablecoin?

    There are four ways you could wind up holding some of a stablecoin:

    • You could create a trustline indicating that you are willing to hold the stablecoin and then someone could pay it to you.
    • You could create a trustline indicating that you are willing to hold the stablecoin and then make a payment to yourself denominated in the same currency as the stablecoin.
    • You could place an offer to acquire the stablecoin and then someone could take that offer. You do not need to create a trustline in this case.
    • You could lock up some XRP and issue the stablecoin. You do not need to create a trustline in this case.

    Notice that in all four cases you have to do something to explicitly indicate your willingness to hold/accept the stablecoin. In two of the cases, it's creating a trust line.

  8. On 10/3/2019 at 9:01 AM, MikeH said:

    1.  How will your stablecoin implementation be superior to the MakerDAO / DAI setup which is what I thought of first when I read your proposal?  They have VERY HIGH fees and we need to make sure XRP stablecoins avoid that same fate.

    It has several significant advantages over the DAI setup but one significant disadvantage.

    One key advantage it has over DAI is that any stablecoin issued by this system is guaranteed (assuming the system as a whole doesn't collapse) to be liquid to XRP at face value at all times the system operator has provided a current price. So you can safely use "niche" stablecoins pegged to a large number of different things such as stock or precious metal prices.

    Another advantage is that the only system fee is a fixed cost when XRP is locked as collateral. This can be set by the system operator and we expect it to be around 0.1% -- there are no fees that must be paid to redeem or close positions. The peg is held by the redemption and margin call logic, not by any attempts to control supply.

    The significant disadvantage it has is that a person who holds a position may be redeemed against because the token is liquid. So if you lock up XRP and issue a stablecoin, you may later find that some of your XRP was taken. Your position holds the same total value, but you lose leverage. This is done to the least-collateralized positions first, so you can reduce this risk by overcollateralizing. But avoiding losing leverage by having less leverage in the first place is not really a perfect solution.


  9. 2 hours ago, EMacBrough said:

    Unless I missed some new developments with the idea, it's not true that the network continues if at least one network functions. To ensure consistency between two different transaction networks, transactions need to be "accepted" by the governance network, which implies that the governance network needs to be live to ensure transactions can be validated. The transaction network also of course needs to be live, but it can be replaced if it goes down, so forward progress is roughly ensured if and only if the governance layer is live.

    Thanks for responding.

    If the governance layer approves a list of validators for the inner layer, those validators agree on something, and that something complies with system rules, I don't see any problem with accepting that without waiting for the governance layer to specifically accept those ledgers or transactions. What would stop it from accepting them?

    Byzantine accountability can be handled with a delay. I'm not particularly worried about concurrent attacks on both the network topology and a significant number of validators because I don't think those kinds of attacks are realistic.

    The inner layer could temporarily censor. But if the outer layer is working, that wouldn't last very long. And if the outer layer isn't working, I'd rather have a temporarily censoring network than a temporarily stalled one.

  10. It can sometimes be difficult to choose the right fee to pay for an XRP Ledger transaction. A common approach is to pick a value known to be large enough, such as .0001 XRP, and just using that all the time.

    We propose adding code to the server to keep track of when a transaction is first observed and what fee level it chose to pay. Then, when the transaction is seen in a fully-validated ledger, the server can update its statistics for transactions at that fee level. Thus the server could report, at any time, the fraction of successful transactions and the average confirmation time for various fee levels.

    In addition to being useful for choosing the fees to pay for a transaction, this would also gather interesting statistical information.

    This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:

    You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 

  11. The XRP Ledger has both statistics reporting and logging by category and severity. However, it has been neglected for some time. The statistics reporting could use a refresh to ensure that it is capturing parameters that are useful and valuable and to add monitoring of newer features that were added without such reporting. The logging needs a thorough audit to ensure that priorities are set appropriately and overly-chatty logging is disabled by default.

    This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:

    You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 

  12. Every XRP Ledger servers has a database called the “node db” that holds all the ledger entries in the current ledger and that the server has chosen to retain as history. Even if you have a cluster of servers, each one has its own node database. If a server loses sync, it cannot keep populating the node database and has to fix what it missed as and after it catches up.

    We propose implementing a network protocol for access to a node database. This would permit servers to share a node database. This will conserve disk space, conserve memory, and allow a server that loses sync to obtain the data it missed locally if another server that stayed in sync populated the database for it.

    This is a bit more complex than it might appear because the software is very sensitive to latency in accessing the node database. This means that sophisticated caching and prediction is needed on both sides. For example, if the software fetches an inner ledger node, the database should probably push all the direct children of that ledger node to the server’s cache to avoid an additional round trip.

    XRP Ledger nodes do not need to trust their node store because they only query by hash. It is not possible for a node store to convince a server to rely on incorrect information. This means that the XRP Ledger software could be enhanced to use a variety of methods to obtain ledger data to reduce local storage requirements and improve synchronization performance.

    This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:

    You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 

  13. The XRP Ledger currently uses flooding to propagate transactions, proposals, and validations. This means a typical server either receives, transmits, or both every one of these objects over every connection that it has. This has a large number of disadvantages:

    • Adding additional server connections means a significant increase in bandwidth consumption.
    • Lots of messages are relayed unnecessarily costing both CPU and bandwidth on both sides.
    • The network diameter is larger than it needs to be.
    • Link latency is higher than it needs to be, making it harder for a server that has lost sync to catch up.

    We propose a system of slots and “squelches”. Each server would create a “slot” for each validator it chose to relay. Each slot would have a list of uplinks and downlinks. When a server receives a proposal or validation message, it would check the “slot” for the validator that originated it. If it had already received enough copies of that message, it would send a “squelch” to the sender of that message which would suppress further messages from that source being sent to it over this connection. When a server gets a “squelch” it would add the sender to its list of non-downlinks for the corresponding slot.

    This would allow each server to maintain a set of three uplinks for each slot. If a server lost an uplink, it could send an “unsquelch” to each server to recover its uplink. Squelches would be time limited to allow for network topology changes.

    This approach requires some tweaks for transaction. Every validation from the same validator comes from the same source and so can follow the same tree to spread over the network. But transactions can originate anywhere. To handle transactions, they can simply be relayed both up and down the tree. So while validations and proposals would only be sent to your downlinks, transactions would be sent to both uplinks and downlinks.

    This change will allow servers to have more connections, reducing network diameter. CPU and bandwidth costs would be reduced and link latency would be significantly improved.

    This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:

    You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 

  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.