Question about the "Index In Ledger" transaction field

[Quadear 1]

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,

[tulo 3,134]

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.

[Quadear 1]

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 ?

[Skippy 6,299]

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 (?)

[Quadear 1]

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 ?

[Skippy 6,299]

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

[tulo 3,134]

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

 

[nikb 4,248]

@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.

[Quadear 1]

Thanks everyone for your imputs, will look at it in details

[xerxesramesepolybius 270]

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

[retryW 3,744]

Not a bad notification to get while at a party. Gives me something to actually celebrate.!!! 

 

Pamp it up!!!!