Skip to content

Ability to set starting token id for ERC721Consecutive #4097

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ernestognw merged 20 commits into from
May 26, 2023
Merged

Ability to set starting token id for ERC721Consecutive #4097

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
20 commits
Select commit Hold shift + click to select a range
b693f7f
first consecutive id
kfishnchips Mar 10, 2023
bf8c076
linting and changeset
kfishnchips Mar 10, 2023
31a565b
using bound instead of assume and small test refactor
kfishnchips Mar 10, 2023
b651b93
modify transfer test to include starting token id
kfishnchips Mar 10, 2023
854b461
checking boundaries
kfishnchips Mar 10, 2023
1c7570d
reduce lookup and rename function for clarity
kfishnchips Mar 10, 2023
ab40061
rename _totalConsecutiveSupply → _nextConsecutiveId
Amxx Mar 10, 2023
1835727
Merge remote-tracking branch 'kfishnchips/master'
Amxx Mar 10, 2023
1fdcbff
Update .changeset/spotty-hotels-type.md
kfishnchips Mar 10, 2023
44cc563
fix minor bug
Amxx Mar 10, 2023
3f8b0f9
Merge branch 'master' of github.com:kfishnchips/openzeppelin-contracts
Amxx Mar 10, 2023
573fa0d
test multiple offsets
Amxx Mar 10, 2023
5d9b21b
make firstConsecutiveId immutable in fuzz tests
Amxx Mar 10, 2023
0fcb048
fix lint
Amxx Mar 10, 2023
dd1d6bf
Merge branch 'master' into master
kfishnchips Mar 10, 2023
361aa8d
Update docs
ernestognw Mar 13, 2023
114a3f6
Merge branch 'master' into master
kfishnchips Mar 13, 2023
6b4e4ee
Merge branch 'master' into master
kfishnchips Mar 27, 2023
78ed610
Merge branch 'master' into master
kfishnchips Apr 6, 2023
7959df3
Merge branch 'master' into master
kfishnchips May 25, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next Next commit
first consecutive id
  • Loading branch information
@kfishnchips
kfishnchips committed Mar 10, 2023
commit b693f7f9d13e24e6df7556f4b10fccae8a47f5df
7 changes: 6 additions & 1 deletion contracts/token/ERC721/extensions/ERC721Consecutive.sol
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -141,8 +141,13 @@ abstract contract ERC721Consecutive is IERC2309, ERC721 {
super._afterTokenTransfer(from, to, firstTokenId, batchSize);
}

/**
* @dev Used to offset the first token id in {_totalConsecutiveSupply}
*/
function _firstConsecutiveId() internal view virtual returns (uint96) { return 0; }

function _totalConsecutiveSupply() private view returns (uint96) {
(bool exists, uint96 latestId, ) = _sequentialOwnership.latestCheckpoint();
return exists ? latestId + 1 : 0;
return exists ? latestId + 1 : _firstConsecutiveId();
Copy link
Member

@ernestognw ernestognw Mar 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think 0 to _firstConsecutiveId() should be accounted for the _totalConsecutiveSupply, it affects line 135, which will be excluding the after hook for real burned tokenIds

For example:

  1. Someone replaces _firstConsecutiveId() with a 5
  2. They consecutively mint tokenIds from 5 to 9 (5 mints)
  3. After that, someone else mints the token 2 via normal minting
  4. Then, they burn it, and the token will make it to the _sequentialBurn on the ownerOf(...) method, which is not what we want

I think this is what we should aim for:

Suggested change
return exists ? latestId + 1 : _firstConsecutiveId();
return exists ? latestId + 1 - _firstConsecutiveId() : 0;

Copy link
Contributor Author

@kfishnchips kfishnchips Mar 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make more sense for someone to consecutively mint token 10 instead of 2? I was thinking that there could be no minting below the first consecutive id.

Copy link
Contributor Author

@kfishnchips kfishnchips Mar 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would requiring that the tokenId be greater than the last batch minted one in the _mint function be a viable option? It might be too inefficient...

    function _mint(address to, uint256 tokenId) internal virtual override {
        require(Address.isContract(address(this)), "ERC721Consecutive: can't mint during construction");
        (, uint96 latestId, ) = _sequentialOwnership.latestCheckpoint();
        require(tokenId > latestId, "ERC721Consecutive: token id must be greater than latest id");
        super._mint(to, tokenId);
    }

Copy link
Collaborator

@Amxx Amxx Mar 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is something we don't want, because it adds 2 (cold) sload to the mint operation, which we want to keep as cheap as possible.

Also, if we do that, it would be impossible to _mint a token that was first minted as part of a batch then burnt.

Copy link
Collaborator

@Amxx Amxx Mar 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note that mint already check if the tokenId has an owner, and revert if that is the case.

Copy link
Contributor Author

@kfishnchips kfishnchips Mar 11, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, I'm still wrapping my head around the internals of this but I think I got it.

}
}
53 changes: 43 additions & 10 deletions test/token/ERC721/extensions/ERC721Consecutive.t.sol
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,8 +15,10 @@ function toSingleton(address account) pure returns (address[] memory) {

contract ERC721ConsecutiveTarget is StdUtils, ERC721Consecutive {
uint256 public totalMinted = 0;
uint96 public firstConsecutiveId = 0;

constructor(address[] memory receivers, uint256[] memory batches) ERC721("", "") {
constructor(address[] memory receivers, uint256[] memory batches, uint96 startingId) ERC721("", "") {
firstConsecutiveId = startingId;
for (uint256 i = 0; i < batches.length; i++) {
address receiver = receivers[i % receivers.length];
uint96 batchSize = uint96(bound(batches[i], 0, _maxBatchSize()));
Expand All @@ -28,36 +30,43 @@ contract ERC721ConsecutiveTarget is StdUtils, ERC721Consecutive {
function burn(uint256 tokenId) public {
_burn(tokenId);
}

function _firstConsecutiveId() internal view virtual override returns (uint96) {
return firstConsecutiveId;
}
}

contract ERC721ConsecutiveTest is Test {
function test_balance(address receiver, uint256[] calldata batches) public {
function test_balance(address receiver, uint256[] calldata batches, uint96 startingId) public {
vm.assume(receiver != address(0));
vm.assume(startingId < type(uint96).max - 5000);

ERC721ConsecutiveTarget token = new ERC721ConsecutiveTarget(toSingleton(receiver), batches);
ERC721ConsecutiveTarget token = new ERC721ConsecutiveTarget(toSingleton(receiver), batches, startingId);

assertEq(token.balanceOf(receiver), token.totalMinted());
}

function test_ownership(address receiver, uint256[] calldata batches, uint256[2] calldata unboundedTokenId) public {
function test_ownership(address receiver, uint256[] calldata batches, uint256[2] calldata unboundedTokenId, uint96 startingId) public {
vm.assume(receiver != address(0));
vm.assume(startingId < type(uint96).max - 5000);

ERC721ConsecutiveTarget token = new ERC721ConsecutiveTarget(toSingleton(receiver), batches);
ERC721ConsecutiveTarget token = new ERC721ConsecutiveTarget(toSingleton(receiver), batches, startingId);

if (token.totalMinted() > 0) {
uint256 validTokenId = bound(unboundedTokenId[0], 0, token.totalMinted() - 1);
uint256 validTokenId = bound(unboundedTokenId[0], startingId, startingId + token.totalMinted() - 1);
assertEq(token.ownerOf(validTokenId), receiver);
}

uint256 invalidTokenId = bound(unboundedTokenId[1], token.totalMinted(), type(uint256).max);
uint256 invalidTokenId = bound(unboundedTokenId[1], startingId + token.totalMinted(), startingId + token.totalMinted() + 1);
vm.expectRevert();
token.ownerOf(invalidTokenId);
}

function test_burn(address receiver, uint256[] calldata batches, uint256 unboundedTokenId) public {
function test_burn(address receiver, uint256[] calldata batches, uint256 unboundedTokenId, uint96 startingId) public {
vm.assume(receiver != address(0));
vm.assume(startingId < type(uint96).max - 5000);

ERC721ConsecutiveTarget token = new ERC721ConsecutiveTarget(toSingleton(receiver), batches);
ERC721ConsecutiveTarget token = new ERC721ConsecutiveTarget(toSingleton(receiver), batches, startingId);

// only test if we minted at least one token
uint256 supply = token.totalMinted();
Expand Down Expand Up @@ -93,7 +102,7 @@ contract ERC721ConsecutiveTest is Test {
batches[0] = bound(unboundedBatches[0], 1, 5000);
batches[1] = bound(unboundedBatches[1], 1, 5000);

ERC721ConsecutiveTarget token = new ERC721ConsecutiveTarget(receivers, batches);
ERC721ConsecutiveTarget token = new ERC721ConsecutiveTarget(receivers, batches, 0);

uint256 tokenId0 = bound(unboundedTokenId[0], 0, batches[0] - 1);
uint256 tokenId1 = bound(unboundedTokenId[1], 0, batches[1] - 1) + batches[0];
Expand All @@ -119,4 +128,28 @@ contract ERC721ConsecutiveTest is Test {
assertEq(token.balanceOf(accounts[0]), batches[0]);
assertEq(token.balanceOf(accounts[1]), batches[1]);
}

function test_start_consecutive_id(
address receiver,
uint256[2] calldata unboundedBatches,
uint256[2] calldata unboundedTokenId,
uint96 startingId
) public {
vm.assume(receiver != address(0));
uint256 startingTokenId = bound(startingId, 1, 5000);

// We assume _maxBatchSize is 5000 (the default). This test will break otherwise.
Copy link
Member

@ernestognw ernestognw Mar 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this breaking? If it's breaking because of the ownerOf range check, we definitely need to address that.

Copy link
Contributor Author

@kfishnchips kfishnchips Mar 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment about the breaking test is from a previous commit which I still can't decipher

Copy link
Collaborator

@Amxx Amxx Mar 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test tries to mint a batch that is too large. too large means bigger than _maxBatchSize. Since the contract is not yet constructed, we assume the value is 5000. If you ever override _maxBatchSize in ERC721ConsecutiveTarget , you should make sure it is reflected here.

Copy link
Contributor Author

@kfishnchips kfishnchips Mar 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, understood. Thanks for clarifying!

uint256[] memory batches = new uint256[](2);
batches[0] = bound(unboundedBatches[0], startingTokenId, 5000);
batches[1] = bound(unboundedBatches[1], startingTokenId, 5000);

ERC721ConsecutiveTarget token = new ERC721ConsecutiveTarget(toSingleton(receiver), batches, uint96(startingTokenId));

uint256 tokenId0 = bound(unboundedTokenId[0], startingTokenId, batches[0]);
uint256 tokenId1 = bound(unboundedTokenId[1], startingTokenId, batches[1]);

assertEq(token.ownerOf(tokenId0), receiver);
assertEq(token.ownerOf(tokenId1), receiver);
assertEq(token.balanceOf(receiver), batches[0] + batches[1]);
}
}