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:
-
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.
-
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.
-
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.
-
Implementation – the modifications to go-zenon to integrate the runtime.
-
Testing – extensive testing on testnet to assess potential failure modes and stress conditions of the implementation using indicative SCs.
-
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:
-
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)?
-
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
