The Cairo Programming Language | Hacker News Reader

The Cairo Programming Language

cairo-book.github.io

72 pointsnoch32 comments

It would be nice to see an example of a real world application as opposed to crypto make believe.

We know that the entire "web3" has the computing power of a Raspberry Pi while running on the computing hardware equivalent of a contry's worth of datacenters, so yeah, anything that helps "scaling" that mess is probably just some very exotic solution to a fake problem that was simply invented as a cover for some convoluted financial fraud.

Finance is a well established use case for blockchain.

I believe that was already covered by "some very exotic solution to a fake problem that was simply invented as a cover for some convoluted financial fraud".

How specifically?

The only halfway decent project I've seen is the Stellar protocol, which might be used as intra-bank network and/or for real digital currencies.

But it's not completely trustless (the banks need to trust eachother), and there is no ponzi scheme going on, since the tokens are just data that represent real assets (held at the banks you need to trust).

Does that differ much from electronic transfers as done currently between banks?

It has 'blockchain' in the description.

The individual banks (and users) would need less trust between eachother, as long as the group as a whole is generally trustworthy.

Cryptocurrency doesn't count, that's more like baseball cards than finance.

I don't understand how a technical audience like HN wouldn't be interested in stuff like this. Sure, maybe it's all exotic solutions to fake problems. They're still pretty cool solutions!

ZK-tech allows you to prove that you evaluated `f(x)` and got `y`. Normally someone would have to evaluate `f(x)` themselves to verify that `y` is the output, but if you encode `f` as a ZK circuit, in addition to getting the output you also get a succinct proof that you evaluated `f` correctly, In other words, you get `f' : x → (y, proof)`. The proof can then be verified in constant time for SNARKs, or log-poly time for STARKs. And depending on how you construct the proof circuit, you don't even necessarily need to know `x` to verify the proof!

How crazy is that? To me, this seems like cryptography from the future. It's not even something that would obviously be possible. It wasn't invented by cryptocurrency developers, but it's impossible to deny that cryptocurrencies have advanced the field dramatically. (Reducing the overhead of creating the proof, for example.)

There are tons of applications for this, too. Imagine you wanted to have a registry of "known-humans", a list of public keys where each private key belonged to a unique person. Now, a user wants to log into your website, and you want to verify that they're on this list. It's not obvious how to do this in a privacy-preserving way, that is, how does the user prove they control a private key associated with a public key on the list, without revealing which one? With ZK-tech, it's easy. The user downloads the list, encrypts something with their public key, then decrypts it, and does this all in a ZK circuit that produces a cryptographic proof that the process was done properly with a key that's on the list. Then they send the proof to the website, which is able to verify it without knowing the secret inputs (the private key, or the which public key was selected). There are other ways of accomplishing this that don't use ZK-tech, this was just a simple example.

If I understand this correctly, would an example use case work as follows?

I want to get a loan for a house. A lender wants to see that I am trust worthy enough for a loan, however I don't want just any potential lender to know my exact bank account balance or anything like that, just that I have enough.

So, a program is written in Cairo that validates either I do or don't have enough, and the lender can verify the results, without seeing anything else.

Is that more or less how it goes or can someone help make this real for me?

There are essentially two use cases for "zero-knowledge" proofs:

1. Zero-knowledge

That's proving a statement without revealing information, this is the example your're giving. For instance, you could prove that you have an account number (private information, input to proof generation, but not input to proof verification, so not revealed to the counterparty) on a blockchain (whose state hash is public, input to both proof generation and verification), with enough quality assets to back your loan.

2. Succintness

It turns out you can verify zk-SNARKS (where SNARK = Succint Non-interactive ARgument of Knowledge) in less time than it takes to execute the program being proven. Some schemes do this in constant time, some in logarithmtic time (the STARKs currently used with Cairo are logarithmic).

This lets you offload computation to a third party (like AWS) but without trusting that the third party will not perform a modified computation instead. The third party gives you back the result along with a cryptographic proof that you can verify relatively fast.

In this use case, there doesn't need to be any private input at all (though there can be, and the verification will still be succint), so it's not even necessarily "zero-knowledge". People sometimes call this "validity proof" to distinguish, but the underlying cryptography is the same.

> I want to get a loan for a house. A lender wants to see that I am trust worthy enough for a loan, however I don't want just any potential lender to know my exact bank account balance or anything like that, just that I have enough.

That's... what? If you "have enough", you don't need a loan, do you? And lenders generally don't want to know your bank account balance either, they want to know if you have a stable (and large enough) current of income, e.g. that you're employed and yearn at least X per month, so that you'd be able to make monthly payments for years to come.

This is a correct intuition yes. A program written in Cairo taking your balance (private) and a minimum collateral (public) and outputs a boolean for pass/fail, where the lender can only see "pass/fail" but trust the program was executed correctly is right.

However the technology isn't particularly useful in this scenario. It's enough for your bank to just reply to a request with "yes" without running the program because in theory you are forced to trust the bank no matter what as you have no guarantee the bank didn't just lie about your balance in the input to the Cairo program, so in this scenario the proof doesn't bring much. This technology is a lot more useful when the data being verified is combined with something that guarantees that the data input wasn't forged somehow, which is why this is more useful in blockchain environments where all transactions and balances are signed, so someone can't just invent a balance out of thin air.

I had to click this to realize this is not about the OG Cairo: https://www.cairographics.org/ .

It looks very similar to rust, with some minor details like typed enums.

It would be nice to find a direct comparison between rust and cairo, and why writing contracts in cairo cannot be done with just a rust create.

Cairo is written in such a way that the execution of a Cairo program can be proven by a zero-knowledge proof. So it optimizes for things that are easier to prove.

You can actually write zkps in pure Rust, but there's not currently any blockchain integration: https://github.com/risc0/risc0

> Ethereum is a decentralized blockchain platform that enables the creation of decentralized applications where every single interaction between a user and a d-app is verified by all the participants.

One keeps hearing about the ability to build “decentralized applications” upon crypto/blockchain tech, but I have yet to actually encounter even one such app.

Is it just vaporware?

Uniswap is a decentralized crypto currency exchange. Aave is a lending protocol where you can get a collateralized loan. There is many others. In fact those cryptocurrency are decentralized apps themselves. All of this combined this millions of transactions every day.

Here are just a few, presented for your curiosity. I have no affiliation with any of them. One thing to understand is that the decentralized application themselves are running over Ethereum. The only way to see the blockchain is either running a node yourself, or through a block explorer which is running its own node and giving you the ability to explore what's happening through a web (e.g. https://etherscan.io/)

So for each of them I'm going to present a frontend UI to the decentralized application, that is just a nice UI hosted on a centralized server that makes it easier to interact the decentralized application. And where to find the smart contracts, these are the code that is running on Ethereum. You don't need the UI to interact with them, you can always run an Ethereum node and relay your own transactions to the network. But as a user you may also simply use the web UI if so inclined.

I make this distinction because as a user, if you simply see a webpage you may ask yourself what's even the difference between that and a traditional web application. The point is that the web UI is just a nice UI, that is not needed to interact with the smart contract. The web app may have downtime, be taken down, censored by your country or ISP. While Ethereum always runs, 100% availability, permissionless, and uncensorable. These properties may not matter to you or for most applications, but they do matter for some users and applications.

Uniswap:

- This is an exchange, like a stock exchange but implemented over Ethereum.

- Frontend URL: https://app.uniswap.org/

- The smart contract(s): https://etherscan.io/address/0x68b3465833fb72a70ecdf485e0e4c...

Ethereum Name Service:

- This is like DNS over Ethereum. It resolves the ugly addresses 0x302834... to more memorable names like "andsoitis.eth". So you can snatch yours and tell people to pay you to "andsoitis.eth", for example.

- Frontend URL: https://app.ens.domains/

- The smart contract(s): https://etherscan.io/address/0x314159265dd8dbb310642f98f50c0...

Aave:

- This allows to lend and borrow.

- Frontend URL: https://app.aave.com/

- The smart contract(s): https://etherscan.io/address/0x24a42fD28C976A61Df5D00D0599C3...

Alchemix:

- Self-repaying loans without risk of liquidation. You can borrow up to 50% from your own-collateral and gradually pay it back, without risk of liquidation.

- Frontend URL: https://app.alchemix.fi/

- The smart contract(s): https://alchemix-finance.gitbook.io/user-docs/contracts

ZkSync Era:

- A zero-knowledge layer 2, that helps scale Ethereum. You can run decentralized application for a fraction of the price you would do on the Ethereum mainnet. The layer 2 posts proofs of correct execution to Ethereum. This way you can run tons of transactions while enjoying the security of Ethereum.

- A bridge to the L2: https://bridge.zksync.io/

- And a block explorer: https://explorer.zksync.io/

- The smart contract(s): https://era.zksync.io/docs/dev/building-on-zksync/useful-add...

Out of curiosity, despite knowing all too well what to expect, I had a look at just one of your links, the "Alchemix" one.

What the... are we supposed to do with "self-repaying" loans, really? I clicked on "Learn More" under "Leverage your wealth" and was taken to a developer documentation page [1] with highly jargoned prose that give me even less idea of what this thing could really help me with. How the hell can I leverage my wealth, please?? Ok, just a loan, how do I get one???

Seriously here's a small excerpt from that site:

"For example, if governance sets the liquidate() cap for DAI to 20 million with a 10 minute cooldown, then the maximum amount of DAI that can be liquidated from all of the strategies used by the alUSD Alchemist over the span of 10 minutes is 20 million. The cooldown period is linear, so if the 20 million cap gets hit, no more DAI can be liquidated in that block, but after 5 minutes users can liquidate up to 10 million DAI."

What the actual... ??

If this is your example of a good crypto app we should be using, thanks but, no thanks.

[1] https://alchemix-finance.gitbook.io/v2/

You are looking at the developer documentation. It explains the different classes and methods they expose, it's technical and the target audience is supposed to be technical.

I didn't provide this example as a particularly good example of a decentralized application but as one that provides some unique financial product that is hard to find an equivalent in traditional finance.

From the point of view of a user what it allows you to do is:

1. Deposit some collateral (e.g. ETH, rETH, or some USD stablecoin...)

2. Leverage that collateral up to 50%. I.e. You get debt of up to 50% of the collateral.

3. Do whatever you want to do with your leverage.

4. Meanwhile the collateral is put to work producing some yield that is repaying the debt you were issued. More interestingly, you can't get liquidated.

Fortunately, if you don't find it interesting you don't have to use it.

> You are looking at the developer documentation.

Did you miss what I said??

> I clicked on "Learn More" under "Leverage your wealth" and was taken to a developer documentation page

> It explains the different classes and methods they expose, it's technical and the target audience is supposed to be technical.

I am about as technical as it gets. If this is not for me, really, this is for such a tiny minority of people who are just very interested in finance, and in particular using cryptocoins, as to be completely out of reach for anybody else. Like every other crypto app I've seen so far.

So you are making the point that one particular decentralized application has poor user documentation? Yes, I agree. I don't think it's a particularly novel observation when discussing small OSS projects.

The following projects have better technical documentation, if you want to scratch that itch:

- Uniswap: https://docs.uniswap.org/

- Aave: https://docs.aave.com/hub/

- RocketPool: https://docs.rocketpool.net/

- OpenSea: https://docs.opensea.io/

>>What [...] are we supposed to do with "self-repaying" loans, really? [...] How the hell can I leverage my wealth, please??

I'm fond of the seemingly accurate sentiment that crypto is trying speedrun the history of finance (including spectacular failures). In this instance, a self-paying loan is a concept similar to a reverse mortgage, home equity loan, home equity line of credit[1], or 401K loan[2]. All are instances of paying back a loan originally borrowed against one's own money or value that has built up over time, and are financial products that exist in the US.

The difference here is that the type of self-paying loan described by the OP is one where the collateral is a digital asset instead of, say, your house or retirement fund. Nothing new under the sun, except perhaps the ability to do this programmatically.

[1] https://www.investopedia.com/mortgage/reverse-mortgage/rever...

[2] https://www.bankrate.com/investing/borrow-from-401k-loan/

I think there is a quite a bit of truth in speedrunning the history of finance. I don't see that per se as a negative, there is a lot of lessons that were learnt for good reasons. Many of these lessons are still valid and some lessons are valid but do not need to be enforced through regulation because the cryptography behind takes cares of them programmatically. This is the main advantage that is being explored IMHO, that you can enforce through code things that before were dependent in a complex network of trust, institutions, auditing, and humans doing busy work and moving papers. The speedrunning part can in itself be an advantage as it allows to iterate quick until you reach maturity. But this is just my personal opinion and I can understand skepticism until these products prove their maturity.

Regarding the comparisons you propose. I don't see how [1] is equivalent. The mechanics are quite different. In Alchemix you receive a lump-sum at the beginning and pay it back gradually through the protocol that is using your collateral to obtain yield in various yield-bearing assets.

[2] is closer in spirit. But as far as I know you can get liquidated. You have a repayment schedule and if you don't meet your obligations then your collateral will be impacted. In Alchemix your collateral is locked bringing some yield, there is no fixed repayment schedule, it adapts based on the yield.

Anyway, the point was not to promote any of these smart contract and I have no affiliation with any of them. It was simply to illustrate the OP that it's not vapor ware, it exists, is implemented and is working today. It's niche, it's not for everyone, but is not vapor ware.

I've been programming in Cairo 1 in the past few weeks and must say that the developer experience is very good for web3, where it's usually very bad.

I also believe that it's the solution to blockchain scaling – this finally lets us have the entire 'web3' have more than the computing power of one single machine.

I do think, that trusting thrid-party hardware is always a bad idea. There will never be a safe execution model where you don't own the hardware. Just my opinion...

The point of zk proofs is that you don't have to trust. But you can verify. Without having to rerun the computation yourself, simply verifying the proof which is much cheaper computationally.

Paranoia about untrusted hardware is absolutely warranted but just to try and convince you of what this is trying to do. Imagine you have a file that you have never shown anyone, and some untrusted host wants to convince you they also have that file. They can prove this to you without you revealing the file to them (or them to you) by having them send you the hash of the file that you can compare to your own. If it matches there is an overwhelming probability they also have the file even though you completely distrust them or their execution environment. In other words, you are able to verify the computation (via the hash) was executed even though you don't trust them. Cairo is using similar techniques that let you verify other forms of computation than just hashes using more advanced primitives.

The obvious caveat to this just as with hashes is you trust the underlying cryptography is secure.

Thanks for the explanation. That sounds like a really smart idea. I first thought, that this is based on Intel SGX, which seams to have some security problems (words of a friend working with that technology). I'll have to dig deeper into this topic. Are there any limitations?

Reply on news.ycombinator.com