Implementing a smart contract runtime on NoM

One of the key components of the network required to support further development of the NoM ecosystem is the implementation of a smart contract (SC) runtime. If we had this in place, it would allow any number of projects to be built on top of the NoM. It seems like adding SC functionality is the biggest gap to ecosystem growth we face right now. Essentially, we need to build this functionality as soon as possible to allow the ecosystem to develop and the value of the network to be realized.

Over the last couple of weeks @Dumeril and I have been discussing the best approach to filling this gap and have had conversations with a few other community members as well.

On the one hand, the core team would be in the best position to implement a SC runtime, given their deep knowledge of the current architecture and blockchain development experience.

However, it seems that we cannot rely on the team to do this as the response has been that a SC runtime should be implemented by the community as part of AZ.

The purpose of this post is to gauge community interest in a multi-stage AZ proposal. Please note we are just putting this out there for community feedback at this point and it’s not an official proposal. We would only consider putting forward a proposal if we get community support for the concept and are able to construct a suitable team.

In brief terms, the proposal would involve the following stages:

  1. External analysis - an assessment of available runtimes, including WASM with a discussion of pros/cons with respect to performance, security, flexibility etc and a recommendation on which runtime to implement.

  2. Internal analysis - an assessment of the current NoM design, the current embedded SCs and how consensus is reached, potential anchor points for the runtime and a generalized approach for how to implement a runtime on NoM.

  3. Implementation proposal - an architectural overview for implementation showing how the vm would fit into the code, how and where it would interact with the existing structures, information flow, storage.

  4. Implementation – the modifications to go-zenon to integrate the runtime.

  5. Testing – extensive testing on testnet to assess potential failure modes and stress conditions of the implementation using indicative SCs.

  6. Softfork – a proposal to take the SC runtime live.

We would plan to deliver these outputs to the community at each stage, so that in the event something goes awry, other community members could pick up the torch and continue the efforts.

To give the community an idea of some of the questions we think we will need to answer through this process, and the fairly significant complexity, please take a look at the following indicative questions currently being discussed:

Which nodes will host the runtime? In the whitepaper, computation as a service is envisaged to be done by sentinels. At present it would need to be performed by all nodes or at the very least pillars. How do the runtime outputs affect consensus? Is the current consensus mechanism setup correctly to take these inputs? What if the runtime produces different outputs on different nodes? How is consensus reached?

How do we ensure that the runtime is efficient and scalable? Poor implementation decisions could have ramifications down the line. For example, there are key decisions to make around runtime termination (ie a timeout if the SC hangs) which could affect the usability of the runtime and/or the stability of the network.

Economics - how does plasma interact with the runtime. Computation has a cost which is borne by nodes. Are the current plasma tables suitable? Should we have higher and higher plasma requirements for computation. For example in EVM you’ll get a high gas fee if you try to do something that can’t be computed. On NoM, would you need really high plasma to do the same? How do you prevent a SC attack (DDoS style) without this? Imagine an attacker sending lots of impossible to compute SCs to overload the network. How do we assign increasing plasma requirements to different computational loads?

The above are just a few things that we are currently considering but of course there will be many more questions to answer.

At this point, we are really looking for feedback in two main areas:

  1. Is the community supportive of a community led effort to develop and implement a SC runtime? We feel that quite a bit of analysis is required before commencing implementation. Is the community supportive of funding these research activities prior to implementation (of course on the proviso that all reports are made available to the community)?

  2. If there is sufficient interest in the approach, we would need to form a team of ~4 people to spread the workload. At present, Dumeril and I are interested in participating as team members. I would be helping with research, project coordination, communications and reporting. Dumeril would be working as a researcher and developer on the project. We are looking for ~2 more people who could assist and would like to hear from the community if anyone is interested. Since the first stages of the project would focus on research, at this point it doesn’t necessarily have to be active developers. It’s possible to regroup for every stage, though ideally we would have a stable (core) team of course.

Finally, neither of us are looking to do this for the money. We will be underpaid versus our day jobs and neither of us are looking for additional work. If we work on this project, it’s to support the development of the ecosystem and the value of NoM rather than for personal gain.

We look forward to your feedback.

Jeron & Dumeril


I absolutely support this effort, and i bet many others do, too.


Great initiative - I would definitely support this

My main thoughts:

-As discussed in the other thread, if the core devs are keen to get involved it’s a no-brainer to say yes
-I think it’s key to assess the benefits of each runtime option in relation to Zenon specifically, even though we think WASM will be the way forward
-Major findings/roadblocks should be shared with the community early to facilitate discussion and insight in an attempt to gain consensus on architectural decisions
-We need a way to garner involvement from the core devs even if it is just review of decisions or ideas


This is an amazing initiative, and you guys are both longtime community members who are well-respected. You guys definitely should be paid for your time and efforts, one of the goals of AZ is to allocate capital to positive contributors.

I’d like to draw attention to the fact that the first three stages (the external/internal analysis and implementation proposal) can cause absolutely no harm as it’s just knowledge and ideas, all verifiable for anyone else wanting to do the same thing. The worst case is we fund research and a design which is not implemented but at least makes understanding Zenon more accessible for external talent. The best case scenario is we unlock the key to building anything on the NoM!!!
Game theory = let’s at least fund until the implementation proposal is presented and open for dissection/feedback/criticism/praise


I just wanna add that I love you guys <3 and that this initiative supports the very ethos of Zenon being a community-driven approach (I just hope that the core team takes note of this and proactively assists in the development of SCs)!


I’m in full support. If you guys need any computing support I can provide that at no cost. In the form of VMs or public nodes. I can also provide API endpoints if you need them.

My only comment is we really need feedback from the core team that they are NOT doing this themselves. Can you imagine spending all this time only to learn they are doing it. That would be a terrible waste of your time that could have been spent on something else to advance the project.

I also think we should ask for support / input from the core devs. They are part of the community and we are asking for community support. Even if that support is through @Sigli. They know the code base better than anyone. And they know the road map. If you were able to collaborate with just one core dev, my sense is it will save you a ton of time.

I can support you guys with websites, VMs, hosting “stuff”, basically anything infrastructure. Just let me know how I can help.


This is a community led initiative, and since the core devs are already part of the community, I have a feeling at least one may or may not be recruited to the team at one or all of the stages. At the very least there’d be some good points raised at stage 3 from a variety of voices.

I wouldn’t say we necessarily need any explicit communications from them, and maybe it has to be this way to respect the fair playing field of AZ contributors.

1 Like

I support this on the condition that the core team/MK is somehow involved in some capacity along the way. The reason is the questions you’ve raised regarding computation, economics, efficiency…etc. These are gaps in our understanding of the NoM’s fundamentals which I believe are only the tip of the iceberg, the rest will start to materialize the more you look into it. I have trust in your capabilities to eventually figure it out, and have full trust in your intentions in this regard as demonstrated through your ongoing contributions to the project. However, I believe that it’s simply not an efficient use of resources to have you effectively start from scratch and play catch-up on your own when the core team has stated that they are part of the community. The deliverable is a huge undertaking and a core aspect of the network. Therefore, I believe that the team/MK must step up/in and help the community to achieve it, that is of course if they are truly part of the community.


Thanks romeo.

Yes we will seek to have the core devs invovled.
The first step will be to assess various runtimes including WASM.
We will definitely share roadblocks as we go and would be careful to get community feedback on key architectural aspects of the proposal.

1 Like

Thanks to everyone for their feedback. We too would like to have the core devs invovled in this and will definitely be reaching out for input. As Zyler said, the best outcome would be to have one of the core devs actually join the team. I guess we don’t even know their identities other than Kaine.

To be clear, the only reason we are thinking to propose this project is that so far Kaine has said its up to the community to implement a SC runtime. We will double check this next time he is in chat. As pointed out in the feedback, this would just be a big waste of everyones time if there is duplication of effort.

We are still looking for expressions of interest from other community members to join the team. Feel free to post here or DM on any other channels if you are interested.


I support the development of a SC runtime, but I think that the goals you present are too ambitious, honestly. Full disclosure, I’ve been thinking of this problem and I do have a ‘solution’ of sorts myself, and I don’t think that having a standard solution, where there is a VM in the node and all is in the node, is what we need.

TL;DR: I think it’ll take 1-2 years to finish this, so by that time, I feel it’ll be too late IMO

  • It took the core devs ~1 year from a public testnet to a release
  • AZ was released a long time after the network went live and that is just an embedded contract, not a generalized VM runtime

Again, I don’t plan to discourage anyone from trying this task, even thou most probably I do just that.

I suggest that you make a TG group specific for the SC Runtime :sunglasses:


Ok great happy to discuss further.

If the VM isn’t in the node, then I would think the SC execution is vulnerable to exploits.

I guess the research steps may indeed reveal that this is more complicated that first thought, but better to at least try to find a path.

It took the core devs ~1 year from a public testnet to a release

Yes but they were fixing the node software, the wallet and then had to implement the swap function, ensure smooth transition etc.

AZ was released a long time after the network went live and that is just an embedded contract, not a generalized VM runtime

Based on what Kaine was saying, AZ has only been a focus for a few months. Prior to that they were getting the bridge running, getting the network to a stable state with mulitple znnd releases, various wallet updates etc. Also the implementation of AZ was an implementaion of a specifc set of SCs and wallet update, not an implementation of a runtime as such. So I think that is probably not too informative in terms of how much wokr it would be to implement a runtime. @Dumeril would be better placed to discussed the VM architecture for the embedded SCs, but that is one of the first things we were going to look at to see how the data flows etc.

Let’s have a further chat on TG. Maybe you should join the team??? :wink:


I support this but 100% agree core team needs to be involved in some way and think that should be before the proposal is submitted. I don’t remember seeing smart contracts in the AZ medium so if the team is working on this obviously we don’t want duplication of efforts. MK has been active lately so maybe he can help refine the scope of the proposal and act as conduit to core


I have reached out to Kaine via DMs on that matter (told him it’s critical the team provides some guidance for WASM / SC runtime implementation). He hasn’t been on TG for weeks and hasn’t read my DM yet :man_shrugging:

1 Like

@Sigli can you ask for a response to Shazz and also MrK to join the forum potentially?


You guys are definitely onto Something big here .

While adding an EVM to a feeless network might not be a good idea, I’ve come across the following solutions that might be perfect in our case:

This could allow users to do all the processing off-chain and only store on-chain the following components:

  • compiled contract
  • execution proof
  • inputs (parameters)
  • outputs (result)

Why is this better than EVM?
On EVM when a user interacts with a smart contract, all the nodes in the network need to execute the contract and every new node needs to re-execute all the smart contract interactions when it syncs.

Using Cairo + Winterfell, on the other hand, nodes would only need to verify the proof and all the execution is done by the user off-chain, only once.


I’m writing the April dev update. I want to make sure I understand the latest developments on L2s. As I understand it, @aliencoder is working on (or plans to work on) a side chain that will be EVM compatible. That general discussion is here.

And @sumamu you are working on a separate L2 scaling solution. Looks like you are considering a Starkware solution.

Are you guys thinking the EVM will live in the Side Chain developed by @aliencoder and a Cairo + Winterfell L2 would be used for Stark contracts?

1 Like

I think @sumamu suggests implementing the Starkware contracts directly on NoM.

This should be in line with MrK’s minimalistic approach.

I think we should call them extension chains and market them accordingly.