polkarun application

[hitchhooker]

Project Abstract

polka.run - PolkaVM disassembler is a project aimed at demystifying PolkaVM bytecode through a suite of web tools, with the centerpiece being a user-friendly disassembler GUI. This tool translates .polkavm binary files into readable formats, making it accessible to a broader audience and enhancing the development and debugging process for PolkaVM-based smart contracts. Building upon our MVP, which successfully demonstrated core functionality (file upload, memory dump visualization, and graphical instruction representation), this project strives to deepen the understanding and usability of PolkaVM bytecode within the community.

Grant Level

• Level 2: Up to $30,000, 3 approvals

Application Checklist

• The application template has been copied and aptly renamed (polkarun.md).
• I have read the application guidelines.
• Payment details have been provided (Polkadot (USDC & USDT) address in the application).
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• [] I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @hitchhooker:matrix.org and Dan's @meeb:matrix.org

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[hitchhooker]

I have read and hereby sign the Contributor License Agreement.

[keeganquigley]

Thanks for the application @hitchhooker I definitely think we can use more RISC-V related grants. A couple of initial questions:

• I don't see a currency specified, are you willing to accept USDC on Asset Hub? If so can you note this to the right of the Polkadot address?
• Generally, we don't pay to get code ready for production. Would you be willing to remove M2 0d. Automated Deployment and reduce the scope/cost accordingly?
• I see that a prototype has already been built, could you specify in the application what has been built already and what would be built as part of the grant? As a note, we don't do retroactive funding.
• Has the PolkaVM team expressed interest in this project, or have you been involved with them in some way?

Thanks!

[hitchhooker]

Hey Keegan,

thank you for reviewing our application.

We are happy to accept USDC on Asset Hub(1Qrotkokp6taAeLThuwgzR7Mu3YQonZohwrzixwGnrD1QDT) as well.

I did post the one of the early versions of disassembler to polkadot forums and polkavm author's response was generally positive alerting about codebase being still alpha and facing a lot of changes. In general changes in upstream have not yet caused us to do any changes in our codebase, but every time application has broken due to changes in binary standard, we have solved it by pumping the dependencies.

I did not realize that W3F grants not doing retroactive funding. Only the first milestone had been done this far to understand a bit better what we are actually building here, is it possible and how it should be done. I will remove the currently first milestone from application and perhaps ask funding for that work from treasuries instead. I will also remove 0d. Automated Deployment and adjust asked grant accordingly.

[keeganquigley]

Awesome thanks for the changes @hitchhooker sounds good, yeah the treasury does do retroactive funding but not the grants program. Looks better to me now so I will mark as ready for review and ping the rest of the committee for comment.

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811/79

[xermicus]

(I am a maintainer of Solang, a Solidity compiler targeting the contracts pallet, with experimental support for PolkaVM. So far, browser-based tooling around Wasm contracts did fall short quite a bit in comparison with EVM, so I thought I'd give a personal opinion on this)

Thanks for this proposal! Strong web-browser based tooling around PolkaVM, comparable to what we have in the EVM world, is something that we will need undoubtedly (in my opinion). I appreciate that you are already building something in that area!

However I have some questions and concerns regarding the usefulness and long term visions of this project.

I think that the proposal is a bit too centric on the disassembler part, something already provided by PolkaVM itself (the core functionality without a web UI) and not required by the average contract developer (contract developers must not regularly rely on using a disassembler for writing contracts or we have failed spectacularly) . In regards to online tooling, there is so much more that can be done that would be very valuable and useful to smart contract developers. Where the disassembler is just a part of it.

Some very useful things that we probably need to have sooner or later anyways to seriously compete with the EVM ecosystem, that could be built on top or next to a disassembler:

• A decompiler. Disassemblers just translate linearly from one representation to another, more human friendly format. Domain specific decompilers can use domain specific analyzer passes and heuristics to distill a lot of information, vastly simplifying reverse-engineering unknown contract blobs. State of the Art currently is probably the dedaub decompiler.
• A database mapping known contract code to it's blob, accounting for compiler and PolkaVM versions. Very useful because it allows lookups and similarity scoring of unknown contract blobs.
• Expanding on above; A signature database (here I mean a code signature database but a function selector signature database for ink! contracts would also be helpful), allowing lookups on individual functions. This is even more useful and one of the reasons why the dedaub decompiler is so good.
• A debugger allowing to replay and debug execution traces, just like on remix IDE. Obviously this is very useful for understanding transactions.
• Above points could then be used by block explorers to build nice "smart contract explorers".
• A "compiler explorer" for PolkaVM contracts. However a bit unclear how it would look like, because contracts can be written in Rust, Solidity or anything that compiles to RiscV.
• Ideally this would be integrated into something like the ink! Playground. This would be useful to understand the compiled contract artifact; it allows for example debugging compiler bugs or it can help spotting costly parts that could be improved. But beware, building a online IDE is a lot of work, especially if we want to compete with Remix.

I understand that the scope of those is way bigger than building a RISC-V disassembler for a custom binary container format. However I fail too see the value added by spending more money on a browser-based RISC-V disassembler at this point in time.

Unless this would just be the principal foundational work required for building solid browser-based tooling competing with what the EVM ecosystem already has. With a clear vision for this project to build browser-based tooling which is actually useful beyond just being an alternative disassembler user interface I'm in full support! Sooner or later we will need such tools anyways to not fall short against EVM.

EDIT: Reading through my comments again they may sound overly negative, however my intend was just to motivate this proposal to aim a bit higher :)

[xermicus]

PolkaVM itself already provides a CLI that can disassemble blobs. Is it re-used or something you developed on your own?

[xermicus]

Why would we need another disassembler already? At this point, it'd be better suited to use the tooling provided by PolkaVM and improve if needed.

PolkaVM is not yet production ready, things can move and break fast. Having multiple implementations already at this point is not desirable in my opinion.

[xermicus]

How does this enhance debugging and development of smart contracts? Are you planning to add a feature to replay transactions based on the hash? Or some mock environment to trace and replay the execution?

A disassembler on its own doesn't enhance debugging and development of contracts. It's way too low level.

[xermicus]

Can you elaborate on what those "hint" fields would contain? Source code locations need to be provided by the compiler

[xermicus]

Where does the source code come from?

[xermicus]

What is the use case for such a "binary editor"?

[xermicus]

This is a contradiction. People that are going to read and make sense of some random RISC-V assembly code (which is always hard) are certainly capable of installing and using the polkatool command line App which already provides a disassembler. That said, a WebApp can certainly be more user friendly and more pleasant to use for some people (but it is a question of personal preference).

[semuelle]

Thanks for contributing to the conversation, @xermicus! I'll just ping @hitchhooker here for visibility.

[semuelle]

@hitchhooker, could you have a look at Cyrill's questions and comments and respond where appropriate?

[semuelle]

I'm closing this PR due to inactivity. Let me know if you want to continue working on it, @hitchhooker, and I'll reopen it.