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

[Core] Deploying all-the-protocol-actors #668

Closed
15 tasks
dework-integration bot opened this issue Apr 12, 2023 · 1 comment
Closed
15 tasks

[Core] Deploying all-the-protocol-actors #668

dework-integration bot opened this issue Apr 12, 2023 · 1 comment

Comments

@dework-integration
Copy link

Objective

Enable deploying different types of protocol actors.

Origin Document

The utility specification outlines several different types of actors:

  1. Validator
  2. Servicer
  3. Fisherman
  4. Portal
  5. Full Nodes (a full node that is not a protocol actor)

As of writing, the V1 repo only supports running validators and the debug client is a "makeshift" full node. As we are about to start working on M3 and have a live devnet, there needs to be an easy way to build and scale different types of actors.

Note that Application and Actor do not fall into the scope of this ticket.

V0 - Swagger Documentation (as a reference)

Note: It is slightly outdated

The V0 RPC spec can be found here.

For example, the height can be queried like so:

curl --location -X 'POST' -H 'Content-Type: application/json' 'https://<user>:<pass>@<hostname>:<port>/v1/query/height' | jq

{
  "height": 89554
}

V1 - Swagger Documentation (as a reference)

Note: It is still in the early stages

The V1 RPC spec can be found here.

Screenshot 2023-04-11 at 4 54 13 PM

Goals

  • Enable deploying different types of protocol actors from a single binary
  • Enable scaling different types of protocol actors
  • Enable iterating on the business logic for M3 (locally & and in devnet)
  • Set a foundation for full nodes, which will extend to light clients

Deliverable

Note that there are a lot of notes and deliverables below. These should be used as a guide but the implementor is expected to use their best judgment and creativity to achieve the goals above.

  • Update config.go to contain the type of actor being deployed
    - Note to implementor: Creating empty XXXConfig (e.g. FishermanConfig) protos that we can build on in the future would help
  • Update/add config.json files for each actor(s) being deployed on this node
  • Add empty placeholder logic (e.g. a print statement in the Utility Module) that is specific to each protocol ator
    • Note to implementor: For example, some code path should only execute if a node is actor X but should not execute if it's actor Y; this will require some thought and creativity
  • Add business logic and tests that limit the types of permutations a single node can be. E.g.
    • A Servicer can also, optionally, be a Validator at the same time
    • A Portal can not double as anyone else must be a standalone
    • Note to implementor: Use your best judgment and we'll review during the PR process
  • Update LocalNet (k8s and docker-compose) to deploy the following configuration:
    • 4 Validators (1 of these should also be a servicer in parallel)
    • 1 full node
    • 1 servicer
    • 1 fisherman
    • Note to implementor: portal will be added in the future
    • Note to implementor: @bryanchriswhite is working on random gossip for full nodes, @gokutheengineer is working on state sync with full nodes, @okdas is working on infrastructure to deploy them; please ping them in the public channels for more details. @Olshansk is not doing anything ;'(
  • Add an RPC endpoint that returns the type of actor(s) running on the node (see the code below as an example)
  • Update the CLI to be able to query the RPC endpoint above
  • Add new RPC endpoints (with placeholder backing code) that either return a static response or an error if the actor type should not support them
    • Note to implementor: For example, you can add the relayDispatch endpoint and if the actor type is not a servicer, it should return an error.
    • Note to implementor: For example, looking at the v1 swagger file, you can implement v1/servicer/... or /v1/fisherman/...
curl --location -X 'POST' -H 'Content-Type: application/json' 'https://<user>:<pass>@<hostname>:<port>/v1/query/nodeRoles' | jq

{
  "node_roles":
  [
  	"servicer",
  	"validator",
  ] 
}

Non-goals / Non-deliverables

  • Implementing new business logic for the actor-specific logic
  • Exhaustively updating all the source code with the appropriate build tags

General issue deliverables

  • Update the appropriate CHANGELOG(s)
  • Update any relevant local/global README(s)
  • Update relevant source code tree explanations
  • Add or update any relevant or supporting mermaid diagrams

Testing Methodology

  • Required: A demo document (w/ video) showing this in action
  • All tests: make test_all
  • LocalNet: verify a LocalNet is still functioning correctly by following the instructions at docs/development/README.md

Creator: @Olshansk
Co-Owners: @okdas

Read more about this task and rewards on Dework.xyz

@Olshansk
Copy link
Member

Duplicate off #613

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

1 participant