hyperlane-monorepo

Commit Graph

Author	SHA1	Message	Date
Yorke Rhodes	60f321f452	docs: elaborate on censorship resistance of two ISMs. (#2474 ) ### Description Changes from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/2425 --------- Co-authored-by: serejke <serejke.best@gmail.com>	1 year ago
Yorke Rhodes	50f04db1fa	Make merkle proofs optional on multisig ISM (#2173 ) ### Description Validators currently sign `(root, index)` checkpoints and during verification, a `message` is passed as calldata, an `id()` is derived, and a `proof` of `id()` at `index` in `root` is verified This provides “all or nothing” censorship resistance guarantees because a validator can only sign roots to allow any contained messages to be processed. We have considered alternatives where validators sign `message` directly and we lose censorship resistance in exchange for eliminating merkle proof verification gas costs. However, if validators sign `(root, index, message)` tuples, we can skip merkle proof verification on the destination chain while still maintaining censorship resistance by providing two valid metadata formats: 1. existing validator signatures and merkle proof verification of inclusion 2. including merkle proof verification for pathway where validators are censoring `message` It’s worth noting the validator is required to index event data to produce this new signature format. However, this does not require historical indexing and new validators being spun up can simply begin indexing from tip. See https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/2187 for validator changes See https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/2248 for relayer and e2e test changes ### Drive-by changes Merkle index also optional ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2192 ### Backward compatibility - new ISM deployment is necessary (we could upgrade implementation in theory) - Validator and relayer upgrades ### Testing Unit (fuzz) Tests, E2E tests	2 years ago

Author

SHA1

Message

Date

Yorke Rhodes

60f321f452

docs: elaborate on censorship resistance of two ISMs. (#2474 )

### Description

Changes from
https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/2425

---------

Co-authored-by: serejke <serejke.best@gmail.com>

1 year ago

Yorke Rhodes

50f04db1fa

Make merkle proofs optional on multisig ISM (#2173 )

### Description

Validators currently sign `(root, index)` checkpoints and during
verification, a `message` is passed as calldata, an `id()` is derived,
and a `proof` of `id()` at `index` in `root` is verified

This provides “all or nothing” censorship resistance guarantees because
a validator can only sign roots to allow any contained messages to be
processed.

We have considered alternatives where validators sign `message` directly
and we lose censorship resistance in exchange for eliminating merkle
proof verification gas costs.

However, if validators sign `(root, index, message)` tuples, we can skip
merkle proof verification on the destination chain while still
maintaining censorship resistance by providing two valid metadata
formats:

1. existing validator signatures and merkle proof verification of
inclusion
2. including merkle proof verification for pathway where validators are
censoring `message`

It’s worth noting the validator is required to index event data to
produce this new signature format. However, this does not require
historical indexing and new validators being spun up can simply begin
indexing from tip.

See https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/2187 for
validator changes
See https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/2248 for
relayer and e2e test changes

### Drive-by changes

Merkle index also optional

### Related issues

- Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2192

### Backward compatibility

- new ISM deployment is necessary (we could upgrade implementation in
theory)
- Validator and relayer upgrades

### Testing

Unit (fuzz) Tests, E2E tests

2 years ago

2 Commits (f4b12a438b38d8130b7930371478bb8b59a10e58)