Quadear 1 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 post Share on other sites
tulo 3,252 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 post Share on other sites
Quadear 1 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 post Share on other sites
Skippy 7,332 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 post Share on other sites
Quadear 1 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 post Share on other sites
Skippy 7,332 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 post Share on other sites
tulo 3,252 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 mDuo13, nikb and Kakoyla 3 Link to post Share on other sites
nikb 4,302 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 post Share on other sites
Quadear 1 Posted November 11, 2020 Author Share Posted November 11, 2020 Thanks everyone for your imputs, will look at it in details Link to post Share on other sites
xerxesramesepolybius 296 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 post Share on other sites
retryW 3,836 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 post Share on other sites
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now