StarkNet Prover code license

[elibensasson]

Hi, excited for my first use of the StarkNet Shamans platform. Would love to share some thoughts and get feedback on the intended license for the StarkNet provers, which should be made source available when we get to the decentralization phase, hopefully by the end of this year (2022). You can see the license here, and a discussion of it in this blog post.

Briefly, the Polaris license allows developers to use and modify the prover code in any way they choose, as long as proofs are sent to a smart contract address that appears on a whitelist. This whitelist is append-only, so one may never remove from it, only add to it. In particular, if you’ve been using the prover code to interact with a particular smart contract (say, StarkNet’s), you’ll know that you may continue using it indefinitely in the future.

The question I’d like to address here is WHO IS THE LICENSOR? I.e. Who makes decisions regarding the whitelist?

When we conceived of Polaris, StarkNet was merely an idea, not a flourishing ecosystem. But over the past year we realized that it makes no sense for StarkWare to be the licensor of the StarkNet prover code. Rather, it should be the StarkNet ecosystem that decides on its fate. Thus, StarkWare has decided that the licensor of this code will be the ecosystem. While the exact governance mechanism for the ecosystem is still being worked out, imagine some standard crypto-economic model that allows a community to vote on important decisions like upgrades to the StarkNet core, or changes to the Polaris license - the topic of this post.

In this case, the StarkNet ecosystem may vote to keep the whitelist restricted only to StarkNet smart contract verifiers. It may negotiate with other chains to agree on conditions under which new verifier smart contracts are added to the whitelist, effectively creating new StarkNet ecosystems on other chains. It may also decide to expand the whitelist to allow all smart contracts to be added, effectively allowing all blockchains to create their own StarkNets and coming very close to full blown open source. Finally, the community may also decide to just drop Polaris and replace it with Apache 2.0 or MIT.

Why would the StarkNet ecosystem decide to limit the Polaris license? My first answer is that if I didn’t have strong arguments, I’d still want the ecosystem, not StarkWare, to decide on this. But I do several reasons the ecosystem might want to limit access: (1) several notable dApps, like Metamask, Zcash and Uniswap, have opted to leave full blown open source in favor of more restrictive licenses; if they chose so, maybe StarkNet will want to limit access as well. (2) Licenses have been useful in the past in preventing abuse and free riding by various large entities that have not contributed to the development of the code/ecosystem but nevertheless wanted to reap the benefits of an ecosystem’s contribution. (3) It’s well known that with licenses, going from restrictive to lenient is easy; going the other direction - from lenient to restrictive, is much harder. So better start slightly more restrictive, than lenient. (4) We’ve seen quite a few cases of projects using open source code developed by others, much to the chagrin of the OGs who worked hard on the original code. It should be the ecosystem’s decision whether its fine for others to use the code, and we’ll leave it to the StarkNet ecosystem in this case.

====================

So, with this preamble, I’d love to hear your thoughts - what are the pros and cons of using the Polaris license, assuming it will be the StarkNet ecosystem that controls it?

[polynya]

I believe full blown open source is the best approach for base protocols. Let’s consider the possibilities:

• People deploy StarkNet forks on Ethereum: assuming there’ll already be a token and established governance by the time the open sourcing happens, this is fine. It’ll be pretty clear what the canonical StarkNet is. Further, let people experiment, over time they’ll realize the pragmatic solution is to actually deploy an L3 StarkNet instance on top of the canonical L2 StarkNet. (Sidenote: incentives for this could be worth considering) Or, if it’s a very large entity like a government or a large corporation that wants to maintain their own L2 instance - that too will build legitimacy for the StarkNet codebase and indirectly drive people to the canonical StarkNet. Also, every StarkNet fork is a testnet and helps discovers edge case bugs & issues.

• People deploy StarkNet instances on other chains: Currently, there are no credibly neutral or sufficiently liquid settlement layers where it makes sense for StarkNet IMO. With volition and growing activity on StarkNet, the short-term cost advantage of other chains disappears, and longer term with data sharding Ethereum will have greater capacity for rollups than other chains too. So, I’d say let people deploy on other chains, it’ll bring a lot of value to their ecosystems, and also build legitimacy for the canonical StarkNet. Long term, StarkNet on Ethereum will be the most secure, credibly neutral, but also the cheapest StarkNet. So why not StarkNet governance deploys everywhere? I believe the cognitive overhead and loss of focus is worth less than the benefits of doing so. Maybe worth considering a few years down the line when StarkNet is mature.

• Deploying to other credibly neutral chains: If in the future we do see another chain that’s sufficiently decentralized, secure & credibly neutral, with significant liquidity, either Bitcoin becomes possible or something else, then StarkNet governance should definitely deploy a canonical instance there before forkers do.

The alternative is going for Polaris or a BSL type license like Uniswap did. On paper, this seems to make sense, but for a brand new tech like StarkNet, I’d argue the drawbacks outweigh the benefits:

• If open source, we’ll see forks, people talking about StarkNet, and build credibility for what is still brand new tech.

• If closed, we’ll see people continue to FUD rollups - I’ve seen more lies and deception about rollups than any community (outside of crypto) I’ve actively engaged in! (Though the situation has improved a lot lately)

[elibensasson]

Thanks, Polynya. What are your thought on the following two cases?

1. StarkNet is hugely successful and provers/sequencers and other service providers are profitable and prosperring. Along comes some huge cloud company, say, Amazon, and offers a clone of StarkNet as part of its basic subscription model on AWS. Like it’s done with many other successful open source things (Databases, for example). This is one place where Polaris could help bolster the StarkNet ecosystem.

2. In various cases, the StarkNet ecosystem, through its governance (elected or direct) could negotiate terms with other companies/ecosystems that want to use the code. This can be easily achieved with Polaris, less so with open source.

[0xMikado]

In the spirit of progressive decentralization and knowing the difficulties to go from lenient to restrictive, I agree with you on having a restrictive license to start with and then leaving to door open to modifications. While StarkNet is maturing and a good governance model is found and deployed, keeping things on the restrictive side seems to be a safe way to go, and if we observe too many drawbacks, then flexibility can be introduced!

[polynya]

The way I see it, if StarkNet is hugely successful, then the canonical StarkNet could be a bigger entity than whatever Amazon may offer, because Amazon will never be able to offer the unique propositions (i.e. decentralization, borderless, permissionless etc.) that StarkNet can. Conversely, if StarkNet isn’t hugely successful yet, and Amazon adopts it in some way, it’ll legitimize StarkNet and once again the public canonical StarkNet will offer things that Amazon will never be able to. So, if we look at the bigger picture, removing all friction for global adoption of StarkNet’s tech stack is ultimately a greater benefit to the public StarkNet ecosystem than negotiating deals. Which would be a very messy process anyway - we don’t yet have a clearly defined way for a DAO to negotiate with a public corporation. So, it may be that with a restrictive license someone like Amazon may never adopt StarkNet tech and just build their own STARK provers. Indeed - isn’t this what Facebook did? I believe ConsenSys and MasterCard are working on their own ZK rollups too. Another case is Uniswap V3 - I don’t think anyone’s bothered making any deals. All we have seen is SushiSwap Trident and others copy its concepts like concentrated liquidity and reimplement them.

The other thing to consider is that all of StarkNet’s “competitors” - Optimism, Arbitrum, zkSync, Polygon Hermez, Zero, Miden etc. have all committed to being fully open source. So, Amazon has plenty of options available to them. Yes, StarkNet is the pioneer, but others are following closely in the grand timeline.

Of course, the Polaris approach made a lot of sense for StarkWare as a B2B company, but as we move into a public decentralized StarkNet, I think the dynamics are quite different.

I do agree that until StarkNet governance is established and decentralized, it makes sense to not open source, and open-sourcing could be one of the early SIPs(?)

Ethereum set a unique precedent - by open sourcing, Ethereum is adopted far and wide across not only private & public companies with permissioned instances, but also most alt-L1s run Ethereum tech. Yet, all of this has accrued value to Ethereum directly & indirectly, and it will be the dominant coordinator of the crypto ecosystem for the foreseeable future. Even big alt-L1s like Avalanche, Polygon PoS & Fantom derive most of their value from ERC-20 assets on an Ethereum bridge, and I have no reason to believe these won’t be bridged back when solutions like StarkNet are decisively more secure, more decentralized & more scalable. Had Ethereum had a restrictive licensing, not only would adoption for Ethereum be set back several years, but the whole blockchain industry itself! I feel similarly with StarkNet.

That was a bit of a long-winded rant, sorry!

Ultimately, I’m happy with whichever direction the community chooses - the only thing that’s important is that the community gets to make this decision instead of any centralized entity, which clearly will be the case.

[Crypto_Fruit]

I hope you will not give this valuable thing for free to people who will only fork it, claimed they solved scalability and earn billions on it without any contribution. Rather build it way like we can trust and others can join if they build their own solution. Or let big exchanges to pay that development.

[SwagtimusPrime]

I generally agree with what polynya is saying, though I think a period of 1-2 years and/or until decentralization is achieved under a more restrictive license makes sense to get things off the ground without people immediately forking StarkNet. The license can be loosened up step-by-step or entirely after that point.

[Kartik]

I believe the Polaris license should exist for next 1-2 years, once Starknet has established its name as the ZK STARK pioneer, then community can discuss whether to make everything open source or not.

[Idan_Levin]

I generally believe that forks are good and any assumption on the licensing terms should be derived from that.

My argument: each original tech in crypto that got forked eventually became the predominant canonical one.

Base layer: Bitcoin had dozens of forks, so does Ethereum, they eventually got bigger than any fork. With time passing by we are seeing Bitcoin competitors deteriorating in their status (e.g. Litecoin).

Dapps: Uniswap beat Sushiswap although it got forked, OpenSea got sort of forked (with LooksRare), and although early I don’t think OpenSea will be severely hit.

Forking means you are becoming the standard. Just like memes, the more you have the stronger you are in a network effect economy.

And I think that because the biggest challenge to StarkWare is other L2s becoming the predominant ones, and they are using different standards (some EVM compatible), the biggest challenge is making everyone use StarkWare as the scaling standard for the whole industry. So I would be generally less concerned about other teams forking the tech and more around winning the standard race.

I think that because blockchains will become so big winning as a standard should be the number one priority. And because I know the quality of people in Starkware, I doubt that other teams can outcompete the canonical Starkware platform with the same level of quality and security, especially when the tech stack is so early and unfamiliar by many.

There is one exemption for my argument - if you are open sourcing the code without a token and some anon team forks it and issue it with a token.

I think that as long as there is no token circulating, the code should be licensed. Because without a code Starkware could be shoved into the Uniswap/ Sushiswap dynamic and leak value to anon teams who are taking advantage of a legal arbitrage without contributing to the ecosystem. I see no benefit in this for Starkware.

[elibensasson]

Thanks, and what’s your thoughts on the different, AWS/Google threat that I mentioned above, and which has played out in the world of Databases?

[Idan_Levin]

It’s a fair concern - I would lean towards this still makes Starkware stronger because you have a different value prop (decentralized, which AWS could never be) and then it just means you absolutely won the standard wars and Cairo wins.

I’m asking myself what if AWS will fork Ethereum and obviously nothing, but Ethereum already has deep network effects. So it is really a question of when rather than if. If there is a risk of this happening in less than 1-2 years from inception - I would agree it is wise to protect the code. After Starkware will be a rich ecosystem I don’t see any risk because the network will create a strong moat.

It is really a question of what is the bigger risk, being behind on the standard wars or being forked by AWS/Google and cannibalized. I lean more towards the former, but you probably have a much better estimation on this than I do.

Anyways imo locking the code should have frequent revisions of this decision to make sure it can be reverted if needed

[RoboTeddy]

Two conflicting needs:

A. Starkware probably wants to become a valuable company so they can give their investors and employees a great return, which may require a restrictive license to avoid copycats.

B. There are large public benefits to the prover being licensed permissively, for example:

• The prover could be used to verify proofs on other Ethereum L2s, sidechains, other L1s, etc
• If there were ever a need to redeploy the verifier (e.g. due to the release of an L1 WASM-based VM), Starkware would be a point of centralization
• If for some reason Starkware ultimately neglected to remove upgradeability from their contract in due time, the community could fork and remove upgradeability on their own.

Shared need:

Starkware wants its products to be broadly adopted by the Ethereum ecosystem, which is most likely to happen if Starkware is supportive of that ecosystem and its values, including open licensing and the attendant benefits of additional censorship resistance, forkability, redeployability, etc.

Potential solution: temporarily license under Polaris, ultimately license permissively

Starkware could license the prover under Polaris for an e.g. 3-4 year period, and then have it convert to something more permissive. There’s precedent for this with Uniswap v3. This would give Starkware time to build up a network effect which makes their organization valuable, giving back to their employees and investors, whilst also reaping some of the benefits of broader ecosystem adoption due to their ultimately values-aligned behavior.

[Killari]

Are there any big companies in crypto ecosystem that have ever forked a project and made it decentralized? I wouldn’t see AWS/google as a risk as they wont decentralize it, and if they deploy a centralized version, it’s not that useful. A vampire attack would be more meaningful attack towards StarkWare (think Uniswap vs Sushiswap). However, I fould still think StarkWare’s initial chain would be seen as “the official” chain and be the most used. Ofcourse if StarkWare stops to support the chain and require community to take over, then the community might decide to move away from the StarkWare’s chain. Also if the StarkWare’s decisions turn out to be bad for the community, community can again move away from their chain.

I would find StarkWare as strongest as possible when its full blown open source. This allows the network to be more decentralized as if its captured, a new version can be launched. Forking is important part of decentralization, if you disagree with something, you can just fork away and do your own thing, no one is stopping you. This keeps the developers honest too, as they have to keep the network meaningful and provide value for the community. Ethereum is an excellent example of this and StarkNet being core infrastructure, it should continue building OS.

While everyone have their own view what is “decentralized”, can proprietary software (even if it code is visible), seen as decentralized?

[tshaka]

I am inclined to agree with @polynya and @Idan_Levin. The most important thing might be prioritising community involvement and the network effects that come with that which might require a more permissive licence.

On the issue of companies forking open source projects and making money off them while contributing little in return, while it might be annoying, I don’t think it poses as much of a threat here? Generally, open source projects tend to rely on enterprise support contracts to be sustainable (among other things) and I can see how a company like AWS offering a competing service can be existential in those cases but databases are still essentially decades old commodity software (maybe less so for Elasticsearch), it is hard to imagine that a more restrictive licence would have been of much help in that regard.

The other part I think one cannot discount is that it is still ultimately an emotional issue too. But that’s perhaps more a question for the team and whether watching someone fork and profit off of their work would materially affect their quality of life.

That said, if history is anything to go by, people tend to end up conceiving open versions anyway as @polynya already gave some examples. There are also others such as work done by the likes of Ben Laurie and Ian Goldberg that to sidestep Chaum’s patents on blinded coins, or EdDSA and Schnorr signatures although that came after the patent had expired if I am not mistaken.

Or maybe one might feel the analogy between licences and patents might be too much of stretch, but if I recall, even Google opted for implementing the Java API in Android themselves over just licensing it from Sun so (in hindsight probably not the best idea).

[Dorox]

I generally agree with what Polynya said and imo the Polaris license should exist for maybe one to maximal two years.

[Tommy]

I am in favor of restrictive licensing in the ecosystem, irrespective of the open source ethos and ideals behind crypto. Many rent seekers have emerged, and they are not merely rent seeking but also nefarious actors who damage the ecosystem badly.

For instance, Uniswap v2 was open source, and this enabled creation of thousands of DEX all across the space, fragmenting liquidity, providing scammers and bad actors a play ground to feed on unsuspecting users. Thousands of DEX tokens were dumped on the market backed by just a Uni v2 fork DEX, enabling creators to cash out by creating a worthless token.

For Starknet, I believe the license should be a permanent feature, it can still be community owned but the community can protect itself from rent seekers.

[polynya]

Another data point on “they’ll just do it themselves”: proof-systems/0001-cairo-gates-and-constraints.md at cairo · querolita/proof-systems (github.com). This is a real opportunity for Cairo to become a standard, and removing all friction is the pragmatic approach that’ll deliver most value to canonical StarkNet. (See: EVM in the L1 world)

Thanks to @georgethms1 on Twitter for informing me about this.

[edmundedgar]

Just to give my point of view as a dapp developer: It’s extremely important to me that the software that I make for my users can be used with no reliance on me or any other team, and that if anyone is unhappy with how the project is run, they can fork it and run their own version. This is a core safety feature that protects users from being rugged by the team whose platform they are developing on top of.

I think the justification that people are trying to make here is that since a rollup system is deployed against a particular contract and the contract in theory prevents user-hostile changes, it doesn’t matter if the software is proprietary. But this is not true in practice, because in the short term it’ll have upgrade features which involve governance, and in the long term there will be advances that require new versions to be deployed; Governance can sometimes go wrong, and the only way a developer is protected from governance failures is if they can exit with their assets, then recreate the platform they were building on without the permission of whoever is in charge of it. The latter part is prevented by a whitelist. Note that the people who may want to do this are not only outsiders, but also often developers from the original team, who may be disaffected with either their own organization’s management or, if you move control to some kind of DAO or other community governance structure, that DAO or whatever you use.

Governance is an unsolved problem in crypto, and to the extent that it’s sort-of solved, the solution involves rage-quit. This license is a prohibition against rage-quit, and as such it makes creating functioning governance harder.

I know a couple of other projects have done this - I guess not coincidentally, while taking a lot of VC money. For this platform to succeed, I would strongly suggest it not do this, and I won’t deploy on this platform unless it gets a free software license.

[nikhil]

I would recommend starting with a restrictive license to complete open source this gradual progression until starknet is completely decentralized will make sure starknet is rewarded to its work while avoiding mercenary forks from ripping of technology.

[LefterisJP]

Stay opensource, stay copyleft. The code itself is never the moat for a project.
Proprietary license that slowly becomes opensource, is not an opensource license.

You will build a better dev community and attract more talent if you are opensource.