WELLDONE Code(2) — Don’t trust, verify.

WELLDONE Code(2) — Don’t trust, verify.

WELLDONE Code(2) — Don’t trust, verify.

What makes a smart contract smart? There may be many reasons, but the transparency and immutability of smart contracts are undoubtedly the important reasons that make contracts smart.

The logic of the code is transparently disclosed, and the code once distributed cannot be modified. Of course, in the case of contracts that can be upgraded, whether or not they can be upgraded is transparently disclosed. Anyone can read the state of the contract or call a function to change the state, and it is equally transparent to see if a specific account has certain permissions.

Contract is called smart because they enable verification of logic and state through code without human value judgment. These characteristics also make the business environment and ecosystem of Web2 and Web3 significantly different.

The most important thing here is code verification.

Code verification

There can be some misconceptions about code verification. There are three major types of code verification.

The first is the verification of the syntactic validity of the code at the compiler level. Code validation is possible even in the local environment, and if there is a problem with compilation, the compiler will return an error and the compilation will fail.

The second is verification of the logic of the code. It is an audit of intentional or unintentional code vulnerabilities, backdoors, etc., even though the code is fine at the compilation stage. In general, service providers entrust the service contract code they have released to a professional audit company for inspection and disclose the report to the community.

And the third is to verify that the code released by the developer matches the actual code uploaded on-chain. This task is to compare the bytecodes distributed on-chain with the bytecodes obtained by compiling the code published by the service provider to see if they match.

Covered in this article is a third on-chain verification to ensure that the code matches.

How do you verify code?

In the case of Ethereum, most use Etherscan. To date, Etherscan is the most popular Ethereum block explorer. Etherscan provides a contract verification service, and stores and publishes the verification status and source code of the contract so that it can be checked.

However, other non-EVM chains do not provide contract code verification function in the block explorer. The biggest reason is that the compilation environment is different. Unlike Ethereum, most chains such as NEAR, Solana, Cosmos, and Aptos, Sui require a separate server for compilation.

Of course, that doesn’t mean verification is impossible. It is cumbersome, but it is possible if the developer directly compiles the code and compares it with the on-chain contract byte code. Some chains receive the contract address and source code file through a google form and inform whether or not they are verified. We need a more comfortable and safe way.

In the case of NEAR, the code verification function is more important because the contract code can always be updated before the contract account is locked. But there are other reasons that make code verification difficult. A language like Rust does not guarantee that the build is deterministic by the compiler. This means that the output built by the same Rust code is not always the same, depending on the compilation environment (OS, compiler version, packages installed). Therefore, it is very difficult to understand and validate all environment variables because not all developers are developing in the same environment.

WELLDONE Code — Don’t trust, verify.

As we saw in the previous article, WELLDONE Code is an open source project that supports Rust and Move compilation and contract deployment through the Remix IDE. Remix IDE is a web IDE, and it provides deterministic builds for contracts compiled through WELLDONE Code because it uses our built compiler server.

WELLDONE Code — Remix IDE Plugin for multi-chain

Because the same compiler environment is used when deploying and verifying contracts, anyone can utilize and check the contract verification function and verification status on the web.

When a contract is deployed through WELLDONE Code (Remix IDE Plugin), the contract information and code are saved. And developers can check the deployed contract information through the WELLDONE Code (Verification).

WELLDONE Code — Verification (main)

On the detailed page for each contract, you can check the source code, verify verification, lock-up, etc., and provide a real-time verification function. And the “Read Contract” function to read the status information of the contract and the “Write Contract” function to execute the function of the contract will be provided.

WELLDONE Code — Verification (detail)

WELLDONE Code (Remix IDE Plugin), a tool that helps contract development and execution on the web, is available right now. WELLDONE Code (Verification) is scheduled to be launched in the first half of next year.

Although contract code verification is a necessary and important function, it was not easy to find an appropriate method. We look forward to taking a step forward with a more reliable protocol through the WELLDONE Code.

Follow WELLDONE Studio

WELLDONE Code(2) — Don’t trust, verify. was originally published in NEAR Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.