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 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. 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. 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. 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. 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 value because your use case isn't compatible with exposure to wide price changes. But there are also interesting cases where you want exposure to things like precious metals or stocks. It's a generic way to hold assets on the XRP Ledger that provide exposure to the price variability of other asset classes with minimal reliance on a counter-party. On the side of people who work on the XRP Ledger and want it to be awesome and able to solve real-world problems, all of these stablecoins are automatically liquid to XRP because of the redemption system. So if you make some asset liquid from XRP, it is liquid from every stablecoin. This really furthers the vision of XRP as a central liquidity pool for a variety of assets and payments. This is just a proposal. I like it a lot technically. It really feels to me like a beautiful system. But I'm not completely convinced that the benefits will outweigh the costs and risks. If you're one of those people who would love to see more on-ledger liquidity and more use of the on-ledger decentralized exchange, issued assets, or even community credit, I think this would be a huge step in that direction. Of course, someone has to actually use it for it to matter and it requires someone (or some coalition) to provide useful, reliable price feeds. A great next step would be for a few entities to step forward and express interest in operating stablecoins on the ledger.
  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 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.
  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 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.
  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 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.
  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 against the collateral. As the price changes, holders of the stablecoin have claims to changing amounts of XRP to keep the value of the stablecoin constant. Holders of XRP collateral have the value of the collateral change. Say you have $100 worth of XRP and you really want to be long XRP. With this scheme, you could lock that $100 worth of XRP up as collateral and issue $50 worth of a USD stablecoin. You could then trade that for XRP and have $150 worth of XRP locked up as collateral. You now have a leveraged long position in XRP.
  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 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 suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ
  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 code later encountered an order, trust line, or escrow for a non-existent account, it would simply handle it appropriately at that time. Orders, for example, would be deleted when discovered to be orphaned. However, that’s probably not optimal. It’s probably sensible to require that some amount of cleanup be done prior to allowing an account to be deleted. In addition, all code that looks up accounts for trust lines, offers, escrows, and the like must be carefully audited to ensure it sanely handles a non-existent account. Due to the severe harm aberrant behavior could cause to those relying on the ledger, this audit is essential even if the implementation intent is that an account cannot be deleted while those objects exist. There is a standard draft for this suggestion: https://github.com/xrp-community/standards-drafts/issues/8 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 suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ
  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. Users who do not want to receive unrequested payments could set their account to only accept checks. They could then simply not accept any unwanted payments. A whitelist of accounts permitted to send directly could be offered. Checks can also be used if the sender is not positive that the receiver still has access to the account. If the check is not cashed within some time period, the sender can cancel it and ensure the funds do not leave their account in the future. 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 suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ
  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 suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ
  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 XRP. We propose a scheme as follows: Anyone may place XRP into a position that they own. If the position is sufficiently collateralized, it may issue a stablecoin. Position owners may adjust the XRP in their positions so long as it maintains sufficient collateral. Position owners may issue and redeem stablecoins in their positions so long as it maintains sufficient collateral. Severely undercollateralized positions may be taken over by re-collateralizing them -- whoever does so keeps the remaining excess collateral. An order book mechanism will be used to permit the stablecoin to be automatically exchanged for XRP by redeeming against the least collateralized positions first. This encourages over-collateralization and cleans up positions that are in danger of becoming under-collateralized Pathfinding will be augmented to use redemption against the collateral so payments with a stablecoin work the same as if you held the corresponding amount of XRP. The scheme is not perfectly decentralized because some organization or federation still must supply the price the asset is pegged to on a continuous basis or the stablecoin will freeze. That organization can set a reserve ratio that they can use to tax the stablecoin system or to provide a reserve to buy out under-collateralized positions. The most obvious application is a stablecoin pegged to a fiat asset such as the dollar. However, stablecoins can also be pegged to the value of precious metals, stocks, indexes, and so on. 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 suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ
  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 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: https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/ You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ
  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-suggestions-for-xrp-ledger-enhancements/ You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ
  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 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: https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/ You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ
  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 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: https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/ You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ
  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 some low-hanging fruit where small efforts could bring large payoffs. The software does do a lot of caching. For example, some data is cached both in raw binary form (typically as SHAMapEntry objects) and in object form (typically as an STObject). It may be sufficient to cache only in binary form and convert to object form as needed. In addition, the SHAMap design pegs lots of SHAMapEntry objects into memory. This design could be changed to only keep SHAMapEntry objects in the cache and fetch them from disk as needed. Code changes would be needed to prevent SHAMap’s from keeping too many strong pointers to SHAMapEntry objects. 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 suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ
  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 selected by the larger set of validators would ensure the network makes reliable forward progress and does not engage in censorship. The larger set of validators would police the smaller set to ensure they are in fact making progress and are not censoring. Any validators in the small set that are not behaving would be voted out by the large set. This design has a number of advantages. The network can continue to make forward progress so long as either consensus layer is working. The set of validators preserving decentralization can be made larger without increasing the amount of work that must be done to generate each new ledger. Poorly-performing validators can continue to help keep the ledger decentralized without slowing down the advancing of the ledger. Validators engaging in censorship or poor service could not affect the advancing of the ledger as they would be voted out by the larger set. 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 suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ
  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 high prevents new, less well-funded participants or participants less committed to rapid response to failures and downtime from running validators as the set of candidate validators shrinks to those who are well-funded or committed to rapid response. We propose a design change to improve the network’s reliability in the face of failed validators. This change also eases the trade-off of wanting diverse validators but having to insist on very high quality and response readiness to avoid the risk of a network halt. The idea is as follows: In the ledger would be a list of validators that are believed to be unreliable at the moment. That list would be maintained by the validators using the same mechanism they use to maintain the network fees and amendments. If a validator is in that list, it would still participate in consensus in precisely the same way. The list would have no effect on the consensus process whatsoever. The decision when to consider a ledger fully validated would be adjusted so that servers in the negative UNL list would not count towards the 80% threshold. Imagine a network where everyone has the same UNL and consider what happens if validators start to fail. Without this proposal, as soon as 20% of the validators fail, the network would stop making forward progress. With this proposal, as validators fail, the remaining validators would add them to the list of validators believed unreliable. This would mean the network could keep making forward progress safely even if the number of remaining validators gets to 70% or even slightly lower. 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 suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ
  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 minimal network traffic. When a server loses synch, it can then collect validations to determine the ledgers it needs to go forward from its last-validated ledger to the current ledger. This has three advantages. First, it provides greater protection from hostile majority attacks because the server only obtains full ledgers by building them locally. Second, it allows the server to conserve network and CPU resources by only having to play the ledgers forward, rather than backwards and then forwards. Third, it reduces the load the server places on other servers and permits it to stop being a burden and resume helping other servers more quickly. 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 suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ
×
×
  • Create New...