There are some non-ML based approaches for ultra low field MRI that are starting to work: https://drive.google.com/file/d/1m7K1W--UOUecDPlm7KqFYzfkoew... . You can still add AI on top of course, but at least you get a better signal to noise ratio to start with!
The benchmarks listed there are approximately 100 times slower than the original Intel 8088 microprocessor released 1979 on which the original IBM PC was based.
That microprocessor was efficient enough for many applications of general purpose computing, but we still need Moore's law to give us a 100-fold increase in compute power to reach this level.
This level of performance seems comparable to (and IMHO slower than) the very first electronic stored-program computer, the 1948 Manchester Baby.
In other words, this can be compared to do the computation manually, but with the guarantee that whoever is performing the computation cannot glean anything from it.
This can be OK for some relatively rare and important computations, which you for some reason must run in a software-untrusted environment. I can imagine using it for some high-stakes, small-scale automated voting. All the intermediate results may be posted in the encrypted form as an audit trail. After the process is completed and results are declared, the encryption keys are released, and any party can check that every step of the computation determining the winner was correct, there was no stuffing.
Multiple teams are working on FHE smart contracts, including us, so it’s definitely happening. Adding ZK to the mix would be awesome for scalability and indeed to avoid replicating the FHE computation
It’s much much faster now, and performance is improving 10x every couple of year. With the current trend, FHE will be applicable to 80% of usecases by 2025
It's really great to see more big companies getting into this game, ease of adoption is really the key here.
When it comes to FHE, there are 3 underlying paradigms you can target with compilers:
1. boolean circuits, where you represent your program as encrypted boolean gates. The advantage is that it's as generic as it gets, the drawback is that it's slow. TFHE is great for that, and it's what is shown here.
2. arithmetic circuits, where you represent your program as a combination of encrypted additions and multiplications. This goes much faster, but you are quickly limited in terms of usecases because you can only do a certain number of arithmetic operations. CKKS/SEAL targets that: https://www.microsoft.com/en-us/research/project/microsoft-s...
3. functional circuits, where you represent your program as a combination of homomorphic functions. Advantage is that you can do very complex things like deep neural network, the drawback being that you have limitations of the bits of precision for the computations. Concrete targets that: https://zama.ai/concrete/
These are all the same paradigm, in priciple. 2 is a special case of 3 and 1 is a special case of 2. All circuits differing in how powerful the processing nodes are.
Homomorphic encryption, which enables you to process data without decrypting it. Would solve privacy / data security issues around sending data to be processed in the cloud
The extra cost is worrying. You're talking at 4 to 6 orders of magnitude increase in resource usage for the same computation.
Unless we figure out some awesome hardware acceleration for it, it's not practical but for a few niche applications.
It also has the problem that you can use computation results to derive the data, if you have enough control over the computation (e.g. a reporting application that allows aggregate reports).
Modern homomorphic encryption schemes only have a ~100x performance hit. That sounds bad, until you remember that computers are really fast and spend the majority of time doing nothing, and that the difference between writing a program in Python or C is already something like 10x.
> Modern homomorphic encryption schemes only have a ~100x performance hit.
Really?! Now I'm curious. If I have a simple program for an 8-bit CPU @ 1 MHz, when can I run this program on a virtual machine using homomorphic encryption, under a reasonable runtime? Is it possible yet? If the performance hit is only 100x, the runtime should not be much longer than the actual chip. But the last time I checked, the hypothetical runtime seems to be still impractical.
- do fast operations, with a limit on how many you can do. This is called Leveled Homomorphic Encryption, with CKKS being the most popular scheme. Microsoft open sourced a lib called Seal for it.
- do unlimited operations, but with extra overhead. This is called Fully Homomorphic Encryption, with TFHE being the fastest implementation. My company Zama has open sourced an library in Rust called Concrete.
Reminds me a lot of deep learning in 2010, just before it took off!
The fact that wallet IDs are visible in the blockchain breaks it completely for me. I do NOT want an immortal record of every penny I spent and to whom I gave it. Fuuuuuuuck that. Today I have a choice, but with many cryptocurrencices (ETH, BTC) that is a "feature" not a "bug".
Monero and Ravencoin have transparent and shielded entries. I believe the node is encrypted with an ECDH shared secret, so the payer and the payee know each other's wallets, but no one else does.
yes, i did mean that. also pegging it to a real currency, like USDCoin. I have not heard of Mimblewimble. Thanks for the reference, I'll add it to my list of coins to study.
Zama uses TFHE, which allows any operation (eg comparisons) with unlimited depth.
So if you only need add/mul, BFV, BGV and CKKS are good options. For anything else, you better use TFHE