Wallet types

Understanding wallet types is key to NFT security, as each type offers unique advantages and trade-offs.

Here are three wallet types:

• Cold Wallets

• Hot Wallets

• Warm Wallets

🥶 Cold Wallets

Offline storage, providing maximum security.

No direct connection to the internet, keeping your private keys and assets safe from hackers. Ideal for long-term storage or large asset holdings.

Examples: Ledger, Trezor.

🔥 Hot Wallets

Online storage, making them more convenient for frequent transactions.

Easier to access and use, but more vulnerable to hacks and phishing attacks.

Good for day-to-day transactions, but not for storing significant value.

Examples: MetaMask, Rainbow.

🌡️ Warm Wallets

A hybrid of cold & hot wallets, balancing security & accessibility.

Private keys are offline, but accessed via secure software when needed.

Suitable for moderate investments & regular transactions.

Example: Connect Ledger to MetaMask.

❄️ Ledger as a Cold Wallet

Use a Ledger hardware wallet for cold storage.

It securely stores private keys offline, keeping them away from hackers.

Safeguard your seed phrase - it's crucial for asset recovery if the device is lost or damaged.

I'm using Ledger Nano X.

🔥 Ledger as a Warm Wallet

Connect your Ledger wallet to a trusted platform like MetaMask, you can use it as a warm wallet.

This setup allows for more accessibility while maintaining a high level of security.

Just be cautious of the websites you interact with.

🕵️ Beware of Random Discord Invites

Avoid joining random Discord servers asking for message signing.

Scammers use this tactic to trick you into granting them access to your wallet.

Verify server legitimacy & admins before joining.

Example: RTFKT Alpha Group scam.

🎮 Be Cautious of closed alpha P2E Games

Avoid participating in closed alpha play-to-earn (P2E) games without researching the game and the development team behind it.

Scammers may use fake P2E games to steal your assets and install malware on your computer.

✍️ Verify What You're Signing

Always double-check the content of transactions before signing.

If you don't understand what you're signing, don't proceed.

Educate yourself on the implications of signing various types of transactions. and messages.

🔎 Double-Check Website URLs

Always double-check website URLs when trading NFTs.

Scammers often create fake websites with similar URLs to trick users.

Ensure the domain name is spelled correctly.

Good idea is to bookmark the correct URLs and access from there.

🛡️ Use Protective Apps

Apps like Wallet Guard can provide an extra layer of security for your wallet.

They can protect against phishing attempts, low-trust websites, unverified marketplaces, and scams.

An app like this can provide human-readable insight on every transaction.

Conclusion

Read those tips, decide what's best for you, protect your assets & stay vigilant. Share knowledge, keep learning, and always double-check everything. Trust no one offering your free fortune.

How do transactions work?

Transactions are cryptographically signed data messages that contain a set of instructions. They enable the transfer of value and execution of smart contracts. It's a powerful concept that enables users to interact on the Ethereum network.

Users initiate transactions through wallets or dApps, which generate a data structure containing the transaction details. The data is signed with the sender's private key, ensuring authenticity.

Validators choose transactions in the mempool when creating new blocks, prioritizing those with higher gas prices.

The mempool (memory pool) is a temporary storage area for pending transactions waiting to be included in a block.

Mempool visualization - https://txstreet.com/v/eth-btc

Once a transaction is confirmed on the Ethereum blockchain, it's irreversible.

However, there are ways to replace a transaction by sending another transaction with the same nonce, but only if the initial transaction hasn't been confirmed yet.

The nonce is crucial for transaction processing. It prevents double-spending and ensures transactions from an address are executed in the correct order. Each transaction from an address must have a unique nonce, incrementing sequentially.

What transaction types exist?

• Regular

• Contract deployment

• Contract execution

Regular transactions transfer ETH between accounts. Nothing special here, we all do this through our Metamask when sending funds between accounts.

Contract deployment transaction creates a new contract with a unique address. This type of transaction has a zero address for the recipient (0x0000...0000) and the data field has to contain a contract bytecode.

Contract execution transaction interact with deployed contracts. The recipient is the address of the smart contract, and the transaction data field holds encoded information about the function to be executed.

Below is an example of a CloneX transfer:

https://etherscan.io/tx/0x704887d812d3c5a65ec7de5165d7f506c27a1fca25461699cce89f2189b52c31

What is gas?

It's important to understand the concept of gas in Ethereum transactions. Gas measures the computational work needed for a transaction or smart contract execution. Each operation within a transaction consumes a specific amount of gas.

The gas cost is determined by multiplying the gas used by the gas price set by the sender. The total gas cost is paid by the sender in ETH, incentivizing validators to execute the transaction.

You can check gas prices on Etherscan at any time:

https://etherscan.io/gastracker

Validators typically prioritize transactions with higher gas prices, as it increases their potential rewards. This leads to a competitive market for gas prices, which fluctuates based on network demand. Users can adjust their gas price to balance transaction speed and cost.

For faster transaction confirmations, users can set a higher gas price, making their transaction more attractive to validators. But be cautious, setting a gas price too low may result in a long wait time or even no confirmation at all.

Transactions can be sped up or canceled by sending another transaction with the same nonce but a higher gas price. This replaces the initial transaction in the mempool, as validators are more likely to process the transaction with the higher fee.

What are the possible states for a transaction?

• Pending - Awaiting confirmation in the mempool

• Queued - Cannot be mined yet due to another pending transaction

• Successful - A transaction has been confirmed and processed

• Cancelled - Can no longer be mined, replaced by a transaction with a higher gas fee, same nonce, and a null value for the data and/or value field

• Failed - A transaction failed due to insufficient gas, incorrect data, or other issues

Common reasons for a failed transaction status are:

• Insufficient gas limit

• Insufficient balance in the sender's account

• Invalid transaction data

• Reverted smart contract execution due to internal errors or conditions not met

Transaction throughput

Ethereum's transaction throughput is limited by the block gas limit, which is the maximum amount of gas that can be included in a single block. This limit is determined by validators and can be adjusted over time to improve network capacity.

Security

It's important to be aware of security when dealing with Ethereum transactions. Always double-check the recipient's address, ensure your private key is secure, and be cautious of signing random stuff.

Here is my thread about staying safe in web3:

https://twitter.com/0xMarko/status/1638541332036591618

Conclusion

Understanding basic concepts like Ethereum transactions is vital for using the network effectively.

Keep exploring and stay informed!

Let's go back to the basics and explore how Ethereum smart contracts are created, deployed, and executed.

What are smart contracts?

Smart contracts are just programs on the Ethereum blockchain. It's a collection of code (its functions) and data (its state) that resides at a specific address on the Ethereum blockchain.

Data = how many NFTs I have

Code = how to transfer NFT from A to B

How are smart contracts created?

To create a smart contract, developers usually write code in a programming language called Solidity. It's a high-level language designed specifically for Ethereum, inspired by C++, Python, and JavaScript.

You'll also see terms like Hardhat and Foundry when talking about smart contracts development. Those are special development environments that simplify the process of building, deploying, and testing smart contracts.

In Solidity, when we compile the code, we get bytecode and ABI.

Bytecode is the machine-readable format that the Ethereum Virtual Machine (EVM) can understand and execute. Bytecode consists of concise numeric codes, constants, and various data elements.

ABIs are application binary interfaces. They define the variables and methods that are available in a smart contract. Thanks to ABI, we know how to interact with that smart contract.

ABIs are represented as JSON and can look like this:

How are smart contracts deployed?

After the contract is compiled, it's time for deployment. Deployment means sending the contract to the Ethereum blockchain. It's done by creating a special transaction with the contract bytecode as data and no recipient address.

The contract is officially deployed when the deployment transaction is included in a block. The contract gets its own unique address on the blockchain, derived from the sender's address and nonce (number of transactions sent from a given address).

Fun facts:

• You can calculate a smart contract address before deployment.

• You can deploy a smart contract to multiple EVM chains to the same address.

Here is a Clone X contract deployment transaction. Notice the absence of a "To" address – this indicates that a new contract is being created (RTFKT: CloneX Token). The Input Data contains a lengthy string, which is the source code of the contract.

How to interact with smart contracts?

Now that the contract is deployed, anyone can interact with it through its functions.

There are two types of functions:

• write functions that require transaction and cost gas

• read functions that are free and don't require transaction

Write functions modify the contract state. These changes need to be propagated across the network, verified, and stored by validators in a new block. Validators require compensation for their work, which is why gas fees are associated with write functions.

Read functions don't require any changes to the blockchain state; they only access the current data. Since they don't involve modifying the blockchain, they can be executed locally on any node without needing a transaction or consensus. This makes them free of cost.

Validators pick up the transaction, execute the function within the EVM, and include the transaction in a block. The results of the function execution are recorded in the blockchain as part of the transaction receipt.

Conclusion

I hope this info helps demystify Ethereum smart contracts a bit. As smart contracts become more vital in shaping our digital future, it's important to understand how they work. Keep exploring and stay informed!

Want to save gas? Consider using Proxies! 

Here's how:

⚡Create implementation contact

⚡Create a Proxy contract that points to the implementation contract

⚡Deploy multiple proxy contracts when needed

The implementation contract is one that contains all the necessary logic for your app.

It may include numerous features, particularly if you are creating an NFT collection with several stages of minting and claiming.

The number of features in a smart contract implementation is directly proportional to the size of the bytecode, which, in turn, increases the gas required for deploying the contract.

We can reduce the deployment cost of new smart contracts by utilizing the Proxy contract.

The Proxy contract is a compact contract that utilizes the EVM instruction 'delegatecall' to delegate all function calls to another contract through its fallback function.

The Proxy contract stores the state variables and the logic contract stores the implementation code.

Check out this Proxy contract implementation I used for my ERC721 collection.

It delegates all calls to a hardcoded implementation contract address and initializes the state with an 'initialize' method that takes the collection name and symbol on deployment.

Btw, don't forget to initialize your implementation contract upon deployment.

It's a common mistake made by developers, and it can result in someone else taking ownership of the contract.

While it's generally not harmful, it depends on the type of proxy used to call it.

To learn about the various types of proxies, be sure to check out the documentation available on OpenZeppelin.

https://docs.openzeppelin.com/contracts/4.x/api/proxy

Without a provenance hash, projects have the ability to manipulate the metadata of an NFT to their advantage once the minting process has been completed.

The sequence in which NFT tokens are assigned to the metadata is important. If the order of assignment is undisclosed before the mint, buyers of the NFTs have no assurance that the project team will not modify the assignment after the mint to benefit themselves.

To address this issue, projects require a way to demonstrate that the metadata order was established before the mint and was not modified afterward.

The provenance hash provides an elegant solution to this problem.

The provenance hash is created in a few steps:

1. Create a hash for each image in the collection.

2. Concatenate the hashes in the order in which the images will be minted to create a large combined string.

3. Hash the combined string to obtain a provenance hash.

The best way to share the provenance hash with the community is by storing it in the collection's smart contract. This should only be done once before the mint. Updating it after the mint can be interpreted as a sign of potential manipulation.

The Bored Ape Yacht Club is a prime illustration of a project that utilizes a provenance hash. Anyone can go to Etherscan and read the BAYC provenance hash that is stored in the smart contract.

BAYC also created a UI to showcase how the provenance hash is calculated - https://boredapeyachtclub.com/#/provenance

So the question is, do you care about the provenance hash?

Does it concern you whether the metadata has been modified after the minting process or not?

Let’s see what is NatSpec is and how to utilize it for smart contract documentation.

NatSpec is a special documentation format for Solidity smart contracts. While good contracts can be self-documenting, including NatSpec enables developers to easily share and export documentation.

The NatSpec format consists of specially formatted comments within the Solidity code. NatSpec comments start with `///` for single or `/**` ending with `*/` for multi-line comments. You are probably familiar with this syntax if you read contracts on Etherscan.

NatSpec supports different optional tags that indicate what type of information is provided. Functions usually have multiple tags attached to them, like notice, dev, params, and return.

Here is an example contract from the official Solidity documentation.

Here is a cheat sheet from the official Solidity docs that explains the purpose of each tag and where it may be used.

Once you've written tags a few times, they become familiar and you won't need to consult the cheat sheet anymore.

If no tags are used, then the Solidity compiler will interpret `///` or `/**` comments in the same way as if they were tagged with the notice tag. Nice default right there.

If you are using HardHat, then NatSpec documentation can be easily exported and updated on each compile. You'll have to add and configure `hardhat-docgen` plugin that does the magic. Plugin has different options so set it up as you like.

A good rule of thumb is to always add NatSpec for all public interfaces (everything in the ABI). Exported documentation can be easily understood by your frontend & backend teams that have to integrate smart contracts in the app.

Thanks for reading.

Follow me on Twitter for more!

https://twitter.com/0xMarko/status/1625840520219041793

First, let’s take a step back to understand the events and how they are stored.

Events in Solidity serve as a mechanism for smart contracts to emit information. They are triggered by functions within the contract and can be monitored by external applications.

An event log is a record of an event that has been triggered and recorded on the blockchain in a form of a special data structure.

Event logs are a more economically friendly method for storing data that is not required for smart contracts to function properly.

Logs require 8 gas per byte while smart contract storage requires 20k gas per 32 bytes. However, it is essential to note that logs are not accessible by smart contracts.

Each event log contains information about the event, an array of topics, and data.

Topics are used to describe the event. The maximum number of topics we can store in a log is 4.

The first topic usually consists of the signature of the event name, including the types of its parameters. This signature is not included as the first topic when emitting anonymous events.

Topics can only hold a maximum of 32 bytes of data, so things like arrays or strings cannot be stored correctly. If you try to store data bigger than 32 bytes, the topic will be hashed instead.

But, arrays and strings can be stored as event data. Event data is not limited to 4x32 byes like topics, which means it can store more complex data.

It's important to note that topics are searchable, but data is not. That means you can filter event logs by topic values. On the other hand, including data is a lot cheaper than including topics.

Event parameters that are marked as `indexed` will be included as additional topics in the topics array of the event log. The rest of the event parameters will still be available in event data, but you won't be able to filter logs by those values.

Event logs can be read using Ethereum client libraries or any specialized library such as ethers.js.

To read an event log, you need to know the contract address, contract ABI, the event name, and the block range in which the event was triggered.

The `indexed` keyword allows us to optimize the way event data is stored on the blockchain, making it easier to retrieve as needed.

Ordinal NFTs (aka digital artifacts or inscriptions) allow users to mint non-fungible tokens onto Bitcoin's blockchain.

Ordinals take advantage of Taproot & Segwit witness data to store JPEGs, videos, games, etc.

Ordinal Theory is the fundamental idea behind Ordinals.

It allows for the creation of Bitcoin-native digital artifacts, "inscribed" to individual Satoshis.

This allows for non-fungible characteristics to be imbued in these Satoshis, similar to traditional NFTs.

Inscriptions leverage capabilities based on Taproot Bitcoin soft fork to store content in Taproot script-path spend scripts.

These scripts have fewer limitations, allowing for the inclusion of content in Taproot outputs.

Inscription data is always stored on-chain and cannot reference any off-chain content.

This feature of inscriptions results in increased durability, as the content cannot be lost, and scarcity, as creators must pay fees that are proportional to the size of the content.

Inscription data is extra non-financial data and will be forever included in the blockchain.

Adding unique traits to Satoshis may harm Bitcoin's privacy and fungibility in the long run.

Inscribed Satoshis will forever differ from those without inscriptions.

If NFTs were to take off on Bitcoin, the increased storage and bandwidth requirements could lead to higher technical requirements for running a full node.

This can result in a potential centralization of the network.

Ordinal protocol has the potential to change the way people interact with the Bitcoin network and make Bitcoin more appealing to the NFT community.

Excited to see where it goes from here. 🚀

In this post, we’ll go over BAYC smart contract code. The source code is available on EtherScan.

ERC721

BAYC is implemented as an ERC721 token, a standard that defines a set of functions that a smart contract must implement in order to be considered a compliant ERC721 token.

These functions include the ability to transfer tokens, approve other addresses to manage your tokens, and check token ownership.

BAYC uses a standard basic implementation of ERC721.

Ownable contract

The contract inherits the Ownable contract which provides basic authorization control functions. It also provides _onlyOwner modifier which restricts certain functions or methods within a smart contract to be executed only by the contract owner.

The owner of a contract is set during the contract deployment and can only be changed by the current owner.

SafeMath library

The contract also uses the SafeMath library. When writing smart contracts, it's important to handle mathematical operations carefully. A single overflow or underflow can result in the loss of funds, data corruption, or other severe issues. For example, an overflow can occur when the result of a mathematical operation exceeds the maximum possible value that can be stored in a variable. In such a case, the result "wraps around" to a negative number and the smart contract will continue to execute with incorrect results.

The SafeMath library provides a simple solution to this problem by checking the result of each mathematical operation and ensuring that it is within the acceptable range. If an overflow or underflow occurs, the library will revert the transaction, preventing the smart contract from executing with incorrect results.

Since Solidity 0.8, the overflow/underflow check is implemented on the language level. Validation is added to the bytecode during compilation. You don't need the SafeMath library for Solidity 0.8+.

Variables

BAYC smart contract has several important variables:

• BAYC_PROVENANCE: a string variable that stores the provenance hash of the token. The NFT Provenance Hash ensures the fairness of a project’s NFT distribution during and post-mint.

• MAX_APES: a variable that stores the maximum number of Bored Ape tokens that can be minted

• REVEAL_TIMESTAMP: a variable that stores the reveal timestamp for the token sale

• startingIndexBlock: a variable that stores the block number of the starting index for the collection

• startingIndex: a variable that stores the starting index of the collection

• apePrice: a constant that stores the price of each Bored Ape token in wei

• maxApePurchase: a constant that stores the maximum number of tokens that can be purchased at one time

• saleIsActive: a boolean variable that indicates whether the sale of Bored Ape tokens is active

Functions

withdraw:

This function allows the owner to transfer the balance of the smart contract to their own wallet. This function can only be called by the owner.

reserveApes:

This function allows the owner to reserve a set number of Bored Apes. The number of Apes that can be reserved is defined as 30. This function can only be called by the owner.

setRevealTimestamp:

This function allows the owner to set the reveal timestamp for the Bored Ape Yacht Club smart contract. The reveal timestamp is used to determine when the sales of Apes will start. This function can only be called by the owner.

setProvenanceHash:

This function allows the owner to set the provenance hash for the Bored Ape Yacht Club smart contract. This function can only be called by the owner.

setBaseURI:

This function allows the owner to set the base URI for the Bored Ape Yacht Club smart contract. The base URI is used to provide a unique identifier for the Bored Apes. This function can only be called by the owner.

flipSaleState:

This function allows the owner to pause or activate the sale of Bored Apes. When the sale is active, Bored Apes can be minted. When the sale is paused, Bored Apes cannot be minted. This function can only be called by the owner.

mintApe:

This function allows a user to mint Bored Apes. To mint Apes, the sale must be active and the user must send the correct amount of ether. The maximum number of Apes that can be minted in a single transaction is defined as 20. This function is payable, which means it requires a payment to be made in ether.

setStartingIndex:

This function sets the starting index for the collection of Bored Apes. The starting index is used to determine the order in which the Bored Apes will be collected. This function can only be called once and the starting index block must be set before this function can be called.

emergencySetStartingIndexBlock:

This function allows the owner to set the starting index block for the collection of Bored Apes in an emergency situation. It can only be called by the owner and is used in the event that the starting index block has not been set.

What is it exactly and why is it useful?

AI-generated art is a game changer in the world of digital art. Algorithms analyze existing styles, images, & data to create new pieces of art. Algorithms can also mimic a specific artistic style for a consistent, recognizable look & feel for brands or projects.

AI-generated art enables experimentation & exploration of new styles & techniques that may not have been possible with traditional methods. It has the potential to revolutionize the way we create & consume art, making it more accessible, efficient & exciting!

Why would you generate art?

• Low cost & quick production of high-quality art makes it accessible to a wider range of people & applications.

• Automates repetitive tasks, freeing up artists to focus on creative & strategic aspects of their work.

How to generate art?

There are many tools, but I really like Midjourney. Midjourney is an independent AI art generator that is open for public use and free to join with a Discord account. Simply enter a few words as a prompt in the channel, and let Midjourney do the rest.

AI and machine learning will create a unique image just for you.

Once you’re satisfied with what the bot returns, you can upscale the image and download it or send it to yourself. Plus, you can also explore a gallery of amazing images created by other users.

Here is a quick start guide for Midjourney

https://t.co/aIpzOIayh3

The general idea is to have a deterministic way to have a large number of participants that are maintaining the network.

NEAR's mission is to remove all barriers to Web3 with the goal of onboarding 1 billion users in the first five years.

Accounts

NEAR accounts have human-readable names (eg. marko.near). Top-level accounts are created by the registrar (.near). near can create bob.near, and bob.near can create app.bob.near. All accounts can be smart contracts.

The NEAR wallet is the quickest way to set up a new account. It supports 2FA and a Ledger hardware wallet. Staking is built right into the wallet, making it simple to stake NEAR and receive rewards. You can also browse your NFTs there very easily.

NEAR Accounts have the unique feature of holding multiple public/private key pairs, called Access Keys, each with its own set of permissions. Access Keys enable you to grant limited access over your account to third parties. Access Keys can be Full Access or Function Keys.

Access Keys

Access Keys provide several advantages.

You may securely pass the key to an app, allowing it to sign app-related transactions without interrupting you on the UI for each transaction (for example web3 games).

Access keys can be simply replaced if they are compromised. You may also set up a key-recovery contract in your account and allow a trusted third party to retrieve keys.

Full Access keys have full control of an account and they can perform:

• CreateAccount

• DeployContract

• FunctionCall

• Transfer

• Stake

• AddKey

• DeleteKey

• DeleteAccount

If you hand a FullAccess to someone, they will have total control over the account.

FunctionCall keys can only be used to call non-payable methods on contracts, i.e. methods that do not require you to attach NEAR Ⓝ.

The main purpose is to be handed to apps, so they can make contact calls in your name.

Gas

Gas is an interesting topic in NEAR. Transaction fees are measured in gas units but paid in $NEAR. Validators receive their reward independent from the gas fees.

30% of the fee goes to the contract as a development incentive, while the remaining 70% gets burned.

Contract developers can prepay gas for their users, allowing them to use the contract without paying any transaction fees.

Gas price variates smoothly from block to block. There are no gas wars and the extra attached gas will be refunded.

Smart contracts

NEAR smart contracts are pieces of executable code stored in the account's state that have their own storage, and perform transactions in the account's name.

When you deploy a smart contract to NEAR, you pay for the storage that this contract requires (1 Ⓝ ~ 100kb).

You can write NEAR smart contracts in Javascript or Rust. I would suggest Rust since SDK is more mature and there are a lot of good examples online.

Contracts are compiled by NEAR SDK into WASM, a binary instruction format for a stack-based virtual machine.

Aurora

One more interesting thing about the NEAR ecosystem is Aurora. It’s an EVM running on top of the NEAR protocol. It’s implemented as a NEAR smart contract. Aurora has its ecosystem of apps and it aims to be fully compatible with Ethereum.

https://t.co/r6YMQazFSo

Conclusion

NEAR is not going anywhere. Technology is fantastic, as is the community that surrounds it. Create a wallet and join the community!

The goal of this puzzle is to mint 150 #NFTs for yourself in one transaction while staying under a certain gas limit.

Smart contract code: https://t.co/TLGP8W1LbY Test code: https://t.co/CPXHadkgNX

Rules are simple:

• You may not create more accounts. You may only use the attacker account.

• Since the mint has to be done in one transaction, everything should be implemented in the constructor.

• You may not modify the victim contract

Let's go over the implementation👇

Line 7 initializes ERC721 which we have to exploit.

Lines 9-11 determine which token IDs will be minted. This is required since the test performs a random number of mints during setup to prevent test fitting. We can determine loop bounds after we get our initial token ID.

The goal of the loop is to mint and transfer 150 tokens. Because our account starts with a token balance of zero, minting and transferring a token immediately changes our balance from 0 to 1 and then back to 0. Because of the way the SSTORE opcode works, this uses a lot of gas. SSTORE is expensive, and the price is determined by a variety of factors.

Here is the cost breakdown:

• If the value of the slot changes from 0 to any non-zero value, the cost is 20000

• If the value of the slot changes from 1 to any non-zero value, the cost is 5000

• If the value of the slot changes from any non-zero value to 0, the cost is 5000

In our situation, this means that each time the loop iterates, we will have to pay 25000 gas for updating our balance from 0 to 1 and then back to 0.

One clever approach we may do is to "premint" 1 #NFT before the loop, which will cause our balance to switch between 1 and 2 in the loop. Gas cost will significantly drop as a result. Premint is on line 13.

Line 15 - 22 is our loop that mints and transfers 150 tokens from the contracts to the initial caller account.

Line 24 transfers preminted NFT and that’s it.

Additionally, the reentrancy attack with the callback function onERC721Received on ERC 721 can be used to solve this challenge since Mint150 contract uses _safeMint and has no reentrancy guard.

However, the onERC721Received callback won’t be triggered if the mint function is called from the constructor, since the method which checks if the caller is a contract (EXTCODESIZE) returns 0 if it is called from the constructor of a contract.

To work around the EXTCODESIZE problem, deploy a new contract from the Attacker contract.

The biggest take from this puzzle is to understand how SSTORE opcode works and how to use it to your advantage.

Knowing programming languages such as JavaScript or Python will make this much easier.

Here's what you can do:

• Read Mastering Ethereum book

• Complete several Udemy courses

• Read existing smart contracts

Mastering Ethereum book is offering a guide to the operation and use of Ethereum and other compatible EVM-based open blockchains. The book provides detailed technical breakdowns and introductions to high and low-level Ethereum concepts.

https://t.co/fXpnhqOsVm

Ethereum and Solidity: The Complete Developer's Guide course on Udemy, by Stephen Grider.

By the end of the course, you should be able to:

• Write Solidity

• Understand smart contracts

• Use smart contracts to build apps based on the blockchain

https://t.co/ugq0zcSGMj

Master Ethereum & Solidity Programming From Scratch course on Udemy, by Andre Dumitrescu.

The course comes with over 40 downloadable resources and 20 articles.

You’ll build 5 smart contracts:

• Token

• ICO

• Lottery

• Auction

• Crowdfunding

https://t.co/xi1r8GMj12

The Complete NFT Web Development Course - Zero To Expert course on Udemy teaches you how to build an NFT Marketplace with Solidity And React.

It goes through the ERC721 standard and shows how to build basic NFT smart contracts.

https://t.co/233SGnq5f7

Advanced Solidity: Understanding and Optimizing Gas Costs Udemy course by Jeffrey Scholz.

You will learn how:

• the EVM sets the gas prices

• to improve the gas price of your code

• to debug execution costs

• to write gas-efficient smart contracts

https://t.co/ra8ZIJUZH5

Advanced Solidity: Yul and Assembly Udemy course by Jeffrey Scholz. You will learn how Solidity works behind the scenes and how to write Smart Contracts in assembly. This is very useful if you like gas puzzles and want to dig deeper into Solidity.

https://t.co/7Ffe15Uygp

Spend some time reading the contracts on Etherscan. You will discover how experienced developers write code, find some interesting solutions, and improve your Solidity skills.

Those were interesting to me:

• WETH

• Uniswap v2

• Clone X & Clone X Mint Vial

• Azuki

• Nouns

Solidity is a very fun language, and the possibilities for smart contracts are limitless.

Here are three helpful extensions to make your coding experience better.

Solidity Visual Developer

Supports developers in writing secure and well-understood code.

It supports you with the following features:

• Advanced Solidity Language Support

• Code Augmentation

• Source Exploration

• Visual Security Linting

https://t.co/dmw2Zw8uZy

ETHover

Enables you to hover over an Ethereum address and:

• Open it in etherscan

• Show $ETH balance

• Download the bytecode and disassemble it

• Show reconstructed contract source

• Show verified contract source

• + much more

https://t.co/eBiI2YyDOA

Slither

Offers integration for Slither, a Solidity static analysis framework.

It enables you to run a set of vulnerability detectors on your Solidity smart contracts in order to annotate potentially risky code and obtain recommended changes.

Why would you create a vanity address?

First of all, it looks cool. The second thing it can help you with is to reinforce your brand and make you more noticeable.

How to generate your own vanity address?

Creating a vanity address is a straightforward trial-and-error process. When performing high-risk cryptographic operations, such as private key creation, it is important to use trusted and audited tools.

The best thing is to run generator software on a secure machine that is not connected to the internet. One example of the tool you can download is - https://github.com/10gic/vanityge

You can also use online tools like VANITY-ETH. It’s less secure since PK is generated in the browser. Vanity-ETH is an open-source tool using your web browser to generate Ethereum vanity addresses - https://vanity-eth.tk.

Enter the prefix/suffix of your choice, and click ‘generate’. Your browser will generate lots of random addresses until one matches your input. Once an address is found, you can reveal the private key, or click the 'save' button to download a password-encrypted keystore file.

How long does it take to generate an address?

The time to generate an address depends on how long is the desired prefix/suffix.

A popular vanity address is 0x000000000000000000000000000000000000dead (with 'dead' at the end), used instead of the default NULL address. Generating the private key for this address would take thousands of years.

It's a technique that allows you to save gas when deploying a smart contract and storing or loading statically-sized variables.

Tight variable packing involves carefully arranging your contract's data structures and variables in a way that maximizes the use of available storage space. This means that you can store more information in the same amount of storage space, reducing the amount of gas required for deployment.

To achieve tight variable packing, you need to pay attention to the order and size of your variables. For example, larger variables should be placed before smaller ones.

Tight variable packing is especially important for large and complex contracts, where the savings can be significant.

If you're interested in learning more about tight variable packing, check out this post with code examples-

https://fravoll.github.io/solidity-patterns/tight_variable_packing.html

Don't forget to consider tight variable packing when designing your next Solidity contract! It could save a lot of gas in the long run

1. Start by familiarizing yourself with the basics of the Solidity programming language and its syntax.

2. Practice writing simple smart contracts and deploying them on a blockchain testnet to gain hands-on experience.

3. Take advantage of online tutorials and resources to deepen your understanding of Solidity and its features.

4. Use debugging tools like Remix and Truffle to test and troubleshoot your contracts before deploying them on the mainnet.

5. Join the Solidity community and participate in online forums and discussions to learn from experienced developers.

6. Always follow best practices and security measures to ensure the integrity and security of your smart contracts.

1. Keep learning and never stop growing your knowledge and skill set.

2. Stay up to date with industry trends and new technologies. Experiment with new tools and languages.

3. Always strive for quality in your code. Write clean, readable, and well-documented code.

4. Always stay one foot outside of your comfort zone. Don't be afraid to tackle tough and challenging problems.

5. Collaborate with other software engineers and learn from their experiences. Attend meetups and conferences to network and expand your knowledge.

6. Never stop seeking feedback and constructive criticism. This will help you identify areas for improvement and growth.

Here are 5 daily habits that can have a big impact:

1. Start your day with a healthy breakfast. Fueling your body with nutrients in the morning can help set the tone for the rest of the day.

2. Get moving. Incorporating physical activity into your routine can help improve your physical and mental health. Aim for at least 3 training sessions per week

3. Establish healthy habits like eating nutritious meals, getting enough sleep, and staying hydrated. These small actions can make a big difference in your overall well-being

4. Set boundaries and say no to things that don't align with your values or goals. This will help you feel more in control of your time and energy and allow you to focus on what truly matters to you.

5. Set small, achievable goals for yourself. Whether it's learning a new skill or simply making your bed every morning, setting goals can give you a sense of accomplishment and help you make progress towards larger aspirations.

By incorporating these daily habits into your routine, you can improve your life quality and set yourself up for success in the new year.

EIP stands for Ethereum Improvement Proposal. It is a design document that outlines a proposed change or improvement to Ethereum. Once an EIP has been authorized and confirmed by a committee, it becomes an ERC.

ERC stands for Ethereum Request for Comment. It is a protocol for proposing and implementing new Ethereum-based tokens, smart contracts, and other related features.

EIPs can cover a wide range of topics, such as new features for the Ethereum Virtual Machine (EVM), updates to the Ethereum network, or changes to the Ethereum protocol itself.

ERCs, on the other hand, are specifically focused on creating new Ethereum-based tokens or standards for smart contracts. Some examples of ERCs include ERC-20 (a standard for creating tokens) and ERC-721 (a standard for creating non-fungible tokens).

In summary, EIPs are proposals for improving or changing Ethereum, while ERCs are proposals for creating new Ethereum-based standards or tokens. Both play important roles in the development and evolution of the Ethereum ecosystem.