You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current args_hash may contain up till 4096 elements, split in 64 chunks of size 64.
By allowing really big input values, we are currently increasing the cost of every single contract function. I'm not sure how this will be impacted by a databus, @LeilaWang might know?
Nevertheless, if the databus is not making a significant diff here, I think it will be worth it to reduce both constants to 16 instead.
Current cost: ~44K
Cost with 16: ~15K
The text was updated successfully, but these errors were encountered:
My understanding is, with databus, it will be way cheaper to commit to the data (public inputs). So it will allow us to cheaply "pass" the entire args array to a call, instead of hashing it to pass a single agrs_hash.
My understanding is, with databus, it will be way cheaper to commit to the data (public inputs). So it will allow us to cheaply "pass" the entire args array to a call, instead of hashing it to pass a single agrs_hash.
Sounds cool. Will the databus also be usable for other calls, just from mikes comment on one of the other issues/prs sounded like it was not clear if there was enough room on the bus? Or maybe I misread it. (cannot find the comment right now though 🤔)
The current
args_hash
may contain up till4096
elements, split in 64 chunks of size 64.By allowing really big input values, we are currently increasing the cost of every single contract function. I'm not sure how this will be impacted by a databus, @LeilaWang might know?
Nevertheless, if the databus is not making a significant diff here, I think it will be worth it to reduce both constants to 16 instead.
Current cost: ~44K
Cost with 16: ~15K
The text was updated successfully, but these errors were encountered: