Tag Archives: json

contracts

Creyzies Contract Review

Leave a comment

Creyzies is the official companion collect to mfers, by Reylarsdam. Every mfers holder received an equivalent amount of Creyzies in a surprise airdrop on 4/20/2022, with all expenses paid by Sartoshi, the creator of mfers.

The contract was written by West Coast NFT, who also wrote the mfers contract. Let’s take a look at the code, which begins with a giant ascii creyzie.

Airdrop

    struct SendData {
        address receiver;
        uint256 amount;
    }

 ...

    function airdrop(SendData[] calldata sendData) external onlyRole(SUPPORT_ROLE) nonReentrant {
        uint256 ts = baseContractAddress.totalSupply();

        // loop through all addresses
        for (uint256 index = 0; index < sendData.length; index++) {
            require(totalSupply() + sendData[index].amount <= ts, 'Exceeds original supply');
            _safeMint(sendData[index].receiver, sendData[index].amount);
        }
    }

The airdrop function receives an array of SendData structs, each of which specifies a receiver address and an amount of tokens to airdrop. Before this function was called, the devs did a snapshot of all mfers owner addresses, and counted how many mfers were owned by each address, to create this SendData array. Then they called this function 14 times to perform the airdrop, for a total gas cost of ~15 ETH. Sartoshi deposited 20 ETH to fund the airdrop, then withdrew 5 ETH when the airdrop was complete.

The baseContractAddress is the mfers contract address, which you can see in the Constructor Arguments below the code. So the first line of the function gets the total number of mfers from the mfers contract. Then, looping through the array of SendData, there’s a requirement that the current supply + the amount to be minted is less than or equal to the total mfers supply. The amounts should have been calculated correctly during the snapshot, but this is a good way to enforce the supply limit. Finally, the amount of tokens is minted to the receiver address. The Creyzies contract uses ERC721A, so minting multiple tokens at a time is very efficient.

There’s no token ownership checks at mint time, so this does all assume that the SendData was calculated correctly from a snapshot. Some addresses were explicitly left out of the airdrop – these were known smart contract addresses such as a Gnosis Safe or NiftyGateway. The devs knew the airdrop may not work for them, so they setup a claim site and implemented a redeem function.

Redeem

    function setUnclaimedTokenIds(uint256[] calldata tokenIds) external onlyRole(SUPPORT_ROLE) {
        for (uint256 index = 0; index < tokenIds.length; index++) {
            unclaimedTokenIds[tokenIds[index]] = true;
        }
    }

    function redeem(uint256[] calldata tokenIds) external nonReentrant {
        uint256 numberOfTokens = tokenIds.length;

        for (uint256 index = 0; index < numberOfTokens; index++) {
            require(unclaimedTokenIds[tokenIds[index]], 'Token has already been claimed');

            try baseContractAddress.ownerOf(tokenIds[index]) returns (address ownerOfAddress) {
                require(ownerOfAddress == msg.sender, 'Caller must own NFTs');
            } catch (bytes memory) {
                revert('Bad token contract');
            }

            unclaimedTokenIds[tokenIds[index]] = false;
        }

        uint256 ts = baseContractAddress.totalSupply();
        require(totalSupply() + numberOfTokens <= ts, 'Exceeds original supply');

        _safeMint(msg.sender, numberOfTokens);
    }

Sartoshi posted claim instructions to redeem unclaimed tokens that were not airdropped. setUnclaimedTokenIds was called immediately after the airdrop, and sets a flag to true in unclaimedTokenIds. Then, when an owner goes to creyzies.art to claim their token(s), the redeem function is called. For each token attempting to be redeem, the function checks that

  1. The token hasn’t been claimed already
  2. The redeemer (msg.sender) owns the corresponding mfers token.

If those checks pass, the token is marked as claimed. But before it is minted, there is one final check that minting these tokens won’t exceed the total mfers supply. The devs definitely put some extra effort into the contract to double check their work, to ensure that Creyzies tokens went to the right addresses and never exceeded mfers supply.

Royalties

Often, royalties from sales are handled by secondary marketplaces, using info from royaltyregistry.xyz. However, this contract implements ERC2981, which defines a royalty standard specified in the contract. Like with mfers, the default royalties are set fairly low, to 2.5%. The royalties are sent to 0x750314177EF0a319DCdC959599C76D63964729f1, which appears to be another contract that splits the royalties automatically.

Provenance

Like with The Picaroons, a provenance hash was set before minting, to 3307bc0bd06029bba4a826856f2e19db62d6df5b7f70d447fa5262117256c46c. They also published a page proving the fairness of the drop.

Token URI

While some NFTs exist fully on chain, most are token numbers in a contract that point to a URI. This URI points to metadata, which is where to find the NFT image and properties. For mfers, the token URI is on ipfs, a distributed filesystem, where the JSON metadata for each mfers token is stored. Creyzies, though, currently points to a web app on heroku.

The token URI for Creyzies #1 is https://minting-pipeline-10.herokuapp.com/1

This is not great, because it means that the Creyzies metadata depends on a Heroku app running correctly and being available. ipfs, being distributed, is a more decentralized and resilient location, and any files stored there can’t be changed without changing the URI. Metadata being served from a web app can be changed very easily. Hopefully there’s a plan to put all the metadata into ipfs as well; the images are there already. If that is done correctly, then the devs can call setBaseURI with the new ipfs URI, just like they did to set the heroku base URI. However, if there is some other surprise planned that requires changing the metadata, then keeping the token URIs pointing to a web app make sense.

    function setBaseURI(string memory baseURI_) external onlyRole(SUPPORT_ROLE) {
        _baseURIextended = baseURI_;
    }

    /**
     * @dev See {ERC721-_baseURI}.
     */
    function _baseURI() internal view virtual override returns (string memory) {
        return _baseURIextended;
    }

Slither Analysis

In order to make slither work this time, I had to tweak the code for one of the dependencies, crytic-compile. Using my branch, you can run slither to analyze the contract.

$ slither 0x19bb64b80cbf61e61965b0e5c2560cc7364c6546 --print human-summary

The issues can all be seen by running slither 0x19bb64b80cbf61e61965b0e5c2560cc7364c6546. I think the way this contract calls baseContractAddress.ownerOf within a try-catch block might be a little unusual, since slither says the return value is unused, when that’s not really the case. The other medium issues are within ERC721A._mint, and look ignorable. However there is an issue about costly operations inside a loop within ERC721A._mint, for _currentIndex = updatedIndex. This is within an unchecked block, which is the same thing that the Counters library does. The Azuki gas optimization analysis was pretty extensive, so there may not be any more that can be done to optimize gas in this case.

Conclusion

This is a very nice & unexpected gift to all mfers holders, and it looks like the devs did excellent work to ensure accuracy and minimize airdrop costs. The Crezies art is cc0 just like mfers, and it’s definitely worth checking out more of Rey’s work.

erlang

Mnesia Records to MongoDB Documents

20 Comments

I recently migrated about 50k records from mnesia to MongoDB using my fork of emongo, which adds supervisors with transparent connection restarting, for reasons I’ll explain below.

Why Mongo instead of Mnesia

mnesia is great for a number of reasons, but here’s why I decided to move weotta’s place data into MongoDB:

Converting Records to Docs and vice versa

First, I needed to convert records to documents. In erlang, mongo documents are basically proplists. Keys going into emongo can be atoms, strings, or binaries, but keys coming out will always by binaries. Here’s a simple example of record to document conversion:

record_to_doc(Record, Attrs) ->
    % tl will drop record name
    lists:zip(Attrs, tl(tuple_to_list(Record))).

This would be called like record_to_doc(MyRecord, record_info(fields, my_record)). If you have nested dicts then you’ll have to flatten them using dict:to_list. Also note that list values are coming out of emongo are treated like yaws JSON arrays, i.e. [{key, {array, [val]}}]. For more examples, check out the emongo docs.

Heavy Write Load

To do the migration, I used etable:foreach to insert each document. Bulk insertion would probably be more efficient, but etable makes single record iteration very easy.

I started using the original emongo with a pool size of 10, but it was crashy when I dumped records as fast as possible. So initially I slowed it down with timer:sleep(200), but after adding supervised connections, I was able to dump with no delay. I’m not exactly sure what I fixed in this case, but I think the lesson is that using supervised gen_servers will give you reliability with little effort.

Read Performance

Now that I had data in mongo to play with, I compared the read performance to mnesia. Using timer:tc, I found that mnesia:dirty_read takes about 21 microseconds, whereas emongo:find_one can take anywhere from 600 to 1200 microseconds, querying on an indexed field. Without an index, read performance ranged from 900 to 2000 microseconds. I also tested only requesting specific fields, as recommended on the MongoDB Optimiziation page, but with small documents (<10 fields) that did not seem to have any effect. So while mongodb queries are pretty fast at 1ms, mnesia is about 50 times faster. Further inspection with fprof showed that nearly half of the cpu time of emongo:find is taken by BSON decoding.

Heavy Read Load

Under heavy read load (thousands of find_one calls in less than second), emongo_conn would get into a locked state. Somehow the process had accumulated unparsable data and wouldn’t reply. This problem went away when I increased the size of the pool size to 100, but that’s a ridiculous number of connections to keep open permanently. So instead I added some code to kill the connection on timeout and retry the find call. This was the main reason I added supervision. Now, every pool is locally registered as a simple_one_for_one supervisor that supervises every emongo_server connection. This pool is in turn supervised by emongo_sup, with dynamically added child specs. All this supervision allowed me to lower the pool size back to 10, and made it easy to kill and restart emongo_server connections as needed.

Why you may want to stick with Mnesia

Now that I have experience with both MongoDB and mnesia, here’s some reasons you may want to stick with mnesia:

Despite all that, I’m very happy with MongoDB. Installation and setup were a breeze, and schema-less data storage is very nice when you have variable fields and a high probability of adding and/or removing fields in the future. It’s simple, scalable, and as mentioned above, it’s very easy to access from many different languages. emongo isn’t perfect, but it’s open source and will hopefully benefit from more exposure.

python

Django Datetime Snippets

Leave a comment

I’ve started posting over at Django snippets, which is a great resource for finding useful bits of functionality. My first set of snippets is focused on datetime conversions.

The Snippets

FuzzyDateTimeField is a drop in replacement for the standard DateTimeField that uses dateutil.parser with fuzzy=True to clean the value, allowing the parser to be more liberal with the input formats it accepts.

The isoutc template filter produces an ISO format UTC datetime string from a timezone aware datetime object.

The timeto template filter is a more compact version of django’s timeuntil filter that only shows hours & minutes, such as “1hr 30min”.

JSON encode ISO UTC datetime is a way to encode datetime objects as ISO strings just like the isoutc template filter.

JSON decode datetime is a simplejson object hook for converting the datetime attribute of a JSON object to a python datetime object. This is especially useful if you have a list of objects that all have datetime attributes that need to be decoded.

Use Case

Imagine you’re making a time based search engine for movies and/or events. Because your data will span many timezones, you decide that all dates & times should be stored on the server as UTC. This pushes local timezone conversion to the client side, where it belongs, simplifying the server side data structures and search operations. You want your search engine to be AJAX enabled, but you don’t like XML because it’s so verbose, so you go with JSON for serialization. You also want users to be able to input their own range based queries without being forced to use specific datetime formats. Leaving out all the hard stuff, the above snippets can be used for communication between a django webapp and a time based search engine.