Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?: Yes
Project Description
We propose to port Glow to target zk-SNARKs via Filecoin’s Lurk.
This will help solve issues of security, privacy, scalability and more for
Decentralized Applications (DApps).
For this first proposal, we will build a proof-of-concept modification to the Glow compiler
so it can target Lurk’s input language.
Unlike existing “smart contract” languages, Glow already generates complementary code
for both off-chain clients and on-chain smart contracts;
it thus requires the least rearchitecting to work with zk-SNARKs.
We will collaborate with Lurk authors to make sure suitable features are present.
Value
Today’s decentralized applications require all network participants
present and future to fully run all computations in the open.
This is both very expensive and not private at all.
Many known methods can mitigate these issues, including
Generalized State Channels, Merkleized Abstract Syntax Tree (MAST), and zk-SNARKs.
But the current tools make these techniques practically unusable for mere mortals,
requiring developers to combine expertise in many fields,
manually yet without any leeway for human mistake whatsoever.
Completely new tools are thus required to effectively write private DApps.
Our approach will offer a practical way to build and deploy private DApps on top of Filecoin.
This presents a great opportunity for Filecoin, that can thereby leapfrog other blockchains
in its support for private DApps, where it currently lags behind with regard to DApps.
Since the current proposal is for a proof of concept, the risk of failure is just
the time and money invested in building this initial work.
When we later productize these features, extra steps will have to be taken
to ensure the design and implementation are both robust against attacks.
Deliverables
For this initial proposal, we will build a Glow compiler backend
that targets zk-SNARKs via Lurk.
The deliverable will include the following elements:
Off-chain client code that runs on behalf of each participant,
and uses the client part of Lurk to generate and evaluate R1CS circuits.
On-chain “smart contract code” that enforces the rules by verifying
participant-submitted transactions using zk-SNARKs.
Glue between the two that simulates any missing parts of the blockchain,
using Lurk for the construction and verification of zk-SNARKs.
A working test flow of our rock_paper_scissors DApp
running against the simulated blockchain.
Considering that Lurk isn’t a complete working part of the Filecoin blockchain yet,
the deliverable will an end-to-end run of a Glow DApp, not against the blockchain itself,
but against a minimal simulation of what the blockchain would do,
involving whichever part of Lurk is working, and simulating the rest,
which would in turn invoke whatever simulation mode Lurk itself provides.
Development Roadmap
Our development will include the following milestones.
We estimate that we will need the equivalent of one senior developer full-time,
one architect or product managing half-time, and
one junior developer full-time in a support role,
for the duration of the project, at the cost of $10,000 per week.
Milestone 1
Study how Lurk and zk-SNARK works, how to compile to circuits,
how to interact with both circuit construction in the off-chain clients
and circuit verification in the on-chain contract.
The deliverable will be a markdown document
that explains what needs to be done in greater detail.
(3 weeks).
Milestone 2
Make a first attempt to add passes to the Glow compiler to generate Lurk code.
The deliverable will be some Scheme code that effectively generates Lurk code
for one of our DApps, but may have various limitations and short-cuts
and not work properly in the general case,
highlighting issues in our existing compiler infrastructure.
(3 weeks).
Milestone 3
Make a first attempt to simulate a blockchain using Lurk.
The deliverable will be some code in Scheme, Common Lisp and/or Rust
that enables our runtime to effectively execute
the code generated by our first compiler attempt above.
Once again, this code may not be full-featured, but will help identify
any issues to be fixed in our existing runtime infrastructure.
(3 weeks).
Milestone 4
Analyze the limitations of the first attempt and design
the required deeper changes to our compiler and runtime architecture.
The deliverable will be a markdown document
that explains the changes required to our architecture.
(3 weeks).
Milestone 5
Refactor the Glow compiler and runtime to enable the features
the first attempts couldn’t achieve.
The deliverable will be modifications to our Scheme code
to implement the above-designed changes.
(3 weeks).
Milestone 6
Make a second attempt to add passes to the Glow compiler to generate Lurk code,
using the refactored architecture.
The deliverable will be Scheme code that fully implements
a Glow compiler backend targeting Lurk.
(3 weeks).
Milestone 7
Make a second attempt to simulate a blockchain using Lurk.
The deliverable will be Scheme code that fully implements
the runtime infrastructure required to test our applications using the Lurk backend.
(3 weeks).
Milestone 8
Debug a flow of rock paper scissors against our simulated Lurk backend.
The deliverable will be fixes to all the above to ensure the test flows
run flawlessly without the need for human intervention.
(3 weeks).
Milestone 9
Package and documentation for the above.
The deliverable will be changes to our packaging glue and documentation
so that anyone can reproduce our proof of concept and run its test suite
with a one-line command.
(3 weeks).
Total Budget Requested
The above plan totals 27 weeks of work, a bit over six months, at a cost of $270,000.
Payment for each milestone would be expected half at the beginning and half at the end.
Maintenance and Upgrade Plans
After this proof-of-concept is complete, we will have to productize it,
which will depend on Lurk being itself ready for production
and the underlying functionality integrated into Filecoin itself.
We anticipate another similar 6-month project to that effect,
which will be slightly more expensive because it will involve an independent software audit
and more complete user documentation in addition to the continued development;
a deeper refactoring of the code base will probably also be required
to bring the compiler and runtime in a good state that is worthy of the independent audit.
Afterwards, we expect the system to have actual users in production,
who will be ready to fund maintenance of the system and improvements to it.
There are several known methods to mitigate privacy and scalability issues for smart contracts.
These methods include Generalized State Channels (GSC), Merkleized Abstract Syntax Tree (MAST),
and zk-SNARKs (or their rivals STARKs).
In the case of GSC and MAST, there is always a fallback case
when one participant stops cooperating, where the other participant(s)
must reveal key part of the agreement and have it publicly evaluated,
defeating at least in part both privacy and scalability.
By contrast, SNARKs can be used as a substitute or complement to these methods
to implement the transaction validation or fallback case
in a way that preserves both privacy and scalability.
However, these potential solutions are hard to impossible to deploy in practice
with the current generation of tools:
they require programmers to express their programs in terms of complex mathematical structures
that are generated off-chain by DApp participants to be verified on-chain by “smart contracts”.
Not only are these structures very different from what developers are used to,
they are also completely unforgiving of any mistake, including mistake in generating the structure,
or mismatch between what the off-chain and on-chain code does.
Debugging at that level of abstraction is nigh impossible.
Introducing Glow: a DSL for DApps
Glow is Mutual Knowledge Systems’
DSL for DApps — a Domain Specific Language for Decentralized Applications.
Compared to Solidity or Rust or Plutus, it offers a much higher level of abstraction:
mutually-distrusting participants are a builtin concept,
as well as economic resources like tokens, or escrows and timeouts;
and of course, it is functional rather than imperative.
Glow’s high-level design allows for much simpler programs than its competitors,
which in itself vastly reduces the surface for bugs and vulnerabilities.
For instance, the simplest DApp, buy_sig, can be written in only 6 lines in Glow,
but requires a hundred lines of a mix of Solidity and JavaScript.
Relevantly for this project, Glow is also based on the notion of
generating matching off-chain computation clients
and on-chain verification smart contracts from the same DApp specification.
Moreover, Glow’s internal architecture is also one of explicit passes
that can be rewired in different ways, so that we can use SNARKs where applicable,
and the usual smart contract VMs where SNARKs aren’t applicable.
These characteristics make Glow uniquely suited to the purpose of
generating code that uses zk-SNARKs,
whether in conjunction with other techniques such as Generalized State Channels or not.
We intend to introduce some compiler passes
that target Filecoin’s Lurk as part of our architecture,
and thereby gain support for targeting zk-SNARKs.
Open Grant Proposal: Glow on Lurk
Name of Project: Glow on Lurk
Proposal Category:
app-dev
Proposer:
fare
Technical Sponsor: Porçu Quine (@porcuquine)
Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?: Yes
Project Description
We propose to port Glow to target zk-SNARKs via Filecoin’s Lurk. This will help solve issues of security, privacy, scalability and more for Decentralized Applications (DApps).
For this first proposal, we will build a proof-of-concept modification to the Glow compiler so it can target Lurk’s input language. Unlike existing “smart contract” languages, Glow already generates complementary code for both off-chain clients and on-chain smart contracts; it thus requires the least rearchitecting to work with zk-SNARKs. We will collaborate with Lurk authors to make sure suitable features are present.
Value
Today’s decentralized applications require all network participants present and future to fully run all computations in the open. This is both very expensive and not private at all.
Many known methods can mitigate these issues, including Generalized State Channels, Merkleized Abstract Syntax Tree (MAST), and zk-SNARKs. But the current tools make these techniques practically unusable for mere mortals, requiring developers to combine expertise in many fields, manually yet without any leeway for human mistake whatsoever.
Completely new tools are thus required to effectively write private DApps. Our approach will offer a practical way to build and deploy private DApps on top of Filecoin. This presents a great opportunity for Filecoin, that can thereby leapfrog other blockchains in its support for private DApps, where it currently lags behind with regard to DApps.
Since the current proposal is for a proof of concept, the risk of failure is just the time and money invested in building this initial work. When we later productize these features, extra steps will have to be taken to ensure the design and implementation are both robust against attacks.
Deliverables
For this initial proposal, we will build a Glow compiler backend that targets zk-SNARKs via Lurk. The deliverable will include the following elements:
rock_paper_scissors
DApp running against the simulated blockchain.Considering that Lurk isn’t a complete working part of the Filecoin blockchain yet, the deliverable will an end-to-end run of a Glow DApp, not against the blockchain itself, but against a minimal simulation of what the blockchain would do, involving whichever part of Lurk is working, and simulating the rest, which would in turn invoke whatever simulation mode Lurk itself provides.
Development Roadmap
Our development will include the following milestones. We estimate that we will need the equivalent of one senior developer full-time, one architect or product managing half-time, and one junior developer full-time in a support role, for the duration of the project, at the cost of $10,000 per week.
Milestone 1
Study how Lurk and zk-SNARK works, how to compile to circuits, how to interact with both circuit construction in the off-chain clients and circuit verification in the on-chain contract. The deliverable will be a markdown document that explains what needs to be done in greater detail. (3 weeks).
Milestone 2
Make a first attempt to add passes to the Glow compiler to generate Lurk code. The deliverable will be some Scheme code that effectively generates Lurk code for one of our DApps, but may have various limitations and short-cuts and not work properly in the general case, highlighting issues in our existing compiler infrastructure. (3 weeks).
Milestone 3
Make a first attempt to simulate a blockchain using Lurk. The deliverable will be some code in Scheme, Common Lisp and/or Rust that enables our runtime to effectively execute the code generated by our first compiler attempt above. Once again, this code may not be full-featured, but will help identify any issues to be fixed in our existing runtime infrastructure. (3 weeks).
Milestone 4
Analyze the limitations of the first attempt and design the required deeper changes to our compiler and runtime architecture. The deliverable will be a markdown document that explains the changes required to our architecture. (3 weeks).
Milestone 5
Refactor the Glow compiler and runtime to enable the features the first attempts couldn’t achieve. The deliverable will be modifications to our Scheme code to implement the above-designed changes. (3 weeks).
Milestone 6
Make a second attempt to add passes to the Glow compiler to generate Lurk code, using the refactored architecture. The deliverable will be Scheme code that fully implements a Glow compiler backend targeting Lurk. (3 weeks).
Milestone 7
Make a second attempt to simulate a blockchain using Lurk. The deliverable will be Scheme code that fully implements the runtime infrastructure required to test our applications using the Lurk backend. (3 weeks).
Milestone 8
Debug a flow of rock paper scissors against our simulated Lurk backend. The deliverable will be fixes to all the above to ensure the test flows run flawlessly without the need for human intervention. (3 weeks).
Milestone 9
Package and documentation for the above. The deliverable will be changes to our packaging glue and documentation so that anyone can reproduce our proof of concept and run its test suite with a one-line command. (3 weeks).
Total Budget Requested
The above plan totals 27 weeks of work, a bit over six months, at a cost of $270,000.
Payment for each milestone would be expected half at the beginning and half at the end.
Maintenance and Upgrade Plans
After this proof-of-concept is complete, we will have to productize it, which will depend on Lurk being itself ready for production and the underlying functionality integrated into Filecoin itself. We anticipate another similar 6-month project to that effect, which will be slightly more expensive because it will involve an independent software audit and more complete user documentation in addition to the continued development; a deeper refactoring of the code base will probably also be required to bring the compiler and runtime in a good state that is worthy of the independent audit.
Afterwards, we expect the system to have actual users in production, who will be ready to fund maintenance of the system and improvements to it.
Team
Contact Info
alex@mukn.io
Team Members
Team Member LinkedIn Profiles
Team Website
Relevant Experience
Relevant previous work by our contributors are listed in our Wiki: https://github.com/Glow-lang/glow/wiki/Bibliography-Glow
Moreover, individual Glow contributors’ biographies can be found on our company website.
Team code repositories
https://github.com/Glow-Lang/glow
Additional Information
Private and Scalable Smart Contract Technology
There are several known methods to mitigate privacy and scalability issues for smart contracts. These methods include Generalized State Channels (GSC), Merkleized Abstract Syntax Tree (MAST), and zk-SNARKs (or their rivals STARKs). In the case of GSC and MAST, there is always a fallback case when one participant stops cooperating, where the other participant(s) must reveal key part of the agreement and have it publicly evaluated, defeating at least in part both privacy and scalability. By contrast, SNARKs can be used as a substitute or complement to these methods to implement the transaction validation or fallback case in a way that preserves both privacy and scalability.
However, these potential solutions are hard to impossible to deploy in practice with the current generation of tools: they require programmers to express their programs in terms of complex mathematical structures that are generated off-chain by DApp participants to be verified on-chain by “smart contracts”. Not only are these structures very different from what developers are used to, they are also completely unforgiving of any mistake, including mistake in generating the structure, or mismatch between what the off-chain and on-chain code does. Debugging at that level of abstraction is nigh impossible.
Introducing Glow: a DSL for DApps
Glow is Mutual Knowledge Systems’ DSL for DApps — a Domain Specific Language for Decentralized Applications. Compared to Solidity or Rust or Plutus, it offers a much higher level of abstraction: mutually-distrusting participants are a builtin concept, as well as economic resources like tokens, or escrows and timeouts; and of course, it is functional rather than imperative.
Glow’s high-level design allows for much simpler programs than its competitors, which in itself vastly reduces the surface for bugs and vulnerabilities. For instance, the simplest DApp,
buy_sig
, can be written in only 6 lines in Glow, but requires a hundred lines of a mix of Solidity and JavaScript.Relevantly for this project, Glow is also based on the notion of generating matching off-chain computation clients and on-chain verification smart contracts from the same DApp specification. Moreover, Glow’s internal architecture is also one of explicit passes that can be rewired in different ways, so that we can use SNARKs where applicable, and the usual smart contract VMs where SNARKs aren’t applicable.
These characteristics make Glow uniquely suited to the purpose of generating code that uses zk-SNARKs, whether in conjunction with other techniques such as Generalized State Channels or not. We intend to introduce some compiler passes that target Filecoin’s Lurk as part of our architecture, and thereby gain support for targeting zk-SNARKs.