Jump to content

JoelKatz

Ripple Employee
  • Content Count

    883
  • Joined

  • Last visited

  • Days Won

    82

Everything posted by JoelKatz

  1. I tend to envision them as stacked, but you could envision them as one encapsulating the other. 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. If nothing goes wrong, the inner algorithm keeps advancing the ledger with the outer algorithm making adjustments that take place at particular l
  2. 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 i
  3. 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
  4. 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
  5. 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. It solves a few different problems. On the side of the people locking up XRP, it allows them to borrow against their XRP at zero interest while retaining full exposure to the price changes in XRP. I can also be used to obtain a leveraged long position in XRP entirely on the ledger. On the side of the people using the stablecoins, it allows them to transact as if they had XRP while being able to get whatever price exposure they want rather than only and exactly what XRP has. The most obvious case is to hold a stablecoin denominated in a currency like USD that has a relatively stable v
  7. 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.
  8. 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
  9. I made a video giving more details on the proposed design.
  10. 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 operat
  11. 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 real
  12. The advantage is that if you hold XRP directly, the value of what you hold changes over time. Some people want that, some people don't. This scheme lets those that want that hold XRP and those that don't can hold the stablecoin. Those that choose to hold the stablecoin have the equivalent of on-ledger XRP that is denominated in dollars, or whatever other peg they like. Someone creates a stablecoin pegged to some asset. The creator provides the price feed and governance. Then anyone who wants to can lock up XRP and issue the stablecoin. Holders of the stablecoin can redeem agains
  13. Light accounts would allow a limited account to be created without having to pay the 20 XRP reserve. Instead, a 5 XRP reserve would be paid. Light accounts would be limited in their function but they could certainly hold, receive, and send XRP. There are some options around what features a light account would be permitted to access. Light accounts could be permitted to have a single multisigner list or they could be permitted to have a small number of payment channels or escrows. Likely they would not be permitted to have any trust lines or offers. This post is one suggestion for an
  14. The 20 XRP reserve requirement has proved to be a bit of an obstacle to some use cases for the ledger. This proposal would provide a path to delete existing accounts, recovering all but one incremental reserve (currently 5 XRP). This would also allow owners of unwanted accounts to clean them up and recover approximately 15 XRP in the process. There is a judgment call involving what to permit an account to have and still be deleted. In principle, you could allow an account to be deleted regardless of what ledger objects it owned and clean up any problems after the fact. For example, if cod
  15. Most public ledgers provide no way to refuse an unwanted incoming payment. While most people would be perfectly happy to receive an unexpected, possibly misdirected, payment, it can create a real problem for some users. Regulatory requirements may make returning the payment difficult but they may also make keeping the payment difficult. We propose adding a feature to allow recipients to actively accept payments. We dubbed the feature “checks” internally. A sender can, instead of making a payment, create a check payable to a recipient. The recipient would have to actively claim the check.
  16. Some enhancements could be made to the XRP Ledger to provide better support for emerging use cases in decentralized finance. For example, validations could be augmented to include the last fully-validated ledger. This would permit validators to automatically operate as oracles and allow, for example, users to prove to Ethereum smart contracts that particular things happened on the XRP Ledger. This post is one suggestion for an enhancement to the XRP Ledger. See this post for context: https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/ You can find all the sug
  17. One of the original use cases for the XRP Ledger (since 2012) was using the built-in decentralized exchange to exchange between stablecoins and to exchange stablecoins for XRP. Currently, only stablecoins that have a backer/issuer are supported. We propose adding a collateralized stablecoin feature to the XRP Ledger. The key distinguishing property of this proposal is that the stablecoin is always redeemable for XRP on the ledger from the collateral pool. So, for example, if you hold one unit of a USD stablecoin, you can make on-ledger payments at any time just as if you held $1 worth of
  18. 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 va
  19. 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: https://www.xrpchat.com/topic/33070-suggesti
  20. 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 d
  21. 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 ha
  22. The XRP Ledger software does use quite a bit of memory. This is especially a problem on virtual machines where memory has a significant cost premium. Reducing the memory consumption would reduce the cost to run the software and improve decentralization indirectly. Unfortunately, we do not precisely understand how the memory is being used. An important first step would be to analyze the software’s memory consumption to see what areas of improvement would be likely to produce the most dramatic results. On the bright side, because this hasn’t been well-studied, it’s possible that there’s som
  23. Today, the network uses a single consensus process to both make forward progress from ledger to ledger and to coordinate network rule and fee changes. Because the consensus process provides a high degree of decentralization, it has some trade-offs in performance, traffic levels, and the number of validators that can be tolerated. We propose to switch to two separate consensus layers. One would exclusively advance the ledger. The other would handle fee changes, coordinate rules changes, and manage the participants in the first layer. With this design, a small set of validators selecte
  24. By deliberate design, the XRP Ledger prefers safety over liveness. When it is unclear whether safe operation is possible, the XRP Ledger does not operate. Fortunately, the circumstances under which safe operation are not possible have never happened in the production network and the greater reliability and peace of mind has proven to be at minimal cost. However, this does mean that the number of validators that must fail for the network to stop making forward progress can be fairly low. This requires people to set a high bar for validators they choose to listen to. But keeping the bar hig
  25. Currently, when a server loses sync with the network, it has to simultaneously try to re-synchronize with the network and fetch all the ledgers it missed. The current design requires the server to first synchronize with the network and then work backwards to fetch what it missed but then work forwards to rebuild any missing intermediary ledgers. We propose that the design be changed to support a fetch operation that fetches a ledger’s header and all the transactions in the ledger in order. This will allow a server to play forward from the preceding ledger to the queried ledger with minima
×
×
  • 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.