Quadear Posted November 10, 2020 Share Posted November 10, 2020 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 comment Share on other sites More sharing options...
tulo Posted November 10, 2020 Share Posted November 10, 2020 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 comment Share on other sites More sharing options...
Quadear Posted November 10, 2020 Author Share Posted November 10, 2020 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 comment Share on other sites More sharing options...
Skippy Posted November 10, 2020 Share Posted November 10, 2020 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 comment Share on other sites More sharing options...
Quadear Posted November 10, 2020 Author Share Posted November 10, 2020 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 comment Share on other sites More sharing options...
Skippy Posted November 10, 2020 Share Posted November 10, 2020 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 comment Share on other sites More sharing options...
tulo Posted November 10, 2020 Share Posted November 10, 2020 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, Kakoyla and mDuo13 3 Link to comment Share on other sites More sharing options...
nikb Posted November 10, 2020 Share Posted November 10, 2020 @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. Lumpy 1 Link to comment Share on other sites More sharing options...
Quadear Posted November 11, 2020 Author Share Posted November 11, 2020 Thanks everyone for your imputs, will look at it in details Link to comment Share on other sites More sharing options...
xerxesramesepolybius Posted November 11, 2020 Share Posted November 11, 2020 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 comment Share on other sites More sharing options...
retryW Posted November 21, 2020 Share Posted November 21, 2020 Not a bad notification to get while at a party. Gives me something to actually celebrate.!!! Pamp it up!!!! Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now