Question: best practicies for offchain consensus

[0xmikko]

I'm working on LayerCakeSwap -DEX protocol that consumes 7 times less gas in comparison with UniSwap, based on L2 network: https://github.com/MikaelLazarev/layer-cake-swap-node

Ethereum interacts with Substrate network via emitting events (logs). It also keeps tokens and eth for swap operation which is executing on L2 chain.

My question is about the best practices for making consensus conserning offchain worker:

1. How to organize correct consensus deposit / swap process? Should it be on decl_module! section?
For the moment, each node signs new event from Ethereum with it's own signature.

1. Node gets a new event, sign it in offchain_worker and send to network.
2. All events with the same transaction(event) id is stored in double hashmap in storage.
3. Each new node checks the size of signatures for particular events. If it's bigger than threshold, it consider this event is valid and update balance on L2 network.

Is this way correct? How to calculate enough confirmations to be sure that event was listen correctly?

2. How to organize consensus process for withdraw?
Withdrawing money is only one process, when L2 networks should send information to Ethereum network back.

Basically, the process could be the following:

1. Client invokes contract method "Withdraw ETH (Token)", which emits "Withdraw ETH (Token) event"
2. Substrate node listens to this event, and make a consenus as it was written on Runtime upgrade/extrinsic scheduling #1.
3. Substrate node choose validator randomly (or using previous history, stake size etc.) who should sign a withdraw message.
4. Selected node, reduce amount of eth (token) on L2 balance and send signed transaction to Ethereum.
5. The contract got this transaction and sends eth (token) to user.

The biggest issue, which it faces is that one validator could be hacked or fraud, and send order to smartcontract to withdraw all money on his account.

To prevent this, I could see some solutions - the question - which one is the best?

1. Use multi-signature for withdraw orders. Checking signature validity cost 3K gas, which is not so much. So, 5 signature would cost 15K gas, 10K would be 30K gas. Algorithm could choose quantity depends on amount, for example.
2. Make contract pausable. If K nodes listen for fraud withdrawals, the could send pause transaction to block stealing more money. With withdraws limit for 1 eth block, it could save money in case of fraud.
3. This limit could also be connected with validators stake. In some perspective, 5 validators, for example could validate the maximum withdrawal for total stakes they own. An user could make a request, using ChainLink connector to check the operation. Chainlink will ask L2 network to prove the correctness. If not, stakes of fraud validators would be returned to pool.

3. Technical question: is it possible to make a http request (to send singed tx) from decl_moudle?
Another key point is about sending transaction to Ethereum network. Where the best place for that in Substrate node?
And even more, sending transaction is async process without clear timing - how to implement this logic? And repeat logic if the i/o problem was occured?

I'm open for discussion, please, share your ideas and the best practises to solve this technical issue.

Thanks,
Mikael