Greetings dear readers!

We continue our series of educational articles and today we’ll look at some professional tips in the auditing smart contracts on NEAR blockchain. In this series we will focus only on those aspects that can be really useful for auditing NEAR-based projects. Everything you see below is based on our personal experience!

Read an original article via the link below:

First and foremost, we would like to express our sincere gratitude to the creators of NEAR and its ecosystem projects, everyone who supports it, the Authors of all the resource materials, and of course our brilliant auditors who have helped us by revealing much-needed information and lifting the curtain of secrecy. And today, dear readers, it will be made available to you.

We can confidently say that such tips can be read publicly in a few places, and our blog is one of those places! The following will be our observations — only dry facts for auditors, tricks and the best life-hacks shared by our best auditors. Let’s get started!

I - What is NEAR?

NEAR is a development platform built on a sharded, proof-of-stake, layer-one blockchain. Using sharding technology, NEAR offers solutions to problems such as slow processing speed, network congestion, and high gas charges, allowing for significant platform scalability without sacrificing protocol security.

It is important to keep in mind that NEAR is a scalable sharded blockchain which means that deployed smart contracts are compiled to WebAssembly (WASM) and can be written in languages:

• Rust

• AssemblyScript (a TypeScript-like language for WebAssembly)

• Solidity (via Aurora EVM)

• Javascript (via JS-VM)

The use of WASM results in a high gas limit and efficiency, quick block generation, and lower transaction fees. Smart contracts in NEAR can be considered micro-services containing data and executable code. Cross-contract interactions are performed asynchronously.

With all said, from our perspective, NEAR Ecosystem is mostly Rust-based!

The platform brings together thousands of community members to deliver the most comfortable experience, as well as a wide multifunctional ecosystem:

The platform is based on several key features:

In terms of block production security, they employ a mechanism known as Doomslug. Doomslug, despite its ominous name, is quite simple and assumes that different validators take turns producing blocks based on how many NEAR tokens they staked.

We will not go into detail in this article because we assume you, dear reader, already have a sufficient understanding of the NEAR ecosystem, so we strongly advise you to visit their knowledge-base and study the project documentation for a better understanding:

II - NEAR Project Review Procedure from the Pessimistic.io Team:

Because the main obstacles that the auditor may have while auditing projects on NEAR are logical, the first suggestion for any firm will be in competent development, which results in solid documentation and reliable tests. It sounds too simple to be true, but be sure it works and it only proves itself over time!

So, our brilliant auditing team would like to present you our own set of rules, accumulated over many months and years of work, in which we will try to avoid redundancy and try to convey everything very concisely and professionally. With all said, we perform our audit according to the following procedures:

Automated analysis:

• We compile contracts;

• We run provided tests and check code coverage;

• We run analysis tools and manually verify (reject or confirm) all reported issues (see below);

Manual audit:

• We manually review the code and assess its quality;

• We check the code for known vulnerabilities;

• We check whether the code logic complies with provided documentation;

• We suggest possible gas and storage optimizations;

Issues:

We are actively looking for:

• Access control issues (incorrect admin or users identification/authorization);

• Lost/stolen assets issues (assets being stuck on the contract or sent to nowhere or to a wrong account);

• DoS due to logical issues (deadlock, state machine error, etc);

• DoS due to technical issues (Out-of-Gas error, other limitations);

• Contract interaction issues (reentrancy, insecure calls, caller assumptions);

• Arithmetic issues (overflow, underflow, rounding issues);

• Incorrect Near SDK usage;

• Other issues.

Gas

We check whether the gas-intesive operations are performed efficiently:

• Collections — collections from std::collections are read all together, which inflates gas consumption. You should use near_sdk::collections or near_sdk::store;

• Collections are tied to a storage, and you can accidentally forget to sync them;

• Maps: LookupMap / UnorderedMap / TreeMap — You need to choose according to the required functionality (the first is the cheapest, the last the most powerful);

• LazyOption — for rarely used “big data” (can only be used in the constructor);

• Borsh/JSON for serialization of messages (parameters/return values) — affects gas consumption;

• Take a close look at The “million cheap data additions” attack to avoid similar issues.

Tools:

Let’s take a close look at the automatic analysis tools you can use in your work and their features:

• Valgrind — can be used if the code includes unsafe blocks with dangerous memory allocation. However, such a practice raises a red flag for the audit. In general, running valgrind makes no big sense!

• Cargo Geiger is a tool that displays statistics about the use of unsafe Rust code in a Rust crate and all of its dependencies. Its ability to focus on possible problems is a beneficial feature. The existence of hazardous code is already an issue in such projects, and any such entries should be double-checked.

• Cargo Audit — checks files for crates that contain security vulnerabilities. That is, it displays out-of-date libraries that everyone still uses. However, you should use it for audit purposes.

• Clippy static analyzer is an awesome code linter to catch common mistakes and improve your Rust code.

• Cargo Tarpaulin — for test coverage — a very handy tool that reveals the number of code lines that are not covered by tests.

Also check out:

III - Audit Public Reports

Our own NEAR ecosystem projects audit public reports are structured according to a presented above audit-flow scheme, so we recommend that you compare these reports, particularly their results, to it:

• Sweat Economy Security Analysis by Pessimistic

• Neatar Security Analysis by Pessimistic

We hope that this article was informative and useful for you! Thank you for reading! What instruments should we review? What would you be interested in reading about in our blog ?

If you still have questions, please feel free to ask! We will be happy to answer every question you have! The best answers and questions may be included in the next blog post!

May the Force be with you!