The blockchain technology has potential applications in various areas such as smart-contracts, Internet of Things (IoT), land registry, supply chain management, storing medical data, and identity management. Although the Github currently hosts more than six thousand active Blockchain software (BCS) projects, few software engineering research has investigated these projects and its' contributors. Although the number of BCS projects is growing rapidly, the motivations, challenges, and needs of BCS developers remain a puzzle. Therefore, the primary objective of this study is to understand the motivations, challenges, and needs of BCS developers and analyze the differences between BCS and non-BCS development. On this goal, we sent an online survey to 1,604 active BCS developers identified via mining the Github repositories of 145 popular BCS projects. The survey received 156 responses that met our criteria for analysis. The results suggest that the majority of the BCS developers are experienced in non-BCS development and are primarily motivated by the ideology of creating a decentralized financial system. Although most of the BCS projects are Open Source Software (OSS) projects by nature, more than 93% of our respondents found BCS development somewhat different from a non-BCS development as BCS projects have higher emphasis on security and reliability than most of the non-BCS projects. Other differences include: higher costs of defects, decentralized and hostile environment, technological complexity, and difficulty in upgrading the software after release. Software development tools that are tuned for non-BCS development are inadequate for BCS and the ecosystem needs an array of new or improved tools, such as: customized IDE for BCS development tasks, debuggers for smart-contracts, testing support, easily deployable simulators, and BCS domain specific design notations.
Florentin Guth, Valentin Wüstholz, Maria Christakis, Péter Müller
Smart contracts are programs that manage digital assets according to a certain protocol, expressing for instance the rules of an auction. Understanding the possible behaviors of a smart contract is difficult, which complicates development, auditing, and the post-mortem analysis of attacks. This paper presents the first specification mining technique for smart contracts. Our technique extracts the possible behaviors of smart contracts from contract executions recorded on a blockchain and expresses them as finite automata. A novel dependency analysis allows us to separate independent interactions with a contract. Our technique tunes the abstractions for the automata construction automatically based on configurable metrics, for instance, to maximize readability or precision. We implemented our technique for the Ethereum blockchain and evaluated its usability on several real-world contracts.
Reproducibility is the ability of recreating identical binaries under pre-defined build environments. Due to the need of quality assurance and the benefit of better detecting attacks against build environments, the practice of reproducible builds has gained popularity in many open-source software repositories such as Debian and Bitcoin. However, identifying the unreproducible issues remains a labour intensive and time consuming challenge, because of the lacking of information to guide the search and the diversity of the causes that may lead to the unreproducible binaries. In this paper we propose an automated framework called RepLoc to localize the problematic files for unreproducible builds. RepLoc features a query augmentation component that utilizes the information extracted from the build logs, and a heuristic rule-based filtering component that narrows the search scope. By integrating the two components with a weighted file ranking module, RepLoc is able to automatically produce a ranked list of files that are helpful in locating the problematic files for the unreproducible builds. We have implemented a prototype and conducted extensive experiments over 671 real-world unreproducible Debian packages in four different categories. By considering the topmost ranked file only, RepLoc achieves an accuracy rate of 47.09%. If we expand our examination to the top ten ranked files in the list produced by RepLoc, the accuracy rate becomes 79.28%. Considering that there are hundreds of source code, scripts, Makefiles, etc., in a package, RepLoc significantly reduces the scope of localizing problematic files. Moreover, with the help of RepLoc, we successfully identified and fixed six new unreproducible packages from Debian and Guix.
Roberto Tonelli, G. A. Pierro, Marco Ortu, Giuseppe Destefanis
Smart contracts (SC) are software programs that reside and run over a blockchain. The code can be written in different languages with the common purpose of implementing various kinds of transactions onto the hosting blockchain. They are ruled by the blockchain infrastructure with the intent to automatically implement the typical conditions of traditional contracts. Programs must satisfy context-dependent constraints which are quite different from traditional software code. In particular, since the bytecode is uploaded in the hosting blockchain, the size, computational resources, interaction between different parts of the program are all limited. This is true even if the specific programming languages implement more or less the same constructs as that of traditional languages: there is not the same freedom as in normal software development. The working hypothesis used in this article is that Smart Contract specific constraints should be captured by specific software metrics (that may differ from traditional software metrics). We tested this hypothesis on 85K Smart Contracts written in Solidity and uploaded on the Ethereum blockchain. We analyzed Smart Contracts from two repositories "Etherscan" and "Smart Corpus" and we computed the statistics of a set of software metrics related to Smart Contracts and compared them to the metrics extracted from more traditional software projects. Our results show that generally, Smart Contract metrics have more restricted ranges than the corresponding metrics in traditional software systems. Some of the stylized facts, like power law in the tail of the distribution of some metrics, are only approximate but the lines of code follow a log-normal distribution which reminds us of the same behaviour already found in traditional software systems.
Bugs severely hurt blockchain system dependability. A thorough understanding of blockchain bug characteristics is required to design effective tools for preventing, detecting and mitigating bugs. We perform an empirical study on bug characteristics in eight representative open source blockchain systems. First, we manually examine 1,108 bug reports to understand the nature of the reported bugs. Second, we leverage card sorting to label the bug reports, and obtain ten bug categories in blockchain systems. We further investigate the frequency distribution of bug categories across projects and programming languages. Finally, we study the relationship between bug categories and bug fixing time. The findings include: (1) semantic bugs are the dominant runtime bug category, (2) frequency distributions of bug types show similar trends across different projects and programming languages, (3) security bugs take the longest median time to be fixed, (4) 35.71% performance bugs are fixed in more than one year, performance bugs take the longest average time to be fixed.
Simone Porru, Andrea Pinna, Michele Marchesi, Roberto Tonelli
The Blockchain technology is reshaping finance, economy, money to the extent that its disruptive power is compared to that of the Internet and the Web in their early days. As a result, all the software development revolving around the Blockchain technology is growing at a staggering rate. In this paper, we acknowledge the need for software engineers to devise specialized tools and techniques for blockchain-oriented software development. From current challenges concerning the definition of new professional roles, demanding testing activities and novel tools for software architecture, we take a step forward by proposing new directions on the basis of a curate corpus of blockchain-oriented software repositories, detected by exploiting the information enclosed in the 2016 Moody's Blockchain Report and teh market capitalization of cryptocurrencies. Ensuring effective testing activities, enhancing collaboration in large teams, and facilitating the development of smart contracts all appear as key factors in the future of blockchain-oriented software development.
Large-scale organizations, such as Siemens, develop a broad field of products for varying domains. Software constitutes a major innovation and cost factor to their development. Organizational-wide reuse of software across products, even across domains, gives these organizations a competitive advantage. This involves large-scale reuse approaches where software is developed in a decentralized manner by several internal, yet self-contained organizational units -- those units are separate profit centers with own business objectives, organizationally independent with own product management, and have widely autonomous processes and software-engineering life cycles. I define those systems as internal software ecosystems. The intra-organizational, yet decentralized development context increases the amount and complexity of dependencies among both software assets and the responsible organizational units. This significantly impacts collaboration in software engineering. Traditional process-centric coordination mechanisms become increasingly inefficient, calling for a suitable software architecture to enable effective collaboration. However, in order to make informed architecture decisions, applied modes of collaboration and resulting architecture challenges must be understood. As first major contribution in this thesis, I provide strong empirical evidence on collaboration and resulting architecture challenges for two of the largest internal software ecosystems at Siemens -- based on a total of 46 hours of semi-structured interviews with 17 leading software architects from all involved organizational units. I identify three collaboration models on a continuum that ranges from high to low coupling and a classification of architecture challenges together with a qualitative and quantitative exposure of the identified recurring hurdles. My results outline a broad field of real-world challenges that need to be investigated by researchers, and my results support practitioners who follow the collaboration models to make informed architecture decisions based on empirical evidence. Besides taking informed architecture decisions, it is equally important to manage and control adherence to the specified architecture at an ecosystem-wide level. However, feature and schedule pressure regularly require to accept architecture violations by several organizational units, which decreases quality and increases maintenance costs. As main finding of my investigation on collaboration and architecture challenges, I identify the explicit and systematic management of architecture violations as the key challenge for internal software ecosystems, in particular the lack of developer support for resolving violations. As second major contribution within this thesis, I elaborate the TrAViM approach, a framework that comprises seven violation-management capabilities for internal software ecosystems. Their main purpose is developer support for resolving architecture violations, aiming to reduce the developers' effort required to handle them. I develop a prototype that instantiates the approach. Using the prototype, I conduct an in-depth case study on the capabilities' usefulness, involving 9 experts from my study systems. All of them expressed that the capabilities are highly valuable and hold great potential to ease violation management for large-scale software engineering.
A key challenge for software engineering is to learn how to reconcile the formal world of the machine and its software with the non-formal real world. In this paper, we describe Problem Oriented Software Engineering (POSE), an approach that brings both non-formal and formal aspects of software development together within a single theoretical framework for software engineering design. We show how POSE captures development as the recordable and re-playable design theoretic transformation of software problems. Their representation and transformation allows for the identification and clarification of system requirements, the understanding and structuring of the problem world, the structuring and specification of a hard-ware/software machine that can ensure satisfaction of the requirements in the problem world, and the construction of adequacy arguments, convincing both to developers and to customers, users and other interested stake-holders, that the system will provide what is needed. Designs are recordable and re-playable through our adaptation of tactics, a (now standard) form of programming language used in transformational proof theoretic presentations. This brings to our system many other benefits of such approaches, including the ability to abstract from a captured design, and to combine programmatically captured designs. This paper provides an example-driven presentation of our framework for software engineering design.