Every time a transaction with a TO ETH ADDRESS that does not have an account already created in L2 (for the transaction token) and also does not have provided the authorization to create an account on behalf of the account owner, makes the txselector to load this tx in order to validate it, if no account is created or authorization is sent until it gets expired, this tx cost resources and time for all the next batches being forged.
This is an example of the log we see in the coordinator when this situation happens:
2021-09-03T13:56:25Z DEBUG txselector/txselector.go:684 txsel.processTxToEthAddrBJJ {"err": "invalid L2Tx: ToIdx not found in StateDB, neither ToEthAddr found in AccountCreationAuths L2DB. ToIdx: 0, ToEthAddr: 0xdc6Bf73BC0A688bC11D5234Cb0F2719672Babd30"}
also this log is being repeated a lot of times in a row, like this:
Implementation
Create a new state like on hold to txs that are in the pool and are valid but their recipient is unknown at Account. Those transactions needs to wait for a L1 account creation transaction or an account-creation POST that creates a record at account-creation table. However, instead of resulting a lot of failure logs, the tx-selector should discard this transaction in this batch evaluation and leave it for the next one. However, this kind of transaction should only last at pool for 24 hours. Later it should be discarded.
Rationale
Every time a transaction with a
TO ETH ADDRESSthat does not have anaccountalready created in L2 (for the transaction token) and also does not have provided theauthorizationto create an account on behalf of the account owner, makes thetxselectorto load this tx in order to validate it, if no account is created or authorization is sent until it gets expired, this tx cost resources and time for all the next batches being forged.This is an example of the log we see in the coordinator when this situation happens:
also this log is being repeated a lot of times in a row, like this:
Implementation
Create a new state like
on holdto txs that are in the pool and arevalidbut their recipient is unknown at Account. Those transactions needs to wait for a L1 account creation transaction or an account-creation POST that creates a record at account-creation table. However, instead of resulting a lot of failure logs, the tx-selector should discard this transaction in this batch evaluation and leave it for the next one. However, this kind of transaction should only last at pool for 24 hours. Later it should be discarded.