Searcharxiv⌕ Search

arXiv subjects

Mohammad Hamdaqa

Publications and source records attributed to Mohammad Hamdaqa.

32 records · Page 2Linked to original sources

Smells-sus: Sustainability Smells in IaC

Practitioners use Infrastructure as Code (IaC) scripts to efficiently configure IT infrastructures through machine-readable definition files. However, during the development of these scripts, some code patterns or deployment choices may lead to sustainability issues like inefficient resource utilization or redundant provisioning for example. We call this type of patterns sustainability smells. These inefficiencies pose significant environmental and financial challenges, given the growing scale of cloud computing. This research focuses on Terraform, a widely adopted IaC tool. Our study involves defining seven sustainability smells and validating them through a survey with 19 IaC practitioners. We utilized a dataset of 28,327 Terraform scripts from 395 open-source repositories. We performed a detailed qualitative analysis of a randomly sampled 1,860 Terraform scripts from the original dataset to identify code patterns that correspond to the sustainability smells and used the other 26,467 Terraform scripts to study the prevalence of the defined sustainability smells. Our results indicate varying prevalence rates of these smells across the dataset. The most prevalent smell is Monolithic Infrastructure, which appears in 9.67\% of the scripts. Additionally, our findings highlight the complexity of conducting root cause analysis for sustainability issues, as these smells often arise from a confluence of script structures, configuration choices, and deployment contexts.

cs.SE↗

Preventing Out-of-Gas Exceptions by Typing

We continue the development of TinySol, a minimal object-oriented language based on Solidity, the standard smart-contract language used for the Ethereum platform. We first extend TinySol with exceptions and a gas mechanism, and equip it with a small-step operational semantics. Introducing the gas mechanism is fundamental for modelling real-life smart contracts in TinySol, since this is the way in which termination of Ethereum smart contracts is usually ensured. We then devise a type system for smart contracts guaranteeing that such programs never run out of gas at runtime. This is a desirable property for smart contracts, since a transaction that runs out of gas is aborted, but the price paid to run the code is not returned to the invoker.

cs.PL↗

Immutable in Principle, Upgradeable by Design: Exploratory Study of Smart Contract Upgradeability

Smart contracts, known for their immutable nature to ensure trust via automated enforcement, have evolved to require upgradeability due to unforeseen vulnerabilities and the need for feature enhancements post-deployment. This contradiction between immutability and the need for modifications has led to the development of upgradeable smart contracts. These contracts are immutable in principle yet upgradable by design, allowing updates without altering the underlying data or state, thus preserving the contract's intent while allowing improvements. This study aims to understand the application and implications of upgradeable smart contracts on the Ethereum blockchain. By introducing a dataset that catalogs the versions and evolutionary trajectories of smart contracts, the research explores key dimensions: the prevalence and adoption patterns of upgrade mechanisms, the likelihood and occurrences of contract upgrades, the nature of modifications post-upgrade, and their impact on user engagement and contract activity. Through empirical analysis, this study identifies upgradeable contracts and examines their upgrade history to uncover trends, preferences, and challenges associated with modifications. The evidence from analyzing over 44 million contracts shows that only 3% have upgradeable characteristics, with only 0.34% undergoing upgrades. This finding underscores a cautious approach by developers towards modifications, possibly due to the complexity of upgrade processes or a preference for maintaining stability. Furthermore, the study shows that upgrades are mainly aimed at feature enhancement and vulnerability mitigation, particularly when the contracts' source codes are accessible. However, the relationship between upgrades and user activity is complex, suggesting that additional factors significantly affect the use of smart contracts beyond their evolution.

cs.SE↗

PathOCL: Path-Based Prompt Augmentation for OCL Generation with GPT-4

The rapid progress of AI-powered programming assistants, such as GitHub Copilot, has facilitated the development of software applications. These assistants rely on large language models (LLMs), which are foundation models (FMs) that support a wide range of tasks related to understanding and generating language. LLMs have demonstrated their ability to express UML model specifications using formal languages like the Object Constraint Language (OCL). However, the context size of the prompt is limited by the number of tokens an LLM can process. This limitation becomes significant as the size of UML class models increases. In this study, we introduce PathOCL, a novel path-based prompt augmentation technique designed to facilitate OCL generation. PathOCL addresses the limitations of LLMs, specifically their token processing limit and the challenges posed by large UML class models. PathOCL is based on the concept of chunking, which selectively augments the prompts with a subset of UML classes relevant to the English specification. Our findings demonstrate that PathOCL, compared to augmenting the complete UML class model (UML-Augmentation), generates a higher number of valid and correct OCL constraints using the GPT-4 model. Moreover, the average prompt size crafted using PathOCL significantly decreases when scaling the size of the UML class models.

cs.SE↗

PrAIoritize: Automated Early Prediction and Prioritization of Vulnerabilities in Smart Contracts

Context:Smart contracts are prone to numerous security threats due to undisclosed vulnerabilities and code weaknesses. In Ethereum smart contracts, the challenges of timely addressing these code weaknesses highlight the critical need for automated early prediction and prioritization during the code review process. Efficient prioritization is crucial for smart contract security. Objective:Toward this end, our research aims to provide an automated approach, PrAIoritize, for prioritizing and predicting critical code weaknesses in Ethereum smart contracts during the code review process. Method: To do so, we collected smart contract code reviews sourced from Open Source Software (OSS) on GitHub and the Common Vulnerabilities and Exposures (CVE) database. Subsequently, we developed PrAIoritize, an innovative automated prioritization approach. PrAIoritize integrates advanced Large Language Models (LLMs) with sophisticated natural language processing (NLP) techniques. PrAIoritize automates code review labeling by employing a domain-specific lexicon of smart contract weaknesses and their impacts. Following this, feature engineering is conducted for code reviews, and a pre-trained DistilBERT model is utilized for priority classification. Finally, the model is trained and evaluated using code reviews of smart contracts. Results: Our evaluation demonstrates significant improvement over state-of-the-art baselines and commonly used pre-trained models (e.g. T5) for similar classification tasks, with 4.82\%-27.94\% increase in F-measure, precision, and recall. Conclusion: By leveraging PrAIoritize, practitioners can efficiently prioritize smart contract code weaknesses, addressing critical code weaknesses promptly and reducing the time and effort required for manual triage.

cs.SE↗

Dissecting Smart Contract Languages: A Survey

Blockchain is a distributed ledger technology that gained popularity for enabling the transformation of cryptocurrency among peers without mediation by a centralized third-party authority. Smart contracts expand the applications of blockchain technology and have played a role in its widespread adoption. Smart contracts are immutable digital programs that are deployed on blockchains to codify agreements between parties. Existing smart contract implementations have faced challenges, including security vulnerabilities, leading to significant losses and concerns. This has stimulated a wave of attempts to improve Smart Contract Languages (SCLs) to overcome implementation challenges and ensure code quality, producing many languages with diverse features. Scholars have made some attempts to classify SCLs and clarify the process of selecting an SCL, but to the best of our knowledge, no comprehensive survey of existing SCLs has been published. Our work surpasses earlier efforts by evaluating a significantly larger set of SCLs, in greater depth, to ease the process of SCL selection for blockchain research and implementation. In this paper, we (1) propose a robust framework for comparing existing SCLs, (2) analyze and discuss 36 SCLs, addressing issues beyond those used to construct the comparison framework, and (3) define new parameters for future research and development of SCLs. The survey provides a guide for those who intend to select or use an SCL to implement smart contracts, develop new SCLs, or add new extensions to the existing SCLs.

cs.CR↗

Exploring Security Practices in Infrastructure as Code: An Empirical Study

Cloud computing has become popular thanks to the widespread use of Infrastructure as Code (IaC) tools, allowing the community to conveniently manage and configure cloud infrastructure using scripts. However, the scripting process itself does not automatically prevent practitioners from introducing misconfigurations, vulnerabilities, or privacy risks. As a result, ensuring security relies on practitioners understanding and the adoption of explicit policies, guidelines, or best practices. In order to understand how practitioners deal with this problem, in this work, we perform an empirical study analyzing the adoption of IaC scripted security best practices. First, we select and categorize widely recognized Terraform security practices promulgated in the industry for popular cloud providers such as AWS, Azure, and Google Cloud. Next, we assess the adoption of these practices by each cloud provider, analyzing a sample of 812 open-source projects hosted on GitHub. For that, we scan each project configuration files, looking for policy implementation through static analysis (checkov). Additionally, we investigate GitHub measures that might be correlated with adopting these best practices. The category Access policy emerges as the most widely adopted in all providers, while Encryption in rest are the most neglected policies. Regarding GitHub measures correlated with best practice adoption, we observe a positive, strong correlation between a repository number of stars and adopting practices in its cloud infrastructure. Based on our findings, we provide guidelines for cloud practitioners to limit infrastructure vulnerability and discuss further aspects associated with policies that have yet to be extensively embraced within the industry.

cs.CR↗

Smart Contract Upgradeability on the Ethereum Blockchain Platform: An Exploratory Study

Context: Smart contracts are computerized self-executing contracts that contain clauses, which are enforced once certain conditions are met. Smart contracts are immutable by design and cannot be modified once deployed, which ensures trustlessness. Despite smart contracts' immutability benefits, upgrading contract code is still necessary for bug fixes and potential feature improvements. In the past few years, the smart contract community introduced several practices for upgrading smart contracts. Upgradeable contracts are smart contracts that exhibit these practices and are designed with upgradeability in mind. During the upgrade process, a new smart contract version is deployed with the desired modification, and subsequent user requests will be forwarded to the latest version (upgraded contract). Nevertheless, little is known about the characteristics of the upgrading practices, how developers apply them, and how upgrading impacts contract usage. Objectives: This paper aims to characterize smart contract upgrading patterns and analyze their prevalence based on the deployed contracts that exhibit these patterns. Furthermore, we intend to investigate the reasons why developers upgrade contracts (e.g., introduce features, fix vulnerabilities) and how upgrades affect the adoption and life span of a contract in practice. Method: We collect deployed smart contracts metadata and source codes to identify contracts that exhibit certain upgrade patterns (upgradeable contracts) based on a set of policies. Then we trace smart contract versions for each upgradable contract and identify the changes in contract versions using similarity and vulnerabilities detection tools. Finally, we plan to analyze the impact of upgrading on contract usage based on the number of transactions received and the lifetime of the contract version.

cs.SE↗

On Codex Prompt Engineering for OCL Generation: An Empirical Study

The Object Constraint Language (OCL) is a declarative language that adds constraints and object query expressions to MOF models. Despite its potential to provide precision and conciseness to UML models, the unfamiliar syntax of OCL has hindered its adoption. Recent advancements in LLMs, such as GPT-3, have shown their capability in many NLP tasks, including semantic parsing and text generation. Codex, a GPT-3 descendant, has been fine-tuned on publicly available code from GitHub and can generate code in many programming languages. We investigate the reliability of OCL constraints generated by Codex from natural language specifications. To achieve this, we compiled a dataset of 15 UML models and 168 specifications and crafted a prompt template with slots to populate with UML information and the target task, using both zero- and few-shot learning methods. By measuring the syntactic validity and execution accuracy metrics of the generated OCL constraints, we found that enriching the prompts with UML information and enabling few-shot learning increases the reliability of the generated OCL constraints. Furthermore, the results reveal a close similarity based on sentence embedding between the generated OCL constraints and the human-written ones in the ground truth, implying a level of clarity and understandability in the generated OCL constraints by Codex.

cs.SE↗

AutoMESC: Automatic Framework for Mining and Classifying Ethereum Smart Contract Vulnerabilities and Their Fixes

Due to the risks associated with vulnerabilities in smart contracts, their security has gained significant attention in recent years. However, there is a lack of open datasets on smart contract vulnerabilities and their fixes that allows for data-driven research. Towards this end, we propose an automated method for mining and classifying Ethereum's smart contract vulnerabilities and their corresponding fixes from GitHub and from the Common Vulnerabilities and Exposures (CVE) records in the National Vulnerability Database. We implemented the proposed method in a fully automated framework, which we call AutoMESC. AutoMESC uses seven of the most well-known smart contract security tools to classify and label the collected vulnerabilities based on vulnerability types. Furthermore, it collects metadata that can be used in data-intensive smart contract security research (e.g., vulnerability detection, vulnerability classification, severity prediction, and automated repair). We used AutoMESC to construct a sample dataset and made it publicly available. Currently, the dataset contains 6.7K smart contracts' vulnerability-fix pairs written in Solidity. We assess the quality of the constructed dataset in terms of accuracy, provenance, and relevance, and compare it with existing datasets. AutoMESC is designed to collect data continuously and keep the corresponding dataset up-to-date with newly discovered smart contract vulnerabilities and their fixes from GitHub and CVE records.

cs.CR↗

A Fly in the Ointment: An Empirical Study on the Characteristics of Ethereum Smart Contracts Code Weaknesses and Vulnerabilities

Context: Smart contracts are computer programs that are automatically executed on the blockchain. Vulnerabilities in their implementation have led to severe loss of cryptocurrency. Smart contracts become immutable when deployed to the Ethereum blockchain. Therefore, it is essential to understand the nature of vulnerabilities in Ethereum smart contracts to prevent them in the future. Existing classifications exist, but are limited in several ways. Objective: We aim to characterize vulnerabilities in Ethereum smart contracts written in Solidity, and unify existing classifications schemes. Method: We extracted 2143 vulnerabilities from public coding platforms and popular vulnerability databases and categorized them using a card sorting approach. We targeted the Ethereum blockchain in this paper, as it is the first and most popular blockchain to support the deployment of smart contracts, and Solidity as the most widely used language to implement smart contracts. We devised a classification scheme of smart contract vulnerabilities according to their error source and impact. Afterwards, we mapped existing classification schemes to our classification. Results: The resulting classification consists of 11 categories describing the error source of a vulnerability and 13 categories describing potential impacts. Our findings show that the language specific coding and the structural data flow categories are the dominant categories, but that the frequency of occurrence differs substantially between the data sources. Conclusions: Our findings enable researchers to better understand smart contract vulnerabilities by defining various dimensions of the problem and supporting our classification with mappings with literature-based classifications and frequency distributions of the defined categories.

cs.CR↗

Chat2Code: Towards conversational concrete syntax for model specification and code generation, the case of smart contracts

The revolutionary potential of automatic code generation tools based on Model-Driven Engineering (MDE) frameworks has yet to be realized. Beyond their ability to help software professionals write more accurate, reusable code, they could make programming accessible for a whole new class of non-technical users. However, non-technical users have been slow to embrace these tools. This may be because their concrete syntax is often patterned after the operations of textual or graphical interfaces. The interfaces are common, but users would need more extensive, precise and detailed knowledge of them than they can be assumed to have, to use them as concrete syntax. Conversational interfaces (chatbots) offer a much more accessible way for non-technical users to generate code. In this paper, we discuss the basic challenge of integrating conversational agents within Model-Driven Engineering (MDE) frameworks, then turn to look at a specific application: the auto-generation of smart contract code in multiple languages by non-technical users, based on conversational syntax. We demonstrate how this can be done, and evaluate our approach by conducting user experience survey to assess the usability and functionality of the chatbot framework.

cs.SE↗

iContractBot: A Chatbot for Smart Contracts' Specification and Code Generation

Recently, Blockchain technology adoption has expanded to many application areas due to the evolution of smart contracts. However, developing smart contracts is non-trivial and challenging due to the lack of tools and expertise in this field. A promising solution to overcome this issue is to use Model-Driven Engineering (MDE), however, using models still involves a learning curve and might not be suitable for non-technical users. To tackle this challenge, chatbot or conversational interfaces can be used to assess the non-technical users to specify a smart contract in gradual and interactive manner. In this paper, we propose iContractBot, a chatbot for modeling and developing smart contracts. Moreover, we investigate how to integrate iContractBot with iContractML, a domain-specific modeling language for developing smart contracts, and instantiate intention models from the chatbot. The iContractBot framework provides a domain-specific language (DSL) based on the user intention and performs model-to-text transformation to generate the smart contract code. A smart contract use case is presented to demonstrate how iContractBot can be utilized for creating models and generating the deployment artifacts for smart contracts based on a simple conversation.

cs.SE↗

EnHMM: On the Use of Ensemble HMMs and Stack Traces to Predict the Reassignment of Bug Report Fields

Bug reports (BR) contain vital information that can help triaging teams prioritize and assign bugs to developers who will provide the fixes. However, studies have shown that BR fields often contain incorrect information that need to be reassigned, which delays the bug fixing process. There exist approaches for predicting whether a BR field should be reassigned or not. These studies use mainly BR descriptions and traditional machine learning algorithms (SVM, KNN, etc.). As such, they do not fully benefit from the sequential order of information in BR data, such as function call sequences in BR stack traces, which may be valuable for improving the prediction accuracy. In this paper, we propose a novel approach, called EnHMM, for predicting the reassignment of BR fields using ensemble Hidden Markov Models (HMMs), trained on stack traces. EnHMM leverages the natural ability of HMMs to represent sequential data to model the temporal order of function calls in BR stack traces. When applied to Eclipse and Gnome BR repositories, EnHMM achieves an average precision, recall, and F-measure of 54%, 76%, and 60% on Eclipse dataset and 41%, 69%, and 51% on Gnome dataset. We also found that EnHMM improves over the best single HMM by 36% for Eclipse and 76% for Gnome. Finally, when comparing EnHMM to Im.ML.KNN, a recent approach in the field, we found that the average F-measure score of EnHMM improves the average F-measure of Im.ML.KNN by 6.80% and improves the average recall of Im.ML.KNN by 36.09%. However, the average precision of EnHMM is lower than that of Im.ML.KNN (53.93% as opposed to 56.71%).

cs.SE↗