I want the opinion of most importantly relayers on this, go register if you haven’t, will immediately start a dicussion on this because I do not like wasting time.
Essentially, as everyone can very obviously see the current relayer system has an issue where it is still not perfectly sybil resistant (through staking and fees) because of the possibility of relayers avoiding the router. Not only that, but it aligns actors which is beneficial for a number of reasons.
What can we do about this?
My idea was the following, an upgrade, at some point in the future, with the following key points about its implementation (ranked by change significance from current status quo):
-
(Major) Instead of Relayers being an EOA, they would instead deploy a “wallet” contract from the Registry (whatever the upgraded Registry looks like).
- The main point is, that then frontends can only scan for these contracts, and that these contracts can enforce burning stake. Obviously, relayers will still be able to run EOAs, but now they can’t sybil/piggyback off of the system, because frontends can only scan for those contracts & build proofs for them.
- It just occured to me, this wallet could support multisig like functionality, this means that if relayer VPS infrastructure is compromised, since fees would be sent to a wallet, or since stake would be available on a wallet, or further more we could even allow ETH stored for gas to be part of this wallet (just allow multicall), then if relayer private keys are compromised, it wouldn’t be as bad because they could use also other keys for the wallet. This resolves an issue that was raised a couple of months ago.
- Obviously, Relayers need to stake to actually deploy the former contract.
- The TORN fee would only be calculated once the Relayer withdraws. Since the Relayer can’t access fees otherwise, but he needs it to stay profitable, the TORN stake will always be deducted.
- Since Relayers can’t sybil/piggyback any longer, nullifications become unnecessary!
- (Medium) If it is possible, a custom ENS Registrar would be written to act instead of the Registry for this upgrade, the reasoning for this is that Relayers already have to deal with ENS and all of that, so this is just a design change which you would expect to see. I suppose that the domain would be registered, set up, and then the ownership tossed.
- (Medium) An ENS resolver would also be deployed, this one would be able to resolve addresses across (non-upgradeable) versions. The question is how assign legitimacy to some version infrastructure without allowing someone else to make use of this as the above is used.
- (Medium) The frontend has to be updated, and all of that has to come in one go, so parallel branches across repositories are necessary and then once everything is tested must be deployed.
Contract spec brainstorming
Infrastructure Overview
The Relayer Wallet in general would be versioned, non-upgradeable and deployed via some permissionless clone factory which then deploys an immutable minimal proxy which points towards a non-upgradeable implementation contract. This is similar to Gnosis Safe.
The factory is immutable too and we support multiple deployments out of the box via some form of general resolver which would be used to provide addresses.
The above also implies that part of the release cycle has to be oracle infrastructure, and each oracle infrastructure can target one contract which rewards lockers.
Relayer Wallet
The Relayer is separated into two components, a usual EOA (Relayer Executor) and the Relayer Wallet, BUT, since the frontend for building proofs necessarily includes a parameter which represents the relayer address, the frontend can make the contract the target address.
- On each Relayer withdraw, check whether the Wallet has enough of balance, then do regular fee calculations, and deduct the TORN calculated.
- Should be able to use multiple addresses in a simple multisig-like scheme to specify which address may be attributed:
-
- Fees collected, this means that the Executor does not necessarily have to be the fee collector, meaning that the Executor wallet can simply be used for processing transactions.
-
- Ethereum used for compensating gas to the wallet. A Relayer could send some lowish amount of ETH to the Executor wallet, and keep most of the ETH in the Relayer Wallet contract. The contract then, through a multicall withdrawal, compensates the Relayer Wallet for the Ethereum.
-
Custom Registrar
- Informs the factory that a minimal Relayer Wallet proxy should be deployed, one of those two then comunicate to the Resolver that there is a new legitimate contract deployed.
- Passes TORN to the respective contract version of the staking contract.
- Would not handle contacting a staking contract any longer. The contract asking oracles to calculate fees would be the one finally informing the contract which rewards lockers that rewards are to be attributed to them.
- Registration must cover Relayer Executor & Wallet subnodes.
- Current balances of Relayers should be preserved.
Custom Resolver
- Should support all record types. Relayer Executor wallet should initially be transferred ownership.
- Must be able to perform lookups across all infrastructure versions. This means that there must exist some scheme by which trusted parties can deploy the next infrastructure version. Is there some better way to align people with new system version deployments?
Not done obviously.