Skip to content
This repository has been archived by the owner on Aug 23, 2022. It is now read-only.

Algorithm

Bernardo Vieira edited this page Aug 12, 2019 · 4 revisions

Welcome

Thank you, first of all. You must be really courageous to be here reading this. You are definitely strong. Keep going.

solviz works in two steps, first it analyses, then maps.

Context

Before getting started, a few things need to be clarified. Each method as a unique identification. That identification is a string that is build following the rule below:

contractName:methodName[:variableType]

First step, profiling

During the first step, the algorithm takes all the information needed on the second step. The require information is mainly contract definitions, import directives, using for declarations, variables declaration, event definitions, struct definition and import directives.

All the types above are added to a contractList array, contractVariables array or event an ignoreList array or importVisited array.

The reason to have all of this is because we want to consider struct calls a variables and not methods for example, or when a method is called within another method, and the variable being sent to the function is a variable instead of a value, it's necessary to know its' type, because the type will be used to map to the correct function id.

Second step, process it

Let's take one result as an example from crypto kitties

{
    "file": "./test/contracts/cryptokitties/KittyAuction.sol",
    "edge": [
        {
            "id": "ClockAuctionBase:_transfer:address:uint256",
            "imports": []
        },
        {
            "id": "ClockAuctionBase:_removeAuction:uint256",
            "imports": []
        },
        {
            "id": "ClockAuctionBase:_cancelAuction:uint256:address",
            "imports": [
                "ClockAuctionBase:_removeAuction:uint256",
                "ClockAuctionBase:_transfer:address:uint256"
            ]
        }
    ]
}

The example above shows a possible and real result, used in edge bundling visualization.

This second step works recursively and uses all the variables from the first step. Using a given contract, it starts navigating through it's imported, recursively, until it gets to a contract that has no imports and then navigates through all functions. And then, it goes through all inherited contracts.

When going through the functions it is registering the function calls within each function definition of a contract. This will map all the calls and give a raw result of everything.

And finally the last step. It takes the data and transforms it to be consumed by the chart, resulting in something as shown above.

Clone this wiki locally