AergoScan: Smart Contract Code

[kroggen]

When hardfork V4 is available, contracts on the blockchain would have been deployed in these 3 ways:

• By other contracts via contract.deploy() function
• Via transactions from V3 and before (old blocks, bytecode)
• Via transactions from V4 (plain text)

For transactions from V4, the indexer can retrieve the code from the transaction itself and then save it to the storage

For the other cases, an user must send the code via aergoscan for verification

Verification

All contracts are saved on blockchain in bytecode format

For verification, the source code of the candidate code must be compiled via aergoluac app or using the luac API.

Then the bytecode can be compared with the bytecode stored on the blockchain for that specific contract.

If the bytecodes match, the source code can be saved on the storage as verified code.

Storage

The source code of contracts can be stored on:

• Files
• AergoLite

Files

The Indexer or AergoScan engine can store the code for each contract on a separate file, on a folder named verified-contracts

Each file named with the <address>.lua format, example:

AmhnfUk4sKaYBAnwdMxsQBw8r8nys3CNibKqaJwZ6qAnfe4soQh2.lua

If replication is required, the folder can be synchronized with rsync

AergoLite

This tool only allow insertions on the database, making it difficult to change stored code.

It also supports replication

It can be setup with a single table verified_contracts

CREATE TABLE verified_contracts (
address TEXT PRIMARY KEY,
code TEXT
) WITHOUT ROWID

or

CREATE TABLE verified_contracts (
id INTEGER PRIMARY KEY,
address TEXT,
code TEXT
)

ARC1 and ARC2 Contract Factories

Contracts created by verified factories can be trusted and can even receive a badge of "Verified"

But the exact source code depends on the options used, and the factories can be called also by other contracts

The indexer can track the events emitted by the factories to check when a contract is deployed

To get the exact source code:

• Read parameters from events, map them to the source code
• Trying every combination of parameters and comparing the bytecode
• Use a map of bytecode hash -> source code

The first option would require to change the factories to publish the parameters on the emitted event. Maybe not good.

The last option is faster, but requires building the map beforehand for each factory

The map can also be stored on a specific folder, with each bytecode hash as the name of the file and the content containing the source code

Client-Side Interface

The Code tab from the contract page on AergoScan would display, when the code is not verified:

• A label "Not Verified Contract"
• A multi-line text editor
• A button with caption "Verify Source Code"

When the button is clicked, the source code pasted on the text editor would be sent for verification on the backend

If the code is correct, the UI for the tab should change to contain the code in the non-editable widget

Auditing

Later it can also have information somewhere about auditing of the given contract, maybe in the Code tab or another one

[rabbitprincess]

it seems payload in deploy transaction is not just bytecode.
when bytecode save in payload, it combined with other element. ( it seems args and abi )
so, code verification need to know how make payload. i`ll see furthermode.

[kroggen]

Why was this closed if not yet implemented?