realChainLife
commented
2 years ago Hi @fare thank you for the proposal. We would like to fund the work outlined here, please email devgrants@fil.org to discuss next steps.
Closed fare closed 2 years ago
realChainLife
commented
2 years ago Hi @fare thank you for the proposal. We would like to fund the work outlined here, please email devgrants@fil.org to discuss next steps.
Open Grant Proposal: Glow on Lurk
Name of Project: Glow on Lurk
Proposal Category:
app-devProposer:
fareTechnical 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_scissorsDApp 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.