Jump to content

Question about the xrpl amendment activation process.


Recommended Posts

According to the resources available online, an amendment in the XRPL requires support from at least 80% the validators over a two week period.

Can anyone help me understand if this "80% validators support" refer to the 80% validators in a UNL of a particular validator OR the 80% validators in the entire network?

If it is 80% validators in a UNL, what will happen if 80% validators in my UNL have supported an amendment but it still has not reached the required 80% in other validator's UNL?

Edited by A01TYAD
Link to post
Share on other sites

It always refers to your own UNL.

 

If you (and 80% of your UNL) have activated that amendment and someone else hasn't, you're no longer going to run on the same chain. Either your UNLs are so different, that there will just be a fork or one of them (your or the other one) will just stop working until there's some manual intervention, depending on how each server's UNLs look like.

Edited by Sukrim
Link to post
Share on other sites
54 minutes ago, Sukrim said:

It always refers to your own UNL.

 

If you (and 80% of your UNL) have activated that amendment and someone else hasn't, you're no longer going to run on the same chain. Either your UNLs are so different, that there will just be a fork or one of them (your or the other one) will just stop working until there's some manual intervention, depending on how each server's UNLs look like.

So, if my UNL currently has 79% support for an amendment and another UNL (let's say Ripple's dUNL) already has the required 80% support, I would have to manually change/add validators to my UNL in order to stop my validator from forking from the network?

Link to post
Share on other sites
11 hours ago, Sukrim said:

Yep, that's the global overlap requirement mentioned in the Consensus Whitepaper.

If you download a new version of rippled, what is the initial state: Are all amendments still switched off and will they all be turned on when you catch up with the validators in your UNL, or are some of the older amendments  hard-coded automatically enabled?

Link to post
Share on other sites
On 8/20/2020 at 8:14 AM, A01TYAD said:

So, if my UNL currently has 79% support for an amendment and another UNL (let's say Ripple's dUNL) already has the required 80% support, I would have to manually change/add validators to my UNL in order to stop my validator from forking from the network?

It's slightly more complicated than this because your validators care about what their validators are doing.

Each server decides individually whether to propose the pseudo-transaction to enable an amendment based on that server's own trusted validators. But whether that pseudo-transaction achieves enough support to become a validated part of the ledger history (from your server's perspective) depends on what your validators observe that their own trusted validators did. If not enough support an amendment, then they say, "Welp, nevermind. It didn't get enough support, so I can't enable it yet." Your server may be a little confused ("Huh? I thought 80% of validators were in favor of this thing, how come it didn't get approved?") but it'll follow what its trusted validators do, so if they don't enable an amendment, it won't either.

For example, say your server trusts none of the validators in Ripple's list directly, but all the validators you trust are configured to use Ripple's list. Then (I think) it's technically possible but extremely unlikely that you'll fork off from the main ledger chain¹. Basically it can only happen if the internet delays specific messages from specific validators just enough and some validators are sending validation messages for mutually-incompatible ledgers. Even if the validators you trust are going to say, "Yes, I think we should support amendment X," and your server says, "Aha, all the validators I trust are in favor of amendment X" it'll say, "Yes, let's try turning it on." But your trusted validators look at their trusted validators, who look at their validators, and so on.

Basically the two main factors that control whether a fork is possible are:

  • How much overlap is there between lists? Not just who you trust but who the people you trust trust. The more the network is fragmented, the more likely. If there are certain cliques of servers that mostly trust themselves and not each other, it's more likely those cliques eventually fork into separate networks. (If there's literally zero overlap, then it's guaranteed to happen—that's pretty much how you make test networks.)
  • How unreliable are internet communications? If everyone gets everyone else's messages with no delay then forks are much less likely. Crucially, it becomes super obvious if one validator is engaging in Byzantine behavior and sending multiple, mutually-incompatible validations for different versions of the same ledger. When that happens servers can't get duped into thinking that enough validators voted one way or another for it to be final.

¹ Note, one way you certainly could fork off from the main ledger chain in this example is if > 80% of the validators you did trust were colluding. It's debatable whether that means they are really configured to trust Ripple's list, but anyway, point being, if you trust a bunch of random validators you could be deceived into trusting bad ones. The main point of Ripple's recommended list is to create a list of reliable, high-quality validators who aren't just sock puppets of one entity (i.e. to protect against a Sibyl attack).

 

Link to post
Share on other sites
23 hours ago, mDuo13 said:

It's slightly more complicated than this because your validators care about what their validators are doing.

Each server decides individually whether to propose the pseudo-transaction to enable an amendment based on that server's own trusted validators. But whether that pseudo-transaction achieves enough support to become a validated part of the ledger history (from your server's perspective) depends on what your validators observe that their own trusted validators did. If not enough support an amendment, then they say, "Welp, nevermind. It didn't get enough support, so I can't enable it yet." Your server may be a little confused ("Huh? I thought 80% of validators were in favor of this thing, how come it didn't get approved?") but it'll follow what its trusted validators do, so if they don't enable an amendment, it won't either.

For example, say your server trusts none of the validators in Ripple's list directly, but all the validators you trust are configured to use Ripple's list. Then (I think) it's technically possible but extremely unlikely that you'll fork off from the main ledger chain¹. Basically it can only happen if the internet delays specific messages from specific validators just enough and some validators are sending validation messages for mutually-incompatible ledgers. Even if the validators you trust are going to say, "Yes, I think we should support amendment X," and your server says, "Aha, all the validators I trust are in favor of amendment X" it'll say, "Yes, let's try turning it on." But your trusted validators look at their trusted validators, who look at their validators, and so on.

Basically the two main factors that control whether a fork is possible are:

  • How much overlap is there between lists? Not just who you trust but who the people you trust trust. The more the network is fragmented, the more likely. If there are certain cliques of servers that mostly trust themselves and not each other, it's more likely those cliques eventually fork into separate networks. (If there's literally zero overlap, then it's guaranteed to happen—that's pretty much how you make test networks.)
  • How unreliable are internet communications? If everyone gets everyone else's messages with no delay then forks are much less likely. Crucially, it becomes super obvious if one validator is engaging in Byzantine behavior and sending multiple, mutually-incompatible validations for different versions of the same ledger. When that happens servers can't get duped into thinking that enough validators voted one way or another for it to be final.

¹ Note, one way you certainly could fork off from the main ledger chain in this example is if > 80% of the validators you did trust were colluding. It's debatable whether that means they are really configured to trust Ripple's list, but anyway, point being, if you trust a bunch of random validators you could be deceived into trusting bad ones. The main point of Ripple's recommended list is to create a list of reliable, high-quality validators who aren't just sock puppets of one entity (i.e. to protect against a Sibyl attack).

 

Very nice explaination. Thank you very much!

Link to post
Share on other sites

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.