I am not that deep into the STARK world, but my understanding is that it’s probably because prime fields just get “more work done”. While binary fields are really cool when you want to compute XORs, they suck at basic arithmetic operations such as addition and multiplication of integers. Prime fields can do this, and while you have to do some range checking to make sure you don’t get overflows, these have massively decreased in cost since all the lookup constructions came out. So with prime field you can get cheap arithmetic operations, and with binary fields you just get some binary operations cheaply but I guess it turns out the arithmetic is more important.
1 Like
On top of that, plain old mathematical simplicity and “intelligibility to people with only a basic undergrad-ish education” is a good in itself. And that’s a criterion that prime fields fare much better in than binary fields.
I’d say there are 3 advantages of prime fields over binary fields (for similar bit-size):
- Prime fields deal somewhat better with integer arithmetic (@dankrad 's point)
- Ethereum verification gas cost favors primes over binary fields (this is the main reason back in the day StarkEx didn’t go with binary fields, as it would have meant we need to get an EIP to support cheap binary field multiplication and it wasn’t worth the hassle).
- For certain primes - FFT friendly ones - like babyBear, deg-2 extesion of Mersenne31 and Goldilocks, you can use the same 2^k group for writing down the trace and doing FFT+FRI. In binary fields you need to either use a multiplicative subgroup of the field, which isn’t of size 2^k, or use the additive group which is harder to work with, or slap on an elliptic curve which makes things harder (this relates to @vbuterin’s point).
Nevertheless, I have a soft spot for binary fields (maybe because the Ben-Sasson Sudan algorithm, which is the primordial father of STARKs, works nicer over them?), and I’m told that when building ASICs they may have their day again.
1 Like