Disclaimer: The opinions expressed by our writers are their own and do not represent the views of U.Today. The financial and market information provided on U.Today is intended for informational purposes only. U.Today is not liable for any financial losses incurred while trading cryptocurrencies. Conduct your own research by contacting financial experts before making any investment decisions. We believe that all content is accurate as of the date of publication, but certain offers mentioned may no longer be available.
In a recent development, Ripple's CTO David Schwartz and head of engineering J.A Akinyele revealed a thought experiment on how XRP could be used in DeFi, both organically with apps and protocol, and natively on-chain.
The conversation deepened as XRP community members discussed the implications of staking for the XRP Ledger.
Along these lines, Ripple CTO David Schwartz hinted at a staking proposal that is yet to be made public. The idea calls for a "governance token" intended to be worthless, with limited circulating supply, and may be used to control holders through voting.
The discussion went further as XRP enthusiast WrathofKahneman asked if the XRPL is not already "governed by fork" in some sense, albeit without staked funds at play.
To this, Ripple CTO David Schwartz answered that all public layer-1 blockchains are ultimately governed by fork. Putting the speculation of an XRP fork to rest, Schwartz noted the essence of robust protections from other governance mechanisms that help reduce the risk of a fork. The Ripple CTO mentioned XRPL's published UNL as one such mechanism, and validators voting for amendments as another.
XRP UNL reduces risk of fork
A unique node list (UNL) is a server's list of validators trusted not to collude. Every XRP Ledger server is configured with a UNL, which determines which validation votes it listens to and which votes it throws out during the consensus process.
However, if two servers operate with totally different UNLs, they are likely to reach different conclusions about when ledgers (and the transactions on them) are validated. This could lead to a fork in the network, with varying parties unable to mutually agree on what has happened and unable to transact with one another. To avoid forking, servers in the XRP Ledger are configured with UNLs that have a high degree of overlap with one another; in the worst case scenario, 90% overlap was required to prevent a fork.
To make it easier to get a diverse list of validators that has high overlap with others, the XRP Ledger uses a system of recommended validator lists. Currently, the default configuration for XRP Ledger servers uses two lists: one published by the XRP Ledger Foundation and one published by Ripple.
Dan Burgin
Vladislav Sopov
U.Today Editorial Team