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
This is the first iteration of the nil-db decentralisation and payment specification.
Background
The initial nil-db POC was a single node running on ECS backed by an Atlas-based mongodb cluster. Given some initial traction, we are looking to evolve the project by:
Decentralising nil-db api nodes
Adding a subscription model for payments
Improving observability
Design aims and non-goals
Where ever possible the design should prioritise:
Keep the cluster simple
Push complexity to clients
Requests should be stateless
Keep minimal features until there is a clear requirement for it
Design goals / non-goals / assumptions
On topology:
No requirement for internode communication and therefore there is currently no requirement for a leader node.
There will be 3 nodes in the cluster, where a node is a publicly accessible nil-db api backed by persistence (e.g. mongodb).
Fixed topology (e.g. nodes cannot join/leave the dynamically).
The POC will run on vanilla EC2 instances using a docker-compose and future operators can use this as their starting point for running a own node.
On data:
Plain text and deterministically encrypted data is replicated across all nodes.
If a value is secret shared, then one share per node.
Warning: If a node losses all data, then secret shared values are lost until threshold secret sharing is supported
On clients:
Communicating with the cluster is the client's responsibility (e.g. retries, failures, communicating with each node, etc).
On payments:
A subscription-based system
Payment made on chain with the client's cluster id as payload
Nodes then validate the subscription transaction independently
This is the first iteration of the nil-db decentralisation and payment specification.
Background
The initial nil-db POC was a single node running on ECS backed by an Atlas-based mongodb cluster. Given some initial traction, we are looking to evolve the project by:
Design aims and non-goals
Where ever possible the design should prioritise:
Design goals / non-goals / assumptions
docker-compose
and future operators can use this as their starting point for running a own node.Architecture
Milestones
Milestone 1 (17 Dec 24) - decentralisation
GET /api/v1/cluster
) #50docker-compose.yaml
for running node with local or atlas based persistenceMilestone 2 (9 Jan 25) - nilql / encryption (tbc)
nilql
tonpm
andpypi
Milestone 3 (23 Jan 25) - payments
Milestone other
Open questions
The text was updated successfully, but these errors were encountered: