Permissionless Blockchain: 3 Propositions for Integration, Implementation, and Impactby@apieconomy

Permissionless Blockchain: 3 Propositions for Integration, Implementation, and Impact

tldt arrow

Too Long; Didn't Read

The article discusses challenges of integrating permissionless blockchain, like conflicting security protocols between traditional systems and open blockchains. It proposes 3 ideas for successful integration: Recognize the contradictions between existing systems and open blockchains. Design applications that leverage the core strengths of blockchain technology. Understand how permissionless blockchains create a level playing field for service providers.
featured image - Permissionless Blockchain: 3 Propositions for Integration, Implementation, and Impact
The API Economy Trends Report HackerNoon profile picture


(1) Johannes Rude Jensen, University of Copenhagen, eToroX Labs ([email protected]);

(2) Victor von Wachter, University of Copenhagen ([email protected]);

(3) Omri Ross, University of Copenhagen, eToroX Labs ([email protected]).

Abstract and Introduction

1 Literature Review

2 Methodology and Artefact Requirements

3 The Implementation and Integration of the Artefact

4 Artefact Evaluation

5 Discussion

6 Conclusion and Future Work, and References

5 Discussion

While the present iteration of the artefact successfully executes the lifecycle of a leveraged trade on the blockchain, the evaluation exposed several weaknesses in the artefact design. These issues were primarily motived by the dissimilarities between a hardened environment such as an exchange database system and a permissionless computational environment, such as the Ethereum blockchain. The tentative achievements presented here came at the cost of several compromises all of which ultimately affects the potential competitiveness of a product of this, or similar, nature. Generalizing the findings produced in this work for a broader IS audience, we offer three propositions on the integration, implementation, and impact of permissionless blockchain technology in the enterprise setting.

Proposition 1: The integration of permissionless blockchain technology in the enterprise setting introduces novel practical and theoretical contradictions.

While the execution of key business processes with permissionless blockchain technology has been shown to introduce performance enhancements and improved risk mitigation across several use-cases in the financial industries (Labazova 2019) the integration of permissionless infrastructure in hardened enterprise infrastructure is likely to introduce ambiguities between traditional and standardized approach to risk management in siloed database architectures, and the radical ‘openness’ of blockchain technology (Schlagwein et al. 2017).

Proposition 2: Client facing implementations of digital artefacts utilizing permissionless blockchain technologies succeed by assimilating relevant parts of the value chain to the key properties of permissionless blockchain technology.

The successful integration of digital artefacts implemented with permissionless blockchain technologies, ought to assimilate necessary aspects of the value chain to the key properties of blockchain technology: Transparency, deterministic execution, and non-custodial management of tokenized assets. Attempts at assimilating business processes executed with blockchain technology into a legacy environment may translate into lack of competitiveness and redundancy. Our advice is to build from the blockchain and up, not the other way around.

Proposition 3: The dissemination of permissionless blockchain technology and the deterministic execution of critical business processes introduces a level playing field for applications, users, and service providers.

An interesting property of permissionless blockchain technology as a computational environment, is the equivalency of computations. Unlike cloud computing models where organizations operate in secured walled environments (Weinhardt et al. 2009), permissionless blockchains introduce a secondary market for transaction processing denominated in the native asset-class.[9] Consequently, computations are prioritized by transaction fees which are, in most cases, paid by the user. The shared computational environment for blockchain based applications is likely to introduce novel implications for competing organizations, as service providers utilizing the same blockchain must share the same resource-constrained computational environment.

This paper is available on arxiv under CC BY 4.0 DEED license.

[9] The native asset for computations on the Ethereum blockchain is called ‘gas’ and is denominated in a floating exchange with ETH.