Summary of Move Monday with Econia and OtterSec. October 10

This Monday the team talked about gas schedule, node requirements, and what could be improved in Move with guests from Econia and OtterSec. 

General information

• Aptos has introduced a new testnet faucet with an attached community platform, as the original faucet was getting drained too fast. The limit is 5 requests per day per IP, which should be enough for testing.

• Node requirements will become higher as the network evolves. On Devnet, you can still use the specs indicated on the website. Mainnet validators should upgrade their hardware, as it is not clear how popular Aptos will be on Day 1.

• A new version of Aptos Explorer is coming soon.

• There are no tutorials for non-developers, but there is information for non-professionals.

https://move-book.com/

Alternatively, some info can be found in the white paper.

https://github.com/aptos-labs/aptos-core/blob/main/developer-docs-site/static/papers/whitepaper.pdf

Econia

• The team published an article about gas and talked about it.

https://aptos.dev/concepts/base-gas/

• Econia came up with a table-based implementation and optimizes everything at the binary level so that people spend less on gas. More details in their article.

https://medium.com/econialabs/optimizing-gas-costs-on-aptos-af31171b768a

OtterSec

• A major blockchain audit firm working with Aptos and other projects.

• Move is secure, but OtterSec wants to make sure that Move VM and Move Framework are secure, too.

• In large projects, there are many parts where things can go wrong. Looking at bug reports, you can identify the area where problems appear.

• They don't see any critical problems across applications, which shows the safety of the Move language. It doesn't allow for a lot of bugs that are common in Solidity.

• Someone can register a coin before you. This is not a serious problem, but it occurs very often across apps. A potential solution would be a notification in case the operation fails.

• For tutorial creators, they recommend creating more complex or high-level examples.

• To successfully find bugs, you need to dig very deep and understand what is happening and what it looks like. Read a lot and try to understand.

• Calling a function is quite expensive, but you can't sacrifice code quality for the sake of gas reduction.

• Immutable elements can be used if an app is small (<100 lines of code) and has been audited. It's also better to use slugs in case something happens.