Muffin Technical Paper
Repo Organization
The muffinVM repository is organized as follow:
- ./lib - Contains all compiled JS code of muffinVM, the files we will actually execute.
- ./muffin-utils - Contains all muffin-utils NPM package related stuff
- ./src - Contains muffinVM source code written in TypeScript
- ./adapters - Contains interfaces to interact with DB
- ./common - Contains utility functions used in the code
- ./consensus - Contains all consensus related functions
- ./contracts - Contains native Muffin Network contracts
- ./ethereum - Contains Ethereum-related functions, sauch as Recursive Length Prefix encoder / decoder
- ./interpreter - CLI stuff
- ./models - Classes used to instanciate objects (Blocks, transactions, accounts…)
- ./rpc - JSON RPC API endpoints
Consensus
To achieve consensus, Muffin Network uses Proof-of-Stake, a system in which a validator is chosen following some conditions.
A new validator is chosen when a block is added or refused, and it is always the candidate with the highest stake that is chosen.
Muffin Network doesn’t rely on randomness to choose a validator to avoid forks. Each node has to be able to predict the next validator itself without any help.
Stake
The stake is a non-negative number which represents the trust that the network puts on an individual.
The stake is calculated following this formula:
Stake = Number of StackedFloats owned * Number of blocks since last action
The stake is at the same time a proof that the users have an interest to keep the chain secured (if they send a fraudlent block, their StackedFloats will be confiscated), and that they are invested in the network for a certain time (the block counter is a sort of proof of history).
To avoid network congestion, the second user with the highest stake can send a block instead of the chosen validator if the latter didn’t send a block within 30s
If the validator needs to be replaced, then they are not trustworthy and a portion of their StackedFloats is confiscated.
Process
Here’s how validation works:
