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.
Vijay Khanna, Director of Engineering at Ripple, sent an important message to XRP Ledger node operators. The advisory pertains to the recent XRPL release, version 3.2.1, which contains an essential fix for the network.
Khanna urges validators to upgrade to 3.2.1 as soon as possible, saying that it contains a hotfix that prevents the manifest flood attack.
A manifest flood was observed on the XRPL network on Friday, July 31, but is now fixed by xrpld version 3.2.1.
Nodes previously accepted, stored, and rebroadcast an unlimited number of manifests from unknown validator keys; version 3.2.1 adds four limits, which include a size cap per manifest where any single manifest larger than expected is rejected; a receive cap where incoming batches over the limit are discarded instead of breaking the peer connection; a send cap where the bulk manifest greeting sent to each new peer is now bounded; and fourth, a cache cap where once 100 unknown keys are held, new ones are refused. Manifests are also no longer persisted from unknown keys to disk, so a flood cannot survive a restart.
Node operators are urged to follow the process by updating normally to XRPL 3.2.1; waiting one to two minutes and confirming xrpld is running; and lastly, restarting xrpld again, which is very essential.
About XRPL 3.2.1
In a detailed blog post, Xora Finance explains what changes with the xrpld 3.2.1 version.
An XRPL validator has two identities, each with a separate job. A stable master key determines who the validator is. A changeable ephemeral key signs daily validation messages. A validator manifest is a master-key-signed statement that links these identities together.
Prior to 3.2.1, a peer could send several manifests that were structurally correct and cryptographically valid even when their master keys were not listed.
XRPL 3.2.1 hardens validator manifest propagation by rejecting oversized objects earlier, caps untrusted processing and retained identities, limits message size, restricts relaying of fresh untrusted identities, and keeps untrusted gossip out of persistent storage.
Dan Burgin
