hyperlane-monorepo

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

blockchain hyperlane interchain monorepo

History

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 -->	6 months ago
..
matching_list.rs	fix: duplicate word typos (#3854 )	6 months ago
mod.rs	feat: address blacklisting in the relayer (#4000 )	6 months ago

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
-->

6 months ago

matching_list.rs

fix: duplicate word typos (#3854 )

6 months ago

mod.rs

feat: address blacklisting in the relayer (#4000 )

6 months ago