From e747dd819af76bec4b20a8bf2785444336dcf53a Mon Sep 17 00:00:00 2001 From: Benoit Chevallier-Mames Date: Thu, 9 Sep 2021 13:31:01 +0200 Subject: [PATCH] doc: let's document the framework refs #143 --- docs/README.md | 6 +++--- docs/user/howto/DEBUG_SUPPORT_SUBMIT_ISSUES.md | 14 +++++++------- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/README.md b/docs/README.md index d2a5916ff..712f8ca6b 100644 --- a/docs/README.md +++ b/docs/README.md @@ -2,14 +2,14 @@ ## Introduction -ConcreteFHE, or Concrete for short, is a python package which aims to simplify the use of so-called fully homomorphic encryption (FHE) for datascientists. FHE is a new powerful cryptographic tool, which allows e.g. servers to perform computations directly on encrypted data, without needing any kind of secret key. With FHE, privacy is at the center, and one can build services which ensure full privacy of the user and are the perfect equivalent of their unsecure counterpart. FHE is also a killer feature regarding data breaches: as anything done on the server is done over encrypted data, even if the server is compromised, there is in the end no leak of any kind of useful data. +ConcreteFHE, or Concrete for short, is an open-source framework which aims to simplify the use of so-called fully homomorphic encryption (FHE) for data scientists. FHE is a new powerful cryptographic tool, which allows e.g. servers to perform computations directly on encrypted data, without needing to decrypt first. With FHE, privacy is at the center, and one can build services which ensure full privacy of the user and are the perfect equivalent of their unsecure counterpart. FHE is also a killer feature regarding data breaches: as anything done on the server is done over encrypted data, even if the server is compromised, there is in the end no leak of any kind of useful data. -Concrete framework is made of several parts: +The Concrete framework is made of several parts: - a library, called concrete-lib, which contains the core cryptographic API's for computing with FHE - a compiler, called concrete-compiler, which allows to turn an MLIR program into an FHE program, on the top of concrete-lib - some frontends, which convert different langages to MLIR, to finally be compiled. -In the first version of Concrete framework, there is a single frontend, called concrete-hnp, which is the equivalent of numpy. With our toolchain, a data scientist can convert a numpy program into an FHE program, without any a-priori knowledge on cryptography. +In the first version of Concrete framework, there is a single frontend, called homomorphic numpy (or hnp), which is the equivalent of numpy. With our toolchain, a data scientist can convert a numpy program into an FHE program, without any a-priori knowledge on cryptography. ## Organization of the documentation diff --git a/docs/user/howto/DEBUG_SUPPORT_SUBMIT_ISSUES.md b/docs/user/howto/DEBUG_SUPPORT_SUBMIT_ISSUES.md index 7660f0f73..b45a13428 100644 --- a/docs/user/howto/DEBUG_SUPPORT_SUBMIT_ISSUES.md +++ b/docs/user/howto/DEBUG_SUPPORT_SUBMIT_ISSUES.md @@ -1,6 +1,6 @@ # Debugging / Support / Submitting Issues -First, let's not forget that this version of Concrete framework is a beta product, meaning that it is not completely polished, contains several bugs (would they be known or unknown at this time). Also, let's not forget that FHE is an highly hot topic, and notably, that it cannot be considered as a solved problem. +First, let's not forget that this version of Concrete framework is a beta product, meaning that it is not completely polished, contains several bugs (would they be known or unknown at this time). Also, let's not forget that FHE is a highly hot topic, and notably, that it cannot be considered as a solved problem. Anyway, let's list some ways to debug your problems here. If nothing seems conclusive, you can still report the issue, as explained in a later section of this page. @@ -8,9 +8,9 @@ Anyway, let's list some ways to debug your problems here. If nothing seems concl If ever your numpy program fails, it may be because: - of bugs due to Concrete framework -- of bugs due to the user, notably who would not use the framework as expected or not consider the limits of the framework. +- of bugs due to the user, notably who would have a bug without even considering FHE (does the function you want to compile run well with numpy?), or who would not use the framework as expected or not consider the limits of the framework. -For the latter kind of bugs, we encourage the user to have a look to: +For the latter kind of bugs, we encourage the user to have a look at: - the error message she gets - the documentation of the product - the known limits of the product (such as the reduced set of supported operations at this time, or the limited precision of the computations). @@ -19,15 +19,15 @@ Once the user has tried to see if the bug was not her own, it is time to go furt ## Having a reproducible bug -Once you're sure it is a bug, it would be nice to try to +Once you're sure it is a bug, it would be nice to try to: - make it highly reproducible: e.g., by reducing as much the randomness as possible; e.g., if you can find an input which fails, there is no reason to let the input random -- reduce it to the smallest possible bug: it is easier to investigate bugs which are small, so when you have an issue, please try to reduce to a smaller issue, notably with less lines of code, smaller parameters, less complex function to compile, faster scripts etc +- reduce it to the smallest possible bug: it is easier to investigate bugs which are small, so when you have an issue, please try to reduce to a smaller issue, notably with less lines of code, smaller parameters, less complex function to compile, faster scripts etc. ## Asking the community We have created a Slack channel (TODO: LINK TO BE ADDED), such that you can directly ask the developpers and community about your issue. -Hopefully, it is just a misunderstanding or a small mistake on your side, that one can help you fix easily. And, the good point with your feedback is that, once we have heard the problem or misunderstanding, we can make the documentation even clearer (such as, increasing the FAQ). +Hopefully, it is just a misunderstanding or a small mistake on your side, that one can help you fix easily. And, the good point with your feedback is that, once we have heard the problem or misunderstanding, we can make the documentation even clearer (such as, completing the FAQ). ## Having a look to the compilation artifacts @@ -45,7 +45,7 @@ Attaching the artifact with your issue or Slack message may help people to have The more precise your bug, the more likely we can reproduce and fix [TODO: Umut, is it still needed or do we already have some of those information in artifacts?] -In order to simplify our work and let us reproduce your bug easily, any information is useful. Notably, in addition to the python script, some information like +In order to simplify our work and let us reproduce your bug easily, any information is useful. Notably, in addition to the python script, some information like: - the OS version - the python version - the python packages you use