Biblio

Conventional blockchain implementations with append-only semantics do not support deleting or overwriting data in confirmed blocks. However, many industry-relevant use cases require the ability to delete data, especially when personally identifiable information is stored or when data growth has to be constrained. Existing attempts to reconcile these contradictions compromise on core qualities of the blockchain paradigm, as they include backdoor-like approaches such as central authorities with elevated rights or usage of specialized chameleon hash algorithms in chaining of the blocks. The contribution of this paper is a novel architecture for the blockchain ledger and consensus, which uses a tree of context chains with simultaneous validity. A context chain captures the transactions of a closed group of entities and persons, thus structuring blocks in a precisely defined way. The resulting context isolation enables consensus-steered deletion of an entire context without side effects to other contexts. We show how this architecture supports truncation, data rollover and separation of concerns, how the GDPR regulations can be fulfilled by this architecture and how it differs from sidechains and state channels.

Programming languages can restrict state change by preventing it entirely (immutability) or by restricting which clients may modify state (read-only restrictions). The benefits of immutability and read-only restrictions in software structures have been long-argued by practicing software engineers, researchers, and programming language designers. However, there are many proposals for language mechanisms for restricting state change, with a remarkable diversity of techniques and goals, and there is little empirical data regarding what practicing software engineers want in their tools and what would benefit them. We systematized the large collection of techniques used by programming languages to help programmers prevent undesired changes in state. We interviewed expert software engineers to discover their expectations and requirements, and found that important requirements, such as expressing immutability constraints, were not reflected in features available in the languages participants used. The interview results informed our design of a new language extension for specifying immutability in Java. Through an iterative, participatory design process, we created a tool that reflects requirements from both our interviews and the research literature.