lacnetnetworks / gas-management Goto Github PK

As I understand it, the proper way to write a smart contract under the proposed change is the following:

• If the function is called from an Ethereum account, then msg.sender won't work, and the sending address must be retrieved through _msgSender().
• If the function is called from another contract, then msg.sender will work, but _msgSender() won't.

If that's correct, I don't think we can go with that model, because we can't expect smart contract authors to know or to restrict how their functions will be called.

What's worse, I don't think a smart contract can detect if it's being called from an account or from another contract, so we will have an unexpected behaviour 50% of the time. If it can be detected however, then that logic should be implemented in _msgSender() so it does behave as a drop-in remplacement for msg.sender.

Hardhat use EIP155 to sign transactions, it is necessary to adapt hardhat to deploy smart contracts and send transactions.

Using Truffle is possible to deploy contracts, but send transactions return a Error without reason (Error Reverted). It is happening because Truffle regenerate function bytes name using ABI. When ABI is changed due to two extra parameters are needed, then ABI gets another function name.

As I understand it, the proper way to write a smart contract under the proposed change is the following:

• If the function is called from an Ethereum account, then msg.sender won't work, and the sending address must be retrieved through _msgSender().
• If the function is called from another contract, then msg.sender will work, but _msgSender() won't.

If that's correct, I don't think we can go with that model, because we can't expect smart contract authors to know or to restrict how their functions will be called.

What's worse, I don't think a smart contract can detect if it's being called from an account or from another contract, so we will have an unexpected behaviour 50% of the time. If it can be detected however, then that logic should be implemented in _msgSender() so it does behave as a drop-in remplacement for msg.sender.

When a transaction is sent, and it is rejected by the TxRelay smart contract, the pending nonce is not returned correctly, since it is always incrementing. This causes problems in distributed scenarios when the query is made through pending. The pending nonce could be returned equal to the latest nonce, since the TxRelay does not handle pending nonce.