I had the pleasure of being a finalist at the Autonomous World Hackathon "ETHGlobalAW"!

https://twitter.com/yamapyblack/status/1662281247761256450?s=20

During this hackathon, I got my first experience using the Solidity framework ‘MUD'. MUD is a framework developed by 'Lattice' which is well-suited for Autonomous Worlds (AW). However, it isn't limited to this usage and could also be employed in DeFi, among other applications.

For those who are wondering what exactly MUD is, I'm going to describe its features along with sharing my personal impressions.

MUD: https://mud.dev/

Please note: The MUD v2 that I used is, as noted on the official site, an alpha version. Since it is still under development, use it at your own risk. Moreover, I am a beginner with MUD and cannot guarantee the accuracy of the content in this article. Please proceed with your own research (DYOR).

As you can see if you check the repository, it has both a React-based frontend and a Foundry-based backend. The package manager used is pnpm.

In previous Dapps development, I felt the backend (smart contract) and the frontend often worked separately. In contrast, with MUD, these elements are unified.

The benefit of this is evident in the local development process, where with a single dev command, you can deploy the smart contract and start up the interface.

For instance, let's say you change the name of a function on the smart contract side. Normally, the frontend would need to switch over to the newly redeployed address. Also, it would be necessary to retrieve and apply the ABI.

In the case of MUD, the frontend can access the latest address and ABI after deployment, making it possible to test from the interface always with the current state of the contract.

It's indeed convenient, isn't it?

By defining the columns of a table in the config, a contract is automatically generated. Have a look at the following config:

tables: {
  MyTable: {
    schema: {
      foo: "uint256",
      bar: "bool",
    },
  },
}

Just by writing this, a smart contract is automatically created.

Smart contracts generally serve two major roles: "Storage" and "Logic." In MUD, these two roles are completely separated. The Storage contract is what gets auto-generated.

You could picture it as similar to migrations in Rails or Laravel (PHP) for a clearer understanding.

The advantages of this feature are not just the readability of the table definitions, but also the fact that you no longer have to constantly consider getters.

For instance, if there's a variable called owner, it can be unclear whether it should be retrieved as:

• address public owner, or

• through a function getOwner(), or

• via an event OwnerChanged.

With the automatic generation, you don't have to worry about this.

Because there are functions prepared to retrieve smart contract values from the frontend, you don't need to worry about how to get the values.

When deploying a contract with MUD, a contract called "World" is generated.

In fact, this is the only contract that should be executed from the frontend.

In conventional applications, you deploy a multitude of contracts and define all of their addresses on the frontend to select and initiate transactions. In MUD, this is simplified to just one.

When you create a logic contract called "System," an Interface is automatically generated.

interface IIncrementSystem {
  function increment() external returns (uint32);
}

Looking at the Interface of World, which is "IWorld," you can see it inherits all the interfaces of the System you created.

interface IWorld is IIncrementSystem, IBaseWorld, IAddSystem {
}

All logic is executed through the World.

Therefore, the only contract that the frontend needs to execute is this single World contract.

I haven't used this yet, but it seems that by creating a Namespace (essentially a directory), you can implement access control to Storage. Access control refers to features like "OnlyOwner".

It's possible to create multiple services within one World.

root
|-- mudswap <- Namespace
    | Balance <- Table
    | Pool <- Table
    | Transfer <- System
|-- Tetris <- Namespace
    | Board <- Table
    | Move <- System
    | Drop <- System
    | Score <- Table
    | Win <- System

The above is an example of creating an app called "mudswap" and another called "Tetris" in the same World.

The last feature I want to mention is a frontend feature called Optimistic Rendering.

Take a look at this.

With MUD, you can perform ultra-fast screen drawing when creating a game. No matter how you look at it, the speed of the characters is faster than the transaction speed, despite all character movements being recorded on-chain.

This mechanism is known as Optimistic Rendering.

It operates in the following flow:

• Send a transaction

• Move the character (front-end)

• Retrieve the result of the transaction. If an error occurs, return the character to its original position

This is similar to Optimistic Rollup. You act optimistically, and if an error occurs, you revert back.

The fact that this feature can be implemented with just a few lines of code is fantastic.

However, of course, there is a risk that reverting might cause bugs in the game screen, so whether to use it or not depends on the use case.

(Also, I think the video is fast because it's local or something like that.)

Up until now, I have been highlighting all the great aspects of MUD, but from here, let's talk about the challenges it faces.

In the MUD tutorial, the private key is written in the .env file. This is a no-go.

While it is possible to execute transactions from a wallet such as MetaMask, there may be UX issues when there are a large number of transactions, like in a game. There might be a need for a wallet specifically for MUD.

With the proliferation of AA, wallet development has become more active, so let's hope this issue will be resolved soon.

MUD is a thick framework, and I can't imagine a concrete image for integrating other contracts. I think it's possible to incorporate ERC20 or ERC721, but if you want to reuse existing contracts for development, it might actually take extra time.

It would be desirable to have many examples of contracts created with MUD.

How will audits be handled? The auto-generated part seems to be no problem, but for other parts, some kind of review or audit is necessary. Audit firms may also need a prerequisite knowledge of MUD.

However, considering the number of hacking cases in DeFi, I believe that a smart contract framework is necessary. It would be nice if MUD could actually enhance security.

MUD is still incomplete and has many challenges to solve, but I felt it was a very promising framework. I think the Lattice team, which developed this, has considerable development capabilities.

Also, with the advent of MUD, I am arbitrarily predicting that other smart contract frameworks will also appear.

I want to continue to keep an eye on the trends in MUD and the AW community.

References:

• Github: https://github.com/yamapyblack/AutonomousLifeGame

• Official MUD: https://mud.dev/

• Ethereum navi: https://ethereumnavi.com/2022/11/19/lattice-mud/

• AW house: https://twitter.com/AW_house