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

Ethereum Integration #557

Merged
merged 64 commits into from
Apr 21, 2024
Merged

Ethereum Integration #557

merged 64 commits into from
Apr 21, 2024

Conversation

kayabaNerve
Copy link
Member

This is not ready for production. It does a lot of the leg work on the actual integration, and is far along enough I'd like to start running the CI on it.

In general, what needs to be done:

  1. Update the documentation
  2. Implement fee handling
  3. Have user specification of the gas limit (instead of a constant)
  4. Have an additional service to publish TXs through
  5. Build a better pattern for event retrieval
  6. Move ScannerEvent::Completed from a tuple to a struct
  7. Re-define key_for_any_change to a stricter definition, as currently expected
  8. Make a proper trait for Eventuality Completions
  9. Handle top-level transfers in the processor

What has been done:

  1. Moved to alloy (Replace ethers-rs with alloy #331), including developing a new transport around our own simple-request
  2. Adds deterministic deployment of the Router, offering efficient location without DoS risks
  3. Adds a Sandbox to make aggregated calls with
  4. Fleshes out the Router
  5. Makes the Scheduler generic to the processor (starting the road on Processor modularity #289)
  6. Replaces transaction signing with eventuality completion, a higher layer of abstraction
  7. Moves creation of refund and forwarding plans into the scheduler

Bit more streamlined for our use case.
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
Also ban payments to the branch/change/forward addresses.
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.

This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).

Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
…serai-processor tests

This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
@kayabaNerve kayabaNerve added feature New feature or request ethereum An issue with the Ethereum integration processor labels Apr 19, 2024
@kayabaNerve kayabaNerve merged commit 0f0db14 into develop Apr 21, 2024
19 checks passed
@kayabaNerve kayabaNerve deleted the ethereum branch April 21, 2024 10:02
@kayabaNerve kayabaNerve mentioned this pull request Apr 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ethereum An issue with the Ethereum integration feature New feature or request processor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant