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
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 thatApplication and Actor do not fall into the scope of this ticket.
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/...
Objective
Enable deploying different types of protocol actors.
Origin Document
The utility specification outlines several different types of actors:
Validator
Servicer
Fisherman
Portal
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
andActor
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:
V1 - Swagger Documentation (as a reference)
Note: It is still in the early stages
The V1 RPC spec can be found here.
Goals
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.
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 helpconfig.json
files for each actor(s) being deployed on this nodeUtility Module
) that is specific to each protocol atorServicer
can also, optionally, be aValidator
at the same timePortal
can not double as anyone else must be a standalonerelayDispatch
endpoint and if the actor type is not a servicer, it should return an error.v1/servicer/...
or/v1/fisherman/...
Non-goals / Non-deliverables
General issue deliverables
Testing Methodology
make test_all
LocalNet
is still functioning correctly by following the instructions at docs/development/README.mdCreator: @Olshansk
Co-Owners: @okdas
Read more about this task and rewards on Dework.xyz
The text was updated successfully, but these errors were encountered: