# Репликация транзакций

Обычно архитектура у таких решений следующая:
* **Listener** - слушает mempool, event'ы из смарт-контрактов или просто транзакции в сети. Делать это можно через разные API типа Blocknative
* **Checker/Logics** - убеждается, что нужно сделать копию транзакции. Возможно, дожидается от пользователя подтверждения или меняет какие-то параметры
* **Executor** - отправляет транзакцию от имени пользователя или от себя

## 1 - Listener

В Ethereum существуют такие сущности:
1. State trie - глобальное состояние, которое меняется после каждого блока
2. Бинарный EVM код смарт контрактов
3. Транзакция - представляет собой бинарное "сообщение", которое несет параметры.

При обработке транзакции срабатывает EVM код из контракта, который может поменять глобальное состояние (поменяет состояния переменных), вызывать другие смарт-контракты, сделать какие-то еще side-effects.

Можно легко распаковать все параметры транзакции и попытаться сфорджить аналогичную. Это довольно просто, и подходит для простых транзакций, где можно подставить только чуть другие значения.

Например, при обмене в Uniswap я посылаю в их смарт-контракт следующие параметры:

Во многих случаях параметры не так просты, они запакованы или вообще поставляются в виде запакованного кода и calldata. Их распаковать сильно сложнее.

## Внутренние транзакции

В некоторых случаях тебе захочется понимать не просто внешние параметры транзакции, но и что происходит внутри. Для этого нужно уже симулировать вызовы...

Вот пример слушалки, которая умеет трейсить внутр. транзакции и понимает, что там происходит внутри при выполнении транзы:
https://explorer.blocknative.com


Вот так можно настроить в ней фильтры:

Есть всякие такие штуки - https://tenderly.co/transaction-simulator
> Run new transactions by changing some or all parameters and observing the outcome.

## 2 - Checker/Logics
Тут любая "бизнес" логика.

Transaction limits: A wallet linked to your smart account can reject a transaction (or ask for additional authorization) if the value exceeds a preset limit.

Multi-party approvals: You could delegate partial control of your account to trusted parties aka “guardians”. Guardians can be friends, family members, service providers, or even a separate device that you own (eg. a hardware wallet).

## 3 - Executor
Здесь вижу такие варианты:
* Транзакция формируется вашей тулзой, но пользователю требуется ее подписать ("открытие метатаска на каждый чих"). За газ платит сам юзер. То есть вы просто генерируете за него транзакцию и предлагаете подписать. Это довольно просто.
* Custodial - ваша тулза сама торгует, то есть источник всех транзакций - ваш EOA. Средства хранятся в вашем смарт-контракте, пользователь может их потом вывести. В целом это тоже норм. Если у вас не будет возможности обновлять код и выводить деньги себе, то это может быть ок. Это тоже довольно просто. Очень сильно походит на InstaDapp - у них как раз средства кладутся в smart account, который далее может торговать/ребалансировать токены итд - https://blog.instadapp.io/defi-smart-accounts/ и вот еще https://github.com/bcnmy/scw-contracts
* Какая-то более хитрая схема с Account Abstraction и relayer'ами. Короче, усложнить и навернуть можно довольно неслабо))

# Куда еще посмотреть:
1. Gasless транзакции, когда газ платит за пользователя 3я сторона - таких штук сейчас много на рынке. Обычно требуется обновить код конечного смарт-контракта, поэтому просто так ее воткнуть посередине не получится.
2. Скоро появится Account abstraction -
> With account abstraction, users don’t need to download wallets and sign transactions every time they want to complete an action. Instead, transactions can be bundled and approved at once. That’s a vast UX improvement for Web3 applications.

https://metamask.io/news/latest/account-abstraction-past-present-future/

Вообще, я бы покопал именно в эту сторону, потому что AA становится все более реальным. Было бы круто встроиться в эту схему.

3. [Instadapp Smart Accounts](https://gist.github.com/mingyeow/a9dd6fabb6bf112376c9039fc39640ed)
>DeFi accounts can compose and execute any number of actions from connectors in a single web3 transaction. Using only web3 calls, frontend developers will be able to string together the available actions in the connectors to create innovative new transactions.
Об этом я писал выше.
4. Множество разных подходов с Proxies:
* https://docs.lens.xyz/docs/dispatcher - The Dispatcher enables gasless and signless transactions (transactions without signing any approval modals) in your Lens app. Basically, it is an intermediate wallet with funds that act as the signer for every transaction. We only have to delegate signing privileges to this dispatcher wallet which operates hidden in the backend.
* https://docs.openzeppelin.com/contracts/3.x/api/proxy#Clones - To simply and cheaply clone contract functionality in an immutable way, this standard specifies a minimal bytecode implementation that delegates all calls to a known, fixed address.

## References
* https://boto.io
* https://cryptocurrencyalerting.com
* https://parsiq.net/tsunami
* https://chain.link/automation
* ...