Evaluation

119 accept the payment by calling AcceptPayment after it learns of the amount that the seller has to receive and the VAT amount that the authority has to receive, with the state changing to

“Paid”.³⁸ After the payment takes place, the auditor can either accept or reject the transaction. In this case, the auditor accepts the transaction by calling AuditOK and changing the state to

“Passed”. The transaction is completed, and all of the steps are recorded on the blockchain with cryptographic signatures. All the resources needed for deployment and a video of the process described above can be found on GitHub.³⁹

120 Category Design principle Evaluation Comments

Data

High level of user access security

Partly met e-ID should have been integrated

High level of data access security

Not met Metadata leakage and split payment mechanism

Architecture

High level of scalability Met Component-based structure Met

Table 1. Design principle evaluation

9.1 High level of user access security

The Azure Blockchain Workbench ensures that the communication between parties is encrypted at the point of distribution so that only the buyer, the seller, their banks, and their auditors can view invoice information distributed across the blockchain. An entire invoice is transferred to bytes and hashed, and its value is added as a part of the transaction. The development team logged in with other users to evaluate whether the access control component of the design principle was complied with through design feature 1 – the transaction trail overview.

Today, authorities have very few touchpoints with companies before the companies self -declare VATs and submit annual financial reporting, which is why design feature 2 – the monitoring dashboard – provides near real-time insight into the Danish economy. It can, therefore, be concluded that DLT features should follow this design principle. In conclusion, because there is no integration with e-ID, the design principle is only partly met. Achieving such integration could strengthen access control and increase companies’ trust in the platform, but as such integration would require the creation of a company registration number and a service fee, its added benefit to the evaluation of the prototype would have been minimal and was therefore not pursued.

9.2 High level of data access security

The artifact does not meet the data access security principle, as all information is on-chain. Even though the data are encrypted, it is possible for other actors to see whether company A and company B have made transactions, which is identified as a case of metadata leakage. Further, the prototype does not comply with regulations on data privacy in a European context (GDPR)

121 as the blockchain's immutability capabilities do not allow participants to delete content. A first step toward addressing these problems would involve spending more time analyzing what an on-chain/off-chain architecture would resemble for an improved version of the artifact following the architecture proposed by Xu et al. (2017). Another research area with great potential for enhancing data protection is zero-knowledge proof, which offers ways to manage this design principle (e.g., Wang and Kogan 2018). Further, design feature 3 – split payments – does not integrate with bank accounts in the present artifact. It would be possible to utilize a token on the blockchain. It would be feasible to utilize the PSD2 directive and connect to European banks through standardized APIs or cryptocurrency platforms in future iterations.

9.3 High level of scalability

During building and evaluation iterations, this research found that some transactions were not processed because of the DLT watcher's malfunction. The DLT watcher monitors events occurring on blockchains attached to the Azure Blockchain Workbench, e.g., creating new contract instances, the execution of transactions, and changes in the state of the blockchain.

These events are captured and sent to the outbound message broker to be consumed by downstream consumers. This issue was corrected during the seven sprints, but its occurrence shows that the platform remains in its infancy. Documentation of the Azure Blockchain

Workbench, however, claims the following: “Using simple transactions, we have benchmarked an average of 400 transactions per second with a network deployed across multiple regions”

(Microsoft, 2019). During the evaluation, this researcher did not test this claim, and Microsoft did not explain what “simple transactions” means. However, this claim means that the current level of maturity achieved is likely to manage approximately 230 million invoices per year (130-150 transactions per average peak second), which implies that the current set-up meets this design principle. While this design principle is met in Denmark's case, extensive scalability tests are recommended if the solution is to be extended to other countries. Recently developed DLT solutions, e.g., Hedera and VeChain (Baird et al., 2020; VeChain, 2018), are claimed to offer more mature and scalable solutions.

9.4 Component-based structure

One of the key arguments for using the Azure Blockchain Workbench as the platform for instantiation lies in its component-based structure. Having worked with the Azure Blockchain Workbench and seen the progress and road map from Microsoft’s development team, this

122 researcher judge that it has met the expectations. The component-based structures (31

components in total) of the Azure Blockchain Workbench, which are all interlinked,

demonstrate the complexity of a blockchain-as-a-service (BaaS) platform. It can be concluded that the artifact meets this design principle. Further, other scholars are encouraged to test alternative types of BaaS platforms, including those provided by Amazon, Baidu, Google, and IBM. There are still many unknown aspects of the emerging area of BaaS. Based on this study alone, it seems as if some integrations of components (the DLT watcher in this study) may create hidden bottlenecks that must be identified.

9.5 Overall evaluation

The present purely technical evaluation of the instantiation shows that DLT is useful in the context of VAT settlement. While not all design principles were met, the artifact clearly shows that VAT settlements made in near real-time can be managed by a DLT system. As illustrated in Figure 8, the prototype (the line is shown below the process) shows that after starting and agreeing on step 1, i.e., business transactions, the following steps 2-5 can be automated with the use of a smart contract. Step 5 is underlined with a dotted line because this step may include a future cryptocurrency layer, whose implications further research can explore.

Figure 8. DLT-enabled VAT settlement process

10. DISCUSSION