Topic: Ripple.com - How does consensus work? - page 2. (Read 2204 times)
@mareo87 u can say that again hahahaha i juz joined and it's crazy but fun...
i watch bitcoin for over a year and just about to get a hang of it. i wonder how long it would take for me to understand ripple hahaha
Oddly enough, it seems that there isn't yet a consensus on how consensus works. But from what I understand, consensus is trusted validators looking at the ledger, and certifying it. The only way this would be vulnerable is if a validator orchestrated a 51% attack.
I think descriptions of the "interesting" case (how Ripple uses consensus to solve the double spend problem) are getting confused with how the uninteresting cases are solved. There are really three cases:1) As a non-validating client or server operates: Here, you just collect validations, which are signed statements of the hash of the last closed ledger. The validations are timestamped and sequenced. This allows a client to determine the current ledger which includes things like balances. You can then follow hash chains to get the results of transactions, view order books, and so on without any trust needed.
2) When a new validator comes online: A new validator can determine the current ledger using the same mechanism a client does. The new validator will then synchronize to the current ledger. The validator can also walk the hash chains to ensure that there is a valid path from the last ledger it accepted to the current ledger.
3) The interesting case -- as a validator operates, solving the double spend problem: The validator must already agree on the last closed ledger as described above. Validators exchange proposals that state which transactions the validator believes should be candidate to be applied to the ledger. Once a consensus is reached, the candidate transactions are applied deterministically so that all validators produce the same new last closed ledger. They then sign validations of this ledger (for use by clients and new validators as in 1 and 2 above). The servers then start the next consensus cycle and also collect validations from the ledger they just closed to ensure that nothing went wrong in the consensus process and to provide to clients.
Using my (overly simplified) agreement room analogy, it works like this:
1) There's a room where everyone agrees on the last closed ledger.
2) If you want to disagree, you can, but you must leave the room to do so.
3) If you want to know what the current ledger is, you walk in and ask everyone in the room.
4) If you want to perform a transaction, you read it out loud. Everyone honest agrees that it's valid.
5) If there are any transactions that someone in the room believes is valid and is not in the current ledger, they attempt to obtain a consensus on that transaction.
6) When a consensus is reach, the consensus transactions are applied to the last closed ledger forming a new last closed ledger.
7) Everyone agrees on the new last closed ledger.
8 ) We go back to step 5. Any transactions believed still valid but that didn't get into the consensus transaction set for some reason should now be voted in by every honest person.
9) If people appear to be acting in ways that don't make sense, such as voting no on transactions that have no reason not to be included or failing to validate the correct ledger, you ignore them.
10) Your top priority is to enforce the rules of the room. Your second priority is to achieve consensus.
Wow, thank you for the amazingly detailed response. That actually really makes sense for me.
Oddly enough, it seems that there isn't yet a consensus on how consensus works. But from what I understand, consensus is trusted validators looking at the ledger, and certifying it. The only way this would be vulnerable is if a validator orchestrated a 51% attack.
I think descriptions of the "interesting" case (how Ripple uses consensus to solve the double spend problem) are getting confused with how the uninteresting cases are solved. There are really three cases:1) As a non-validating client or server operates: Here, you just collect validations, which are signed statements of the hash of the last closed ledger. The validations are timestamped and sequenced. This allows a client to determine the current ledger which includes things like balances. You can then follow hash chains to get the results of transactions, view order books, and so on without any trust needed.
2) When a new validator comes online: A new validator can determine the current ledger using the same mechanism a client does. The new validator will then synchronize to the current ledger. The validator can also walk the hash chains to ensure that there is a valid path from the last ledger it accepted to the current ledger.
3) The interesting case -- as a validator operates, solving the double spend problem: The validator must already agree on the last closed ledger as described above. Validators exchange proposals that state which transactions the validator believes should be candidate to be applied to the ledger. Once a consensus is reached, the candidate transactions are applied deterministically so that all validators produce the same new last closed ledger. They then sign validations of this ledger (for use by clients and new validators as in 1 and 2 above). The servers then start the next consensus cycle and also collect validations from the ledger they just closed to ensure that nothing went wrong in the consensus process and to provide to clients.
Using my (overly simplified) agreement room analogy, it works like this:
1) There's a room where everyone agrees on the last closed ledger.
2) If you want to disagree, you can, but you must leave the room to do so.
3) If you want to know what the current ledger is, you walk in and ask everyone in the room.
4) If you want to perform a transaction, you read it out loud. Everyone honest agrees that it's valid.
5) If there are any transactions that someone in the room believes is valid and is not in the current ledger, they attempt to obtain a consensus on that transaction.
6) When a consensus is reach, the consensus transactions are applied to the last closed ledger forming a new last closed ledger.
7) Everyone agrees on the new last closed ledger.
8 ) We go back to step 5. Any transactions believed still valid but that didn't get into the consensus transaction set for some reason should now be voted in by every honest person.
9) If people appear to be acting in ways that don't make sense, such as voting no on transactions that have no reason not to be included or failing to validate the correct ledger, you ignore them.
10) Your top priority is to enforce the rules of the room. Your second priority is to achieve consensus.
Oddly enough, it seems that there isn't yet a consensus on how consensus works. But from what I understand, consensus is trusted validators looking at the ledger, and certifying it. The only way this would be vulnerable is if a validator orchestrated a 51% attack.
How does Ripple select the validators that we trust not to collude?
In principle, each user can select their own set of trusted validators based on entites they trust not to collude. The system is designed to be robust even with only minimal overlap.Right now, you select a list of domains to trust and those domains list validators they believe are independently managed. Currently, only servers need a trust list and clients trust server to tell them what the current consensus ledger is. We are transition to an untrusted server model where clients will tell the server which validators they trust and servers will pass on validations from those validators to clients to convince them that the current ledger is what they claim it is.
Clients only need to trust validators to determine what the current ledger is. They can then walk the hash chains to confirm balances, transactions, and so on.
Servers need to decide which validators they will work to establish a consensus with. So having a good list of validators is much more important if you yourself are a validator. We expect people who choose to be a validator and ask people to trust them to put some effort into selecting the validators they will trust.
Quote
And how do I know that 15 years from now, they will still be sensibly selecting validators?
I can't tell you today what the scheme will be 15 years from now. If Ripple catches on, it may be domain scraping. Essentially, as you visit web sites, your browser would check if they provide a Ripple validator list. If so, you might click on a button to add them as a validator source. You would then look at validators that were nominated by several of your sources.Unless your list winds up consisting of almost all colluding validators all colluding with each other, a bad trust list will be easily detected. And even if it does, good servers won't be able to convince you to accept what they claim is the latest ledger. So there would be multiple clear indications that your trust list was broken.
How does Ripple select the validators that we trust not to collude?
And how do I know that 15 years from now, they will still be sensibly selecting validators?
And how do I know that 15 years from now, they will still be sensibly selecting validators?
Greetings toz,
Thank you for the link.
I just wanted to start a dialog for newbies to discuss questions or comments about how it works.
Do you understand all the details? Any concerns of how consensus could have problems in certain situations?
Best regards,
-ibuyXRP
--
[email protected] - i pay above market value, and i offer any currency issued by Bitstamp.net
XRP: rNnLFDCRrAtuESodmwamAasMBZqCmkqQH9
Any newbies understand how consensus works on Ripple.com?
-ibuyXRP
Ripple.com address: rNnLFDCRrAtuESodmwamAasMBZqCmkqQH9
questions or to make an offer: [email protected]
i pay above market price
-ibuyXRP
Ripple.com address: rNnLFDCRrAtuESodmwamAasMBZqCmkqQH9
questions or to make an offer: [email protected]
i pay above market price
Jump to: