Skip to content

Latest commit

 

History

History
85 lines (51 loc) · 3.69 KB

Awesome-Q.md

File metadata and controls

85 lines (51 loc) · 3.69 KB

block.timestamp is unreliable

Using block.timestamp as part of the time checks could be slightly modified by miners/validators to favor them in contracts that contain logic heavily dependent on them.

Consider this problem and warn users that a scenario like this could occur. If the change of timestamps will not affect the protocol in any way, consider documenting the reasoning and writing tests enforcing that these guarantees will be preserved even if the code changes in the future.

Here are some of the instances: Line 28

Line 52

Line 85

Line 50-51

Typos

Consider sticking to the proper spelling of words otherwise, it will decrease readability

There are 6 instances of this issue consider making the following changes:

Line 36

Line 36:    emit DiamondCutProposalCancelation(

Refactor to

Line 36:    emit DiamondCutProposalCancellation(

Line 30, Line 296, Line 357, Line 376

Line 30:    // Check that block contain all meta information for L2 logs.

Line 296:    function _verifyRecursivePartOfProof(uint256[] calldata _recurisiveAggregationInput) internal view returns (bool) {

Line 357:    bytes32 auxiliaryOutputHash = keccak256(_blockAuxilaryOutput(_newBlockData));

Line 376:    function _blockAuxilaryOutput(CommitBlockInfo calldata _block) internal pure returns (bytes memory) {

Refactor to

Line 30:    // Check that block contains all meta information for L2 logs.

Line 296:    function _verifyRecursivePartOfProof(uint256[] calldata _recursiveAggregationInput) internal view returns (bool) {

Line 357:    bytes32 auxiliaryOutputHash = keccak256(_blockAuxiliaryOutput(_newBlockData));

Line 376:    function _blockAuxiliaryOutput(CommitBlockInfo calldata _block) internal pure returns (bytes memory) {

Unspecific Compiler Version Pragma

Avoid floating pragmas for non-library contracts.

While floating pragmas make sense for libraries to allow them to be included with multiple different versions of applications, it may be a security risk for application implementations.

A known vulnerable compiler version may accidentally be selected or security tools might fall-back to an older compiler version ending up checking a different EVM compilation that is ultimately deployed on the blockchain.

It is recommended to pin to a concrete compiler version.

For example: 🤦 Bad:

pragma solidity ^0.8.0;

🚀 Good:

pragma solidity 0.8.4;

for more info: Consensys Audit of 1inch

Solidity docs