Reviewerly/exHarmony huggingface dataset:
DELTA: DLT-Database Synchronization

An increasingly common application for DLTs is their exploitation in enterprise systems operated by a consortium of organizations, who may assume different roles and whose interaction takes place over a blockchain network (in this scope, often permissioned), which holds a data state that they need to query frequently. In this regard, one of the main drawbacks of DLTs is their unsuitability for the efficient execution of complex queries on the data stored by the nodes comprising the network. Arising from this issue, many solutions propose to dump the ledger contents into databases, which, due to their own nature and purpose, are certainly optimized for the execution of such queries. However, most proposals on this area are not intended for querying the shared state held by the network, just the transaction history. Actually, through conducting a study on the state of the art, a lack of support for handling and querying complex structured data has been identified. DELTA provides a solution for the synchronization, with negligible overload, of the state of a DLT into a database, enabling (a) the operation with smart contracts whose data possess a complex structure and (b) the efficient execution of elaborate queries on these data. By using DELTA, query times decrease, at least, between one and five orders of magnitude, depending on the DLT, compared to queries directed to the ledger nodes.
Toward Gaze-assisted Developer Tools

Many crucial activities in software development are linked to gaze and can potentially benefit from gaze-assisted developer tools. However, despite the maturity of eye trackers and the potential for such tools, we see very few studies of practitioners. Here, we present a systematic mapping study to examine recent developments in the field with a focus on the experimental setup of eye-tracking studies in software engineering research. We identify two gaps regarding studies of practitioners in realistic settings and three challenges in existing experimental setups. We present six recommendations for how to steer the research community toward gaze-assisted developer tools that can benefit practitioners.
Smart Contract Data Monitoring and Visualization

Blockchain technology has attracted significant industry, academic, and governmental attention since its emerged in 2008. Blockchain use cases are now being explored by traditional, transaction-oriented businesses in the finance, insurance, logistics and healthcare sectors to name a few. This has expanded further with the widespread use of Internet of Things (IoT) devices. Massive amounts of data are generated by IoT devices and are recorded in the blockchain. While blockchain provides many advantages, such as immutability and transparency, its serialized nature makes impossible to read in a single query. Multiple requests are required even for simple tasks, such as displaying an account's transaction history. This further leads to the difficulty in understanding the data in the blockchain. In this paper, we address the problem of smart contract visualization in a real-time manner. To this end, we design a visualization dashboard for smart contracts. A visual aid for massive amounts of data helps users understand the blockchain's overall activities, uncover operational risks and provide critical intelligence by visualising unusual activities and connections. Such insights may enable the user to investigate and predict any anomalies or reveal any network vulnerabilities. Cattle farm selected as a use case because the voluminous data can be acquired from IoT sensors on the farm cattle. Our dashboard has been proven to help visualize the life cycle of animals, the distribution of activities and time factor analysis. This visualization can give a user a better perspective of the token functions and results as well as animal management issues.
A Game-Theoretic Analysis of the Consistency Requirement for Permissioned Blockchains

Although BFT(Byzantine Fault Tolerance) is one of the most distinctive features of a blockchain system, many permissioned blockchains adopt RAFT as their consensus protocols, which cannot tolerate any Byzantine nodes. This paper analyzes this phenomenon base on the hypothesis of Rational Man. We propose a new consistency requirement in terms of Nash equilibrium, called NE-consistency, which requires a blockchain to guarantee consistency given that all participants are rational when choosing their strategies. We prove that both PBFT and RAFT can satisfy NE-consistency by modeling a permissioned blockchain as a repeated game. Particularly, we prove that in the sole subgame perfect equilibrium of both PBFT and RAFT, all participants tend to be good to maximize their profits.
What Warnings Do Engineers Really Fix? The Compiler That Cried Wolf

Build logs from a variety of Continuous Integration (CI) systems contain temporal data about the presence and distribution of compiler warnings. Results from the analysis and mining of that data will indicate what warnings engineers find useful and fix, or continuously ignore. The findings will include resolution times and resolution types for different warning categories. That data will help compiler developers adjust the warning levels according to the ground truth, clarify the diagnostic messages, and improve the non-actionable warnings. The empirical findings will also help engineers to decide what warnings are worth fixing and which ones are not.
Siguard: Detecting Signature-Related Vulnerabilities in Smart Contracts

Ethereum smart contract enables developers to en-force access control policies of critical functions using built-in signature verification interfaces, i.e., ecrecover. However, due to the lack of best practices for these interfaces, improper verifications commonly exist in deployed smart contracts, leaving potential unauthorized access and financial losses. Even worse, the attack surface is ignored by both developers and existing smart contract security analyzers. In this paper, we take a close look at signature-related vulnerabilities and de-mystify them with clear classification and characterization. We present Siguard, the first automatic tool to detect these vulnerabilities in real-world smart contracts. Specifically, Siguard explores signature-related paths in the smart contract and extracts data dependencies based on symbolic execution and taint analysis. Then, it conducts vulnerability detection based on a systematic search for violations of standard patterns including EIP-712 and EIP-2621. The preliminary evaluation validated the efficacy of Siguard by reporting previously unknown vulnerabilities in deployed smart contracts on Ethereum. A video of Siguard is available at https://youtu.be/xXAEhqXWOu0
Feature Toggle Usage Patterns: A Case Study on Google Chromium

Feature toggles control the state of features and allow exposing unfinished features to a reduced cohort of users without affecting the general software operation. It is basically a variable used in if conditions to control the flow of program execution. Since there is no universal standard of using feature toggles established yet, developers write code around feature toggles and use them spontaneously. Certain usage patterns of feature toggles may even lead to code smells. In this short paper I introduce six different toggle usage patterns from Google Chromium and discuss the possible reasons, consequences, and detection methods. I further conduct a mixed-method approach to analyze them. Since this study is still in progress, I report the early results only for the three most commonly appeared usage patterns. I validate the quantitative findings with the qualitative results obtained by interviewing 15 Google developers. I found that there are 3.1K toggles present in 38 components of Chromium. In the median case, nested toggles are shared by 5 different files, spread toggles span 2 different components, and dead toggles cover an average of 4 lines of code (loc).Novel aspects:- Although usage patterns of C pre-processors (#ifdefs) are studied in the past, I did not find any study particularly focusing on the run-time feature toggles usage patterns. Hence, I have been inspired to do an exploratory study to investigate different usage patterns of feature toggles. I chose Google Chromium as a case study at this point since Google developers use feature toggles extensively.
SightsTeeple: Agreeing to Disagree with Functional Blockchain Consensus

Classical and contemporary distributed consensus protocols, may they be for binary agreement, state machine replication, or blockchain consensus, require all protocol participants in a peer-to-peer system to output (agree on) exactly the same information as part of the consensus payload. Although this model of consensus is extensively studied, and is useful for most consensus based decentralized applications, it falls short of defining correct distributed systems which mandate participant credential based privileged visibility into the consensus payload, through the consensus protocol itself. We introduce a new paradigm for permissioned blockchain consensus, called functional blockchain consensus. Functional blockchain consensus allows each blockchain protocol participant to output some distinct sub-information of the list of transactions, as a function of the credentials of the participant in the blockchain system, instead of outputting the entire list of transactions. We motivate a novel rational-fault adversary to compromise functional blockchain consensus, and present a blockchain protocol called SightsTeeple, that achieves functional blockchain consensus in the said fault model. Sight-steeple relies on a novel combination of standard blockchain consensus and functional encryption, among other primitives, to achieve its goal of correctness. Further, we outline the realization of novel decentralized applications through functional blockchain consensus.
PyMigBench: A Benchmark for Python Library Migration

Developers heavily rely on Application Programming Interfaces (APIs) from libraries to build their projects. However, libraries might become obsolete, or new libraries with better APIs might become available. In such cases, developers replace the used libraries with alternative libraries, a process known as library migration. Since manually migrating between libraries is tedious and error prone, there has been a lot of effort towards automated library migration. However, most of the current research on automated library migration focuses on Java libraries, and even more so on version migrations of the same library. Despite the increasing popularity of Python, limited research has investigated migration between Python libraries. To provide the necessary data for advancing the development of Python library migration tools, this paper contributes PyMigBench, a benchmark of real Python library migrations.PyMigBench contains 59 analogous library pairs and 75 real migrations with migration-related code changes in 161 Python files across 57 client repositories.
BDSP: A Fair Blockchain-enabled Framework for Privacy-Enhanced Enterprise Data Sharing

Across industries, there is an ever-increasing rate of data sharing for collaboration and innovation between organizations and their customers, partners, suppliers, and internal teams. However, many enterprises are restricted from freely sharing data due to regulatory restrictions across different regions, performance issues in moving large volume data, or requirements to maintain autonomy. In such situations, the enterprise can benefit from the concept of federated learning, in which machine learning models are constructed at various geographic sites. In this paper, we introduce a general framework, namely BDSP, to share data among enterprises based on Blockchain and federated learning techniques. Specifically, we propose a transparency contribution accounting mechanism to estimate the valuation of data and implement a proof-of-concept for further evaluation. The extensive experimental results show that the proposed BDSP has a competitive performance with higher training accuracy, an increase of over 5%, and lower communication overhead, reducing 3 times, compared to baseline approaches.
MANDO-HGT: Heterogeneous Graph Transformers for Smart Contract Vulnerability Detection

Smart contracts in blockchains have been increasingly used for high-value business applications. It is essential to check smart contracts' reliability before and after deployment. Although various program analysis and deep learning techniques have been proposed to detect vulnerabilities in either Ethereum smart contract source code or bytecode, their detection accuracy and scalability are still limited. This paper presents a novel framework named MANDO-HGT for detecting smart contract vulnerabilities. Given Ethereum smart contracts, either in source code or bytecode form, and vulnerable or clean, MANDO-HGT custom-builds heterogeneous contract graphs (HCGs) to represent control-flow and/or function-call information of the code. It then adapts heterogeneous graph transformers (HGTs) with customized meta relations for graph nodes and edges to learn their embeddings and train classifiers for detecting various vulnerability types in the nodes and graphs of the contracts more accurately. We have collected more than 55K Ethereum smart contracts from various data sources and verified the labels for 423 buggy and 2,742 clean contracts to evaluate MANDO-HGT. Our empirical results show that MANDO-HGT can significantly improve the detection accuracy of other state-of-the-art vulnerability detection techniques that are based on either machine learning or conventional analysis techniques. The accuracy improvements in terms of F1-score range from 0.7% to more than 76% at either the coarse-grained contract level or the fine-grained line level for various vulnerability types in either source code or bytecode. Our method is general and can be retrained easily for different vulnerability types without the need for manually defined vulnerability patterns.
Tornado Vote: Anonymous Blockchain-Based Voting

Decentralized apps (DApps) often hold significant cryptocurrency assets. In order to manage these assets and coordinate joint investments, shareholders leverage the underlying smart contract functionality to realize a transparent, verifiable, and secure decision-making process. That is, DApps implement proposal-based voting. Permissionless blockchains, however, lead to a conflict between transparency and anonymity; potentially preventing free decision-making if individual votes and intermediate results become public. In this paper, we therefore present Tornado Vote, a voting DApp for anonymous, fair, and practical voting on the Ethereum blockchain. We propose to use a cryptocurrency mixer such as Tornado Cash to reconcile transparency and anonymity. To this end, we adapt Tornado Cash and develop a voting protocol that implements a fair voting process. While Tornado Vote can technically process 10 k votes on Ethereum in approximately two hours, this is not feasible under realistic conditions: Third-party transactions on the Ethereum Mainnet reduce the possible throughput, and transaction fees make it infeasible to use all available block capacities. We therefore present various Gas cost models that yield lower bounds and economic estimations with respect to the required number of blocks and voting costs to assess and adjust Tornado Vote's feasibility trade-off.
Determining Optimal Incentive Policy for Decentralized Distributed Systems Using Reinforcement Learning

Cryptocurrencies have gained a lot of attention in recent years, mostly due to their decentralized manner of operation and their growth in value. However, a major drawback most of them possess is their high energy consumption. Current solutions to this problem have significant limitations: bringing back centralization and/or substituting the required energy with, e.g., storage space. This paper aims to address the problem by investigating the use of a two-level deep reinforcement learning (RL) model to design incentive policies for green mining in cryptocurrencies. This is done by modeling one such energy-intensive cryptocurrency system and creating an RL environment. Finally, by running simulations in an RL environment, we develop and test incentive policies, according to which cryptocurrency participants who primarily use renewable energy for their mining operations are more likely to add new blocks to the blockchain. Our results show that even when the green score of each crypto miner (determined by their use of green energy sources) has relatively small importance (up to 0.3) in their selection probability, miners still shift towards green mining in order to increase their chance of being picked to validate cryptocurrency transactions and receive the corresponding rewards.
DeWS: Decentralized and Byzantine Fault-tolerant Web Services

Many real-world applications employ web service frameworks to provide application programming interface (API) services to businesses and end-consumers, following a client-server architecture. Service providers typically run a web server to deliver services to consumers. Here, service providers and consumers often belong to different organisations in applications such as supply chain management and logistics. In multi-stakeholder safety-critical and mission-critical applications, the centralised web server delivers services by executing computations upon receiving consumers' API requests. Such computations may fail due to crash or byzantine failures. The former happens because of hardware or infrastructure faults, while the latter happens because of a malicious actor. Note that the organisation that runs the web server may act dishonestly by running computations incorrectly for financial benefits, or an external attacker may compromise the web server without the knowledge of the infrastructure owner. As a result of these failures, the centralised web server is susceptible to single-point-of-failure issues. The organisation that runs the web server must be blindly trusted and does not provide transparency and auditability to its clients. We propose DeWS, a Decentralised and Byzantine Fault-tolerant Web Service framework, which overcomes these single-point-of-failure issues while delivering transparency and auditability through a blockchain-based ledger. The proof-of-concept implementation of DeWS using the Tendermint blockchain platform shows that our framework can tolerate byzantine failures at the cost of high latency. DeWS is the first Byzantine Fault-tolerant web service framework. It can support a shift towards more decentralised web services to provide safety assurances for safety-critical and mission-critical applications.
SecurShard: A Model for Hierarchical Fault Detection in Blockchain Sharding

Sharding increases concurrency in a blockchain system by splitting validators into groups (shards). Each shard processes a different transaction block such that throughput increases linearly in proportion to the number of shards. Contemporary sharding systems assume that shards are ‘perfect’. Therefore, shards need to be formed in such a way that they have negligible probability of failure. However, there are several limitations. In reality, shards can be faulty (violates the ‘perfect’ shard assumption) and an invalid block validated by a faulty shard cannot be detected until the block is appended to the blockchain. Thus, there is no fault detection mechanism during transaction processing. In this paper, we present a hierarchical fault detection model called SecurShard. The SecurShard model proposes mechanisms of combining shards into groups, one-to-all mapping of a transaction block to all shards in a group, and 100% consensus requirement to validate and append a block to blockchain; all these to ensure that a potentially invalid block is detected with high probability during transaction processing rather than after appending to blockchain. Furthermore, the mapping scheme relaxes the constraint that all shards need to be ‘perfect’. This also leads to the possible usage of smaller shards that are more performant than contemporary bigger shards while still maintaining the collective fault tolerance of the system. An elaborated theoretical analysis is presented which demonstrates the advantages of SecurShard in terms of fault tolerance and performance over traditional sharding systems.
TSVD4J: Thread-Safety Violation Detection for Java

Concurrency bugs are difficult to detect and debug. One class of concurrency bugs are thread-safety violations, where multiple threads access thread-unsafe data structure at the same time, resulting in unexpected behavior. Prior work proposed an approach TSVD to detect thread-safety violations. TSVD injects delays at API calls that read/write to specific thread-unsafe data structures, tracking whether multiple threads can overlap in their accesses to the same data structure through the delays, showing potential thread-safety violations. We additionally enhance the TSVD approach to also consider read/write operations to object fields. We implement the TSVD approach in Java in our tool TSVD4J. TSVD4J can be integrated as a Maven plugin that can be included in any Maven-based application. Our evaluation on 12 applications shows that TSVD4J can detect 55 pairs of code locations accessing the same shared data structure across multiple threads, representing potential thread-safety violations. We find that the addition of tracking field accesses contributed the most to detecting these pairs. TSVD4J also detects more such pairs than existing tool RV-Predict. The demo video for TSVD4J is available at https://www.youtube.com/watchv-wSMzlj5cMY
State of Refactoring Adoption: Better Understanding Developer Perception of Refactoring

We aim to explore how developers document their refactoring activities during the software life cycle. We call such activity Self-Affirmed Refactoring (SAR), which indicates developers’ documentation of their refactoring activities. SAR is crucial in understanding various aspects of refactoring, including the motivation, procedure, and consequences of the performed code change. After that, we propose an approach to identify whether a commit describes developer-related refactoring events to classify them according to the refactoring common quality improvement categories. To complement this goal, we aim to reveal insights into how reviewers decide to accept or reject a submitted refactoring request and what makes such a review challenging.Our SAR taxonomy and model can work with refactoring detectors to report any early inconsistency between refactoring types and their documentation. They can serve as a solid background for various empirical investigations. Our survey with code reviewers has revealed several difficulties related to understanding the refactoring intent and implications on the functional and non-functional aspects of the software. In light of our findings from the industrial case study, we recommended a procedure to properly document refactoring activities, as part of our survey feedback.