Poor Man's Attempt to Learn+Earn with Aptos Code Collision

Exploring Code Collision (as a poor web2 dev)

hey guys, so aptos code collision is coming up, and there are many events.

oooooo check out this Aptos bootcamp over here. wait what? you have to pay $250 deposit for this? i dont have any money...

OH HEY WAIT there's also this writing competition. OK LET'S GO earn some $$$ for the bootcamp!

hey they even prepped us some workshop streams. Let's have a look!

hmm wow the 1st workshop by Brian is really interesting!

As someone with a software engineering day job dealing with web2 transactions and attend many workshops on web3 on the side - but not much actual experience building web3 product - i have to say the points highlighted in Brian's workshop are really very very interesting. Here are some fun facts I learnt during the talk!

I liked the fact that Brian started his workshop straightaway with a terminal. Get things straight to the point. What a gigachad.

Fun fact #1: Use NVM

Hopefully you guys are also comfortable with the CLI! If not, I assume you haven’t install nodejs and aptos-cli on your machine, so now is the best time to install your node with nvm! This will allow you to switch between node versions later on. hastag lifehacks!

If you’re on a Mac, it’s best to use homebrew for aptos-cli. Aptos stopped supporting the binary with Aptos because of the way SSL ships with Aptos.

If you're on Linux, you can download the binary release off the aptos-core GitHub page

By the way, the workshop also mentioned that which version of node should not matter, just so long as it’s in LTS.

Here’s how to check if you installed the tools correctly

Fun Fact #2: Use IntelliJ, maybe?

So here, Brian also shared that the best IDE to accompany all these setups is actually IntelliJ from Jetbrains because the plugin for Aptos Move actually works. In contrast, the plugins for move on VS code don't work really well.

The main reason for that is because it's trying to support Sui Move and Aptos Move at the same time so you’ll have to configure some specific features that are specific to Aptos. And even after jumping over those hoops, you're still not going to get good highlighting and weird random warnings and errors.

Though, Brian is using Cursor which is basically a fork of VSCode with AI suggestions add-ons that is making waves on social media right now. So he’s taking a hit on terrible compile messages and syntax highlighting. GigaChad Count: 2!

Fun fact #3: No more cargo or move commands, use npx create-aptos-dapp!

With the environment set up, we can now get use the new tool by the team - create-aptos-dapp! This is a recent endeavour the team has come up with. I know this because I first knew Aptos from their world tour hacksingapore 2023 as one of the Token2049 side events.

Back then, I loved the way how the event venue was organised just for us devs, so I have been following the Aptos progress ever since via Stackup quests, which used to involve manually copy-pasting or typing out manually the boilerplate files. So having this tool now is a tremendous upgrade!

As we go through the steps that the tool shows us, there’s 1 part that is very interesting. So fun fact, while it’s true that both Testnet and Devnet have faucets and their funds on there should not have any value, Devnet can get wiped every single week but Testnet is a long-standing deployment.

So it's good to experiment on Devnet because you can redeploy like a new version that's not like backwards compatible on Devnet, but on Testnet you're stuck with the things deployed so if you have backward incompatible changes you're going to have to pick a different address to deploy again.

The rest of the other options are pretty standard, so now we can proceed on with creating a template project and installing the dependencies. When it's done, amongst all the files generated, we’ll mainly just look into 2 files:

• the Move.toml and

• module.move in the sources folder

Since this blog is getting long, let's have a look at the Move.toml in this article first. And maybe the the module.move in another article if I do well in the writing competition haha! Also, I'm running too close to the deadline for this writing competition, so chop chop!

[package]
name = "boilerplate_template"
version = "1.0.0"
authors = []

[addresses]
module_addr = "_"

[dependencies]
AptosFramework = { git = "https://github.com/aptos-labs/aptos-core.git", rev = "mainnet", subdir = "aptos-move/framework/aptos-framework" }

[dev-dependencies]

Fun Fact #4: Backwards compatibility by default: Strong standardisation at expense of some flexibility

By default, Aptos comes with backwards compatibility, so you don’t have to configure that in this Move.toml. However, if you still want to be explicit about the publishing upgrades, there’s this upgrade_policy options which you can include.

For immutable, you're not going to be able to deploy an upgrade. Is that even a good thing, you may ask? It’s good! Because then the users are guaranteed that there's never going to be “a crypto rug” because this implementation is going to be here forever.

For compatible, it only allows compatible upgrades. So you can change the implementation of functions but you cannot change any of their function signatures. the reason for that is because:

1. you don't want to break that link between contracts by introducing a breaking interface to that function and

2. the other thing that you can't change is your state, so you cannot modify struct you can only introduce new struct to your smart contract but you cannot extend a deployed contract with another field.

Comparing this with the EVM world, this is kind of like a first class support for backwards compatibility. Why? In EVM, you’ll need to use OpenZeppelin proxy and changing the implementation contract, or having separate contracts for logic and states. Think about the times when you wrestled with the fear of overwriting storage somewhere because of the way you structured your state variable.

With Aptos, just republish your package and you get backwards compatibility checking by default because you simply cannot deploy a contract that’s not backwards compatible. This means that you can keep the same contract address AND change the logic.

"so we’re making a token and then deploy it and then add functionality to it in that same contract now?"

Well, yes and no. Because while you can change the implementation of things in your upgrade however Coin is actually a standard.

Drawing parallels with EVM, every token implements the ERC20 interface, so you can implement functions like, "transfer", "show your balance", "show total supply", "name symbol", etc. but inside those functions, it's extremely flexible to the point where there can be booby traps. For example,

You could also write an ERC20 that's perfectly valid for Bob to try to send 10 coins but only five of them ever show up with Alice and then five of them get burned. Psych!

In move, standards and implementations for things like Coins & NFTs are the same for every single one. Because in Move, Coins or NFTs are there in one smart contract in the framework for it first. Then subsequently, you're deploying coins off of that same contract and/or NFTs off of that same contract. So you lose some flexibility but what you gain is really strong standardisation.

Fun fact #5: Use rev = "mainnet" for stable releases

[dependencies]
AptosFramework = { git = "https://github.com/aptos-labs/aptos-core.git", rev = "mainnet", subdir = "aptos-move/framework/aptos-framework" }

Now let’s take a look at the AptosFramework dependency, it’s from GitHub and specifying the rev as mainnet, which you can think of it as the stable version. Fun fact: you can also define this as main to be literally at the bleeding edge with the releases, and that can some times lead to publishing errors because something is in development. Typically you’ll only opt for this option if you know what you’re doing, and you want this special feature that might be only on testnet.

Fun fact #6: Explore Aptos standard libraries in subdir

What’s interesting is that this subdir will directly correspond with the folder structure on Github, and the entry folder will also be sources - which is an important folder name. Inside that folder, those are the files you can import - think of it as a standard library. Drawing parallels (again) to EVM, this is very similar to Foundry.

That's a wrap!

If you made it this far, thanks! I hope you liked my semi-informal approach. I'm under the assumption that all of us don't have enough attention span for lengthy articles, so I hope reading a chill and fun article is a little more bearable. There are many formal technical blogs published for this competition so you should go check them out too by searching #CodeCollision on X! While you're at it, please drop my article some likes to help fund your poor boy into the Aptos bootcamp :( Otherwise there's a Aptos CTF 2024 coming up too, but that looks too intimidating to beginners like me.