Written by Sections in this article
Overview
This Plasma implementation follows the proof-of-authority model described in the Minimum Viable Plasma specification: that is, there exists a root node (called the ‘Plasma node’ in these docs) that is granted the authority to create new blocks and submit them to the Plasma smart contract. This is acceptable for most use cases, since it strikes a good balance between trustlessness and security. Since there is no consensus mechanism, the root node can perform thousands of transactions per second. To protect against a cheating root node, we use validator nodes that can function as both clients (i.e., they submit transactions to the root node) as well as watchers that observe the root node’s behavior and exit the smart contract on behalf of their users in case of misbehavior.
For more information on Plasma’s security model, see the Minimum Viable Plasma spec on ETHResearch.
Root Nodes
There is only one root node for a given Plasma chain. As described above, it receives transactions and packages them into blocks. By default, our implementation will mint new blocks every 100 milliseconds as long as there are transactions in the mempool. A block can contain a maximum of 65535 transactions, since the transaction Merkle tree has a fixed depth of 16. Blocks are by default submitted to the Plasma contract immediately after creation.
We expect that dApp creators or payment services will generally be the entities operating root nodes.
Validator Nodes
There can be any number of validator nodes for a given Plasma chain. Validator nodes have two responsibilities: verifying the blocks emitted by the root node, and submitting transactions on behalf of dApp users to the root node. Validator nodes use gRPC to stream new blocks from the Root Node in order to validate them.
We expect that validator nodes will be operated either by a neutral third party, or as a background process in dApp clients.
Clients
Client communicate with either the Root Node or a Validator Node in order to deposit, send funds, and exit on behalf of a single user. For example, a Client might be a web wallet that holds the private keys to a user’s account. That web wallet would use the private key to sign Plasma transactions that send value and forward them to a Validator Node. The Validator Node will in turn forward the transaction to the Root Node for processing and eventual inclusion in a block. By passing the transaction to the Validator first, the Client places the burden of checking for improper exits and Root Node malfeasance on the Validator, which we expect to be an always-on server daemon. This allows Clients to go offline at any time without compromising the safety of their funds.
