Should Starkware make their software open source?


#1

I think the concepts behind zk-STARKS is utterly fascinating but I’m a little worried that their software won’t be open source. At least, that’s how I’ve understood things so far. I do understand that developers and researchers need to make money in order to pay the bills, but it doesn’t seem the best to make their technology closed source.

Thoughts?


#2

There are two pieces to an implementation of zk-starks.

The first piece is the proofer. It’s the piece of software that takes a bunch of inputs (e.g. transactions) and computes a succinct proof that everyone can then verify. This component doesn’t live on-chain and hence it could be proprietary.

The second piece is the verifier. It’s the piece of software that takes a proof and ensures that it is correct. In the context of a public blockchain this piece lives on-chain and is run as part of the state machine. Since it is part of the state transition function it has to be open-source, unless you are trying to pull a Hashgraph move and try to ship binaries that run a public blockchain.

I am of the strong opinion that the proofer has to be open-source. Imagine a scenario where a major public blockchain adopts a zk-stark implementation with a closed-source proofer. This technically has all sorts of applications and maybe Google acquires the company that developer the proofer. Now your blockchain is at the mercy of Google and may end up being shut down whenever they feel like it.


#3

Thanks for adding more details.

This is somewhat similar to Polkadot, where the parachain can be entirely private, but the State Transition Verification Function (i.e. the mechanism that validators use to validate the state transition of a parachain) has to be public. Of course, the the STF itself could be private.

Naturally, just because the architecture allows it to be closed source doesn’t necessitate that it should be. With cryptographic schemes we should be always skeptical about trusting closed source algorithms. In the context of a private parachain, that only runs within the context of trusted entities I dare say many risks are mitigated but it does go against the principle of open design - i.e. poor from an info sec point of view (c.f. Saltzer and Schroeder).


#4

There are more than two components here :

  • prover, verifier, and common run-time libraries,
  • individual proofers and verifiers for a specific tasks ranging form individual cryptographic widgets up through full state transition functions,
  • a compiler that helps produce individual proofers and verifiers from both AIRs, which sounds more general than R1CS, and other composable proofers and verifiers pairs used as “libraries”.

I’d think proovers must be open source and run by block producers, collators, or archive nodes. If not, then your chain is insecure, due either to being close source, or worse maybe outsources important functionality to some prooving company, making it not even decentralized.

We cannot make exactly this security argument about the compiler however. If the compiler is closed source then designated people can modify the chain, but the compiler’s output might be somewhat readable Rust or C ode, making security auditing possible, while not providing the full benefits of open source software.

We cannot quite build such a compiler for SNARKs and bulletproofs yet, because they require so much manual fiddling, although the ZEXE paper starts introducing a set of widgets that might eventually yield a higher level language. An enormous selling point of STARKs is promising this compiler though, so if the compiler is closed source then STARKs seem much less useful, especially from our point of view with many different parachains.