Long running Snaps for synchronous work

[david0xd]

This ticket should focus on implementing a solution that would allow Snaps to run for a longer period of time that is beyond the current timeout for execution. This is needed mostly for the use cases where cryptographic synchronous operations require longer periods of time to complete their work (e.g. ZK proofs, etc).

Proposal on how to achieve specified requirements:

• Provide an endowment in the form of a callback with configuration.
• Configuration should specify the time limit for timeout extension.
• Callback should contain functionality that should be executed.
• When a callback is called, pause the termination timers and reset according to the new time limit requested.

Security related requirements:

• Specify maximum time limits that can be requested and used (consider having lowest and highest values).
• Prevent calling the callback endowment multiple times while one is already in the state of execution.
• Prevent (ignore) nested calls of a callback.
• Track a number of the endowment callback calls and make sure there is a limitation to it.

Requirements for future improvements of the UX/UI: Track current state of long running execution requests in order to provide that information to the UI and other platform's architectural elements, in order to improve user experience.

Notes: Consider having e2e testing strategy for improvised use case.

Related resources: https://github.com/MetaMask/snaps/issues/1483 https://github.com/MetaMask/MetaMask-planning/issues/517 Long running snaps research conclusion document: https://docs.google.com/document/d/1BsL75IiepnS1rbfzOVJ5xX3YS3W79Hmyk725lydsqq8/edit

[kenhkan]

From standup: David needs some input from Erik on endowment copy, etc

[eriknson]

Suggested metadata

• Title: Extend runtime
• Icon identifier: timer
• Endowment name: endowment:extend-runtime
• Description: Let this snap run for an extended duration. This can be used when processing large amounts of data.

[Montoya]

Will create another ticket in MetaMask-planning and mark this as blocked

[david0xd]

This ticket is blocked since September 21st because of architectural obstacle with not having proper requestId communicated between the Snap Controller and Execution Environment

Several approaches to this are presented and communicated on Slack channel in the following thread: https://consensys.slack.com/archives/C02GL38PLE6/p1695301614878949 Since all known solutions to this have tradeoffs it is left to be determined which one would be or if should be acceptable or to search for new ideas around the problem.