Jump to content
Sign in to follow this  

Recommended Posts

6 hours ago, Hodor said:

I know you're not here to talk about amendments, but does SHAMapV2 promise to result in XRPL performance improvements? 

I personally don't know what performance benefits it's expected to have. Presumably some; I think it reduces the space required to store a lot of the ledger? The problem is that switching over after enabling it would require a long downtime as every server re-calculates the V2 version of the ledger. If I'm recalling correctly, it also affects backwards compatibility of data. That's why it's commented out in the codebase right now—Ripple doesn't want it to get enabled by accident. Honestly, the downsides may outweigh the upsides now, given the extent to which people already rely on the XRP Ledger for actual business 24/7.

Share this post


Link to post
Share on other sites
6 hours ago, Hodor said:

does SHAMapV2 promise to result in XRPL performance improvements

It would be a bit faster to look up objects and a bit less disk used to store them, but to get hard numbers you'd need to do benchmarks.

Switching to the new system (especially if you want to deprecate and completely remove the current one over time) would likely be a large task in itself, as Rome already said.

A "clean slate" approach where a ledger state from the current ledger is used as genesis ledger for a "XRPLv2" chain would be an option, but also has its issues. It depends on the implementation in detail though, it could maybe be done in a way that only validators need to switch initially, and they shouldn't have much history to begin with.

Still SHAMapv2 would change root hash calculations and thus influence the block headers and thus need to be understood and adopted by all servers in the network.

Share this post


Link to post
Share on other sites

When we started developing the SHAMapV2 code, our goal was to have it voted on and enabled ASAP.

But, unlike every other amendment that have been activated to date, SHAMapV2 makes a radical change in the core data structure of the ledger: the SHAMap.

At the time of activation, the network would have to halt, as it converted the V1 maps to V2, before continuing. And, of course, this would be non-reversible (without another amendment and another conversion). This was a serious concern, so we kept putting off voting for the amendment.

Throughout this time, we’ve implemented a lot of incremental improvements to the V1 maps to the point that the additional improvements that V2 offers are, simply, no longer big enough to justify activating this amendment, especially considering the costs & risks activation entails.

My preference would be to withdraw this amendment and remove the SHAMap V2 code from the codebase.

Share this post


Link to post
Share on other sites
Sign in to follow this  

×
×
  • Create New...