pith. sign in

arxiv: 2605.22239 · v1 · pith:7CYR5XB4new · submitted 2026-05-21 · 💻 cs.SE

An Architecture for Decentralised Deployment and Operation of Blockchain Applications

Fabian Stiehle , Kirill Inozemtsev , Ingo Weber This is my paper

Pith reviewed 2026-05-22 04:20 UTC · model grok-4.3

classification 💻 cs.SE
keywords decentralisedapplicationsarchitecturedeploymentintegrationblockchainsmartallow
0
0 comments X

The pith

Proposes a novel architecture integrating DevOps, DAOs, and an extended registry pattern for deterministic, decentralized deployment of blockchain applications with a reference implementation.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Blockchain apps run on smart contracts that need testing and updates, but current tools are often run by one company. The authors suggest using DAOs so that groups can vote on changes and deploy new versions automatically once enough people agree. They extend a standard registry to make deployments predictable and provide tools for pipelines, user interfaces, and version control. Each participant runs their own tests before using a new contract version. A working open-source example is included.

Core claim

We integrate these concepts considering DevOps best-practices into a novel architecture that remains agnostic to different governance and upgrade implementations. We extend the known registry pattern to support deterministic deployments and present a decentralised deployment framework.

Load-bearing premise

That the proposed architecture can be implemented in practice while remaining agnostic to specific governance and upgrade implementations and that participants will reliably implement and verify their own tests before using newly deployed contracts.

Figures

Figures reproduced from arXiv: 2605.22239 by Fabian Stiehle, Ingo Weber, Kirill Inozemtsev.

Figure 1
Figure 1. Figure 1: Overview of the proposed architecture with on- and off-chain entities. formulate our main requirements R1–R3, as depicted in [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Overview of the CI/CD workflow with decentralised file storage integration. registry and governance contract. Using these functionalities, the proposal creation and execution can be automated. However, such (centralised) automation increases the reliance on the repository platform. Depending on the trust model, package build, proposal creation, and proposal execution can be handled by a stakeholder, who ta… view at source ↗
Figure 3
Figure 3. Figure 3: Performance-annotated graph mined from conforming scenario logs (C1–C3). Based on this, we define seven non-conforming scenarios, simulating possible violations against the enforced order of events. For the scenarios, we verify our upgrade proposal implementation, as the other proposal flows are equal to OpenZeppelin’s Governor (version 5) implementation. All scenarios were executed on a local Hardhat bloc… view at source ↗
read the original abstract

Blockchains and distributed ledger technologies allow the operation of manifold decentralised applications (dApps). Such applications are based on smart contracts, a programmable abstraction that is executed in a decentralised manner. To ensure the correctness of smart contracts, blockchain application developers rely on DevOps practices such as automated testing and continuous integration and deployment. However, such infrastructure is often controlled by single entities. For larger blockchain applications, this issue is resolved by relying on concepts of Decentralised Autonomous Organisations (DAOs), which allow proposals to be autonomously executed once they reach a pre-defined quorum. Such a governance architecture is complex and requires integration with existing patterns for contract discovery and upgradeability. In this paper we integrate these concepts considering DevOps best-practices into a novel architecture that remains agnostic to different governance and upgrade implementations. We extend the known registry pattern to support deterministic deployments and present a decentralised deployment framework, including integration and deployment pipelines, user-interfaces, and version control integration. In our approach, each party implements and verifies their own tests before engaging in the use of a (newly deployed) smart contract. We provide a reference implementation, available as open-source, and evaluate the proposal thoroughly. Our architecture can serve as a reference for future integrations, while our open-source framework is aimed at reducing the complexity of adopting such a process in practice.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The paper proposes a novel architecture integrating DevOps practices (automated testing, CI/CD) with DAO-style governance and an extension of the registry pattern to support deterministic smart contract deployments. It claims the resulting decentralized deployment framework, including pipelines, UIs, and version-control integration, remains agnostic to concrete governance and upgrade mechanisms; each participant independently verifies tests before using new contracts. A reference implementation is provided as open source and the proposal is evaluated thoroughly.

Significance. If the agnosticism claim holds and the framework can be implemented without hidden platform coupling, the work would be significant for blockchain software engineering: it addresses the centralization problem in DevOps infrastructure for dApps and supplies a reusable reference plus open-source code that could lower adoption barriers for decentralized governance. The emphasis on participant-driven test verification and deterministic deployment is a constructive contribution if the abstractions prove portable.

major comments (3)
  1. [§3 and §4] §3 (Architecture) and §4 (Registry Extension): the central claim that the architecture 'remains agnostic to different governance and upgrade implementations' rests on the existence of abstract interfaces, yet the description of pipeline and registry interactions does not exhibit or prove such interfaces; concrete event signatures and deployment primitives are referenced without showing how they can be satisfied by arbitrary governance models.
  2. [§4] §4 (Deterministic Deployments): the extension of the registry pattern for deterministic deployments is described without addressing platform-specific requirements such as CREATE2 or equivalent opcodes; if these are used, the agnostic property fails for non-Ethereum chains, directly undermining the load-bearing claim of cross-platform applicability.
  3. [Evaluation] Evaluation section: the 'thorough evaluation' and reference implementation are asserted to validate the framework, but no concrete test cases, cross-governance verification results, or interface conformance checks are reported that would confirm participants can reliably implement and verify tests without platform coupling.
minor comments (2)
  1. [§4] Notation for the extended registry pattern could be clarified with a small diagram or pseudocode to distinguish the deterministic-deployment additions from the base pattern.
  2. [Related Work] A few citations to prior registry and proxy-upgrade patterns appear to be missing or incomplete in the related-work discussion.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the constructive feedback on our architecture's agnosticism claims and the evaluation details. We address each major comment below, agreeing where clarification is needed and outlining specific revisions to strengthen the manuscript.

read point-by-point responses

  1. Referee: [§3 and §4] §3 (Architecture) and §4 (Registry Extension): the central claim that the architecture 'remains agnostic to different governance and upgrade implementations' rests on the existence of abstract interfaces, yet the description of pipeline and registry interactions does not exhibit or prove such interfaces; concrete event signatures and deployment primitives are referenced without showing how they can be satisfied by arbitrary governance models.

    Authors: We agree that the presentation of abstract interfaces in §3 and §4 would benefit from greater explicitness. In the revised manuscript we will add formal interface definitions (including method signatures and event specifications) to §3 and include two worked examples in §4 demonstrating how the same interfaces are satisfied by distinct governance models—one using simple quorum voting and one using a token-weighted proposal system. These additions will directly illustrate conformance without altering the core agnostic design. revision: yes

  2. Referee: [§4] §4 (Deterministic Deployments): the extension of the registry pattern for deterministic deployments is described without addressing platform-specific requirements such as CREATE2 or equivalent opcodes; if these are used, the agnostic property fails for non-Ethereum chains, directly undermining the load-bearing claim of cross-platform applicability.

    Authors: The registry extension employs a salt-based deterministic address derivation that is realized via CREATE2 in the Ethereum reference implementation. We acknowledge that other chains require analogous mechanisms. The revision will insert a short subsection in §4 explaining how equivalent address-prediction primitives (nonce-based derivation, chain-specific opcodes, or precomputed addresses) can be substituted while preserving the architecture-level determinism and agnosticism to governance. revision: yes

  3. Referee: [Evaluation] Evaluation section: the 'thorough evaluation' and reference implementation are asserted to validate the framework, but no concrete test cases, cross-governance verification results, or interface conformance checks are reported that would confirm participants can reliably implement and verify tests without platform coupling.

    Authors: The Evaluation section summarizes outcomes from the open-source reference implementation, whose test suite already contains the requested verification logic. We will expand the section with explicit descriptions of representative test cases, including cross-governance deployment verification and interface-conformance checks. These additions will make the participant-driven verification process transparent while pointing readers to the repository for full reproducibility. revision: yes

Circularity Check

0 steps flagged

Architecture integrates external patterns and DevOps concepts without self-referential derivation or fitted predictions

full rationale

The paper proposes integrating DevOps practices, DAO governance, and an extension of the known registry pattern into a novel architecture claimed to be agnostic to specific governance and upgrade implementations. No equations, fitted parameters, or predictions appear in the abstract or context that reduce by construction to the paper's own inputs. The central claims rest on described integration of standard external concepts (registries, DAOs, deterministic deployments via existing primitives) rather than self-definition or self-citation chains. This qualifies as a normal low-circularity outcome for a design-oriented software engineering paper that remains self-contained against external benchmarks and open-source evaluation.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The architecture rests on standard assumptions from software engineering and blockchain literature about smart contract execution, DAO quorum mechanisms, and the feasibility of deterministic deployments. No free parameters or invented entities are introduced in the abstract.

axioms (2)
  • domain assumption Smart contracts can be executed in a decentralized manner with correctness ensured via automated testing and CI/CD practices.
    Invoked in the description of DevOps practices for blockchain applications.
  • domain assumption DAOs allow proposals to be autonomously executed once a pre-defined quorum is reached.
    Stated as the mechanism to resolve single-entity control issues.

pith-pipeline@v0.9.0 · 5770 in / 1269 out tokens · 29832 ms · 2026-05-22T04:20:11.612334+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

31 extracted references · 31 canonical work pages

  1. [1]

    Springer, Heidelberg (2011)

    van der Aalst, W.M.P.: Process Mining: Discovery, Conformance and Enhancement of Business Processes. Springer, Heidelberg (2011)

    work page 2011

  2. [2]

    In: EASE

    Akbar, M.A., Mahmood, S., Siemon, D.: Toward effective and efficient DevOps using blockchain. In: EASE. pp. 421–427 (2022)

    work page 2022

  3. [3]

    In: Intl

    Bankar, S., Shah, D.: Blockchain based framework for software development using DevOps. In: Intl. Conf. Nascent Technologies in Engineering (ICNTE). pp. 1–6. IEEE (2021)

    work page 2021

  4. [4]

    Bass,L.,Weber,I.,Zhu,L.:DevOps:ASoftwareArchitect’sPerspective.Addison-Wesley Professional (2015)

    work page 2015

  5. [5]

    In: ICSE-NIER

    Beller, M., Hejderup, J.: Blockchain-based software engineering. In: ICSE-NIER. pp. 53–56. IEEE (2019)

    work page 2019

  6. [6]

    In: Intl

    Benedetti, A., Henry, T., Tucci-Piergiovanni, S.: A comparative gas cost analysis of proxy and diamond patterns in evm blockchains for trusted smart contract engineering. In: Intl. Conf. Financial Cryptography and Data Security. pp. 207–221. Springer (2024)

    work page 2024

  7. [7]

    Software Impacts17, 100556 (2023)

    Berti, A., van Zelst, S., Schuster, D.: PM4Py: A process mining library for python. Software Impacts17, 100556 (2023)

    work page 2023

  8. [8]

    In: USENIX Security

    Bodell III, W.E., Meisami, S., Duan, Y.: Proxy hunting: Understanding and characteriz- ing proxy-based upgradeable smart contracts in blockchains. In: USENIX Security. pp. 1829–1846 (2023)

    work page 2023

  9. [9]

    https://eips.ethereum.org/EIPS/eip-1014 (Apr 2018), ethereum Improvement Proposal 16 F

    Buterin, V.: EIP-1014: Skinny CREATE2. https://eips.ethereum.org/EIPS/eip-1014 (Apr 2018), ethereum Improvement Proposal 16 F. Stiehle et al

    work page 2018

  10. [10]

    Buterin, V., Dankrad, F., Diederik, L., Lightclient, Rory, S.: EIP-4844: Shard blob transactions.EthereumImprovementProposals(2022),https://eips.ethereum.org/EIPS/ eip-4844, accessed: 2026-03-26

    work page 2022

  11. [11]

    Concurrency and Computation: Practice and Experience 32(17), e5668 (2020)

    Casalicchio, E., Iannucci, S.: The state-of-the-art in container technologies: Application, orchestration and security. Concurrency and Computation: Practice and Experience 32(17), e5668 (2020)

    work page 2020

  12. [12]

    Springer, Heidelberg (2018)

    Dumas, M., La Rosa, M., Mendling, J., Reijers, H.A.: Fundamentals of Business Process Management. Springer, Heidelberg (2018)

    work page 2018

  13. [13]

    Sensors22(1), 128 (2021)

    Górski, T.: Continuous delivery of blockchain distributed applications. Sensors22(1), 128 (2021)

    work page 2021

  14. [14]

    Applied Sciences11(24), 11745 (2021)

    Górski, T.: Towards continuous deployment for blockchain. Applied Sciences11(24), 11745 (2021)

    work page 2021

  15. [15]

    Journal of Corporate Finance91, 102734 (2025)

    Han, J., Lee, J., Li, T.: A review of dao governance: Recent literature and emerging trends. Journal of Corporate Finance91, 102734 (2025)

    work page 2025

  16. [16]

    Business & Information Systems Engineering pp

    Hobeck, R., Klinkmüller, C., Bandara, H.D., Weber, I., van der Aalst, W.: On the suitability of process mining for enhancing transparency of blockchain applications. Business & Information Systems Engineering pp. 1–20 (2024)

    work page 2024

  17. [17]

    In: SAFE- COMP

    Jämthagen, C., Lantz, P., Hell, M.: Exploiting trust in deterministic builds. In: SAFE- COMP. pp. 238–249. Springer (2016)

    work page 2016

  18. [18]

    IEEE TSC (2025)

    Kumar,G.,Saha,R.,Conti,M.,Buchanan,W.J.:Leagan:Adecentralizedversion-control framework for upgradeable smart contracts. IEEE TSC (2025)

    work page 2025

  19. [19]

    In: EDOC

    Ladleif, J., Weske, M.: Time in Blockchain-Based Process Execution. In: EDOC. pp. 217–226. IEEE (2020)

    work page 2020

  20. [20]

    https://eips.ethereum.org/EIPS/ eip-2535 (Feb 2020), ethereum Improvement Proposals, no

    Mudge, N.: ERC-2535: Diamonds, Multi-Facet Proxy. https://eips.ethereum.org/EIPS/ eip-2535 (Feb 2020), ethereum Improvement Proposals, no. 2535, Online

    work page 2020

  21. [21]

    IJACSA15(6) (2024)

    Nasr, R., Marie, M.I., El Sayed, A.: A hybrid framework to implement devops practices on blockchain applications (devchainops). IJACSA15(6) (2024)

    work page 2024

  22. [22]

    Galaxy Research (August 2024), https://www

    Pokorny, Z.: 150 days after dencun. Galaxy Research (August 2024), https://www. galaxy.com/insights/research/ethereum-150-days-after-dencun, accessed: 2026-03-26

    work page 2024

  23. [23]

    In: 2024 7th Conference on Cloud and Internet of Things (CIoT)

    Saleh, S.M., Madhavji, N., Steinbacher, J.: Blockchain for securing ci/cd pipeline: A review on tools, frameworks, and challenges. In: 2024 7th Conference on Cloud and Internet of Things (CIoT). pp. 1–5. IEEE (2024)

    work page 2024

  24. [24]

    IEEE access5, 3909–3943 (2017)

    Shahin, M., Babar, M.A., Zhu, L.: Continuous integration, delivery and deployment: a systematic review on approaches, tools, challenges and practices. IEEE access5, 3909–3943 (2017)

    work page 2017

  25. [25]

    In: BPM: Forum

    Stiehle, F., Weber, I.: Blockchain for business process enactment: a taxonomy and systematic literature review. In: BPM: Forum. LNBIP, vol. 459, pp. 5–20 (2022)

    work page 2022

  26. [26]

    Stiehle, F., Weber, I.: Process channels: A new layer for process enactment based on blockchain state channels. In: BPM. pp. 198–215. Springer (2023)

    work page 2023

  27. [27]

    In: International Conference on Business Process Management

    Stiehle, F., Weber, I.: The cost of executing business processes on next-generation blockchains: The case of algorand. In: International Conference on Business Process Management. pp. 89–105. Springer (2024)

    work page 2024

  28. [28]

    In: 2021 IEEE International Conference on Blockchain (Blockchain)

    Wöhrer, M., Zdun, U.: DevOps for Ethereum blockchain smart contracts. In: 2021 IEEE International Conference on Blockchain (Blockchain). pp. 244–251. IEEE (2021)

    work page 2021

  29. [29]

    Ethereum project yellow paper (2014)

    Wood, G., et al.: Ethereum: A secure decentralised generalised transaction ledger. Ethereum project yellow paper (2014)

    work page 2014

  30. [30]

    In: Transactions on Pattern Languages of Programming V, pp

    Xu, X., Pautasso, C., Lo, S.K., Zhu, L., Lu, Q., Weber, I.: An extended pattern collection for blockchain-based applications. In: Transactions on Pattern Languages of Programming V, pp. 67–117. Springer (2025)

    work page 2025

  31. [31]

    In: EuroPLoP

    Xu,X.,Pautasso,C.,Zhu,L.,Lu,Q.,Weber,I.:Apatterncollectionforblockchain-based applications. In: EuroPLoP. pp. 1–20 (2018)

    work page 2018