No funded issue found.
Check out the Issue Explorer
Be the OSS Funding you wish to see in the world.
Looking to fund some work? You can submit a new Funded Issue here .
Time left
Opened
Issue Type
Workers Auto Approve
Project Type
Time Commitment
Experience Level
Permissions
Accepted
Reserved For
Add Operator cloud deployment
plasma-group
JavaScript
### 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:
1. `Express API` / `Eth Service` -- Parent process
2. `State Manager` -- Child 1, makes use of a LevelDB database & an append only log
3. `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!
😊
Setup your profile
Tell us a little about you:
Skills
No results found for [[search]] .
Type to search skills..
Bio Required
[[totalcharacter]] / 240
Are you currently looking for work?
[[ option.string ]]
Next
Setup your profile
Our tools are based on the principles of earn (💰), learn (📖), and meet (💬).
Select the ones you are interested in. You can change it later in your settings.
I'm also an organization manager looking for a great community.
Back
Next
Save
Enable your organization profile
Gitcoin products can help grow community around your brand. Create your tribe, events, and incentivize your community with bounties. Announce new and upcoming events using townsquare. Find top-quality hackers and fund them to work with you on a grant.
These are the organizations you own. If you don't see your organization here please be sure that information is public on your GitHub profile. Gitcoin will sync this information for you.
Select the products you are interested in:
Out of the box you will receive Tribes Lite for your organization. Please provide us with a contact email:
Email
Back
Save
