-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: missing gas costs and memory issues #121
Conversation
tfhe.FheUint64: SstoreFheUint4Gas * 16, | ||
tfhe.FheUint128: SstoreFheUint4Gas * 32, | ||
tfhe.FheUint160: SstoreFheUint4Gas * 40, | ||
tfhe.FheUint2048: SstoreFheUint4Gas * 120, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldnt price be proportional to number of bits here as well to avoid DDOS?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, yes, but the size is around 8 MB for FheUint2048. Not sure what the best approach is here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, then if price becomes prohibitive maybe it would make sense to reduce SstoreFheUint4Gas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, could be. But reducing cost for other types could also be an attack. Maybe let's deal with that later.
tfhe.FheUint64: SstoreFheUint4Gas * 16, | ||
tfhe.FheUint128: SstoreFheUint4Gas * 32, | ||
tfhe.FheUint160: SstoreFheUint4Gas * 40, | ||
tfhe.FheBool: SstoreFheUint4Gas / 2, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't price be divided by 4 instead of 2, since ebool is a single bit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me check, because it is related to serialised size and not plaintext bits. Overall, these values might be off.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jatZama Sizes for these data types as serialised:
FheBool (0) = 0x0:
8268 = 0x204c
FheUint4 (1) = 0x0:
16544 = 0x40a0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
weird... wondering why ebool is an exception here with respect to size.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because of the way the ciphetext is represented, I think. I guess 4 bit is two 2 bit low-level ciphertexts. And 1 bit is just one.
Add missing gas costs for multiple operations, mainly for FheBool, FheUint160 and FheUint2048. Note that verify for bool is more expensive due to lack of cast from 2048 bits to bool - doing not equal instead. Make `castTo()` fail and not panic on bad type input. Fixed a memory leak in `executeTernaryCiphertextOperation()` - the `first_ptr` pointer was never freed. Refactor some of the code such that it uses `defer` with destroy as close to the point where memory is allocated as possible - that fixes memory leaks on early returns in multiple places. C code needs to be refactored and reduced. Maybe we can use codegen or a tool for that.
Add missing gas costs for multiple operations, mainly for FheBool, FheUint160 and FheUint2048.
Note that verify for bool is more expensive due to lack of cast from 2048 bits to bool - doing not equal instead.
Make
castTo()
fail and not panic on bad type input.Fixed a memory leak in
executeTernaryCiphertextOperation()
- thefirst_ptr
pointer was never freed.Refactor some of the code such that it uses
defer
with destroy as close to the point where memory is allocated as possible - that fixes memory leaks on early returns in multiple places.C code needs to be refactored and reduced. Maybe we can use codegen or a tool for that.