Sections in this article
This Plasma implementation follows the proof-of-authority model described in the Minimum Viable Plasma specification: that is, there exists a root node 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 plasma node can perform thousands of transactions per second. To protect against a cheating root node, we use validator nodes that 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 in case of misbehavior.
For more information on Plasma’s security model, see the Minimum Viable Plasma spec on ETHResearch.
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 once every 500 milliseconds. A block can contain a maximum of 65536 transactions, since the transaction Merkle tree has a fixed depth of 16. Blocks are submitted to the Plasma contract immediately after creation.
The root node exposes a JSON-RPC API for communication with validator nodes. By default, the JSON-RPC API listens for HTTP requests on port 8643. Validator nodes use the JSON-RPC API to both submit transactions and get latest block information. There is currently no peer-to-peer connection between nodes; validator nodes are expected to poll the root node using the JSON-RPC API. This will likely change in the future. Note that this means the root node must be accessible via HTTP to validators. We recommend assigning a static IP or domain name to the root node.
DApp creators will generally be the entities operating root 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. We expect that validator nodes will be operated either by a neutral third party, or as a background process in DApp clients.
As mentioned in the Root Nodes section, validator nodes communicate with the root node via the root nodes JSON-RPC API.