Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modify Replica.sol to manage multiple Replicas for all remote domains in 1 contract #23

Merged
merged 11 commits into from
Jun 3, 2022

Conversation

aureliusbtc
Copy link
Contributor

@aureliusbtc aureliusbtc commented May 26, 2022

Description

Currently, Replica.sol only allows for one replica at a time per contract, making it extremely inefficient to manage as the number of chains Home's are deployed on increases.

For example, if we deploy on 10 chains, each chain needs to maintain 9 different replicas, resulting in 90 different Replica, and 10 Homes.

This is untenable to manage long-term, since Synapse is already deployed on 15 chains. There are two solutions:

  1. Create a ReplicaRouter, an advanced version of XAppConfig, which would route the relevant function calls to the most recently enrolled Replica. The main consideration with this is that events won't bubble up top-level, thus making it difficult for off-chain agents to track all events, including most relevantly, watch-towers.
  2. Modify Replica to allow for multiple different states to exist inside of mappings which are keyed by uint32 remoteDomain. This approach increases gas, but allows for events to bubble on one address.

TODOs / Questions:

  • Edit all events in Replica.sol to correspond to which remoteDomain is being used
  • Evaluate whether using a Mapped Struct vs. all Mappings is better, from both a gas perspective, and usability
  • Handling Replica unenrolls: Should all previous data moved to a new storage slot called archivedReplicas? Can we rely on off-chain event data to re-build the previous Replicas if needed in the future? Is a major benefit of multiple Replica contracts being able to leave a Replica in a failed state and re-deploying a new clean one?
  • Integrate XAppConfig into the new modified Multi-Replica contract

Gas Considerations:

Multi-Replica modified contract (not yet gas optimized):
image

Original Replica
image

@aureliusbtc aureliusbtc requested a review from trajan0x May 26, 2022 07:24
@github-actions github-actions bot added 2-reviewers C-Protocol-Critical PRs that modify protocol-critical code. M-contracts Module: Contracts labels May 26, 2022
@aureliusbtc aureliusbtc changed the title [WIP]: Modify Replica manage multiple Replicas for all remote domains in 1 contract Modify Replica manage multiple Replicas for all remote domains in 1 contract Jun 3, 2022
@aureliusbtc aureliusbtc marked this pull request as ready for review June 3, 2022 03:07
@aureliusbtc aureliusbtc changed the title Modify Replica manage multiple Replicas for all remote domains in 1 contract Modify Replica.sol to manage multiple Replicas for all remote domains in 1 contract Jun 3, 2022
@aureliusbtc aureliusbtc merged commit 302a07d into master Jun 3, 2022
@trajan0x trajan0x deleted the multi-replica branch March 28, 2023 19:11
abtestingalpha added a commit that referenced this pull request Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2-reviewers C-Protocol-Critical PRs that modify protocol-critical code. M-contracts Module: Contracts
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant