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
The testnet does not need much explanation. It is intended to establish a continuous development process by which each iteration will be released to the testnet, and available to use. Initially this will remain internal, and at some point it will be made public. This can best be done when all the subprojects in this document have been developed far enough that they provide a cohesive functionality.
When the Testnet is made publicly available, we expect an increased time dedication to handle issues, fixes and community.
Estimated Delivery Date
This is a continuous project. It is already live and it will see consistent improvement.
Resources Required
Currently we have two developers contributing to it most actively:
DevOps: Gusto.
Peripheral functionality to make the testnet usable: Al.
Servers for testnet:
500€/m (currently at 40€/m)
Used for deploying the Nomos Base Layer Testnet. Currently this is not public. For now the main functionality is to establish CI/CD processes and test the setup internally.
End of the year / Early 2025, we plan to turn this Testnet public.
Deliverables
The testnet itself, which serves as a backbone for other deliverables, is the deliverable itself.
Intended audience: both internal and external. Externally it serves as a way to show progress and for the community to test it.
Tracking Metrics
In progress:
Github commits (node implementation)
Weekly progress reports
Functioning Testnet that integrates the latest iteration's code changes.
Work Breakdown
This is pretty much ad-hoc, as it reflects the last mile of development. When base functionality is ready to be deployed to the Testnet, it is likely that some interface needs to be added to interact with it. I consider this work part of the Testnet subproject, and it is always defined after the functionality is ready. An example of this is the chat application, which serves to showcase a trimmed-down data availability layer (ie no cryptography or sharding involved).
Perceived Risks
Nothing worth noting here.
The text was updated successfully, but these errors were encountered:
Testnet
The testnet does not need much explanation. It is intended to establish a continuous development process by which each iteration will be released to the testnet, and available to use. Initially this will remain internal, and at some point it will be made public. This can best be done when all the subprojects in this document have been developed far enough that they provide a cohesive functionality.
When the Testnet is made publicly available, we expect an increased time dedication to handle issues, fixes and community.
Estimated Delivery Date
This is a continuous project. It is already live and it will see consistent improvement.
Resources Required
Currently we have two developers contributing to it most actively:
Servers for testnet:
Deliverables
The testnet itself, which serves as a backbone for other deliverables, is the deliverable itself.
Tracking Metrics
In progress:
Work Breakdown
This is pretty much ad-hoc, as it reflects the last mile of development. When base functionality is ready to be deployed to the Testnet, it is likely that some interface needs to be added to interact with it. I consider this work part of the Testnet subproject, and it is always defined after the functionality is ready. An example of this is the chat application, which serves to showcase a trimmed-down data availability layer (ie no cryptography or sharding involved).
Perceived Risks
Nothing worth noting here.
The text was updated successfully, but these errors were encountered: