The home for Hyperlane core contracts, sdk packages, and other infrastructure

blockchainhyperlaneinterchainmonorepo

You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

Trevor Porter c84a1dc73b feat: address blacklisting in the relayer (#4000) ... ### Description See context here https://discord.com/channels/935678348330434570/1236041564673806427/1252918894755319920 and https://discord.com/channels/935678348330434570/1252953507833708605/1252954456400592997 This is a rudimentary first step toward blacklisting addresses. Future options are outlined in https://discord.com/channels/935678348330434570/1236041564673806427/1252918894755319920. Eventually we can also fetch these addresses directly within the agent from an updated list that we cache and re-fetch occasionally. For now, this just relies on configured addresses. The approach is: - Allow hex addresses to be configured. These are intentionally treated as a Vec<u8> instead of an H160 / H256. This is because treating them as H160 is a leak of Ethereum-specific logic into non-chain-specific code in the relayer, and treating them as H256 would pad Ethereum addresses with a bunch of zeroes which would diminish the accuracy of our heuristic implemented in this. The subsequence stuff is a bit unfortunate because it's O(n^2) but 🤷‍♂️ - The heuristic is as follows - if any of the configured addresses are found as a subsequence in the message sender, recipient, or body, it's thrown out by the message processor, and the message will never make its way to the op_submitter. This heuristic for the body is to prevent warp route transfers that include that address. We could maybe convert Vec<u8> to H256 for the sender and recipient, I'm open to this - I just went with the substring approach bc it felt easiest tbh. ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues - Fixes https://github.com/hyperlane-xyz/issues/issues/1285 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->		5 months ago
..
merkle_tree	chore: reduce agents log verbosity, reword (#3026)	1 year ago
msg	feat: address blacklisting in the relayer (#4000)	5 months ago
settings	feat: address blacklisting in the relayer (#4000)	5 months ago
lib.rs	feat: batching igp (#3870)	6 months ago
main.rs	feat: batching igp (#3870)	6 months ago
processor.rs	feat: Relayer tokio task instrumentation (#3760)	6 months ago
prover.rs	Sealevel (#2404)	1 year ago
relayer.rs	feat: address blacklisting in the relayer (#4000)	5 months ago
server.rs	feat: batching igp (#3870)	6 months ago