Why does Starknet need a debugger?

In this article, we'll explore current challenges developers face with debugging transactions on Starknet.

For any Starknet developer, errors are common occurrences. Broadly classified into Syntax Errors, Runtime Errors, and Logic Errors, each presents its unique challenges. While Syntax errors are easily detected by the compiler, the others pose more significant challenges.

Runtime Errors and Logic Errors spring into action after the contract has been deployed. While Runtime Errors result in reverted transactions, Logic Errors might hide in the shadows where transactions seem to have completed but produce unexpected output.

A key challenge in debugging these errors is the lack of clear error messages and missing runtime context to aid debugging. For instance, an exception like the following might emerge from a transaction.

Error in the called contract (0x049d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7):
Error at pc=0:9:

Got an exception while executing a hint: Assertion failed, 0 % 0x800000000000011000000000000000000000000000000000000000000000001 is equal to 0

For the above exception, Starkscan reveals the contract address where the error occurred, accompanied by an error message stating Assertion failed. Such information is very raw and leaves developers scratching their heads in search of potential solutions to understand this error.

Effective debugging tools are essential in blockchain development. Starknet, like other ecosystems, needs tools that assist developers in addressing transaction errors.

Currently, Starknet developers rely on methods like logging and Call Traces to debug failed transactions. Logging is helpful but limited to the pre-deployment phase, only available for local development. Call Traces, as implemented on Starknet today, provide details of function calls in successful transactions but lack execution details within functions, making it challenging to reconstruct execution states and locate errors. Additionally, Call Traces aren't available for failed transactions, making them unusable for Runtime Errors.

A significant gap in Starknet's debugging arsenal is the absence of a dedicated debugger. Such a tool would allow developers to inspect variables and states during transaction execution. A debugger would make it easier for developers to reconstruct execution state without any modifications to the code and pinpoint errors effectively.

In summary, Starknet's debugging challenges stem from the limitations of current tools like Call Traces and the absence of a debugger. At Walnut, we're committed to improving Starknet's debugging capabilities by enhancing Call Traces for failed transactions and developing a dedicated debugger for Cairo transactions.