Add Operator cloud deployment #30

karlfloersch · 2019-01-31T19:04:37Z

Scaling Plasma

Because security of the chain is ensured by the exit game, it is safe for operators to scale past the computational limits of consumer hardware. Now that we have a reasonable Plasma implementation, I think it's time to see just how far we can push this thing!

Current Architecture

The Plasma Chain operator as it stands is a single node.js application. However, internally it has three separate processes:

Express API / Eth Service -- Parent process
State Manager -- Child 1, makes use of a LevelDB database & an append only log
Block Manager -- Child 2, makes use of a separate LevelDB database & ingests the append only log

This separation of concerns is critical to the long-term scalability of Plasma Operators as it allows for different functions to be easily processed in parallel. Each component when benchmarked alone can already achieve thousands of transactions per second, & with a little love I'm sure could go way faster.

The following is a rough diagram of what you can find in: https://github.com/plasma-group/plasma-chain-operator

Hand-wavy AWS toolstack architecture

This is a rough outline of how one might port this design to a cloud provider, in this case AWS. The general structure remains the same; however, message passing is more sophisticated (rabbitmq) and signature checking is trivially parallelizable (aws lambda). The significant downside of this architecture is it's expensive, so if there are better approaches I'd love to hear them.

The ask

The ask for this issue is to take the first steps to realize the vision of a more scalable operator. That means breaking out the API, tx-log, state, and block managers into their own Docker containers, handle message passing between them with some message queue, and set up some deployment script.

That said, comments on the overall architecture & approach to scaling are more than welcome. I've had very little peer review!! eek!

Hugs!
😊

The text was updated successfully, but these errors were encountered:

gitcoinbot · 2019-01-31T20:21:31Z

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

This issue now has a funding of 1000.0 DAI (1000.0 USD @ $1.0/DAI) attached to it.

If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
Want to chip in? Add your own contribution here.
Questions? Checkout Gitcoin Help or the Gitcoin Slack
$55,062.96 more funded OSS Work available on the Gitcoin Issue Explorer

gitcoinbot · 2019-01-31T20:52:41Z

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

Workers have applied to start work.

These users each claimed they can complete the work by 2 months, 4 weeks from now.
Please review their action plans below:

1) mul1sh has applied to start work (Funders only: approve worker | reject worker).

I'll break down the plasma chain operator into different docker containers as required. I'll then use either apache kafka or rabbitmq to handle the queue of messages between the various containers.

Finally i'll come with a simple and clear bash script that ties in all the above components together for easy deployment. Looking at the workload i can confidently say i'll get this done in less than a week. Thanks

Learn more on the Gitcoin Issue Details page.

gitcoinbot · 2019-01-31T20:52:41Z

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

Work has been started.

These users each claimed they can complete the work by 3 weeks, 6 days ago.
Please review their action plans below:

1) websoftwares has applied to start work (Funders only: approve worker | reject worker).

Hello

I have read your project description and it looks absolutely interesting, i have experience in CI/CD in various programming languages and also a long development career.

I have deployed in lambda various projects also with low costs by choosing the right strategy (lambda@edge/lambda step/lambda functions/etc) in combination with containers on ECS with auto-scaling.

Let me know if you want to have a conversation to talk further in details.

Greetings
Boris

Learn more on the Gitcoin Issue Details page.

2) websoftwares has applied to start work (Funders only: approve worker | reject worker).

Hello

I have read your project description and it looks absolutely interesting, i have experience in CI/CD in various programming languages and also a long development career.

I have deployed in lambda various projects also with low costs by choosing the right strategy (lambda@edge/lambda step/lambda functions/etc) in combination with containers on ECS with auto-scaling.

Let me know if you want to have a conversation to talk further in details.

Greetings
Boris

Learn more on the Gitcoin Issue Details page.

3) mathewdgardner has applied to start work (Funders only: approve worker | reject worker).

I work with node, rabbitmq and kubernetes with eks and aks daily. Just this week I configured rabbitmq (for node any python services) to run in a container using a persistent volume claim so that we could have durable queues and persistent messages while still sitting inside kube and it's still very fresh in my mind.

At my day job I own the stack so that means I write code, then see it through to production. I look to automate things for tight feedback loops so scripting won't be an issue.

This would be my first bounty so I'm eager to see this come together!

Learn more on the Gitcoin Issue Details page.

4) voxelot has been approved to start work.

Just finished reviewed the repo and it looks pretty straightforward for what needs to be re-worked to convert from IPC to AMQP or SQS. S3 based block ingestion should also use SQS to react to S3 events. If using other AWS native features like Lambda, I think it makes sense to stick with cloud-native managed services like SQS as we'd would definitely cut costs and complexity in comparison to AMQP / Kafka.

The requirements for this task could shift a bit as other new features are added, so we'll need to lock down the scope of this task so we have a good starting point to grow from. Here's some issues I came across that may depend on this task later on:
#23 - Would require extra S3 logic to reingest the txlogs
#37 - May entail config management for the docker containers (e.g. confd / AWS parameter store)

I have experience with cloudfront/terraform, AWS, Docker, K8S, Fargate and picture this repo morphing into something easy to use like the Serverless CLI but one that manages containers and resources for plasma operators.

Let me know if you'd like to keep the existing IPC interfaces as a fallback for spinning up local environments without any remote/docker/AWS dependencies.

Learn more on the Gitcoin Issue Details page.

spm32 · 2019-02-13T21:25:56Z

You're good to go @Voxelot!

gitcoinbot · 2019-02-17T17:16:20Z