Jump to content

Question about the "Index In Ledger" transaction field


Recommended Posts

Hello !

I noticed that in a transaction, I have a IndexInLedger field in addition to the ledgerVersion field.

Does that field have any impact on transaction resolution ? from what I understood, I though that all the new transactions were applied atomically on a new ledger. If it indeed has an impact on transaction resolution, is it possible to have any impact on it ?

Transaction Example: https://bithomp.com/explorer/A811CD63E2CB0B5FB78EADD7C39BCE76E912F39EF0A6A4490CDC571C7F565742

Thanks,

Link to post
Share on other sites
5 hours ago, Quadear said:

Hello !

I noticed that in a transaction, I have a IndexInLedger field in addition to the ledgerVersion field.

Does that field have any impact on transaction resolution ? from what I understood, I though that all the new transactions were applied atomically on a new ledger. If it indeed has an impact on transaction resolution, is it possible to have any impact on it ?

Transaction Example: https://bithomp.com/explorer/A811CD63E2CB0B5FB78EADD7C39BCE76E912F39EF0A6A4490CDC571C7F565742

Thanks,

It has an impact in the sense that transactions are applied one by one in new ledgers and the ones with lower index are applied first (in succession).

In your case 26 transactions were applied before yours, and those transactions can modify the state of the ledger, for example adding or removing liquidity.

Some years ago it was possible to "mine" lower index for transactions, but now it's almost impossible because they fixed it.

Link to post
Share on other sites

Thanks !

How is that order determined ? first come, first serve I guess ? How can the system determine an order when the system is composed of hundreds of servers, and obviously with different server time for each ?

Link to post
Share on other sites
55 minutes ago, Quadear said:

Thanks !

How is that order determined ? first come, first serve I guess ? How can the system determine an order when the system is composed of hundreds of servers, and obviously with different server time for each ?

First come, first serve. Any valid transaction will be completed if it's valid, the order shouldn't matter (?)

Link to post
Share on other sites
4 minutes ago, Skippy said:

First come, first serve. Any valid transaction will be completed if it's valid, the order shouldn't matter (?)

How can the system determine a "first" in such a decentralized network ? I will obviously be the first to post the transaction on my private rippled, but how does it translate in the "global" ledger ? Timestamp depending on the server's system ? First transaction to reach an UNL server ?

Link to post
Share on other sites
2 minutes ago, Quadear said:

How can the system determine a "first" in such a decentralized network ? I will obviously be the first to post the transaction on my private rippled, but how does it translate in the "global" ledger ? Timestamp depending on the server's system ? First transaction to reach an UNL server ?

I wish I could answer you quickly now but I will instead guide you here if you have the time https://xrpl.org/consensus.html

Link to post
Share on other sites
2 hours ago, Skippy said:

First come, first serve. Any valid transaction will be completed if it's valid, the order shouldn't matter (?)

It's not first come first serve.

There is an algorithm which can't be gamed easily which "orders" all the transactions which should be included in the ledger:
 

Quote

1- Start with the previous validated ledger.

2- Place the agreed-upon transaction set in canonical order so that every server processes them the same way.

Canonical order  is not the order the transactions were received, because servers may receive the same transactions in different order. To prevent participants from competing over transaction ordering, canonical order is hard to manipulate.

3- Process each transaction according to its instructions, in order. Update the ledger's state data accordingly.

If the transaction cannot be successfully executed, include the transaction with a tec-class result code.

For certain "retriable" transaction failures, instead move the transaction to the end of the canonical order to be retried after other transactions in the same ledger version have executed.

Canonical ordering algo: https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/src/ripple/app/misc/CanonicalTXSet.cpp#L25-L36

 

Link to post
Share on other sites

@tulo basically nailed it. One small clarification: basically, once consensus determines the set of transactions, the set is placed in a deterministic (but very hard to predict) order. This is done by sorting transactions based on the hash of the consensus set (which is, for our purposes, effectively random), their transaction IDs and their sequence numbers.

You might find https://xrpl.org/consensus.html to be useful.

Link to post
Share on other sites
22 hours ago, nikb said:

@tulo basically nailed it. One small clarification: basically, once consensus determines the set of transactions, the set is placed in a deterministic (but very hard to predict) order. This is done by sorting transactions based on the hash of the consensus set (which is, for our purposes, effectively random), their transaction IDs and their sequence numbers.

You might find https://xrpl.org/consensus.html to be useful.

Nik, you are the coolest guy at Ripple

Link to post
Share on other sites
  • 2 weeks later...

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