Marigold: layer-2 scaling for Tezos
An introduction to Marigold
Current blockchain networks offer strong guarantees of correctness and resistance to censorship. In exchange, they are slow and too expensive to run applications at scale. Marigold is a layer-2 project that trades off censorship resistance for speed and low fees, enabling applications that scale.
Initially, the Marigold project focuses on a plasma-inspired implementation, but is not bound to any specific technology and can evolve to incorporate new advances from research. Marigold’s main focus is on a smooth developer and user experience rather than a commitment to any specific technology.
How Marigold works: extending Plasma
Marigold is so far based on Plasma, a layer-2 solution where smart contracts are encoded to enable fraud proofs, allowing arbitrary computation to be safely executed off-chain. Vitalik Buterin and Joseph Poon introduced this idea in 2017.
So far, Marigold implements the Minimal Viable Plasma, which is a form of Plasma restricted to simple transfers using a UTXO model.
Dealing with mass exits
A common concern around Plasma design is avoiding the “mass exit” problem.
Basically, the system unravels when the Layer-2 operator behaves unexpectedly (e.g. by withholding blocks or sending an invalid block) and users have to leave. In this scenario, funds are locked during the exit period and some users can lose their funds if they forget to leave or the base blockchain can become clogged as many users try to leave at once.
In Marigold, the plan is to solve this mass exit problem via the following mechanisms:
- Delegation of UTXOs exit permission
- Users can assign their exit rights to another user (an exit-delegate)
- When an exit-delegate leaves, all of their delegators’ funds leave at the same time
- A vote to move to another Marigold chain to minimize the interruption of service by an exit (with the goal of no interruption at all in the best case)
Watching the chain
Another concern is that the system’s security relies on all users of Marigold watching the system for misbehavior. To avoid a free-rider problem, making an operation on Marigold will require solving a challenge, which amounts to checking that a few operations in the previous blocks are valid.
Deploying Marigold
The project’s main focus is on enabling developers from all horizons to start hacking and building on Marigold as soon as possible.
Smart Contract Language for Marigold
Given the public beta-version of Marigold will support arbitrary contracts (rather than only transfers), a smart-contract language tailored to developing applications on Marigold is in development.
To avoid a steep learning curve, there will be support for multiple syntaxes and full integration with existing editors, such as Javascript in SublimeText and OCaml in Emacs.
Easy deployment
A key design goal of Marigold is to make the deployment process as frictionless as possible for other developers. For users of contracts, making two signed API calls to a web-server is all that is needed, which makes it easy to build a Marigold-powered app, or a backend using Marigold for parts of its logic.
Some work is also being done on interoperability between Marigold chains. This is important to compartmentalize failures between each application, yet retain the ability to use funds in all apps developed on Marigold. It also easily enables interoperability with other base-layer blockchains (e.g. Ethereum).
Smart Contract Language for Tezos
But first, project resources are dedicated to a new smart contract language for Tezos. What currently exists was sufficient for the Marigold prototype. However, the contracts needed for the full feature set described above require more because of their additional complexity.
The future
Right now, the focus is on building a platform that enables scalable applications on Tezos. But after the platform is built, the project will move to add capabilities to the core of Marigold and building applications and a developer ecosystem on the platform.
Improving the Core
Once built, the project will integrate state-of-the-art research.
The first direction is adding privacy features. This could be done through zk-snarks, mixing schemes, or homomorphic encryption (as seen in the AZTEC protocol).
The second direction is making the protocol less interactive (ideally, non-interactive), so that users do not have to watch the chain at all. This could be done by adding an incentive layer, using state channels, or through recursive zk-snarks (a la Coda protocol).
Attracting Applications
We plan to attract a wide range of applications to the platform.
On one hand, there is a concrete need to build solid blockchain applications that scale. Marigold is a strong fit for this category.
On the other hand, there is a big emphasis on tooling, docs and examples. So that developers can hack on Marigold from the comfort of their own garage. This reduces the barriers to innovation, with the hope to encourage building on the platform through hackathons and bounty programs.
Contact
For those interested in learning more about Marigold: {contact@mflower.io}. More details to come.
