Skip to content
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

refactor: TFHEExecutor #141

Merged
merged 5 commits into from
Nov 26, 2024
Merged

refactor: TFHEExecutor #141

merged 5 commits into from
Nov 26, 2024

Conversation

PacificYield
Copy link
Contributor

@PacificYield PacificYield commented Nov 25, 2024

This PR removes the codegen for TFHEExecutor.sol and TFHEExecutor.events.sol; it replaces the codegen logic through inheritance and the use of super().

All files in types/ that are auto-generated are removed.

@PacificYield PacificYield force-pushed the refactor-tfhe-executor branch from 790dc79 to da2f9fa Compare November 25, 2024 15:24
@immortal-tofu
Copy link
Collaborator

I think we shouldn't commit types folder

@PacificYield
Copy link
Contributor Author

I think we shouldn't commit types folder

Agreed. I wanted to remain consistent. Should we remove the types altogether instead?

@immortal-tofu
Copy link
Collaborator

I think we shouldn't commit types folder

Agreed. I wanted to remain consistent. Should we remove the types altogether instead?

I think It has been commited by error, so yeah you can add it to gitignore

@PacificYield PacificYield force-pushed the refactor-tfhe-executor branch from da2f9fa to 1bbdb04 Compare November 25, 2024 16:38
@PacificYield PacificYield force-pushed the refactor-tfhe-executor branch from 1bbdb04 to cfb5bb0 Compare November 25, 2024 16:40
@PacificYield
Copy link
Contributor Author

I think we shouldn't commit types folder

Agreed. I wanted to remain consistent. Should we remove the types altogether instead?

I think It has been commited by error, so yeah you can add it to gitignore

I removed all.

@PacificYield PacificYield self-assigned this Nov 25, 2024
@PacificYield PacificYield marked this pull request as ready for review November 26, 2024 08:11
@PacificYield PacificYield changed the title refactor: TFHEExecutor (WIP) refactor: TFHEExecutor Nov 26, 2024
@@ -2,6 +2,7 @@

pragma solidity ^0.8.24;

import "@openzeppelin/contracts/utils/Strings.sol";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you add this import?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, it is my mistake. I wanted to restrict the scope of the import but I didn't finish. I adjusted to be as such:

import {Strings} from "@openzeppelin/contracts/utils/Strings.sol";
import {TFHEExecutor} from "../contracts/TFHEExecutor.sol";

@PacificYield PacificYield force-pushed the refactor-tfhe-executor branch from cfb5bb0 to fea3f8c Compare November 26, 2024 11:08
@@ -286,7 +285,7 @@ contract TFHEExecutor is UUPSUpgradeable, Ownable2StepUpgradeable {
result = binaryOp(Operators.fheRotl, lhs, rhs, scalar, lhsType);
}

function fheRotr(uint256 lhs, uint256 rhs, bytes1 scalarByte) external returns (uint256 result) {
function fheRotr(uint256 lhs, uint256 rhs, bytes1 scalarByte) public virtual returns (uint256 result) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed this one didn't have the virtual

@PacificYield PacificYield force-pushed the refactor-tfhe-executor branch from fea3f8c to a0f4b42 Compare November 26, 2024 11:18
@PacificYield PacificYield force-pushed the refactor-tfhe-executor branch from 4fa88d5 to d9fbba9 Compare November 26, 2024 13:48
pragma solidity ^0.8.24;

import "./ACL.sol";
import "./FHEPayment.sol";
import "../addresses/ACLAddress.sol";
import "../addresses/FHEPaymentAddress.sol";
import "../addresses/InputVerifierAddress.sol";
import "@openzeppelin/contracts/utils/Strings.sol";
import {Strings} from "@openzeppelin/contracts/utils/Strings.sol";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why this kind of import?

Copy link
Contributor Author

@PacificYield PacificYield Nov 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is better to be strict for imports

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For instance, the UUPSUpgradeable was imported from the import of ACL before

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

@PacificYield PacificYield merged commit a630534 into main Nov 26, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants