dataesr/scientific-paragraphs-categorization huggingface dataset:
Patients signed informed consent; • Luminal cohort (n=42) included residual breast tumors after treatment with neoadjuvant chemotherapy. Patients signed a form of nonopposition to research. Study ethics approval was obtained on 17 January 2019 (CECIC Rhône-Alpes-Auvergne, Grenoble, IRB 5921). mRNAseq Total cellular RNA was extracted from cell lines using RNeasy kit (Qiagen), and mRNA was purified using Oligotex mRNA kit (Qiagen). cDNA librairies were then generated following the GS-FLX Titanium cDNA Rapid Library Preparation Method Manual (Roche). Finally, emPCR amplification and 454 sequencing were performed according to the manufacturer's protocol (emPCR Amplification Manual-Lib-L LV and Sequencing Method Manual-GS FLX Titanium Series, Roche). Sequence reads were aligned on the human genome (hg19) with GS Reference Mapper software (Roche) and mapped on the human exome using an home-made software named AGSA  (15).
TCGA data analysis Both clinical and RNA sequencing data (Illumina HiSeq RNAseq Version 2 data) of invasive breast cancers were downloaded from The Cancer Genome Atlas (TCGA) database. A total of 449 patients with information on estrogen receptor (ER), progesterone receptor (PR) and human epidermal growth factor receptor -2 (HER2) status was selected to compare gene expression profiles. 71 cases were found to have a negative ER, PR end HER2 phenotype (i. e. , triplenegative), whereas 371 cases were positive for at least one of these receptors.
The invasive and migratory abilities of cells were tested in Boyden chambers, with or without addition of Matrigel, respectively (Figure  3A  and 3B ). The luminal MCF7 cells had very low migratory and invasive capacity, whereas the MDA-MB21 and Sequence reads were aligned on the human genome (hg19) normalized in reads per kilobase per million mapped reads (RPKM). B. RhoA and RhoB expression in breast cancer cell lines was confirmed by q-RT-PCR. C. Cell proteins were extracted and Western Blot was performed using mouse monoclonal anti-RhoA (Santa Cruz) and rabbit polyclonal anti-RhoB (Santa Cruz) antibodies. Quantification of western blot was performed using ImageJ software and presented in the table under the blots. HCC1937 basal-like cells showed high numbers of migrant and invasive cells.
Inhibition of RhoA by RNA interference significantly decreased both the migratory and invasive abilities of the basal-like cell lines. Treatment with a RhoB-directed siRNA significantly increased invasion of both basal-like cell lines and migration of MDA-MB-231. Using an assay for wound healing (Figure  S3 ), we confirmed antagonistic effects of RhoA (inducer) and RhoB (inhibitor) in the migratory and invasive properties of basal-like breast cancer cells, with no effect on luminal MCF7 cells. RNA was extracted from cryopreserved tumors using AllPrep DNA/RNA kit (Qiagen). Rho expression was analysed by qRT-PCR using TaqMan gene expression inventoried assay. TN: triple negative. Since data is highly non-normal and heteroscedastic, ANOVA was performed after elimination of outliers and log-transformation.
There is a statistically significant difference between the three groups as determined by one-way Welch's ANOVA (Welch's F (2, 61. 3) = 29. 7, p< 0. 001). Games-Howell posthoc test shows that the TN cohorts 1 and 2 differ significantly from the luminal cohort (p< 0. 001 and p = 0. 001 respectively); the difference between the two TN cohorts is not statistically significantly different (p=0. 4). B. The Cancer Genome Atlas (TCGA) data are presented as reads per kilobase per million mapped reads (RPKM) values. TNBC: triple negative breast cancers. Again since data is highly non-normal and heteroscedastic, ANOVA was performed after elimination of outliers and log-transformation. There is a statistically significant difference between the two groups as determined by one-way Welch's ANOVA (Welch's F (1, 98) = 118.
Figure2. Rho expression in triple negative breast tumors. A. RNA was extracted from cryopreserved tumors using AllPrep DNA/RNA kit (Qiagen). Rho expression was analysed by qRT-PCR using TaqMan gene expression inventoried assay. TN: triple negative. Since data is highly non-normal and heteroscedastic, ANOVA was performed after elimination of outliers and log-transformation. There is a statistically significant difference between the three groups as determined by one-way Welch's ANOVA (Welch's F (2, 61. 3) = 29. 7, p< 0. 001). Games-Howell posthoc test shows that the TN cohorts 1 and 2 differ significantly from the luminal cohort (p< 0. 001 and p = 0. 001 respectively); the difference between the two TN cohorts is not statistically significantly different (p=0. 4). B. The Cancer Genome Atlas (TCGA) data are presented as reads per kilobase per million mapped reads (RPKM) values.
In the context of blockchain, a smart contract is a immutable computer program stored in the blockchain and executed by some of its nodes. The smart contract is usually written in a high-level language such as Solidity or Vyper, and then it is compiled down to the bytecode that runs on the blockchain like Ethereum Virtual Machine (EVM) in Ethereum blockchain. Other blockchain platforms can create and run smart contracts written by different high-level languages. For example, the Hyperledger Fabric  [16]  is a permissioned blockchain infrastructure, contributed by IBM and Digital Asset. Hyperledger Fabric provides execution of Smart Contracts called "chain code", written in a Golang and javascript  [17]. Also, Tezos is a blockchain-based cryptocurrency and a smart contracts platform for building decentralized applications (dApps)  [18].
A smart contract is a computer program represented by its source code. It can implement automatically the content of a separate agreement expressed in natural language. Smart Contracts are often written using high-level languages such as Solidity (see figure  2 ), then are compiled into bytecode and embedded in self-contained that can be deployed in any node in the Blockchain. Due to the losses caused by uncorrected smart contracts, the verification of smart contracts is mandatory to avoid the failures and vulnerabilities. In the next section, we present several reasons to show why smart contracts should be verified before the deployment on Blockchain.
This work is helpful for researchers that would start working with the formal verification and the vulnerabilities detection of smart contracts. We briefly explain some notions mentioned in this survey. Bytecode refers to the list of byte-size integers that serve as instructions for the Ethereum Virtual Machine (EVM). Source code refers to a program in a high-level programming language, here Solidity. Static analysis refers to a class of methods that examine the source code or bytecode of a contract without executing it. Dynamic analysis means to observe a contract while executing (parts of) it in the original context. Disassembling means to translate EVM bytecode into better readable assembly language, where machine operations and storage addresses are represented symbolically. Decompilation is the process of transforming EVM bytecode to a more compact representation on a higher abstraction level (like intermediate or Solidity code) to enhance the readability of the code or to ease data flow analysis.
Basic block is a sequence of statements without branches. Control flow graph (CFG) is a directed graph, where the basic blocks of a program serve as the nodes. An arc connects node A with node B if it is possible that block B gets executed immediately after block A. The arc may be labeled by the condition under which this path is chosen. Abstract Syntax Tree (AST) represents the syntactic structure of Solidity code as a tree. It occurs as an intermediate product when compiling Solidity to bytecode. Often, it is better suited for analyzing Solidity code. Execution trace is the sequence of instructions (possibly including additional information) executed during a particular run of the code. Transformation from a stack to a register-oriented view is a particular de-compilation technique that replaces stack-oriented instructions of the Ethereum Virtual Machine by instructions operating on registers.
The basic blocks are further divided into different types, depending on the last instruction of the block. The types are Terminal, Jump, Jumpi, and Next  [42]. When the basic blocks are obtained, the program logic is created using Hoare logic, which has Hoare triple designed for program correctness. As a result, a framework was created for expressing the EVM bytecode using logic, which is necessary in order to use a theorem prover for verification. The entire verification procedure was successfully applied to a case study. However, the framework does not support the full syntax of Solidity. For instance, loops and the message calls to other contracts are currently not supported.
The FSPVM-E has three main parts  [46] : GERM a formal memory framework that supports different formal verification specifications at the code level; Lolisa an extensible formal intermediate programming language, and FEther a formally verified interpreter for Lolisa. These parts work conjointly: GERM simulates the physical memory hardware structure, Lolisa is a large subset of the Solidity programming language mechanized in Coq, and finally, FEther the virtual execution engine to symbolically execute and verify the formal version of smart contracts in FSPVM-E.
F* Translation In cooperation between Microsoft Research and Harvard University, a framework is done to analyze and formally verify Ethereum smart contracts using F* functional programming language  [37]   [47]. Such contracts are generally written in Solidity  [48]  and compiled down to the Ethereum Virtual Machine (EVM) byte-code. In  [37]  they develop a language-based approach for verifying smart contracts. Two prototype tools based on F* are presented and a smart contract verification architecture is proposed and illustrated in figure  4. The contracts The two tools are Solidity* and EVM*. Solidity* is a tool that compiles Solidity contracts into F*  [37]  in order to verify, at the source level, functional correctness specifications and safety with respect to runtime errors. The figure  5  show a simple solidity code translated by F* to Solidity*.
Model Checking Given a finite-state model of a system and a formal property, model checking is an automated technique that systematically checks whether this property holds for that model  [50]. The verification is done with model checking software like NuSMV, SPIN, etc. The model checker checks automatically if each state of the model satisfies the specifications given by the user. In case that there is a property not satisfied, the model checker provides a counterexample that can help us to identify mistakes and to correct bugs. On the other hand, if each state of the model satisfies the specification, the model is formally verified for that specific property. The figure  6  shows the procedure of the model checker. We can summarize the procedure of the model checking by the following steps  [50] : i.
Model checking for smart contracts (MCSC) This work aims at establishing a generic modeling method of Ethereum application to apply a model-checking approach on smart contracts and its execution environment  [51]. The proposed model is written in NuSMV input language  [52]  and the properties to check are formalized into temporal logic CTL (Computation Tree Logics)  [53]. It has three components: the kernel layer that captures the (Ethereum) blockchain behavior, the application layer that models the smart contracts themselves (Translation rules from Solidity to NuSMV language have been provided to build the application layer), and the environment layer that determines an execution framework for the application  [51]. To check whether the contracts behave as they are supposed to do, expected properties of the application have to be formalized into temporal logic.
VERISOL (Verifier for Solidity) VERISOL (Verifier for Solidity)  [29]  it aims at prototyping a formal verification and analysis system for smart contracts developed using the Solidity programming language. It is based on translating programs written in Solidity language into programs in Boogie intermediate verification language, and then leveraging and extending the verification tool chain for Boogie programs. According to  [29] , the verifier "VeriSol" is built on the Boogie tool chain, because it can be used for both verification and counter-example generation. VERISOL takes as input a Solidity contract annotated with assertions, and then it yields one of the following three outcomes: fully verified, that means that the assertions in the contract are guaranteed not to fail under any usage scenario.
refuted that indicates at least one input and invocation sequence of the contract functions under which one of the assertions is guaranteed to fail. partially verified, that is the case when VERISOL can neither verify nor refute contract correctness. It performs bounded verification to establish that the contract is safe up to k transactions. As shown in figure  7 , VERISOL has three modules, namely (a) Boogie Translation from a Solidity program, (b) Invariant Generation to infer a contract invariant as well as loop invariants and procedure summaries, and (c) Bounded Model Checking. If VERISOL fails to verify contract correctness using monomial predicate abstraction, it employs an assertion directed bounded verifier, namely CORRAL, to look for a transaction sequence leading to an assertion violation  [29].
The results of applied smart contracts in VERISOL verifier are relatively good for simple contracts. But according to the table of results in  [29] , the number of lines of Solidity code increases after the instrumentation (in average 159 versus 79 before the instrumentation). In addition, VERISOL finds bugs in 4 of 11 well-tested contracts and precisely pinpoints the trace leading to the violation, but the researchers did not mention the running time of VERISOL when it applied on original contracts. This leads us to conclude that VERISOL is not suitable for complex contracts.
VeriSolid VeriSolid  [60]  is an open-source and web-based framework that is built on top of We-bGME  [61]  and FSolidM  [62]. The VeriSolid framework introduces formal verification capabilities, by providing an approach for correct-by-design development of smart contracts. First, the tool generates an augmented transition system from an initial transition system, based on the operational semantics of supported Solidity statements. Second, a Behavior Interaction-Priority (BIP) model of the contract is automatically generated from the augmented transition system. Then, the specified properties are automatically translated to Computational Tree Logic (CTL)  [63]. The verification of safety and liveness properties of the model can be verified using the BIP-to-NuSMV tool  [55] , to translate the BIP to NuSMV, the input language of the nuXmv symbolic model checker )  [52].
Formal Modeling and Verification of Smart Contracts (FMVSC) The method in  [64]  aims to combine the formal methods and smart contracts to reduce potential errors and costs during the contract development process. A general smart contract template is provided from applying formal methods to smart contracts( it can be represented by tuple and finite state machine). They used the PROMELA  [65]  (Process Meta Language) to model a shopping smart contract (SSC) and then the model is verified by the model checking SPIN  [65]  to verify the correctness and important properties of this model.
Oyente OYENTE is a static analysis tool that detects security vulnerabilities. Designed by Luu et all. [71] , it is one of the earliest security tools for Solidity smart contracts. OYENTE tool uses symbolic execution to check for the following vulnerabilities: transaction ordering dependency, reentrancy, timestamp dependence, and unhandled exceptions. The tool takes as input the bytecode of a smart contract and a state of the Ethereum blockchain. The Ethereum global state provides the initialized (or current) values of contract variables, thus enabling more precise analysis. Oyente consists of four main components  [71] , namely CFGBuilder, Explorer, CoreAnalysis and Validator. An illustration of the Oyente Workflow can be seen in Figure  9. CFGBuilder builds a control flow graph from the smart contract bytecode, where nodes are basic execution blocks, and edges represent execution jumps between the blocks.
MAIAN The authors of  [72]  built a dynamic tool to analyze contracts to find vulnerabilities across long sequences of invocations of a contract. This tool extends the Oyente approach  [71]. It can find the vulnerabilities directly from the bytecode of Ethereum smart contracts, without requiring source code access. In this context, the smart contracts are divided in three categories: greedy contracts, prodigal contracts, and suicidal contracts. The greedy contracts can lock funds by being unable to send Ether, while the prodigal ones can leak Ether to a user they have never interacted with. The suicidal contracts can kill the contract or force it to execute the suicide instruction. MAIAN uses systematic techniques to find the violations of the defined specific properties of traces in smart contract executions.
SmartCheck SmartCheck  [73]  analyzes the high-level solidity source code of the smart contract to find vulnerabilities using static analysis. It is also able to find a wide range of vulnerabilities, such as the Re-entrancy. SmartCheck uses the Extensible Markup Language (XML) syntax tree  [74]  to convert the solidity contract in an intermediate representation (IR). The vulnerabilities are specified as XQuery path expressions that are used to search the vulnerability patterns in the Extensible Markup Language tree by using XPath queries on the intermediate representation. The complex rules cannot be precisely described with XPath, which leads to false positives. SmartCheck is written in Java with a command-line version that is available on Github.
Slither Slither  [75]  is a static analysis framework designed to provide granular information about smart contract code. There are four use-cases provided by Slither framework (according to  [75] ): 1) Automated vulnerability detection that detects smart contract bugs without user intervention. 2) Automated optimization detection that detects code optimizations. 3) Code understanding, to improve the user's knowledge of the contracts and 4) Assisted code review, which allows users to interact with Slither. Slither analyzes in a multistage procedure using static analysis. Solidity compiler generates the Solidity Abstract Syntax Tree (AST) from the contract source code; then Slither takes it as initial inputs. Slither recovers essential information in the first stage, such as the contract's inheritance graph, the control flow graph (CFG), and the list of expressions.
Gasper A static analysis tool named GASPER was developed by Chen and al. [77]  that focus on gas costly patterns from the existing smart contracts instead of the vulnerabilities. Gasper looks for patterns such as dead code or expensive operations in loops to help contract developers reduce gas costs. The authors of  [77]  identified 7 gas-costly patterns. Gasper takes the bytecode as input to identify gas costly patterns. Gasper builds a control flow graph from the EVM bytecode. Using the symbolic execution, Gasper finds all the reachable code blocks in a candidate smart contract. First, Gasper disassembles its bytecode to construct the control flow graph (CFG) of the smart contract. Then, symbolic execution starts from the root node of the CFG and traverses the CFG. If a conditional jump is found, GASPER checks its feasibility by querying the Z3 SMT-solver.
Mythril Mythril  [78]  is a static security analysis tool for Ethereum smart contracts. It analyzes the smart contracts interactively using the symbolic execution of backend LASER-Ethereum. Then, the tool visualizes the CFG with the nodes containing disassembled code and the edges being labeled by path formulas. A SMT-solver Z3 is used to exploiting the potential vulnerabilities. Mythril can detect 8 types of vulnerabilities, such as the manipulated balance vulnerability, the authentication through tx. origin vulnerability, Unchecked call, Unchecked math, and others.
Osiris Osiris  [79]  is a static analysis tool that combines symbolic execution and taints analysis to detect integer bugs in Solidity smart contracts. It has evaluated according to a large experimental dataset containing more than 1. 2 million smart contracts. The tool covers three different types of integer bugs: arithmetic bugs, truncation bugs, and signedness bugs. Taint analysis is a technique that consists of tracking the propagation of data across the control flow of a program and used by numerous integer error detection tools to reduce the number of false positives  [80]. It works at bytecode level and consists of three components: symbolic analysis, taint analysis, and integer error detection (see Figure  11 ). The symbolic analysis constructs a Control Flow Graph (CFG) and executes the different paths of the contract.
Ethir Based on the rule-based representations of the control flow graphs (CFG) produced by the OYENTE tool  [71] , Ehtir  [85]  analyze sthe smart contracts statically. Unlike oyente, Ethir includes all possible jump addresses. It disassembles the given bytecode and constructs a CFG. Then, The basic blocks are transformed from a stack to a register-oriented view. The control flow is represented as guarded rules to examine the conditional and unconditional jump instructions by the high-level static analyzer SACO (Static Analyzer for Concurrent Objects).
It then infers facts from the contract, such as data and control-flow dependencies. Finally, the security patterns are coded as DataLog rules and check it against its facts. GRECH. and all  [87]  provide MadMax, a static program analysis technique to detect gas-related vulnerabilities the integer overflows vulnerabilities automatically. It is the first tool to detect so-called unbounded mass operations where a loop is bounded by a dynamic property such as the number of users, causing the contract to always run out of gas passed a certain number of users. MadMax uses the analysis pipeline and takes the EVM bytecode as input to convert it into an intermediate representation. The main MadMax analysis operates on the output of the Vandal decompiler using logic-based specifications then it encodes properties of the smart contract into Datalog  [82].
ContractFuzzer A dynamic tool called ContractFuzzer  [89]  used Fuzz testing to detect vulnerabilities in smart contracts. This tool contains an offline EVM instrumentation tool (the responsible for instrumenting the EVM) and an online fuzzing tool (which can monitor the execution of smart contracts to extract information for vulnerability analysis). The ContractFuzzer tool analyzes the ABI interface and the bytecode of the smart contract. Then, it extracts the data types of each argument of ABI functions as well as the signatures of the functions used in each ABI function. In addition to this, ContractFuzzer performs the ABI signature analysis and indexes all smart contracts crawled from Ethereum. Then, the ContractFuzzer generates inputs for the contracts based on the application binary interface (ABI).