This PR contains a merge of the two other PRs that are open right now, namely bundler-refactor and security-zones
Notes:
1) Test pass but only when run on the version of localfhenix that supports security zones, which means they will not pass the CI. we can either upload a new localfhenix and use it here or docker-login to use an internal version of the localfhenix.
2) uses new signature of getNetworkPublicKey, encoding the securityZone in the calldata, but without using ethers, so that it will be a smaller lib.
3) ~This PR introduces an inconsistency between encrypted numbers returned by the exported encrypt_x top-level functions, and those returned by the bounded instance.encrypt_x methods of the FheClient. Namely, that the numbers returned from the bounded method include the security zones as first byte. This means that only they can be sent to the network, while numbers returned from the exported top-level functions cannot. I did this in order to still make it possible to use the encrypt_x functions as they were used in the text, by providing a locally generated publicKey and then decrypting with its clientKey, (otherwise they couldn't be decrypted because there was an extra byte at the beginning). This is just the quickest fix, but probably a better one is to add the securityZone as a separate field in the encrtypedNumber type, and not considering it when working locally. This means that we need to change a bit the FHE.sol to support it, but it shouldn't be a problem. @Cashmaney, we should do that, right?~
Edit: fixed, including the security-zones-field reformatting which solves this (devs should now use the .data field of the encrypted number only when working with locally encrypted numbers)
This PR contains a merge of the two other PRs that are open right now, namely bundler-refactor and security-zones Notes: 1) Test pass but only when run on the version of localfhenix that supports security zones, which means they will not pass the CI. we can either upload a new localfhenix and use it here or docker-login to use an internal version of the localfhenix. 2) uses new signature of
getNetworkPublicKey, encoding the securityZone in the calldata, but without usingethers, so that it will be a smaller lib. 3) ~This PR introduces an inconsistency between encrypted numbers returned by the exportedencrypt_xtop-level functions, and those returned by the boundedinstance.encrypt_xmethods of the FheClient. Namely, that the numbers returned from the bounded method include the security zones as first byte. This means that only they can be sent to the network, while numbers returned from the exported top-level functions cannot. I did this in order to still make it possible to use theencrypt_xfunctions as they were used in the text, by providing a locally generated publicKey and then decrypting with its clientKey, (otherwise they couldn't be decrypted because there was an extra byte at the beginning). This is just the quickest fix, but probably a better one is to add the securityZone as a separate field in the encrtypedNumber type, and not considering it when working locally. This means that we need to change a bit the FHE.sol to support it, but it shouldn't be a problem. @Cashmaney, we should do that, right?~ Edit: fixed, including the security-zones-field reformatting which solves this (devs should now use the.datafield of the encrypted number only when working with locally encrypted numbers)