Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Milestone: Decentralisation and payments specification #48

Open
7 of 19 tasks
tim-hm opened this issue Dec 2, 2024 · 0 comments
Open
7 of 19 tasks

Milestone: Decentralisation and payments specification #48

tim-hm opened this issue Dec 2, 2024 · 0 comments
Assignees

Comments

@tim-hm
Copy link
Collaborator

tim-hm commented Dec 2, 2024

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:

  1. Decentralising nil-db api nodes
  2. Adding a subscription model for payments
  3. 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

  1. On topology:
    1. No requirement for internode communication and therefore there is currently no requirement for a leader node.
    2. There will be 3 nodes in the cluster, where a node is a publicly accessible nil-db api backed by persistence (e.g. mongodb).
    3. Fixed topology (e.g. nodes cannot join/leave the dynamically).
    4. 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.
  2. On data:
    1. Plain text and deterministically encrypted data is replicated across all nodes.
    2. If a value is secret shared, then one share per node.
    3. Warning: If a node losses all data, then secret shared values are lost until threshold secret sharing is supported
  3. On clients:
    1. Communicating with the cluster is the client's responsibility (e.g. retries, failures, communicating with each node, etc).
  4. On payments:
    1. A subscription-based system
    2. Payment made on chain with the client's cluster id as payload
    3. Nodes then validate the subscription transaction independently

Architecture

Image

Milestones

Milestone 1 (17 Dec 24) - decentralisation

Milestone 2 (9 Jan 25) - nilql / encryption (tbc)

  • feat: validate secret shares
  • feat: validate deterministic queryable encryption
  • feat: validate aggregations
  • feat: package and publish nilql to npm and pypi

Milestone 3 (23 Jan 25) - payments

  • feat(nilchain): Document/support the payment tx payload (e.g. website)
  • feat(payments): Add payment validation endpoint with tx validation and cache/db for subscription status
  • feat(payments): Add api-key-based rate limiting (eg 10k are free then require subscription)

Milestone other

  • feat(db): support migrations as part of upgrades
  • feat: persist api request counters

Open questions

  1. When would an external node operator be looking to run nil-db?
  2. For decentralisation do web want fixed or client-selected clusters?
@tim-hm tim-hm added the internal label Dec 2, 2024
@tim-hm tim-hm self-assigned this Dec 2, 2024
@tim-hm tim-hm changed the title [FEATURE] Decentralisation and payments specification Milestone: Decentralisation and payments specification Dec 2, 2024
This was referenced Dec 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants