# Streaming Games Like *Black Myth: Wukong* at 4K and 240fps

As a gamer, I'm always on the lookout for the next big leap in technology, and lately, cloud gaming has been capturing my attention. I recently had the chance to test *GeForce Now*, Nvidia’s cloud gaming service, by playing the much-anticipated *Black Myth: Wukong*. The result? I was absolutely stunned. The game streamed seamlessly at 4K resolution and 240fps, something that, at first, seemed impossible in a cloud-based environment. The technical marvel of this experience got me thinking about the technology powering it all.

In this blog, I’ll explore how GeForce Now can deliver such an exceptional gaming experience, from advanced video compression to real-time rendering. Through my research, I now have a deeper understanding of the core technologies and methods involved, which I’ll break down below.

---

  
## What Makes Streaming at 4K 240fps Possible?

### 1. **Efficient Video Compression: The Role of Codecs**

Streaming games at such a high resolution and frame rate requires vast amounts of data, which would be impractical to transmit without some form of compression. GeForce Now employs modern video codecs like **H.265 (HEVC)** and **AV1** to shrink data sizes without sacrificing quality.

- **HEVC (H.265)**: This codec can compress video to about half the size of the older H.264 while maintaining similar quality. It uses advanced techniques like **motion compensation** and **adaptive quantization**, which are crucial when streaming games with fast-moving action, like *Black Myth: Wukong*.
  
- **AV1**: Even more efficient than H.265, AV1 offers a 20-30% reduction in bitrate, meaning it can maintain the same visual quality with less data. With **multi-symbol entropy coding** and **global motion compensation**, AV1 is optimized for high-resolution, high-frame-rate streams like 4K at 240fps.

These codecs are vital to reducing the amount of data that needs to be sent over the internet, ensuring smooth gameplay even in complex, fast-paced games.

![alt](https://firebasestorage.googleapis.com/v0/b/architecture-wizard-a48a6.appspot.com/o/uploads%2FthHMCllc9TcR24op6iZUtxI5Kte2%2F1725544484941.webp?alt=media&token=4e44c619-8e4d-4ac4-b682-43cd4fdfb48d)

### 2. **Low-Latency Encoding: Real-Time Performance**

When gaming, latency is everything. Any delay between a player's input and the on-screen reaction can ruin the experience. To minimize this, GeForce Now uses **low-latency hardware encoders** like NVIDIA’s **NVENC**. These encoders are designed for real-time applications and can process video frames quickly without introducing noticeable delays.

**Parallel processing** techniques also help, where high-end GPUs can handle multiple tasks simultaneously—rendering and encoding frames in real-time. This ensures that the gaming experience feels responsive, even when playing at a blistering 240fps.

### 3. **Adaptive Bitrate Streaming: Handling Network Variability**

Your network connection isn't always stable, which is where **adaptive bitrate streaming (ABR)** comes into play. This method allows GeForce Now to adjust the video quality in real time based on the strength of your internet connection. For instance, if your connection slows down, the system will lower the bitrate to maintain a smooth experience, then boost it back up as your bandwidth improves.

By segmenting the video into short bursts (1-10 seconds), GeForce Now can switch between different quality levels dynamically, ensuring the game stays playable even when the network fluctuates.
  

## Streaming Deltas: The Unsung Hero of High-FPS Gaming

![alt](https://firebasestorage.googleapis.com/v0/b/architecture-wizard-a48a6.appspot.com/o/uploads%2FthHMCllc9TcR24op6iZUtxI5Kte2%2F1725544501889.webp?alt=media&token=66a0bd44-ce2d-490e-bfaa-3d69fc366804)

In my research, I found the idea of **streaming deltas**, which refers to transmitting only the changes between frames, rather than sending each frame in its entirety. This technique is essential in high-frame-rate gaming, especially at 240fps, where consecutive frames are often very similar.

Here’s how delta streaming works:

- **Keyframes (I-frames)**: These are full images sent at regular intervals. They serve as reference points for decoding the rest of the stream.
  
- **Delta Frames (P-frames, B-frames)**: Instead of transmitting complete frames, delta frames contain only the differences between the current frame and previous or future frames. This reduces the amount of data that needs to be sent drastically, especially in scenes with minor changes.

By relying on motion compensation techniques, GeForce Now can predict and transmit only the areas of the screen that change, minimizing the data load. This process happens extremely quickly and efficiently, ensuring that even at 240fps, the stream remains smooth.
  

## The Network Backbone: Low Latency, High Bandwidth

Streaming games at 4K 240fps isn't just about compression and encoding; it’s also about optimizing the network. GeForce Now employs **UDP-based protocols like QUIC** for fast, low-latency transmission and **edge computing** to reduce the distance between servers and players. With edge servers positioned strategically around the globe, data doesn’t have to travel far, which reduces lag and improves responsiveness.

For those with high-speed connections, GeForce Now can stream at up to **120 Mbps**, enabling a fluid 4K experience at 240fps. For comparison, streaming regular 4K content at 60fps typically requires 25-50 Mbps.

![alt](https://firebasestorage.googleapis.com/v0/b/architecture-wizard-a48a6.appspot.com/o/uploads%2FthHMCllc9TcR24op6iZUtxI5Kte2%2F1725544520294.webp?alt=media&token=0e6c18b9-f2a7-4c64-8697-1933922a95ae)

---

## Conclusion: The Future of Gaming, Today

My experience playing *Black Myth: Wukong* on GeForce Now made it clear that cloud gaming technology has matured rapidly. The combination of advanced codecs, low-latency encoding, adaptive bitrate streaming, and delta compression techniques allows the service to stream graphically intense games in stunning 4K resolution at 240fps.

GeForce Now represents the future of gaming—one where hardware limitations no longer prevent us from enjoying the best visuals and smoothest gameplay. With a fast enough internet connection, you can experience cutting-edge games at their highest settings without needing a top-tier gaming PC.

If you're a gamer, or even just curious about where technology is headed, I highly recommend giving GeForce Now a try. The future of cloud gaming is already here, and it's astonishing.


Discover how GeForce Now delivers an unparalleled cloud gaming experience. I tested it with Black Myth: Wukong in stunning 4K and was blown away by the seamless performance. Here’s a breakdown of my understanding of technology that makes this possible!

The Magic Behind GeForce Now

![alt](https://firebasestorage.googleapis.com/v0/b/architecture-wizard-a48a6.appspot.com/o/uploads%2FthHMCllc9TcR24op6iZUtxI5Kte2%2F1685105940451.jpeg?alt=media&token=5a198051-c499-4ab7-875d-96544f85814f)

# Setting the stage

In the ever-evolving world of software development, making the right architectural choices can be critical to the success of a project. While microservices have garnered considerable attention in recent years, there are scenarios in which a monolithic architecture may be better suited to simplify the development and release processes. In this article, we'll explore how migrating from microservices to a monolith can provide numerous advantages, while steering clear of the pitfalls of a distributed monolith.

# Uncovering the Benefits of Monoliths

The world of software development demands the right architectural approach to ensure project success. A modular monolith, which combines the best aspects of both monolithic and microservices architectures, provides a streamlined yet powerful solution to many software development challenges.

One of the primary advantages of a modular monolith is the cohesive development experience it offers. With all components housed within a single codebase, developers can work more efficiently, quickly accessing and modifying related features and functionalities. This clear structure promotes tight-knit collaboration among team members and limits the need for extensive cross-team communication.

In a modular monolith, components maintain a level of independence similar to what is seen in microservices, due to the modular design. This approach encourages reusability and makes it easier to manage the long-term maintainability of the codebase. By enforcing logical separation between modules, developers can implement changes to individual components while minimizing the impact on the rest of the system.

Finally, a modular monolith helps reduce overhead and improve the application's overall efficiency. By keeping all components within the same process memory, the need for network communication and the ensuing latency and other performance issues are eliminated. This approach also reduces the resources required for data serialization and deserialization, maximizing resource utilization and optimizing runtime performance.

In summary, modular monoliths present an opportunity to benefit from a more cohesive development experience, independent and reusable components, as well as reduced overhead and increased efficiency. By striking the right balance between monolithic and microservices architectures, modular monoliths provide a streamlined and robust solution that caters to the dynamic needs of modern software development. Teams adopting this architecture can create applications that are flexible, scalable, and better able to adapt to ever-changing business requirements, delivering enhanced value to end-users and ensuring the long-term success of their software projects.

# Practical Approaches and Techniques for Building Modular Monolith

Adopting a modular monolith approach necessitates the implementation of certain techniques and strategies to ensure its success. Here are some practical approaches for building and managing modular monoliths effectively:

1. Modular Design: Organize your monolith into well-defined, logically separated modules, each with its specific responsibility and clear boundaries. This promotes modular code, better maintainability, and simplified future growth.

2. Shared Interfaces: Focus on well-defined interfaces and contracts between modules to ensure compatibility and communication. By adhering to an agreed-upon set of interfaces, the modules can be more easily swapped or modified without impacting other parts of the application.

3. Dependency Inversion: Adopt the Dependency Inversion Principle (DIP) to limit direct dependencies between modules. This inversion of control (IoC) approach enables greater flexibility and reduces coupling between the components.

4. Domain-driven Design (DDD): Implement DDD principles to design the modules around clearly defined business domains, resulting in a more accurate representation of business processes within the application’s structure.

5. Testability: Ensure each module is designed in a manner that enables thorough testing, both as a standalone unit and within the broader integrated system. This will help validate the behavior and performance of individual modules and minimize regressions.

6. Consistent Coding Standards and Design Patterns: Encourage the use of consistent coding standards and best practices throughout the modular monolith. By leveraging established design patterns and adhering to a shared set of guidelines, the codebase becomes more cohesive, maintainable, and easier to understand for all team members.

7. Continuous Integration and Deployment: Embrace continuous integration and deployment practices to streamline the development workflow in a modular monolith setup. Regular integration will help identify potential issues earlier in the development process, minimizing the risk of costly, time-consuming fixes later on.

8. Monitor and Optimize: Actively monitor the performance and health of your modular monolith, frequently identifying and addressing potential issues and bottlenecks. Regular assessments of critical performance metrics can help ensure a robust, efficient, and reliable system over time.

9. Encourage Collaboration and Shared Ownership: Foster an environment where team members take shared responsibility for different parts of the modular monolith. This not only results in cross-functional knowledge sharing but also mitigates risks associated with developer turnover or knowledge silos.

By following these practical approaches and techniques, teams can successfully build and manage a modular monolith, reaping the benefits of both monolithic and microservices architectures. This hybrid approach enables efficient, maintainable, and high-performing software development, providing an ideal balance of cohesion, independence, and simplified process management. With modular monoliths, organizations can create applications that are flexible, scalable, and better equipped to adapt to the ever-changing demands of modern software development. As teams embrace these best practices and apply them to building modular monoliths, they will deliver greater value to their users and facilitate their applications' long-term success.

# Avoiding the Pitfalls of a Distributed Monolith

While the benefits of a monolithic architecture are clear, it's essential to avoid falling into the trap of creating a distributed monolith. A distributed monolith is a system that appears to have a microservices architecture but does not fully leverage its benefits due to tight coupling and improper separation of concerns. To ensure a successful monolithic architecture migration, consider the following best practices:

1. Maintain Clear Boundaries: Ensure that each component within the monolith has a well-defined responsibility and clear boundaries. This promotes separation of concerns, allowing each component to evolve independently and minimizes the risk of creating a tightly-coupled, unmanageable system.

2. Implement Modular Code: Write modular, testable code and encourage the use of design patterns like SOLID to ensure clean, maintainable code. This will make it easier to manage, understand, and refactor individual components within the monolithic application over time.

3. Monitor and Optimize Performance: As the application scales, be proactive in monitoring and optimizing your monolith's performance. Carefully observe critical performance metrics and promptly address any bottlenecks or issues that arise.

4. Plan for Scalability: Building a monolithic application doesn’t mean relinquishing the ability to scale. Employ strategies like vertical scaling, horizontal partitioning, and identifying key components to scale independently as needed. While making these choices, consider future growth and potential modifications in your application's requirements.

5. Encourage Collaboration and Shared Ownership: To succeed with a monolithic architecture, it's vital to foster a culture of collaboration and shared ownership among team members. Encourage functional teams to work together, share knowledge, and contribute to different parts of the application. This will improve the overall quality of the code and reduce complexities associated with siloed development efforts.

# Conclusion

While microservices are often seen as a go-to choice for modern application development, a monolithic architecture can offer numerous benefits in simplifying development and release processes. By considering the mentioned best practices and avoiding the pitfalls of a distributed monolith, organizations can successfully make the transition from a microservices-based system to a more streamlined, efficient monolith.

Ultimately, the decision to shift to a monolithic architecture should be made on a case-by-case basis, taking into account various factors such as project requirements, team structure, and long-term scalability goals. By harnessing the advantages of monolithic architecture while mitigating its potential drawbacks, teams can deliver high-quality, maintainable, and performant software solutions in a more efficient and cost-effective manner.

Discover how migrating from microservices to a monolithic architecture can simplify development and release processes, boost efficiency, and optimize resource utilization. Learn best practices to avoid the pitfalls of a distributed monolith and successfully transition to a streamlined, effective monolith while reaping its benefits.

Monolith Magic: Simplify & Save

# 🧠 AI

An old/new player in all fields of our existence. We're definitely diving into a new era of computing with all these changes. To embrace this change and our new overlords I've decided to let the GPT-4 model write the third part of the series! So let's get to it!

```css
DISCLAIMER: Contract was prepared and written by me. 
However, I will not change anything it writes in the post and will make sure to define prompts as clear and concise as possible.
```

Welcome back to our token contract creation series! In this third installment, brought to you by ChatGPT, we take a deep dive into building an ERC721 contract featuring private and public sales, Merkle tree verification, and versatile contract management functions. We guide you through each step of the process, ensuring you have a solid understanding of the concepts and techniques. After mastering the creation of an advanced ERC721 contract, stay tuned for the fourth part of our series, where we'll explore testing the contract using Hardhat, a popular Ethereum development environment. Join us on this exciting journey as we continue to expand your knowledge and skills in smart contract development.

## Step 1: Import necessary contracts and libraries

To begin, let's import the required contracts and libraries from OpenZeppelin. These imports will allow us to inherit various functionalities for our ArchWizCharactersV1 contract.

```sol
pragma solidity ^0.8.17;

import "@openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/security/PausableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/security/ReentrancyGuardUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/utils/cryptography/MerkleProofUpgradeable.sol";
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";  
```  
  
## Step 2: Define the ArchWizCharactersV1 contract

Next, let's define the ArchWizCharactersV1 contract and inherit the necessary contracts we imported earlier. We'll also define an enumeration for SaleType and some state variables to be used later.  

```sol
contract ArchWizCharactersV1 is
    Initializable,
    ERC721Upgradeable,
    OwnableUpgradeable,
    PausableUpgradeable,
    ReentrancyGuardUpgradeable
{
    enum SaleType {
        Private,
        Public
    }

    SaleType public saleType;

    bytes32 private root;

    string internal baseUri;
    uint256 public minted;
    uint256 public maxTokens;

    mapping(address => bool) private controllers;
    mapping(SaleType => uint256) private salePrice;
    mapping(SaleType => uint256) private saleDiscount;
    mapping(SaleType => uint256) private saleLimit;
    mapping(SaleType => mapping(address => uint256)) private saleTokens;

    IERC20 public token;
}
```

## Step 3: Initialize the contract

We need an initialize function to set up the initial state of the contract. This function will set the base URI, maximum token supply, and ERC20 token address. It also initializes various inherited contracts.

```sol
function initialize(
    string memory _baseUri,
    uint256 _max,
    address _token
) public initializer {
    __ERC721_init("Arch Wizard Characters", "AWC");
    __Ownable_init();
    __Pausable_init();
    __ReentrancyGuard_init();
    baseUri = _baseUri;
    maxTokens = _max;
    saleType = SaleType.Private;
    token = IERC20(_token);

    salePrice[SaleType.Private] = 0;
    salePrice[SaleType.Public] = 0;

    saleDiscount[SaleType.Private] = 0;
    saleDiscount[SaleType.Public] = 0;

    saleLimit[SaleType.Private] = 0;
    saleLimit[SaleType.Public] = 0;
}
```

## Step 4: Implement `publicMint` function

Now, let's implement the `publicMint` function, which will allow users to mint tokens during the public sale. This function checks if the contract is in the public sale state, validates the requested mint amount, and ensures that the user has sent enough funds to cover the cost of minting. Finally, it mints the tokens to the user.

```sol
function publicMint(uint256 _amount) external payable whenNotPaused {
    require(saleType == SaleType.Public, "Only Public Sales");
    require(minted + _amount <= maxTokens, "All tokens minted");
    require(_amount > 0 && _amount <= 20, "Invalid mint amount");

    uint256 price = getPrice();
    require(msg.value >= price * _amount, "Insufficient funds");
    for (uint256 i = 0; i < _amount; i++) {
        _safeMint(_msgSender(), minted);
        minted++;
    }
}
```

## Step 5: Implement `privateMint` function

Next, let's implement the `privateMint` function. This function allows users to mint tokens during the private sale, given they have a valid Merkle proof. The function verifies the proof, checks the mint amount, and ensures the user has sent enough funds to cover the cost of minting. Finally, it mints the tokens to the user.

```sol
function privateMint(
    uint256 _amount,
    uint256 _allowedAmount,
    bytes32[] calldata _proof
) external payable whenNotPaused {
    require(saleType == SaleType.Private, "Only Private Sales");
    require(minted + _amount <= maxTokens, "All tokens minted");
    require(_amount > 0 && _amount <= 20, "Invalid mint amount");
    require(
        _verify(_leaf(msg.sender, _allowedAmount), _proof),
        "Invalid proof"
    );
    require(
        saleTokens[saleType][_msgSender()] + _amount <= _allowedAmount,
        "Invalid amount"
    );

    uint256 price = getPrice();
    require(msg.value >= price * _amount, "Insufficient funds");
    for (uint256 i = 0; i < _amount; i++) {
        _safeMint(_msgSender(), minted);
        minted++;
    }

    saleTokens[saleType][_msgSender()] += _amount;
}
```

## Step 6: Implement Merkle Tree functions

To validate the private sale eligibility, we need to implement two Merkle tree-related functions: `_leaf` and `_verify`. The `_leaf` function generates the leaf node, while the `_verify` function verifies that a given leaf is in the Merkle tree.

```sol
function _leaf(address _account, uint256 _amount)
    internal
    pure
    returns (bytes32)
{
    return keccak256(abi.encodePacked(_account, _amount));
}

function _verify(bytes32 _leafNode, bytes32[] memory _proof)
    internal
    view
    returns (bool)
{
    return MerkleProofUpgradeable.verify(_proof, root, _leafNode);
}
```

## Step 7: Implement additional utility functions and setters

In this section, we are going to implement the remaining functions and modifiers that help manage the contract, such as setting the price, sale limit, sale type, and Merkle tree root, as well as adding and removing controllers.

```sol
function getPrice() public view returns (uint256) {
    return salePrice[saleType] - saleDiscount[saleType];
}

function isController(address _controller) external view returns (bool) {
    onlyAuthorized();
    return controllers[_controller];
}

function totalSupply() public view returns (uint256) {
    return minted;
}
```

These functions allow you to get the current price of the token, check if an address is a controller, and get the total supply of the minted tokens.

The following functions are setters that can only be called by authorized users (owner or controllers):

```sol
function setMaxTokens(uint256 _max) external {
    onlyAuthorized();
    maxTokens = _max;
}

function setPaused(bool _paused) external {
    onlyAuthorized();
    if (_paused) _pause();
    else _unpause();
}

function addController(address _controller) external {
    onlyAuthorized();
    controllers[_controller] = true;
}

function removeController(address _controller) external {
    onlyAuthorized();
    controllers[_controller] = false;
}

function setBaseUri(string memory _uri) external {
    onlyAuthorized();
    baseUri = _uri;
}

function setToken(address _token) external {
    onlyAuthorized();
    token = IERC20(_token);
}

function setPrice(SaleType _saleType, uint256 _price) external {
    onlyAuthorized();
    salePrice[_saleType] = _price;
}

function setSaleLimit(SaleType _saleType, uint256 _limit) external {
    onlyAuthorized();
    saleLimit[_saleType] = _limit;
}

function setSaleType(SaleType _saleType) external {
    onlyAuthorized();
    saleType = _saleType;
}

function setRoot(bytes32 _root) external {
    onlyAuthorized();
    root = _root;
}

function setDiscount(SaleType _saleType, uint256 _discount) external {
    onlyAuthorized();
    saleDiscount[_saleType] = _discount;
}
```

These functions allow you to manage the contract effectively, by setting the maximum number of tokens, pausing and unpausing the contract, adding or removing controllers, setting the base URI for metadata, setting the token address for payments, setting the price for each sale type, setting the sale limit for each sale type, setting the current sale type, setting the Merkle tree root for private sales, and setting the discount for each sale type.

Finally, we have the `transferFrom` function and the `onlyAuthorized` modifier:

```sol
function transferFrom(
    address from,
    address to,
    uint256 tokenId
) public virtual override(ERC721Upgradeable) {
    if (!controllers[_msgSender()]) {
        require(_isApprovedOrOwner(_msgSender(), tokenId), "Unauthorized");
    }
    _transfer(from, to, tokenId);
}

function onlyAuthorized() internal view {
    require(
        controllers[msg.sender] || owner() == msg.sender,
        "Unauthorized"
    );
}
```

The `transferFrom` function is overridden to allow controllers to transfer tokens without the need for approval or ownership. The `onlyAuthorized` modifier is used throughout the contract to ensure that only the owner or a controller can call certain functions.

With this, we have completed the implementation of the ArchWizCharactersV1 contract. This contract allows for the minting of ERC721 tokens during private and public sales, with different pricing and eligibility verification. Users can mint tokens by calling the appropriate privateMint or publicMint functions, and the contract owner or controllers can manage the contract effectively by using the provided setter functions. The contract also employs various security features such as pausing, reentrancy guards, and access control to ensure smooth operation and safety.

In summary, we have covered the following aspects in this tutorial:

 - The basic structure of the ArchWizCharactersV1 contract, including the imports, contract inheritance, and variables.
 - The initialize function that sets up the initial state of the contract.
 - The implementation of `publicMint` and `privateMint` functions for different sale types and eligibility checks.
 - The Merkle tree verification functions, `_leaf` and `_verify`, to ensure that users are eligible to participate in private sales.
 - The view functions for getting the current price, checking controller status, and getting the total supply of minted tokens.
 - The setter functions for managing contract properties such as maximum tokens, pausing, adding/removing controllers, setting the base URI, 
 - setting token address, setting prices, sale limits, sale types, Merkle tree root, and discounts.

With this information, you should now have a good understanding of how to create an ERC721 contract with private and public sales, Merkle tree verification, and various contract management functions. You can use this tutorial as a starting point to build more advanced features and customize the contract to fit your specific use case.

In this third part of our series on creating token contracts, we delve into the creation of an ERC721 contract with private and public sales, Merkle tree verification, and various contract management functions. We walk you through the process step by step, covering essential aspects like the contract structure, minting functions for different sale types, Merkle tree verification, view functions, and setter functions for contract management. With this tutorial, you'll gain valuable insights on how to build advanced features and customize an ERC721 contract to fit your specific use case.

Solidity and Typescript - Part 3

![alt](https://firebasestorage.googleapis.com/v0/b/architecture-wizard-a48a6.appspot.com/o/uploads%2FthHMCllc9TcR24op6iZUtxI5Kte2%2F1676578979716.png?alt=media&token=f3a6caae-2f4b-460a-84b4-d727ce93101c)

Gamers are constantly pushing the boundaries of what's possible in the virtual world, and emerging technologies like the metaverse ideas, augmented reality (AR), and web3 are opening up new possibilities for gamers and developers alike. In this article, we'll explore what these technologies are and how they are being integrated into the gaming industry. We'll provide ideas and case studies to show how these technologies are being used in real-world scenarios, and how they can be used.  

## Defining the Technologies

The gaming industry is no stranger to technological innovations, but some of the latest advancements are taking things to a whole new level. In recent years, the concepts of the metaverse, augmented reality (AR), and web3 have become increasingly popular, especially in the tech world. But what do they actually mean?  

Let's start with the metaverse. Essentially, the only real metaverse to date is the internet itself. Metaverse refers to an open platform that allows everyone to create and publish their little piece of it to the public. AR, on the other hand, is all about enhancing the real world with digital overlays. This technology uses things like smartphones or smart glasses to project images, information, or even entire environments onto the user's view of the physical world. Lastly, web3 refers to the latest evolution of the internet, where blockchain technology is used to create decentralized systems that provide more control and ownership to users.  

## Integrating

Now that we understand the basics, let's talk about how these technologies are being integrated into gaming. One of the most exciting things about AR is its potential to create incredibly immersive experiences. For example, games like Pokemon Go have used this technology to allow players to catch virtual creatures in the real world. Meanwhile, the metaverse is all about creating new ways for players to connect with each other, whether it's through virtual social spaces or shared game worlds. And with web3, there's a whole new level of player ownership and participation that's possible. Players could potentially own in-game assets that they can sell, trade, and use in other games. This last aspect is very important for the concept of metaverse even existing.

![alt](https://firebasestorage.googleapis.com/v0/b/architecture-wizard-a48a6.appspot.com/o/uploads%2FthHMCllc9TcR24op6iZUtxI5Kte2%2F1676579357813.jpeg?alt=media&token=7ae98172-644b-4f99-9a14-e385bfe9a5bb)

## Case Studies

So, what does this look like in practice? One great example is Nike RTFKT, a virtual sneaker marketplace that is based on blockchain technology. Users can buy and trade limited edition sneakers, and the rarity of each shoe is guaranteed by the blockchain. It's a great example of how web3 can create new opportunities for ownership and commerce in the gaming industry. But it's not just about gaming. The metaverse is being used in other industries too, like fashion and entertainment. For example, some fashion brands are already using virtual showrooms to showcase their collections, and musicians are holding virtual concerts that can be attended by anyone, anywhere. These examples provide inspiration for how the gaming industry could take advantage of these technologies to create new and exciting experiences for players.

## Idea

Imagine a game where you're a treasure hunter exploring an ancient ruin. You use your smartphone as a tool to detect hidden objects and clues in the real world around you, thanks to the power of AR. As you collect items, you're transported to a virtual world where you can interact with other players in a shared game space. This is the metaverse aspect of the game. In this virtual world, you can trade items with other players, form teams to solve puzzles, and battle each other to claim rare treasures.

But here's where web3 comes in. Instead of just collecting items in the game, players can actually own them, thanks to the power of blockchain technology. Each item is a unique, digital asset that can be bought, sold, or traded on a decentralized marketplace. This gives players a real sense of ownership and investment in the game, which can make it even more engaging and fun.

The game could have different levels, each with its own theme and challenges. For example, one level could take place in an Egyptian tomb, while another could be set in a medieval castle. As players progress through the game, they earn rewards and unlock new features.

Ultimately, key to making *any* game *work* is to focus on gameplay first and foremost, and later on the systems that are integrated in it. Systems should serve the player, not the other way around, and this is, in my honest opinion, the greatest error companies make when trying to push the boundaries of gaming.

In conclusion, the future of gaming is looking more exciting than ever with the idea of the metaverse, AR, and potential of web3 technologies. These technologies have the potential to create truly immersive gaming experiences that can transform the way we play and interact with each other. By allowing for player ownership and participation, web3 is opening up new opportunities for gamers and developers alike. And as more and more industries begin to explore the possibilities of the metaverse, we can expect to see even more innovative uses of these technologies in gaming and beyond. As with any new technology, the success of these advancements will depend on how they are implemented and their usefulness. But with the potential benefits they offer, it's clear that they're worth exploring even in the world of gaming.

Gamers are constantly pushing the boundaries of what's possible in the virtual world, and emerging technologies like the metaverse ideas, augmented reality (AR), and web3 are opening up new possibilities for gamers and developers alike.

Gaming: About Metaverse, AR, and Web3

## 🥅 Goal

The goal of this series is to show bits and pieces of techniques and approaches available when building a project with solidity.

## 🏆 What will we achieve in this part?

First part of the short post series will go through project configuration and setup using the latest packages and compilers available (to date). Visit [the GitHub repository](https://github.com/rexdefuror/solidity-and-typescript/tree/89d152968a33aa274aa1bc0d4677baf52e062a44) to see a complete project for this part. 

## 👉 What to expect for next session?

In the next session we will be building and deploying an upgradeable contract and writing basic tests.  

&nbsp;  

# 🏃‍♀️ The Beginning  
&nbsp;  

```css
Suggestion: Create a GitHub repository for this project as we'll use GitHub actions in future parts.
```

Since we have already defined some objectives lets start the fun. So what we need before we even begin creating the projects are some major dependencies. First of which is, of course, NodeJs which can be downloaded from [here](https://nodejs.org/en/), as well as [Visual Studio Code](https://code.visualstudio.com/download) but you can use any IDE you like, I'm just used to VSC for solidity. Extensive NodeJs knowledge is not required to follow along, however some principles is good to know for deeper understanding of whys.

To start it off, let's create a folder for our project, I'll name mine `bc_blog`, you can choose any name you like, and then navigate to it.

```bash
> mkdir bc_blog
> cd bc_blog
```

Next we'll need to initialize NodeJs for our project as well as Hardhat, which we'll use as a main solidity tool.

```bash
> npm init -y
> npx hardhat
```
During hardhat initialization confirm to proceed if asked to install the package, and select a typescript project, confirm project root and add `.gitignore` if you don't have one already. It will create a baseline for the project with example configuration, contract, deploy script and tests. We will use these to check if our project has been set up correctly.

&nbsp;  
# 🔧 The Setup
&nbsp;  

Let's configure our project dependencies, we'll install OpenZeppelin contract abstractions, environment configurations, type supports and some tools to make our life easier.

```bash
> npm i --save-dev @openzeppelin/hardhat-upgrades @typechain/ethers-v5 @types/chai @types/node chai dotenv @nomicfoundation/hardhat-chai-matchers ethers hardhat solhint ts-node typechain typescript @nomicfoundation/hardhat-toolbox
> npm i --save @openzeppelin/contracts @openzeppelin/contracts-upgradeable hardhat-abi-exporter keccak256 merkletreejs web3-utils
```
After running these two commands update `package.json` with some convenience scripts.
```json
"scripts": {
    "test": "npx hardhat test",
    "compile": "npx hardhat compile",
    "deploy-rinkeby": "npx hardhat run scripts/deploy.ts --network rinkeby",
    "deploy-mainnet": "npx hardhat run scripts/deploy.ts --network mainnet"
}
```

Now before we configure Hardhat, let's add needed environment variables first. In project root, create a `.env` file like shown below.

```env
REPORT_GAS=true
ETHERSCAN_API_KEY=<your etherscan api key>
RINKEBY_RPC=https://rinkeby.infura.Io/v3/9aa3d95b3bc440fa88ea12eaa4456161
RINKEBY_PRIVATE_KEY=<your private key>
MAINNET_RPC=https://rpc.ankr.com/eth
MAINNET_PRIVATE_KEY=<your private key>
COINMARKETCAP_API_KEY=<your coinmarketcap api key>
```

As you can see, there are some platforms like Etherscan and CoinmarketCap as well as private keys that you need to provide. Regarding private key, the best recommendation I can give is to create a new Metamask wallet and [export its private key](https://metamask.Zendesk.Com/hc/en-us/articles/360015289632-how-to-export-an-account-s-private-key), additionally you might need a [faucet](https://rinkebyfaucet.Io/) to feed your testnet wallet. 

There's also an odd one which is `REPORT_GAS=true` this variable will tell gas reporter plugin to include gas in test report.

Next step would be go obtain API keys, [from Etherscan](https://info.etherscan.com/api-keys/) as well as [from CoinmarketCap](https://coinmarketcap.com/api/), and no worries both of those have free tiers which are quite sufficient for development purposes. After registering to both platforms and obtaining their keys, come back to the `.env` file and update the variables.

Let's use those in `hardhat.config.ts`.

```ts
import * as dotenv from "dotenv";

import { HardhatUserConfig, task } from "hardhat/config";
import "@nomicfoundation/hardhat-toolbox";
import "@openzeppelin/hardhat-upgrades";
import "hardhat-abi-exporter";
import "@nomicfoundation/hardhat-chai-matchers";
dotenv.config();

task("accounts", "Prints the list of accounts", async (taskArgs, hre) => {
    const accounts = await hre.ethers.getSigners();

    for (const account of accounts) {
        console.log(account.address);
    }
});

const rinkebyAccount: string = process.env.RINKEBY_PRIVATE_KEY ?? "";
const mainnetAccount: string = process.env.MAINNET_PRIVATE_KEY ?? "";

const config: HardhatUserConfig = {
    solidity: "0.8.16",
    networks: {
        rinkeby: {
            url: process.env.RINKEBY_RPC,
            accounts: [rinkebyAccount]
        },
        mainnet: {
            url: process.env.MAINNET_RPC,
            accounts: [mainnetAccount]
        },
    },
    gasReporter: {
        currency: "USD",
        token: "ETH",
        gasPriceApi:
            "https://api.etherscan.io/api?module=proxy&action=eth_gasPrice",
        coinmarketcap: process.env.COINMARKETCAP_API_KEY,
        showTimeSpent: true
    },
    abiExporter: {
        path: "./data/abi",
        runOnCompile: true,
        clear: true,
        flat: true,
        spacing: 2,
        pretty: false,
    },
    etherscan: {
        apiKey: process.env.ETHERSCAN_API_KEY,
    }
};

export default config;
```

This setup will allow your tests to calculate gas estimates automatically and present them to you in a very readable way so that you can focus on writing as optimized code as possible.

And lastly, update our `tsconfig.json`.

```json
{
  "compilerOptions": {
      "target": "es2018",
      "module": "commonjs",
      "strict": true,
      "esModuleInterop": true,
      "outDir": "dist",
      "declaration": true
  },
  "include": [
      "./scripts",
      "./test",
      "./typechain"
  ],
  "files": [
      "./hardhat.config.ts"
  ]
}
```
&nbsp;
## 🧪 Testing  
&nbsp;

After we've configured everything it is time to test it out. Go ahead and run:

```bash
npm run test
```

The result should be as seen in the image below.  

![alt](https://firebasestorage.googleapis.com/v0/b/architecture-wizard-a48a6.appspot.com/o/uploads%2FthHMCllc9TcR24op6iZUtxI5Kte2%2F1661635167078.png?alt=media&token=977b5012-8de6-4a4a-a78d-c063270495c8)

🆘 If you have any errors or issues you're not able to solve, feel free to tweet me and I'll try to help out whenever possible.

&nbsp;
## 🏁 Conclusion
&nbsp;

This is it for the first part of the series. Let's summarize what we've done:
 - Installed NodeJs and IDE (who needed it)
 - Created and initialized the project
 - Installed project package dependencies
 - Added npm scripts to package.json
 - Configured environment variables
   - Including creating accounts and obtaining API keys from Etherscan and CoinmarketCap
 - Updated Hardhat and Typescript configurations
 - Tested the setup.

For the next part of the series we will be creating an upgradeable contract, testing it and deploying it to testnet using this project.

Hope you find this post useful. Keep crunching. 👋

This is a step by step guide with explanations and exact instructions how to configure your local development environment for testing and deployment with Hardhat. 
This is just a first part of the short post series that will go through each phase of development and deployment process for solidity projects.

Solidity and Typescript - Part 1

## ↪️ Recap

If you do not have it configured I strongly recommend going back to Part 1 of the series and starting [there](https://www.arch-wizard.app/rexdefuror/solidity-and-typescript-part-1).

## 🏆 What will we achieve in this part?

To continue where we left off, in this part we’ll be creating an upgradeable ERC20 contract, as well as adding some features to them and testing them. The use case will be to be able to stage sales on an ERC721 and control whether you buy them with default currency or our ERC20.
However, the ERC721 we'll build in the next part of the series since I did not want to skip too many details just to make it shorter.

If you need reference or want to see complete project for this part, you can go to the [GitHub repository](https://github.com/rexdefuror/solidity-and-typescript/tree/part-2).

## 👉 What to expect for next session?

In the next session, we'll build our ERC721 and go over adding some ways to obtain our new ERC20 token.

# 📖 The Backstory

Smart contracts are applications (programs) that are stored on a blockchain and run based on a set of conditions. They can be used to automate a certain transactional process, or define an advanced workflow or even a distributed transaction by relying on multiple contracts communicating with each other. This is accomplished with the contracts ability to preserve state as variables on the network.

Due to the immutability of a blockchain network and smart contracts themselves since they are living in a blockchain, upgrading your application is a little more difficult than releasing a REST API. What are these upgradeable contracts then? First off, *upgradeable* doesn't mean *mutable*. Instead, upgradeable contract uses a proxy pattern.

![alt](https://firebasestorage.googleapis.com/v0/b/architecture-wizard-a48a6.appspot.com/o/uploads%2FthHMCllc9TcR24op6iZUtxI5Kte2%2F1666366831693.png?alt=media&token=0bf09779-5eb5-4fb0-9e48-81f87904c89f)

There are many proxy patterns available, which can be used to create upgradable contracts. Furthermore, while there are also many types of proxy patterns, most proxy patterns use transparent proxy and UUPS (universal upgradable proxy standard). Fortunately, these two types are also offered at [OpenZeppelin](https://www.openzeppelin.com/), which makes things a whole lot simpler for developers. This is also a shortcut that you will learn more about as we’ll go through this part of the project.

## 🕧Before we start

Let's do some basic project maintenance. Latest solidity compiler that was released (to date) is `0.8.17`. In our `hardhat.config.ts` file lets raise the version of solidity property to that.

```sol
const config: HardhatUserConfig = {
    solidity: "0.8.17",
    ...
```

Also raise the version in our `Lock.sol` contract.

```sol
// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.17;
```

There are some package updates that happen from time to time that can make our project break. Let's make sure to run updates, navigate to the project folder and run:

```
> npm update
```

```
Note: If you experience issues with dotenv package, simply reinstall it with
 >  npm i dotenv --save
```

After updates use our test command to compile and check if anything is broken:
```bash
> npm run test
```

## 🪙The ERC20 Contract

For our first contract we'll use transparent proxy pattern to create an ERC20 contract, with some additional functionalities. Let's first create a new contract in our contracts folder, I'll name mine `ArchWizToken.sol`, but you can choose any name you like. 

Defining a base ERC20 contract with dependencies (OpenZeppelin) will look like this:

```sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

import "@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";

contract ArchWizToken is Initializable, ERC20Upgradeable {
    
    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }

    function initialize() public initializer {
        __ERC20_init("Arch Wizard Gem", "AWG");
    }
}
```

Initialize function in this case is a replacement for the constructor, and in it we'll pass `name` and `symbol` parameters to the inherited contract. Now let's add some features, we'll start with adding support for supply control, as well as minting.

Add a state variable in the contract.

```sol
uint256 private maxSupply;
```

And set it through our initialize function.

```sol
function initialize(uint256 _maxSupply) public initializer {
    __ERC20_init("Arch Wizard", "AWIZ");

    maxSupply = _maxSupply;
}
```

To be able to see the values of these private state variables we can use view functions. Create a public view function that returns our `maxSupply`.

```sol
function maximumSupply() external view returns (uint256) {
    return maxSupply;
}
```

Current state of the contract looks like this.

```sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

import "@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";

contract ArchWizToken is Initializable, ERC20Upgradeable {
    uint256 private maxSupply;

    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }

    function initialize(uint256 _maxSupply) public initializer {
        __ERC20_init("Arch Wizard", "AWIZ");

        maxSupply = _maxSupply;
    }

    function maximumSupply() external view returns (uint256) {
        return maxSupply;
    }
}
```

Let's write a test that deploys our contract with a maximum supply and verifies it. In the test folder add a new file with the name of the contract, `ArchWizToken.ts`.

```
Note: If you're getting some weird errors in Visual Studio Code Editor, try pressing CTRL + SHIFT + P and find Developer: Reload Window
command and run it.
This should remove any false issues the editor might report.
```

For test, we'll start with imports and define a scenario that is named after our contract. First step is deployment, we'll use the approach where we have one instance of the deployed contract within one main scenario, then we can split that into several different scenarios based on purpose.

So our test class would look like this.

```typescript
import { expect } from "chai";
import { ethers, upgrades } from "hardhat";

describe("Arch Wizard Gems", function () {
    let archWizToken: any;

    this.beforeAll(async () => {
        const ArchWizToken = await ethers.getContractFactory("ArchWizToken");
        archWizToken = await upgrades.deployProxy(ArchWizToken, [ethers.utils.parseEther("1000000")]);
        await archWizToken.deployed();
    });

    describe("Deployment", function () {
        it("Should have a name", async function () {
            expect(await archWizToken.name()).to.equal("Arch Wizard Gems");
        });

        it("Should have a symbol", async function () {
            expect(await archWizToken.symbol()).to.equal("AWG");
        });

        it("Should have 18 decimals", async function () {
            expect(await archWizToken.decimals()).to.equal(18);
        });
    });

    describe("State", function () {
        it("Should have a max supply of 1,000,000", async function () {
            expect(await archWizToken.maximumSupply()).to.equal(ethers.utils.parseEther("1000000"));
        });
    });
});
```

This approach allows us to have one state of contract throughout that scenario. Later on, we'll be making different types of scenarios where we force the state to reset for each test.

Knowing that our contract is deployable and our maximum supply is working we can add more features to it. We'll be adding minting function as well as a way to protect it so not everyone can simply mint, this will allow us to control ways of earning. Additionally we'll be adding a way to burn both the minted tokens, so they can be reminted and the maximum supply itself. This way maximum supply cannot be increased only decreased, it will prove useful to have this functionality later on.

First we'll define a way to control the contract. Create a new abstract contract, I will name it `Minters.sol`. It should have a key-value-pair mapping where key is a wallet address and value is a boolean, here is where we'll store all the minters. 

```sol
mapping(address => bool) public minters;
```

Additionally we'll add two functions so that we can add and remove minters from that mapping. For these we'll add a special access modifier `onlyOwner` that restrict execution of these functions to just owner. This modifier is provided by the inherited abstract contract `OwnableUpgradeable`.

```sol
function addMinter(address _account) public onlyOwner {
    require(_account != address(0));
    minters[_account] = true;
}

function removeMinter(address _account) public onlyOwner {
    require(_account != address(0));
    minters[_account] = false;
}
```

To have `Minters` contract be initialized when we inherit it, an internal function with `onlyInitializing` modifier needs to be defined that handles all of the setting up for our abstract contract. In this case initialize its base contract, which is `OwnableUpgradeable`.

```sol
function __Minters_init() internal onlyInitializing {
    __Ownable_init();
}
```

 Lastly, we'll make our own modifier `onlyMinters` that we'll use within the token contract. So the entire abstract contract will look like this.

```sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";

abstract contract Minters is Initializable, OwnableUpgradeable {
    mapping(address => bool) public minters;

    function __Minters_init() internal onlyInitializing {
        __Ownable_init();
    }

    modifier onlyMinters() {
        require(minters[msg.sender] || owner() == msg.sender);
        _;
    }

    function addMinter(address _account) public onlyOwner {
        require(_account != address(0));
        minters[_account] = true;
    }

    function removeMinter(address _account) public onlyOwner {
        require(_account != address(0));
        minters[_account] = false;
    }
}
```

In order to use this newly created utility contract, we'll need to import it to our token contract, inherit it and initialize it.

```sol
...
import "./Minters.sol";

contract ArchWizToken is Initializable, ERC20Upgradeable, Minters {
...

    function initialize(uint256 _maxSupply) public initializer {
        __ERC20_init("Arch Wizard Gems", "AWG");
        __Minters_init();
...
```

Let's add a minting and burning functions that we'll guard with `onlyMinters` modifier and then add tests for all of those features.

```sol
function mint(address _account, uint256 _amount) public onlyMinters {
    require(_account != address(0));   // Check if address is empty
    require(totalSupply() + _amount <= maxSupply, "Max supply reached");   // Check if maximum supply is reached
    _mint(_account, _amount);    // Mint the specified amount
}

function burn(address _account, uint256 _amount) public onlyMinters {
    _burn(_account, _amount);
}
```

We're ready to add those tests now. Create two new categories named "Minting" and "Burning", and we'll go through it one by one. Check for adding and removing controllers in the "State" category, minting as a controller, minting as not a controller and expecting transaction to fail, minting over the supply in "Minting" category, and finally same for burning in "Burning" category.

Let's make a small refactor as well, since we'll be needing wallet addresses, we can get simulated addresses from `ethers` library to use in our tests. So we'll set up the following:

```typescript
describe("Arch Wizard Gems", function () {
    let archWizToken: any;
    let owner: any;
    let minter: any;
    let buyer: any;

    this.beforeAll(async () => {
        [owner, minter, buyer] = await ethers.getSigners();
...
```
This will allow us to have those three addresses at our disposal in all of our tests within this scenario.

```typescript
describe("State", function () {
    it("Should have a max supply of 1,000,000", async function () {
        expect(await archWizToken.maximumSupply()).to.equal(ethers.utils.parseEther("1000000"));
    });
    it("Should be able to add minter", async function () {
        const addMinterTx = await archWizToken.addMinter(minter.address);
        await addMinterTx.wait();
        expect(await archWizToken.minters(minter.address)).to.be.true;
    });
    it("Should be able to remove minter", async function () {
        const removeMinterTx = await archWizToken.removeMinter(minter.address);
        await removeMinterTx.wait();
        expect(await archWizToken.minters(minter.address)).to.be.false;
    });
});

describe("Minting", function () {
    it("Should be able to mint", async function () {
        const mintTx = await archWizToken.mint(buyer.address, ethers.utils.parseEther("100"));
        await mintTx.wait();
        expect(await archWizToken.balanceOf(buyer.address)).to.equal(ethers.utils.parseEther("100"));
    });
    it("Should not be able to mint more than max supply", async function () {
        await expect(archWizToken.mint(buyer.address, ethers.utils.parseEther("1000001"))).to.be.revertedWith("Max supply reached");
    });
    it("Should not be able to mint as non-minter", async function () {
        await expect(archWizToken.connect(buyer).mint(buyer.address, ethers.utils.parseEther("100"))).to.be.reverted;
    });
});

describe("Burning", function () {
    it("Should be able to burn", async function () {
        const burnTx = await archWizToken.burn(buyer.address, ethers.utils.parseEther("100"));
        await burnTx.wait();
        expect(await archWizToken.balanceOf(buyer.address)).to.equal(ethers.utils.parseEther("0"));
    });
    it("Should not be able to burn more than balance", async function () {
        await expect(archWizToken.burn(buyer.address, ethers.utils.parseEther("1"))).to.be.revertedWith("ERC20: burn amount exceeds balance");
    });
    it("Should not be able to burn as non-minter", async function () {
        await expect(archWizToken.connect(buyer).burn(buyer.address, ethers.utils.parseEther("100"))).to.be.reverted;
    });
});
```

The only thing left for our ERC20 is to allow for non-signable transfers if the target of the transfer is a minter, and test upgradeability of our contract. What the first, will do is make transactions cheaper within the ecosystem of our contracts, so that transfers don't need to be specifically approved if you're within the allow list of the ERC20.

```sol
function transferFrom(
    address from,
    address to,
    uint256 amount
) public virtual override(ERC20Upgradeable) returns (bool) {
    if (!minters[to]) {
        address spender = _msgSender();
        _spendAllowance(from, spender, amount);
    }
    _transfer(from, to, amount);
    return true;
}
```
Note that this functionality will be tested through integration with ERC721.

### ⤴️Upgradeability

To upgrade a contract we'll need a completely separate contract class with a different contract class name, so what we'll do is duplicate our existing `ArchWizToken.sol` and name it `ArchWizTokenV2.sol`, then rename the declaration within the file as well. In order to confirm that the upgrade has went well, we'll add a new functionality to our new version. Note that there are constraints to upgrading contracts. Due to the nature of proxy pattern and that storage and logic are separated, we need to make sure not to move state variables order, or functions that deal with storage directly. Read more about proxy upgrade pattern [here](https://docs.openzeppelin.com/upgrades-plugins/1.x/proxies).

We'll add an ability to burn supply, rather than minted ones, and a way to see the remaining supply rather than just maximum. So `ArchWizTokenV2.sol` would look like this.

```sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

import "@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "./Minters.sol";

contract ArchWizTokenV2 is Initializable, ERC20Upgradeable, Minters {
    uint256 private maxSupply;

    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }

    function initialize(uint256 _maxSupply) public initializer {
        __ERC20_init("Arch Wizard Gems", "AWG");
        __Minters_init();

        maxSupply = _maxSupply;
    }

    function mint(address _account, uint256 _amount) public onlyMinters {
        require(_account != address(0));
        require(totalSupply() + _amount <= maxSupply, "Max supply reached");
        _mint(_account, _amount);
    }

    function burn(address _account, uint256 _amount) public onlyMinters {
        _burn(_account, _amount);
    }

    function burnSupply(uint256 _amount) public onlyOwner {
        require(maxSupply - totalSupply() >= _amount);
        maxSupply -= _amount;
    }

    function remainingSupply() public view returns (uint256) {
        return maxSupply - totalSupply();
    }

    function maximumSupply() external view returns (uint256) {
        return maxSupply;
    }

    function transferFrom(
        address from,
        address to,
        uint256 amount
    ) public virtual override(ERC20Upgradeable) returns (bool) {
        if (!minters[to]) {
            address spender = _msgSender();
            _spendAllowance(from, spender, amount);
        }
        _transfer(from, to, amount);
        return true;
    }
}
```

Upgrade tests.

```typescript
describe("Upgradeable", function () {
    it("Should be able to upgrade", async function () {
        const ArchWizTokenV2 = await ethers.getContractFactory("ArchWizTokenV2");
        archWizToken = await upgrades.upgradeProxy(archWizToken.address, ArchWizTokenV2);
        expect(await archWizToken.name()).to.equal("Arch Wizard Gems");
    });
    it("Should be able to burn supply", async function () {
        const burnTx = await archWizToken.burnSupply(ethers.utils.parseEther("100"));
        await burnTx.wait();
        expect(await archWizToken.maximumSupply()).to.equal(ethers.utils.parseEther("999900"));
    });
    it("Should be able to check remaining supply", async function () {
        const mintTx = await archWizToken.mint(buyer.address, ethers.utils.parseEther("100"));
        await mintTx.wait();
        expect(await archWizToken.balanceOf(buyer.address)).to.equal(ethers.utils.parseEther("100"));
        expect(await archWizToken.remainingSupply()).to.equal(ethers.utils.parseEther("999800"));
    });
});
```

# 🔚 Conclusion

Woah, this took a while 😅. Let's recap briefly, in this part we have:

 - Created an upgradeable ERC20 token
 - Tested deployment
 - Added and tested control features
 - Added and tested minting
 - Added and tested burning
 - Tested upgradeability

Hope that you have enjoyed reading this second part of the series, in the next one we'll go over making an ERC721 with lots of features and testing them, we'll also create a deploy script for various networks.

Keep crunching. 👋

Continuation from Part 1 which tackled initial setup for development and deployment environment by using Hardhat. In this, Part 2, we will go over building a version of an upgradeable ERC20 as well as going over tests and adding features to it.

Solidity and Typescript - Part 2

Being a huge platform as it is twitter processes insane amounts of information and provides millions of users with their precious dopamine 😄. That being said, it is very worth while to look into how one would build such a platform.  
Thinking about basic premise of the system, even before going into requirements and details we can make few assumptions:
 - Designing the system as monolithic, even modular, wouldn't suffice, as we will probably run into many pitfalls with scaling and thus performance
 - Likely, not all parts of the system would have the same architecture 
 - Using synchronous approach to data fetching will result in severe bottlenecks as the platform scales

With this in mind we can go ahead and think about requirements and design:

- Definitions
  - User, person who has registered and logged in to the platform
  - Follower, User who has chosen to Follow another User's posts
  - Tweet, a post/message shared on a platform, visible by followers
  - Retweet, sharing a Tweet within the platform
  - Topic, Tweet topic defined by content and/or hashtags
  - Timeline, a feed for Tweets
 - Functional requirements
    - Users must be logged in to use the platform
    - Users can create and delete accounts
    - Users can: create, share and search for Tweets
    - Users must be able to reach millions of followers within several seconds of tweeting
    - Timelines:
      - Home timeline, a landing page timeline, main feed
      - User timeline, profile page feed of Tweets
      - Results timeline, shown when any filter is applied to any timeline
    - Tweets can have text, images and/or videos
    - Recommendations for users based on Tweets and Topics
    - Notifications when Followed User has taken action
    - Notifications when related Trending Topic (Re)Tweet has been created
    - Analytics for how Users interact with the platform
 - Non-functional requirements
   - System must not fail completely in case something bad occurs
   - As the platform grows, it must be able to support new features as easily as possible
   - Popularity of the platform assumed, it must be made fairly easy to integrate with
   - Constant updates make the system susceptible to often change thus working with the system must be seamless
   - System must adapt to often changes in load and concurrent userbase.

### Characteristics

Considering that Twitter has more than 200 million users where larger influencers have even millions of followers, it can be determined that Twitter is far more _read_ focused. Meaning that hundreds of thousands of queries are made every second to provide Timelines for users. While writing is also a challenge since we must provide content to large audiences when tweeting we must use asynchronous approach when dealing with creating Tweets. Applying eventual consistency seems reasonable since it is acceptable if a Follower receives/sees Tweet after a small delay.

With the outline defined, next thing that should be considered is data. Storing large amounts of data can certainly be a challenge, though Tweets are small we must take into consideration that we do not duplicate data needlessly, or create some unnecessary couplings. Additionally, due to large read requirements caching mechanics must be considered, thus we need a system that is capable of fast reads and horizontal scaling, this is where Redis would come in as a fitting solution. This does mean that we will need to store Tweet clones into Redis and our main storage (whatever that ends up). Note that I did mention that we should not duplicate data needlessly, however I do feel that this is very much needed, as the performance of the system takes precedence over storage in this context.

Now we can outline a high level solution as an initial version that we can iterate upon.

![alt](https://firebasestorage.googleapis.com/v0/b/architecture-wizard-a48a6.appspot.com/o/uploads%2FthHMCllc9TcR24op6iZUtxI5Kte2%2F1644603842303.png?alt=media&token=66242f5d-7416-4e05-878c-478659f86494)





Being a huge platform as it is twitter processes insane amounts of information and provides millions of users with their precious dopamine 😄. That being said, it is very worthwhile to look into how one would build such a platform.

Design your system with ease