Jump to content

Memory in a transaction


wojake
 Share

Recommended Posts

I'm curious how much memory one transaction takes, since the ledger resources is finite, it would be cool to do some calculations for fun.

I would try to calculate the cost of spamming the ledger's resources, the cost would be in XRP since other currencies are not accepted to pay for transaction fees as of writing this.
Spamming the ledger's resources will not be profitable nor worth it.

Adding a few fields like memo and destination tag to a transaction would increase the memory without the need to increase the transaction fee, so I'll try to include them.

I won't actually spam the network to deplete its resources, I'm actually curious

Edited by wojake
Link to comment
Share on other sites

I'm not the big guns, but I do think it'd be helpful to remind you that a number of the numbers involved are flexible/granular.

(And that the current "lower the reserve(s) or do lite accounts" stuff is largely driven by an "adoption/spam v chicken/egg")

Link to comment
Share on other sites

1 minute ago, NightJanitor said:

I'm not the big guns, but I do think it'd be helpful to remind you that a number of the numbers involved are flexible/granular.

(And that the current "lower the reserve(s) or do lite accounts" stuff is largely driven by an "adoption/spam v chicken/egg")

I see, I suppose you're right since the DB used in the XRP Ledger can be altered to an even better one with better storing and better performance overall, thank you! :banana:

https://xrpl.org/capacity-planning.html#more-about-using-rocksdb

Link to comment
Share on other sites

13 hours ago, wojake said:

I'm curious how much memory one transaction takes, since the ledger resources is finite, it would be cool to do some calculations for fun.

Which memory do you mean? RAM to process the transaction or RAM/HDD to store the "effects" of the transaction in the ledger (the merkle tree)?

I think it's really hard to answer. I don't have for sure the answer but I think also the gods summoned before don't have it. Probably only practical tests would give a good approximation.

I'm very curious about this since long time but I never had answer (because they can be dangerous :rolleyes:).

Edited by tulo
Link to comment
Share on other sites

54 minutes ago, tulo said:

RAM/HDD to store the "effects" of the transaction in the ledger (the merkle tree)?

On this you can have a rough estimate from here https://xrpl.org/ledger-data-formats.html.

An "offer" in the ledger takes at least 145 Bytes and it locks 2 XRP. The memo field is not saved in the ledger (well it's included in the transactions of the ledger but the data is not carried on in the "state data").

So if you want to spam the network with lots of Offers and you have 10M XRP, then you'll add at least 725MB. For a "decent" attack you should consider to add at least 32GB which would require 440M XRP (or less probably). My rippled node would fail in that case. I think it's a feasible attack since the XRP are not lost but only locked temporarily, so that you can have an XRP loan and pay only a small percentage of those 440M XRP.
Maybe with other transactions there is a better XRP to memory usage.

EDIT: a signerlist takes at least 262 Bytes, lowering the 32GB attack to 244M XRP! :D

Edited by tulo
Link to comment
Share on other sites

17 hours ago, tulo said:

On this you can have a rough estimate from here https://xrpl.org/ledger-data-formats.html.

An "offer" in the ledger takes at least 145 Bytes and it locks 2 XRP. The memo field is not saved in the ledger (well it's included in the transactions of the ledger but the data is not carried on in the "state data").

So if you want to spam the network with lots of Offers and you have 10M XRP, then you'll add at least 725MB. For a "decent" attack you should consider to add at least 32GB which would require 440M XRP (or less probably). My rippled node would fail in that case. I think it's a feasible attack since the XRP are not lost but only locked temporarily, so that you can have an XRP loan and pay only a small percentage of those 440M XRP.
Maybe with other transactions there is a better XRP to memory usage.

EDIT: a signerlist takes at least 262 Bytes, lowering the 32GB attack to 244M XRP! :D

I might be wrong here but the number of XRP burnt from transaction fees is 10 million XRP, and there's already ~14 terabytes worth of ledger history, so something is definitely wrong here.

"Such a large amount of solid state storage is not cheap, and the total amount of history you must store increases by approximately 12 GB per day."
- xrpl.org


 

Link to comment
Share on other sites

16 hours ago, wojake said:

I might be wrong here but the number of XRP burnt from transaction fees is 10 million XRP, and there's already ~14 terabytes worth of ledger history, so something is definitely wrong here.

"Such a large amount of solid state storage is not cheap, and the total amount of history you must store increases by approximately 12 GB per day."
- xrpl.org

Actually the memory needed for historycal ledger is not exactly a network resource. The XRPL can go forward only from the last ledger, so validators could in theory only store the last ledger to make the network work. In practice no nodes store only the last ledger, but the older ledgers are mainly for queries purpose.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share


×
×
  • 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.