A Correction to this paper has been published: 10.1007/s10664-020-09924-6

Bitcoin introduced delegation of control over a monetary system from a select few to all who participate in that system. This delegation is known as the decentralization of controlling power and is a powerful security mechanism for the ecosystem. After the introduction of Bitcoin, the field of cryptocurrency has seen widespread attention from industry and academia, so much so that the original novel contribution of Bitcoin, i.e., decentralization, may be overlooked, due to decentralizations’ assumed fundamental existence for the functioning of such crypto-assets. However, recent studies have observed a trend of increased centralization in cryptocurrencies such as Bitcoin and Ethereum. As this increased centralization has an impact the security of the blockchain, it is crucial that it is measured, towards adequate control. This research derives an initial taxonomy of centralization present in decentralized blockchains through rigorous synthesis using a systematic literature review. This is followed by iterative refinement through expert interviews. We systematically analyzed 89 research papers published between 2009 and 2019. Our study contributes to the existing body of knowledge by highlighting the multiple definitions and measurements of centralization in the literature. We identify different aspects of centralization and propose an encompassing taxonomy of centralization concerns. This taxonomy is based on empirically observable and measurable characteristics. It consists of 13 aspects of centralization, classified over six architectural layers: Governance, Network, Consensus, Incentive, Operational, and Application. We also discuss how the implications of centralization can vary depending on the aspects studied. We believe that this review and taxonomy provides a comprehensive overview of centralization in decentralized blockchains involving various conceptualizations and measures.

Blockchain systems have gained substantial traction recently, partly due to the potential of decentralized immutable mediation of economic activities. Ethereum is a prominent example that has the provision for executing stateful computing scripts known as Smart Contracts. These smart contracts resemble traditional programs, but with immutability being the core differentiating factor. Given their immutability and potential high monetary value, it becomes imperative to develop high-quality smart contracts. Software metrics have traditionally been an essential tool in determining programming quality. Given the similarity between smart contracts (written in Solidity for Ethereum) and object-oriented (OO) programming, OO metrics would appear applicable. In this paper, we empirically evaluate inheritance-based metrics as applied to smart contracts. We adopt this focus because, traditionally, inheritance has been linked to a more complex codebase which we posit is not the case with Solidity based smart contracts. In this work, we evaluate the hypothesis that, due to the differences in the context of smart contracts and OO programs, it may not be appropriate to use the same interpretation of inheritance based metrics for assessment.

Feature Location (FL) aims to locate observable functionalities in source code. Considering its key role in software maintenance, a vast array of automated and semi-automated Feature Location Techniques (FLTs) have been proposed. To compare FLTs, an open, standard set of non-subjective, reproducible "compare-to" FLT techniques (baseline techniques) should be used for evaluation. In order to relate the performance of FLTs compared against different baseline techniques, these compare-to techniques should be evaluated against each other. But evaluation across FLTs is confounded by empirical designs that incorporate different FL goals and evaluation criteria. This paper moves towards standardizing FLT comparability by assessing eight baseline techniques in an empirical design that addresses these confounding factors. These baseline techniques are assessed in twelve case studies to rank their performance. Results of the case studies suggest that different baseline techniques perform differently and that VSM-Lucene and LSI-Matlab performed better than other implementations. By presenting the relative performances of baseline techniques this paper facilitates empirical cross-comparison of existing and future FLTs. Finally, the results suggest that the performance of FLTs partially depends on system/benchmark characteristics, in addition to the FLTs themselves.

In this paper, we discuss the feasibility of using an automated speech-to-speech pipeline to encode voice samples instead of regular voice codecs, in situations that require high data compression with high packet loss scenarios. To analyse the advantages of using a speech-to-text transcription as a voice encoder and a text-to-speech synthesis as a decoder and compare it against standard a PCM A-law codec, we have measured the error rate of user-transcribed sentences based on the Semantically Unpredictable Sentences (SUS) test. Some of the PCM speech samples were also played in a way to simulate poor network conditions, specifically 5% and 10% packet loss. These were added to compare the performance of the speech-to-text method to standard voice codecs. Additionally, we have evaluated how similar the transcribed messages were to the ground truth by measuring the Levenshtein distance between the sentences and also their Double Metaphone phonetic representations. We conclude it may be feasible to use speech-to-text as a codec, as the results of do not show a significant difference between the synthesised voice and the real voice.

Abstract Objectives: Software architecture is perceived as one of the most important artefacts created during a system's design. However, implementations often diverge from their intended architectures: a phenomenon called architectural drift. The objective of this research is to assess the occurrence of architectural drift in the context ofde novosoftware development, to characterize it, and to evaluate whether its detection leads to inconsistency removal.Method: Anin vivo, longitudinal case study was performed during the development of a commercial software system, where an approach based on Reflexion Modelling was employed to detect architectural drift. Observation and think‐aloud data, captured during the system's development, were assessed for the presence and types of architectural drift. When divergences were identified, the data were further analysed to see if identification led to the removal of these divergences.Results: The analysed system diverged from the intended architecture, during the initial implementation of the system. Surprisingly however, this work showed that Reflexion Modelling served to conceal some of the inconsistencies, a finding that directly contradicts the high regard that this technique enjoys as an architectural evaluation tool. Finally, the analysis illustrated that detection of inconsistencies was insufficient to prompt their removal, in the small, informal team context studied.Conclusions: Although the utility of the approach for detecting inconsistencies was demonstrated in most cases, it also served to hide several inconsistencies and did not act as a trigger for their removal. Hence additional efforts must be taken to lessen architectural drift and several improvements in this regard are suggested. Copyright © 2010 John Wiley & Sons, Ltd.

A software designer often has little control over, or means of checking, whether his design is being adhered to, once the implementation begins. This 'architectural drift', where the original design of the system and the as-implemented design of the system diverge, can cause serious problems for evolution, maintenance and the comprehensibility of a system if it remains undocumented or uncorrected. The earlier such discrepancies can be identified, the better.

Abstract Design abstractions such as components, modules, subsystems or packages are often not made explicit in the implementation of legacy systems. Indeed, often the abstractions that are made explicit turn out to be inappropriate for future evolution agendas. This can make the maintenance, evolution and refactoring of these systems difficult. In this publication, we carry out a fine‐grained evaluation of Reflexion Modelling as a technique for encapsulating user‐targeted components. This process is a prelude to component recovery, reuse and refactoring. The evaluation takes the form of twoin vivocase studies, where two professional software developers encapsulate components in a large, commercial software system. The studies demonstrate the validity of this approach and offer several best‐use guidelines. Specifically, they argue that users benefit from having a strong mental model of the system in advance of Reflexion Modelling, even if that model is flawed, and that users should expend effort exploring the expected relationships present in Reflexion Models. Copyright © 2008 John Wiley & Sons, Ltd.

Continuing to develop software from scratch will not be feasible indefinitely. Reusing existing software would seem to be a viable solution to this problem. The paradigm of component-based development (CBD) explicitly accounts for reuse in its process. Unfortunately the majority of existing software systems are not implemented using CBD, thus reusing portions of this software using CBD becomes difficult. Reengineering and maintenance research contains a plethora of software analysis and restructuring techniques that could be used to help us exploit legacy applications for reuse. This thesis focuses on two such techniques and combines variations of them for the purpose of component recovery: A feature location technique called Software Reconnaissance and a design recovery technique called Software Reflexion Modelling. Their combination is called "Component Reconn-exion." We describe the technique, highlight results and evaluation to date and finally discuss further work necessary to complete our contribution as a PhD. thesis.