frangio

frangio

Member Since 11 years ago

@OpenZeppelin,

Experience Points
390
follower
Lessons Completed
73
follow
Lessons Completed
958
stars
Best Reply Awards
109
repos

1504 contributions in the last year

Pinned
⚡ OpenZeppelin Contracts is a library for secure smart contract development.
⚡ An upgradeable proxy with minimal overhead.
⚡ Automatically expose internal Solidity functions for smart contract testing.
⚡ 🗞️ A Netlify template for LaTeX projects.
⚡ :wrench: Personal configuration files.
⚡ 🌾 Improve your workflow by caching native dependencies.
Activity
May
20
22 hours ago
Activity icon
issue

frangio issue OpenZeppelin/openzeppelin-upgrades

frangio
frangio

BUG - Wrong incompatible storage layout error

I am trying to upgrade an NFT contract. The original one (https://github.com/ndujaLabs/everdragons2-core/blob/main/contracts/Everdragons2Genesis.sol#L28) has the variables:

  bool private _mintEnded;
  bool private _baseTokenURIFrozen;
  string private _baseTokenURI;

  address public manager;

The V2 (https://github.com/ndujaLabs/everdragons2-core/blob/main/contracts/mocks/Everdragons2GenesisV2Mumbai.sol#L26) has

  bool private _mintEnded;
  bool private _baseTokenURIFrozen;
  string private _baseTokenURI;

  address public manager;

  mapping(address => bool) public pools;
  mapping(uint256 => address) public staked;

Since pools and staked are added after manager, the storage should be compatible. In fact, all tests pass.

But, trying to upgrade the contract on Mumbai, I get an error:

$ bin/deploy.sh upgradeE2Mumbai mumbai
Deploying contracts with the account: 0x34923658675B99B2DB634cB2BC0cA8d25EdEC743 to mumbai
Account balance: 7585303523419268809
Error: New storage layout is incompatible

Everdragons2Genesis: Deleted `manager`
  > Keep the variable even if unused

contracts/mocks/Everdragons2GenesisV2Mumbai.sol:30: Inserted `manager`
  > New variables should be placed after all existing inherited variables

This error does not make sense. In fact, it suggest to keep the variable manager (which has not been deleted) and later says that manager has been inserted.

Activity icon
issue

frangio issue comment OpenZeppelin/openzeppelin-upgrades

frangio
frangio

BUG - Wrong incompatible storage layout error

I am trying to upgrade an NFT contract. The original one (https://github.com/ndujaLabs/everdragons2-core/blob/main/contracts/Everdragons2Genesis.sol#L28) has the variables:

  bool private _mintEnded;
  bool private _baseTokenURIFrozen;
  string private _baseTokenURI;

  address public manager;

The V2 (https://github.com/ndujaLabs/everdragons2-core/blob/main/contracts/mocks/Everdragons2GenesisV2Mumbai.sol#L26) has

  bool private _mintEnded;
  bool private _baseTokenURIFrozen;
  string private _baseTokenURI;

  address public manager;

  mapping(address => bool) public pools;
  mapping(uint256 => address) public staked;

Since pools and staked are added after manager, the storage should be compatible. In fact, all tests pass.

But, trying to upgrade the contract on Mumbai, I get an error:

$ bin/deploy.sh upgradeE2Mumbai mumbai
Deploying contracts with the account: 0x34923658675B99B2DB634cB2BC0cA8d25EdEC743 to mumbai
Account balance: 7585303523419268809
Error: New storage layout is incompatible

Everdragons2Genesis: Deleted `manager`
  > Keep the variable even if unused

contracts/mocks/Everdragons2GenesisV2Mumbai.sol:30: Inserted `manager`
  > New variables should be placed after all existing inherited variables

This error does not make sense. In fact, it suggest to keep the variable manager (which has not been deleted) and later says that manager has been inserted.

frangio
frangio

Closing as it will be hard or impossible to reproduce the issue.

As a side note, you should be committing .openzeppelin/ into your git repository.

Activity icon
issue

frangio issue comment OpenZeppelin/contracts-wizard

frangio
frangio

Add Cairo API for a general contract

Related to https://github.com/OpenZeppelin/contracts-wizard/issues/110 and https://github.com/OpenZeppelin/contracts-wizard/issues/82

Requested for https://github.com/onlydustxyz/generator-starknet/issues/28

Proposed API

New function:

function printGeneral(opts?: GeneralOptions): string

With the following interfaces:

interface GeneralOptions {
  name: string;
  access?: 'ownable' | false;
  upgradeable?: boolean;
  info?: {
    license?: string;
  };
  storageVars?: StorageVariable[];
}

interface StorageVariable {
  name: string;
  type: 'felt' | 'Uint256';
  view?: boolean;
  setInConstructor?: boolean;
}

Open questions

  • Feedback welcome on function or option names
  • Should the storage variables support arguments or multiple values? (this would increase complexity when posing the questions in the user interface (whether console or GUI))
Activity icon
issue

frangio issue comment OpenZeppelin/openzeppelin-contracts

frangio
frangio

ERC4626

Fixes #3393

Reference EIP.

We still have not decided the scope of customization we want to include in this implementation (fees?) Should ERC165 be included? The ERC does not mention it.

Feel free to discuss/ask for features.

PR Checklist

  • Tests
  • Documentation
  • Changelog entry
  • Check ERC compliance
frangio
frangio

I'm thinking we should add fees. Isn't the contract otherwise vulnerable to sandwich attacks of the transaction where interest is accrued? I feel like I must be missing something there. Maybe the interest would just be small enough that a sandwich attack wouldn't really be profitable.

pull request

frangio merge to OpenZeppelin/openzeppelin-contracts

frangio
frangio

ERC4626

Fixes #3393

Reference EIP.

We still have not decided the scope of customization we want to include in this implementation (fees?) Should ERC165 be included? The ERC does not mention it.

Feel free to discuss/ask for features.

PR Checklist

  • Tests
  • Documentation
  • Changelog entry
  • Check ERC compliance
open pull request

frangio wants to merge OpenZeppelin/openzeppelin-contracts

frangio
frangio

ERC4626

Fixes #3393

Reference EIP.

We still have not decided the scope of customization we want to include in this implementation (fees?) Should ERC165 be included? The ERC does not mention it.

Feel free to discuss/ask for features.

PR Checklist

  • Tests
  • Documentation
  • Changelog entry
  • Check ERC compliance
frangio
frangio

We shouldn't expect this to be overriden, the contract should have reasonable behavior out of the box.

So yes, the first depositor gets all the previous assets for free ... but it would also have got them for free if they had been transferred to the vault just after the deposit.

The fact that these things commute makes me think the current behavior is reasonable.

Activity icon
issue

frangio issue comment rollup/rollup

frangio
frangio

All but the first change to an indirect dependency are ignored by watch

Rollup Version

v2.74.1

Operating System (or Browser)

Linux

Node Version (if applicable)

v16.14.2

Link To Reproduction

https://replit.com/@frangio/rollup-repro-watch-deps

Expected Behaviour

When an indirect dependency changes on disk during watch mode, the build is rerun. Files added by plugins using addWatchFile behave the same as those added natively by Rollup.

Actual Behaviour

Using rollup-plugin-styles, indirect CSS dependencies (via CSS @import) only trigger a rebuild the first time they change, and any subsequent changes to that particular file are ignored.

I don't think this is an issue with the plugin. Here's the line where it watches imported files:

https://github.com/Anidetrix/rollup-plugin-styles/blob/ca9879deca6de34da52a1f90cd25fc52d77f1985/src/index.ts#L100

Note that this doesn't happen for direct CSS dependencies of JS files, which are handled by Rollup. It only happens with those added by the plugin.

The reproduction repl starts watch mode. Change files to see when it gets rebuilt and when it doesn't.

frangio
frangio

By the way I spent a while trying to debug the cause but couldn't figure it out.

pull request

frangio merge to OpenZeppelin/openzeppelin-contracts

frangio
frangio

Procedural SafeCast.sol generation

Fixes #3159

PR Checklist

  • Tests
  • Documentation
  • Changelog entry
pull request

frangio merge to OpenZeppelin/openzeppelin-contracts

frangio
frangio

Procedural SafeCast.sol generation

Fixes #3159

PR Checklist

  • Tests
  • Documentation
  • Changelog entry
push

frangio push Amxx/openzeppelin-contracts

frangio
frangio
frangio
frangio

Add mention of events possibly emitted (#3421)

frangio
frangio

Add uint to uint enumerable map (#3338)

frangio
frangio

Merge branch 'master' into codegen/safecast

commit sha: 5b1d4917358276a3d024913403a2c2a33096e614

push time in 6 hours ago
pull request

frangio merge to OpenZeppelin/openzeppelin-contracts

frangio
frangio

Procedural SafeCast.sol generation

Fixes #3159

PR Checklist

  • Tests
  • Documentation
  • Changelog entry
Activity icon
issue

frangio issue rollup/rollup

frangio
frangio

All but the first change to an indirect CSS dependency are ignored by watch

Rollup Version

v2.74.1

Operating System (or Browser)

Linux

Node Version (if applicable)

v16.14.2

Link To Reproduction

https://replit.com/@frangio/rollup-repro-watch-deps

Expected Behaviour

When an indirect dependency changes on disk during watch mode, the build is rerun. Files added by plugins using addWatchFile behave the same as those added natively by Rollup.

Actual Behaviour

Using rollup-plugin-styles, indirect CSS dependencies (via CSS @import) only trigger a rebuild the first time they change, and any subsequent changes to that particular file are ignored.

I don't think this is an issue with the plugin. Here's the line where it watches imported files:

https://github.com/Anidetrix/rollup-plugin-styles/blob/ca9879deca6de34da52a1f90cd25fc52d77f1985/src/index.ts#L100

Note that this doesn't happen for direct CSS dependencies of JS files, which are handled by Rollup. It only happens with those added by the plugin.

The reproduction repl starts watch mode. Change files to see when it gets rebuilt and when it doesn't.

pull request

frangio merge to OpenZeppelin/openzeppelin-contracts

frangio
frangio

Procedural SafeCast.sol generation

Fixes #3159

PR Checklist

  • Tests
  • Documentation
  • Changelog entry
frangio
frangio
May
19
1 day ago
started
started time in 23 hours ago
pull request

frangio merge to OpenZeppelin/openzeppelin-contracts

frangio
frangio

Procedural SafeCast.sol generation

Fixes #3159

PR Checklist

  • Tests
  • Documentation
  • Changelog entry
frangio
frangio
push

frangio push OpenZeppelin/docs.openzeppelin.com

frangio
frangio

Add tip on upgrades (#317)

Co-authored-by: Francisco Giordano [email protected]

commit sha: c75a8c6f472fa784bf274d847f706892a6559333

push time in 1 day ago
pull request

frangio pull request OpenZeppelin/docs.openzeppelin.com

frangio
frangio

Add tip on upgrades

Adding a TIP on the upgrades page to signal a good start point if the user doesn't know anything about upgradeability.

pull request

frangio merge to OpenZeppelin/docs.openzeppelin.com

frangio
frangio

Add tip on upgrades

Adding a TIP on the upgrades page to signal a good start point if the user doesn't know anything about upgradeability.

Activity icon
issue

frangio issue comment OpenZeppelin/openzeppelin-contracts

frangio
frangio

Documentation of events emitted by functions

Currently, we require the natspec comment of each function to include details of events emitted by this function.

Some cases are however not that simple and need to be clarified:

  • Should a function's documentation include events emitted by sub-calls?
  • What if a function may or may not emit an event depending on the state? What wording should be used?
  • What if a function triggers another contract to emit an event?

As an example, the PullPayment includes a dedicated Escrow instance. Calling withdrawPayments on the pull payment contract will not directly emit any events, but will cause the Escrow (which is another address) to emit the Withdrawn event. Should that be documented in the withdrawPayments natspec comments?

A proposal is to automate that part in the future, by analysing the function code and detecting events being emitted, but that might be difficult to do, particularly with regard to "WILL" vs "MAY"

frangio
frangio

An argument for automating it in doc generation is that if you are looking at the code it's already more or less evident what events are emitted. If they are indirectly emitted as part of a function call it's not so obvious but still possible to get the info, and with go-to-definition becoming more available even more so.

As for "will emit" vs "may emit", I think it would be fine to default to "may emit".

pull request

frangio pull request OpenZeppelin/openzeppelin-contracts

frangio
frangio

Custom errors start with the address of the emitter

As previously discussed here, custom errors should start with the address of the emitter.

PR Checklist

  • Tests
  • Documentation
  • Changelog entry
Activity icon
issue

frangio issue comment OpenZeppelin/openzeppelin-contracts

frangio
frangio

Custom errors start with the address of the emitter

As previously discussed here, custom errors should start with the address of the emitter.

PR Checklist

  • Tests
  • Documentation
  • Changelog entry
frangio
frangio

After a brief discussion with @Amxx, both us now agree that we should not do this for the following reasons:

  • It's redundant information. For debugging, services like ethtx.info and Tenderly already know how to display the emitter, and we expect block explorers to display it as well.
  • It's not reliable inforation. Custom error parameters can be forged by an attacker.

I share the intention behind the proposal, and agree that we want a competitive landscape for explorers, but I don't think this is the way we achieve that goal.

pull request

frangio pull request OpenZeppelin/openzeppelin-contracts

frangio
frangio

Add mention of events possibly emitted

Fixes #3376

PR Checklist

  • Changelog entry
Activity icon
issue

frangio issue OpenZeppelin/openzeppelin-contracts

frangio
frangio

Suggesting updates on the doc of AccessControl._grantRole and AccessControl._revokeRole

Hi,

The AccessControl._grantRole function might emit a RoleGranted event, which is not documented in its doc. https://github.com/OpenZeppelin/openzeppelin-contracts/blob/fcf35e5722847f5eadaaee052968a8a54d03622a/contracts/access/AccessControl.sol#L220

Similarly, the AccessControl._revokeRole function might emit a RoleRevoked event, which is not documented in its doc either. https://github.com/OpenZeppelin/openzeppelin-contracts/blob/fcf35e5722847f5eadaaee052968a8a54d03622a/contracts/access/AccessControl.sol#L232

A potential fix could be adding "Might emit a {RoleGranted} event" to the doc of AccessControl._grantRole, and adding a "Might emit {RoleRevoked} event" to the doc of AccessControl._revokeRole, respectively.

Could you please check it?

Thanks.

pull request

frangio merge to OpenZeppelin/openzeppelin-contracts

frangio
frangio

Add mention of events possibly emitted

Fixes #3376

PR Checklist

  • Changelog entry
pull request

frangio merge to OpenZeppelin/openzeppelin-contracts

frangio
frangio

Add mention of events possibly emitted

Fixes #3376

PR Checklist

  • Changelog entry
May
18
2 days ago
open pull request

frangio wants to merge OpenZeppelin/openzeppelin-contracts

frangio
frangio

Procedural SafeCast.sol generation

Fixes #3159

PR Checklist

  • Tests
  • Documentation
  • Changelog entry
frangio
frangio
// Returns the version of OpenZeppelin Contracts in which a particular function was introduced.
// This is used in the docs for each function.
const version = (selector, length) => {
open pull request

frangio wants to merge OpenZeppelin/openzeppelin-contracts

frangio
frangio

Procedural SafeCast.sol generation

Fixes #3159

PR Checklist

  • Tests
  • Documentation
  • Changelog entry
frangio
frangio

It doesn't make sense to use Chai here because there's a native assert module. Chai is a testing library. This change should do:

const assert = require('assert');
Previous