Proposal to move the Compact programming language under LFDT

[kmillikin]

This is a first revision of a proposal to move the Compact programming language into LFDT. We have already received some feedback which we are still to address.

[kmillikin]

Obviously we don't intend to merge this :)

[tkuhrt]

Please undo the changes and update this PR so that we can merge when appropriate.

[tkuhrt]

Thank you for the proposal. As we discussed today, we will be formally reviewing this at the July 24 TAC meeting. Here are some initial comments.

[tkuhrt]

Are there any sponsors outside of Shielded? See Project Incubation Entry Considerations for sponsorship expectations and who might be a sponsor.

[tkuhrt]

Could you provide characteristics that would define what a "sufficiently similar" smart contract system would be?

[kmillikin]

Yes, it's the characteristics described just above (off-chain code has access to private data, on-chain code does not, a ZK proof is constructed off chain and verified on chain).

I'll try to make that clear.

[tkuhrt]

Are both of these implementations (compiler and SDK) being proposed for inclusion in this project?

[kmillikin]

Yes. They are both part of the Compact open-source (not yet public) repository that we are preparing.

[petermetz]

@kmillikin Quick question: Is there any sort of interoperability/transpilation possible between EVM chains and Compact compiled contracts? For example if I wanted to use Compact to develop more secure contracts deployed on the Ethereum mainnet, would there be a path for that? Totally fine if the answer is no, I'm just trying to get a handle of the scope of the project. In general the proposal looks good to me so far.
One more quick question: what project lifecycle are you targeting? Incubation or ?

[kmillikin]

@petermetz that's an interesting question about EVM!

Much of the work in the Compact programming model happens off chain. On chain there is "only" verfication of a proof (a zkSNARK on Midnight) and execution of public state updates. So that suggests to me that the answer is "possibly yes". You would have to implement the proof verification at the contract level rather than in the blockchain itself.

We're proposing incubation, I've added some more text to the proposal about that.

[arsulegai]

Thank you for addressing the majority of open questions during the recent TAC meeting. I’d like to capture and reiterate a few key points here for continued clarity and action:

1. Could you specify which components of the project will be open sourced? Additionally, how do you plan to position each open-sourced repository—as a code contribution, a specification contribution, or otherwise? This clarification will help the community understand the intended scope and encourage the right type of engagement.
2. Please outline the “lego” or modular components that will enable adaptation of compact programming languages to various blockchain protocols.
3. I encourage the team to define clear, strategic goals for the project, including both a 3-year and a 5-year plan. Taking a longer-term perspective will help ensure sustained progress, effective tracking, and alignment of the community’s expectations regarding project milestones and future development.
4. Providing example implementations and reference cases will help guide contributors and kickstart development.
5. Sharing real-world examples and past success stories will help build credibility and increase engagement.
6. Consider organizing technology sessions or workshops to deepen knowledge sharing and foster a stronger sense of community.

[arsulegai]

Please provide additional context, what does cross-chain security mean per the project proposal?

[kmillikin]

We're not proposing anything specific because we don't know the details of the multiple chains and how they will interact. We will consider if there are cross-chain security issues and what they are and if there are mitigations we can implement.

[kmillikin]

Thanks for the questions and suggestions, @arsulegai. I'll work on addressing them in the proposal but in the mean time, here are some responses:

1. We are proposing to open source the "Compact" repository except for the very small amount of third party code and a small amount of code that we intend to upstream to various projects. This includes: the Compact compiler, the tests, the Visual Studio Code extension for Compact, the compact command line developer tools, the Compact language reference, and the formal specification. It also includes some Midnight-specific components like the Compact runtime JavaScript package. It does not include the definitions or implementations of either the Impact VM or the ZKIR intermediate representation (these are in separate project Midnight repositories and they are Midnight-specific. They will be open sourced but separately from the Compact language.)
2. I will attempt to make it more clear in the proposal. The Midnight-specific components are (a) two backend passes that generate JavaScript, and (b) one that generates ZKIR (proof representations). There is (c) a Midnight-specific "Compact runtime" JavaScript package that's used by the generated JavaScript code. There is (d) a Midnight-specific implementation of the ledger data types. You would have to provide replacements for these components, but there's a lot of flexibility to how those are implemented.
3. Yes. As incubation progresses one of the deliverables will be a long-term roadmap.
4. The implementation of Compact for Midnight is the example implementation. There is an active Midnight testnet to help contributors understand how the language interacts with the blockchain.
5. We already have some real world examples of Compact (such as the Open Zeppelin token implementations at https://github.com/OpenZeppelin/compact-contracts, we have partners building more examples like these) and if the project succeeds there will be more.
6. Yes. We will engage with the community to help build it. We are currently doing irregular but frequent "dev diary" blog posts and community calls on the Midnight Discord server and we'd expect to establish a more regular structure for those.

[ryjones]

please rebase on the tip of gh_pages

[ryjones]

@kmillikin @bobblessinghartley please rebase and squash to important commits and rebase that on the tip of gh-pages. please combine the contents of #36 with this PR and have @djetchev close it

[petermetz]

LGTM, but I'll wait for final review once the rebase has been done, please re-request review once that's finished!