Web Platform-based Debugger for NEAR Protocol contracts

[nagisa]

This is an issue that outlines a concrete implementation proposal for the abstract issue #6485. The problems to solve and goals are outlined in that issue, do by all means read it first.

In order to solve this issue a PoC of the NEAR Contract debugger web-app is made available at near.gihub.io/debugger or elsewhere. The web-app executes locally with no server components and heavily utilizes Web platform APIs to make debugging a similar experience to that of the regular web applications. This hints at the core of this proposal: the implementation of the debugger heavily relies on the web developer tools available in web browsers such as Firefox or Chrome(-ium). These web-tools already have a pretty well fleshed out story for debugging webassembly code, as seen e.g. in this video. Furthermore, as the toolchain ecosystem is generally geared towards wasm use in web2 contexts, any improvements to the debugging story will be immediately available for use when debugging NEAR Protocol Contracts as well.

The debugger web page facilitates very specific task of setting up and calling entrypoints inside the contract. In order to do so it needs to give user an ability to at least "upload" the WASM contract, specify the function call parameters (function name & arguments) and, once the execution is requested, run the code in the browser's WebAssembly runtime.

In order to achieve execution the debugger will need to provide the implementation of the host functions in terms of web platform APIs as well as to (optionally) implement the contract preparation code (if not everything, a significant part of this logic – finite-wasm – could also be compiled to WASM.) The implementation of host functions wouldn't necessarily be super holistic 1:1 representation of the NEAR Protocol runtime. The logging messages would immediately output to the console through console.log instead of accumulating up internally, storage would directly store key-values in the local storage (this allows using the developer tools to debug the storage! Though at the same time representing "trie node touching" fees becomes hard or infeasible,) promises wouldn't necessarily do anything (other than be shown somewhere in the interface as an "execution result",) etc.

With these ideas implemented we'd have a PoC that should significantly improve developer experience of the near protocol and make this part of it much better compared to many other blockchains on the market. It would become much easier to estimate the amount of gas to attach to a contract (though still not exactly, due to e.g. differences in trie fees.)

---

As post-PoC development opportunities we could work on: ability to export from mainnet/testnet/*net a subset of trie and to import it into the debugger for debugging problems with specific storage, ability to tweak host functions within the debugger for further flexibility, in-depth customization of the execution context (input/block index/block timestamp/epoch height/account balances/random seed), retention of configuration (so that you don't need to redo all of the setup after reloading the page...)