This looks like an interesting paper. I only partly get the paper but it reads like it might be usefull for inspiration on building non-interactive transfers.
2 Likes
It’s more useful for accelerating the Initial Bytes Download by using Incrementally Verified Computation to verify existence of a valid kernel history, without having to download all those kernels. I.e. it would make IBD just UTXO sized.
A more recent paper that might offer further improvements is
2 Likes
STARKs can also be very useful in accelerating IBD, as John Davies pointed out on keybase:
3 Likes
And this paper seems to address the challenge of Grin’s secp256k1 curve not being very FFT friendly:
1 Like
What does FFT stand for, Fast Finit Field Transform or Fast Fourier transform? Maybe add a bit of context for the less mathematically gifted among us 
This is what I got after some digging,
“Finite field cryptography” is fancy language for group-based cryptography done over the integers modulo a prime (instantiating a field) to distinguish this more “classic” approach from the new fancier elliptic curve cryptography."
Still no clue about why that is relevant for Grin, or if being able to do FFT with Grin creates new possibilities.
FFT always stands for Fast Fourier Transform.
You can see one of the references make this explicit:
[BCKL21] Eli Ben-Sasson, Dan Carmon, Swastik Kopparty, and David Levit. Elliptic curve fast fourier transform (ECFFT) part I: fast polynomial algorithms over all finite fields. Electron. Colloquium Comput.
Complex., page 103, 2021.
The term FFT-friendly is a technical one that means having a subgroup of size 2^k. The larger k, the friendlier it is. For secp256k1, k=0 so it is as unfriendly as it gets:-(
There is no subgroup over which you can perform a (discrete) fast fourier transform.
I never heard of Fast Finite Field Transform but that would be FFFT, wouldn’t it?
1 Like