You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're interested in hearing what quality-of-life improvements would be most useful when developing for the zkVM. These could be, e.g., extensions to the nexus_rt runtime, enhancements to the nexus_sdk, or improved tooling around the cargo nexus CLI.
Our ultimate goal is to in some sense make the Nexus zkVM as invisible as possible, so that the experience of developing and deploying on top of it is nearly indistinguishable from normal execution -- other than, of course, the production of a proof at the end. So we're looking to understand what are the major pain points for developers between us and that goal as things stand.
We also have some quality-of-life improvements in the pipeline, especially around program input and output handling, and so want to have this discussion as a forum for feedback as they become available.
Note: The fact that our runtime is #![no_std] is, we know, a significant quality-of-life pain point. We are working on how best to provide std-like functionality within our verifiable computation that is trustworthy and reliable, which just enabling std would not accomplish. It would be helpful to hear, however, which parts of the standard library are most important to our community, so that we can prioritize thinking about how we might enable support.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
We're interested in hearing what quality-of-life improvements would be most useful when developing for the zkVM. These could be, e.g., extensions to the
nexus_rt
runtime, enhancements to thenexus_sdk
, or improved tooling around thecargo nexus
CLI.Our ultimate goal is to in some sense make the Nexus zkVM as invisible as possible, so that the experience of developing and deploying on top of it is nearly indistinguishable from normal execution -- other than, of course, the production of a proof at the end. So we're looking to understand what are the major pain points for developers between us and that goal as things stand.
We also have some quality-of-life improvements in the pipeline, especially around program input and output handling, and so want to have this discussion as a forum for feedback as they become available.
Note: The fact that our runtime is
#![no_std]
is, we know, a significant quality-of-life pain point. We are working on how best to providestd
-like functionality within our verifiable computation that is trustworthy and reliable, which just enablingstd
would not accomplish. It would be helpful to hear, however, which parts of the standard library are most important to our community, so that we can prioritize thinking about how we might enable support.Beta Was this translation helpful? Give feedback.
All reactions