JohoGo



An Investigation into the use of a blockchain based payment interface with the Business World ERP product

David Evans, Hamid Jahankhani, Stefan Kendzierskyj,Northumbria University London, UK Hamid.jahankhani@northumbria.ac.uk; Stefan@cyfortis.co.uk

Abstract

This research investigates the integration of blockchain payment methods with Agresso ERP system, a mid-tier application with a wide adoption in the public sector and moderate adoption in the private sector.

To enable a payment to take place between the ERP system and a third party, an API was configured between the chosen ERP system and the Coinbase application which forms the interface to the Ethereum blockchain. The results of the research show that whilst it is possible to settle payments using blockchain technologies, specifically Ethereum, via an API, the process does not improve upon existing payment methods involving third parties i.e. Banks, and that for

intra-currency transactions e.g. GBP to GBP with differing rates. The research found that additional

element of complexity in the form of ‘currency gains / losses’ from having to hold balances of Ether has introduced an additional level of risk into the payment process by utilising a technology that has known vulnerabilities.

Keywords: Blockchain, ERP, Banking, payment interface, GDPR, smart contracts, Crypto Currency, Ethereum, Agresso, Coinbase.

Introduction

The ERP sector has greatly evolved over time, however there are more recently claims that blockchain can revolutionise it through streamlining processes and improving auditability (IBM, 2018). The motivation for investigating was curiosity, generated from the publicity of distributed ledger technologies, specifically blockchain and the many claims of it being a disruptive technology, but specifically and understanding of how it related to business and accounting software (ERP). To look at a complete ERP system would be overwhelming because it contains so many areas customers, suppliers, reporting, foreign currency, GDPR etc. There are many ERP systems, all performing the same sorts of functions but using different methods. However, for basis of this paper and research, the focus is on a particular area regarding the payment or settlement process. This is because it is one that is closest to the original ideas of crypto currency and is common to all ERP systems and is a frequently used interface into banking systems.

The principles of Blockchain theory started in 1991 with Haber and Stornetta (Stuart Haber, 1991) when they considered the problem of timestamping electronic documents, or as they postulated, the problem of timestamping the data, not the artefact. In an interview with Scott Stornetta he summarised the problem as “If we can’t tell an old document from a new document, or a tampered one from an original, we’re going to be in real trouble as a society. And so, I realized there was going to be a need to create tamper-proof, immutable records in the digits themselves.” (Emsley, 2018).

By exploring the existing physical methods of proof of tampering e.g. that page is missing or that date has been changed by focusing on the data not the medium of transferring it, allowed the discussion to enter the digital realm as well as the physical one, and therefore the discussion became relevant to the digital age. Haber and Stornetta proposed a solution to the problem of confirming data integrity that comprised two elements, a hash and a signature. The signature being based on private key signatures linked to the hashes. Hashing and signing is one of the fundamental principles of the immutable nature of blockchain technologies and one that is essential to the payment process. Paying suppliers twice or losing data, or not being able to find it when asked by auditors is an issue for businesses.

Smart Contracts

A ‘smart contract’ first considered by Nick Szabo in his paper “The Idea of Smart Contracts” (Szabo, 1997) using analogy of a vending machine to explain the principle of a smart contract. Authors highlight that the areas of security (preventing breach), control (who can legitimately contract), ownership (preventing theft) and risk (revoking control whilst in use resulting in an accident). Szabo, 2002 went on to create an embryonic language in which to write them in his paper ‘A Formal Language for Analysing Contracts (Szabo, 2002), where the author specifically includes the supply chain workflow as an example of a type of contract that can be created using Smart Contracts. Szabo, 2002 explains that the language is not a mark-up language (HTML) used to manipulate text, but instead purposed to ‘model the dynamics of contract performance’ (Szabo, 2002) Nick goes on to express some very old contracts in the language he proposes, which, given that the language (English, Latin, Szabo-code) is only needed for interpretation, the problem being essentially syntactical, shows that the problem is one of logic.

In 2002, the same year that Nick Szabo wrote ‘A Formal Language’, Jorg F Witterberger in his paper called Askemos – A Distributed Settlement (Wittenberger, 2002) proposed an approach that concentrates on three principles:

It’s distributed

It uses voting to achieve consensus

There is no concept of super user rights

By using a distributed operating system residing on a peer to peer network where each node on the network processes the steps of the virtual machine and then votes on the result to achieve consensus and not having unique names spaces or super user rights, Jorg, is seeking to combine the benefits of the traditional paper based systems that have existed since paper was created and used to record the contracts. Nick Szabo uses in his example of a contract that can be coded, with those of a computer-based system that can duplicate the data and in doing so reduce the risk of permanent data loss. Whereas in this paper Jorg states that ‘messages are understood as orders. A set of rights is associated with a message which indicates the authority under which the ordered operation shall be performed’ (Wittenberger, 2002) is the essence of a smart contract, where Jorg introduces the element of rights and authority. Important elements in ensuring data integrity and relevant to the process of transacting via a third party in the most efficient manner i.e. automated.

The Creation of a Crypto Currency

The next development in distributed ledger theory came from Satoshi Nakamoto with the paper ‘Bitcoin: A Peer to Peer Electronic Cash System’ (Nakamoto, bitcoin, 2008) with the well documented crypto currency that brought blockchain technology to the attention of the public. But also links to the previous work by developing a solution for double spending which in Haber and Stornetta’s paper was expressed as ‘hash collision’ and resolved through a consensus mechanism whereby the longest chain is considered canonical via a proof of work (PoW) method.

Bitcoin itself is not wholly relevant to the evolution of smart contracts, Satoshi’s white paper does not even mention smart contracts, however, it has relevance as an evolution of the mechanism used to contain smart contracts (Blockchain) and also as the first of one of the potential currencies used for settlement.

Ethereum

At this point in the history of Smart Contracts, the work around distributed ledger technologies has been fairly theoretical, however, the next significant development brought it into the practical realm and came from Vitalik Buterin who connected the principles of Smart Contracts established by Nick Szabo with the decentralised solution to the dual payment problem provided by Satoshi Nakamoto, and extended the theory into the realm of the decentralised autonomous organisation wherein ‘long term smart contracts that contain the assets and encode the bylaws of an entire organisation’ (Buterin, 2013) Vitalik created the Ethereum blockchain with the aim of moving beyond a simple currency through the use of an arbitrary state transition function i.e. based on the prespecified rules (the terms of a contract) the state of an object will change (go from unpaid to paid).

(Casado-Vara, Briones, Prieto, & Corchado, 2019) highlight some of the use cases for smart contracts for monitoring and control aims to use blockchain, smart contracts in conjunction with multi agent systems to increase organisation, security and improve distribution times, emphasises the multi-purpose nature of smart contracts, which whilst not relevant to solving the more specific problem considered in this piece of work, are useful for context.

How do Smart Contracts Work?

In the article ‘Smart Contracts’ are defined by Nick Szabo (Szabo, Smart Contracts: Building Blocks for Digital Markets, 2019) using the definition that smart contracts are programs executed by miners allowing parties unknown to each other to securely transact. It outlines 3 components

The contract between parties

Governance of preconditions

Execution of the contract

This paper is not concerned with the first and second components because they are outside the scope of this document and have their origin in business processes. The execution of the contract, in this case, the triggering of the transfer of Ether between two parties, is relevant.

It is worth considering the variety of use cases for smart contracts before narrowing them down to the specific case considered by this document. The Ethereum foundation (Ethereum Community, 2016) outlines four purposes of smart contracts:

Smart contracts act to as a data store and as such represent something of use to another contract or useful outside the contract realm, the example stated is that of a currency.

Smart contracts can act as a ‘forward contract’ that will, when certain criteria specified in

the contract, forward a message on to a pre-specified address in the blockchain, the example given is for a wallet contract, and relevant to the investigation because the Coinbase wallet will be used in the absence of authority from the Agresso ERP software owners.

Smart contracts can manage an ongoing contract or relationship between multiple users.

One example is an escrow contract. Relevant to the document because, one of the solutions to high transaction cost of an on blockchain payment method is to use an escrow account.

Smart contracts can also provide functions to other contracts, essentially serving as a software library.

The Ethereum homestead outlines the two different types of contract, externally owned and contract accounts. (Ethereum Community, 2016) and outlines the characteristics of each, the essential differences being that externally controlled accounts do not have code associated with them and are controlled by private keys, where contract accounts have code associated with them and are triggered by a message or call from another contract.

In their simplest form, smart contracts are statements of complexity as explained in (Sillaber, 2019). The smart contract will sit in a specific location on the blockchain waiting to be triggered by an API call which will send a message to run the contract and may also feed in specific values, for example, about the value of the payment, public key of the person paying and public key of the person receiving and many others. Using the example of the blockchain record from (McConnell, 2019) shown below, to show that the smart contract will have a place in one of the ‘Record n.2’ fields in the blockchain record.

[pic]

Figure 1: Blockchain record – source McConnell, 2019

The life cycle of smart contract in Blockchain ecosystems is explained in (Sillaber, 2019) which also sketches the holistic lifecycle of decentralised smart contracts but also introduces distributed ledger and crypto currencies as base lines for smart contracts that need to be stored safely in blocks. It also shows the logic of a smart contract as ‘If then else’, which is relevant because the logic is what will be used to trigger the payment used in the data section.

The Lifecycle of a smart contract

In the work (Szabo, Smart Contracts: Building Blocks for Digital Markets, 2019) Szabo defines a 4 part lifecycle:

Creation of the smart contract

Freezing of the smart contract

Executing the contract

Finalising the contract

The focus of this paper is on the 3rd element of the lifecycle, the execution of the contract, specifically, the trigger of the contract that will result in the transfer of value from one party to another, or in practical terms, the creation of a record on the blockchain that records the transfer of Ether between parties. To consider the other elements would involve a lot more work than time and content limits would allow.

(Casado-Vara, Briones, Prieto, & Corchado, 2019) re-emphasises the work of Szabo by stating that smart contracts have a unique address in the blockchain with a hash that identifies it. The contracts can be triggered independently and automatically on every node in the network according to the data contained in the triggered transaction.

Smart Contracts In The Payments Process

Transfers of crypto currencies between owners of currency are essentially records on a ledger. They do not represent a physical transfer of asset like in barter or an amount of gold. The Ethereum foundation in (Foundation, 2016-2019) outline two types of payments; off blockchain and on blockchain. The distinction has come about because of the problems associated with payments made directly on a blockchain.

In an article which outlines two of the main problems with on blockchain processing, speed and cost (Mearian, 2018) highlights that traditional databases can be updated in parallel, while blockchain ledgers need to be serialised, and therefore are slower. The article also mentions that it is a restriction on scalability.

The solidity foundation defines a method of getting around the problems associated with making payments directly onto the blockchain by using an off chain method called a payment channel. (Foundation, 2016-2019). Payment channels require both parties to hold amounts of currency, in this example case Ether, in Escrow, and draw down against the balances, with a settlement process at the end of the transaction, and also the update to the main chain with a summary of the transactions. This is known as ‘sharding’. The solution is aimed at high volume low value transactions most likely on private blockchain systems, where on-block transactions are best used for high value low volume transactions across borders. The decision to use an on or off block payment process is one that should be made at the design stage of the implementation. For the purposes of expediency and scale, this exercise will focus on an on-block payment process.

The cost of transacting

The Ethereum protocol charges a fee for each computational step executed in a contract called‘gas’.

Gas is analogous to bank charges, although bank charges are set and vary infrequently, gas fees can vary from transaction to transaction making them more volatile. Every transaction is required to include a gas limit and fee that it is willing to pay in order to validate the record. If the actual fee exceeds that amount, the transaction is voided. So, it is possible for a payment to be sent but not received. That is a problem for those involved in the settlement process, so it is important that the issue is highlighted quickly in order to rectify the problem. If gas is not included in the transaction then it’s not possible to proceed, which is the fastest form of feedback and therefore best. When using traditional methods with third party intermediaries (Banks) there are varying feedback loop speeds, cheques can take weeks, card payments can be instant. (Community, 2016) which leads to the problem of making sure you have enough currency first, although, that problem is mitigated by off-block payment processing.

At the time of writing this paper, there are no interfaces between the Agresso ERP system and blockchain for the utilisation of smart contracts and payment channels. In an article by (Kulkarni, 2018) called Blockchain v ERP, which proposes that blockchain-connected ERP systems will offer the best supply chain management option for most companies, although the article doesn’t mention how it will come about, and focuses more on the whole business process rather than the specific business problem of transaction with blockchain.

That detail is approached in the paper by (Annesley, 2018) which proposes a solution to the problem in the form of a bridge between legacy IT systems and Blockchain networks to enable business and IT to transition to Blockchain when and where it makes sense. This approach is more practical and offers a lower risk than migrating all platforms and assuming a ‘one size fits all’ approach. The article mentions that whilst blockchain networks like Ethereum are well established it is still early to bet on one blockchain network and it is likely that corporations will want and need to leverage multiple networks, however it does not explore the possibility of private blockchain solutions and it does not explore the practical side of interfacing from the existing systems into a blockchain environment.

The practicalities of interfacing are approached in a paper by (Stefan Schmidt, 2018) which starts to explore the possibilities of integrating blockchain based solutions into a business by developing a framework called ‘Unibright’ on which the systems can interact through the creation of templated approach that utilises automatic smart contract generation. The goals of cross blockchain and cross systems connections for business integration are ambitious and meet the ambition of this paper, and the use of automated smart contract generation could meet the needs of the project, however, the focus of the white paper is on business integration rather than the settlement function of a payment process. The scope and focus of that paper is more on aligning business processes across organisations than the specific use case considered in this paper.

Rather than following the heavyweight approach of utilising a framework or building customised and therefore maintenance heavy solutions and following the need for lightweight, in terms of infrastructure and impact on business processes, there have been a number of digital apps (DAPPS) that utilise blockchain technologies and are available from the Ethereum foundation. There are 105 Ethereum DAPPS that relate to Finance out of a total of 1248 live Ethereum DAPPS. (ethereum organisation, 2019) none of which relate to ERP and none relate to the payment process from Agresso. The implication being that the area is immature, and there is a gap in the knowledge of interfacing to the Agresso application.

Rather than exploring the creation of a specific DAPP for a company, Infosys propose a solution of Blockchain as a Service (BAAS) (Infosys, 2018) however the paper does not go into detail on what that service should look like, or how it should function.

Taking a further step back to look at the broader ERP environment there are, at the time of writing, a number of solutions other than DAPPS or blockchain as a service which are available for integrating to ERP environment, the Raiden Network, and a link between the Oracle platform and Citi Treasury tools (pymnts, 2018) neither of which integrate with the Agresso product, but do show that for the larger ERP platforms, integration is being explored and actively worked on. In order to benefit from either of these tools, one would have to migrate platforms and banks first, which is a significant effort and not a consideration of this document which is focusing on the Agresso application.

Whilst there is a lot of interest and noise around blockchain technologies with 805 articles on Google Scholar in 2018 (Browser, 2019) outside the industry there is caution, for example, the ECB defines crypto currencies as unregulated and decentralised and as such they are unsupported (ECB, 2018) by the ECB. Which is a cautious approach.

Blockchain technologies are starting to attract more measured responses, (Kashima, 2018) states that enhancing the accountability / transparency of algorithms is important but no panacea, implying that this is a continuum rather than an end in itself.

Certainly, the journey has seen the likes of algorithmic trading account for more than 50% or equity trades in the US and EU stock markets. Algorithmic trading being a form of ‘smart contract’. The technologies underlying the transactions may differ, but the principle of automated programs transferring property in the event of certain conditions being met is true. On that basis it is fair to consider the exercise a worthwhile one.

Removal of Intermediaries

The shift towards blockchain technologies comes from the removal of intermediaries. An intermediary being banks, lawyers, consultants and others. A computer program fulfils the whole lifecycle as shown in the following diagram from (SanjaySaigal, 2017) including concluding the contract and fulfilling the terms.

[pic]

Figure 2: Intermediaries lifecycle (SanjaySaigal, 2017)

The benefits of removing intermediaries are many:

Fraud prevention by using digital signatures supported by a consensus mechanism, ownership is agreed.

Reduction in Processing Time. The ability to save time in processing giving a better user experience and therefore improved brand loyalty and success.

Reducing the cost of a process. The benefit of reduced reducing costs through automation.

Code is cheaper than people and more reliable (Maltverne, 2017) You can trust the data and the process that runs on top of it, although that assumes that the data is captured correctly and also migrated correctly.

Removing intermediaries also makes new data available for analysis and opportunities for revenue Maersk using blockchain to ‘optimise freight flows by publicly identifying empty containers and finding takers for the extra capacity’ (Morris, 2017) although the analysis does not detail how successful it was or what the criteria for success were.

An additional benefit of smart contracts is that they do not need a third party judge to officiate instead the consensus protocol of the blockchain and its immutability and irreversibility are paramount.

Methodology

A test environment made up of windows technologies and the Agresso Demo application were installed on it and configured to contain an API interface to act as the originating source for the data used in the payment to be made on the Ethereum blockchain. Two Coinbase accounts were created and the interface created which was used to test the movement of currency between accounts as a representation of the payment process.

The API between Business World and Coinbase

The previous sections have highlighted the lack of available solutions for user of the Agresso ERP system to settle amounts using blockchain and crypto-currencies, so an alternative approach is needed if transactions are to be recorded on Ethereum.

In the absence of permission, the proposed solution will utilise the Coinbase DAPP as the API that will affect the transaction onto the Ethereum blockchain. The payment process from Agresso is shown in the following Figure 3.

[pic]

Figure 3: The payment process from Agresso

The output of the payment process outlined above is used to feed the API that takes the data from Agresso and imports it into Coinbase. We are only concerned with the ‘Remittance Process’ section of the process as it is this that generates the output file, albeit made up of values obtained from the previous stages. The data comes from the asutrans table. The asutrans table contains the invoice data as in the Figure 4.

[pic]

Figure 4: A typical asutrans table

In order to generate a file that contains acceptable values for processing by Coinbase, the following values need to be present. Figure 5 is an example request from the Coinbase developer’s forum.

[pic]

Figure 5: an example request from the Coinbase developers forum

The API_KEY and API_SECRET is set up in the management console of the Agresso application (shown below). The to, amount and currency values come from the payment process defined above, specifically the asutrans table.

The Setup

Before payment processing can begin, the following will need to be in place:

Creation of the API connector between the ERP system and the Ethereum blockchain.

Creation of a pseudo supplier account to receive the payment.

Creation of an account on Coinbase used to transact in Ethereum

Customised export table from Agresso

A 3rd party intermediary between the ERP system and the Ethereum block chain is necessary in order to convert the currency from GBP to Ether. Coinbase also has a pre-built API which can be

used to connect the two systems, however due to the limitations previously mentioned and the Agresso application not having an existing API that could provide the information, it has not been possible to build the API, although the following is an example of the API code that could be used.

The API

The API between Agresso and Ethereum will be via Coinbase. In order to configure Agresso, the Api key and Api secret will need to be configured, but before that the Web_API server will need to be created in the following screen (Figure 6) of the management console of Agresso.

[pic]

Figure 6: management console of Agresso

Once the server has been created and configured appropriately, the authentication method can be defined to contain the scope secret created by the Agresso identity manager which will allow communication with the Coinbase application, as seen in Figure 7.

[pic]

Figure 7

From the Coinbase side the authentication is managed by creating a new Oath2 application, Figure 8.

[pic]

Figure 8

When not using API, the Agresso application will need a ‘redirect’ in the GET message as shown here in an excerpt from the Coinbase developers forum.

GET

e9c4654e7f97ed40194a1547e114ca1c682f44283f39dfa49&redirect_uri=https%3A%2F%2Fexamp %2Foauth%2Fcallback&state=134ef5504a94&scope=wallet:user:read,wallet:accounts:read

The Coinbase application will then redirect back to the Agresso application via a call-back.

GET

a2c2a590cc7e20b79ae8&state=134ef5504a94

Now we have the code it can be exchanged for access tokens by using a POST call, as shown in this example of a request

curl \

-X POST \

-d 'grant_type=authorization_code&code=4c666b5c0c0d9d3140f2e0776cbe245f3143011d82b7a2c 2a590cc7e20b79ae8&client_id=1532c63424622b6e9c4654e7f97ed40194a1547e114ca1c682f442 83f39dfa49&client_secret=3a21f08c585df35c14c0c43b832640b29a3a3a18e5c54d5401f08c87c8 be0b20&redirect_uri='

The access token is returned in the response:

{

"access_token":

"6915ab99857fec1e6f2f6c078583756d0c09d7207750baea28dfbc3d4b0f2cb80", "token_type": "bearer",

"expires_in": 7200, "refresh_token":

"73a3431906de603504c1e8437709b0f47d07bed11981fe61b522278a81a9232b7",

"scope": "wallet:user:read wallet:accounts:read"

}

In this section, the payment channel between Agresso and the Ethereum blockchain was constructed.

Results Analysis and Evaluation

This research has reviewed the API creation and how well it and the technology meet the criteria for a viable payment alternative to existing payment solutions using intermediaries.

Focus on whether smart contracts can resolve some of the issues identified in the previous research

is discussed here. The problem of not being allowed to use Agresso meant that only one side of the process can be addressed, that of the smart contract payment and not the automated interface that generates the payment. In light of that restriction, a manual payment was made. A payment was manually sent in GBP from Agresso to the Ethereum blockchain via Coinbase. The primary indicator of fitness for purpose is whether the interface has achieved it’s intended goal. The goal was to enable a payment in GBP from the Agresso ERP system to be sent to a 3rd party using a crypto currency specifically Ether. A transaction was created using the public key

[pic]

Using the Block Explorer to check that the transaction appeared in the blockchain.

[pic]

Which has the following transaction

[pic]

From the evidence above, it can be concluded that the objective has been met. Existing payment methods involve a third party in the form of a bank, this solution also involves a third party in the form of Coinbase so the proposed solution has the same number of ‘actors’ and as such cannot be called more efficient. Had the process negated the need for an intermediary, it would have been more efficient.

Existing system make payments from GBP to GBP and do not involve a currency translation, e.g. a payment in GBP and the supplier also receives a GBP payment. The solution proposed involves a conversion to ETH from GBP when making the payment and also a conversion from ETH to GBP when it is received, so introducing an element of gain / loss into the process that does not exist in the current process. On that basis, it seems fair to state that the proposed process is riskier than the current one and therefore, not as good. In the event of ETH becoming more popular as a settlement currency the need to convert it back to GBP will reduce and balances can be kept in ETH and transactions can be executed only in ETH so reducing the exposure to gain / loss, however that future is not a certainty and it would be risky to assume it will come about.

The proposed solution requires the holding of reserves of Ether in order to pay for the ‘gas’ to effect the transaction which is analogous to per transaction bank charges, so there is no change there, although the fact the balance is in another currency, means that the balance at the end of a period will need to be translated back into GBP and stated in the accounts. Holding cash in order to transact is not an efficient use of capital, so it could be argued that the process is not as good as the existing method. Transaction costs will be incurred when a transaction is executed, where the holding of a balance of ETH means that money can’t be used elsewhere and also that it represents a pool of charges that may be incurred, the money is ’prepaid’ not paid when executed.

The evidence above suggests that there will be few advantages for efficiencies in a business process, but will smart contracts really save any effort overall?

In a paper by (Combs, 2018) which proposes that smart contracts will require multidisciplinary teams of lawyers, software developers and coders which is a new way of working that Combs calls a ‘new practice model’ implying that the effort used to define and create existing business processes will be expended in other areas. Overall effort will not reduce. This suggests that overall effort may increase given that adoption of new technologies will sit alongside existing legacy technologies.

The Security Implications of Smart Contracts

In a paper by (loi lu, 2016) which investigates the security of running smart contracts based on Ethereum in open distributed networks like those of cryptocurrencies. The paper identifies several new security problems where the adversary can manipulate the smart contract for profit. The refinement in the paper is to propose ways of enhancing the operational semantics of Ethereum to make contracts less vulnerable, which is something that the proposed solution deliberately avoids by keeping the details of the transaction within the ERP system and using the Coinbase product to act as the transaction execution device, which acts as a mitigation of the risk from poor coding of a smart contract or a vulnerability in the blockchain itself. A sentiment echoed by (Song, 2018) who comments that ‘Smart contracts are simply too easy to screw up, too difficult to secure, too hard to make trustless and have too many external dependencies to work for most things’ and goes on to state that ‘The only real place where smart contracts actually add trustlessness is with digital bearer instruments on decentralized platforms like Bitcoin’ or in our case, Ether. Which can be interpreted as a validation of the approach.

The purpose of the research was to understand smart contracts and how they relate to blockchain technologies and whether a practical interaction with existing legacy systems to transact payments in Ether is possible and if so, how it can be achieved. The question is an important one because it seeks to explore the possibility of combining legacy and existing ERP solutions with new technologies in the form of payments on the Ethereum blockchain.

The discussion initially outlined the origins and history of smart contracts which showed how the theory has evolved and developed from being a solution to a digital signature problem to a much broader use case and the creation of solutions that touch many aspects of business and law, as well as new problems that need to be solved. After that came the problem statement where the Agresso application needed to be set up and configured and a transaction submitted via Coinbase onto the Ethereum blockchain.

One of the objectives of the exercise was to understand smart contracts and by exploring the origins of the technology and how it has evolved into its current state has given an invaluable degree of perspective and an awareness of the limitations of the technology that can inform future use cases. The analysis process was challenging having encountered many difficult choices and decisions, especially when refusal to create an API within the Agresso application meant the creation of the API was a theoretical one; however, the data generated in the form of a payment that was entered into Coinbase and appeared on the Ethereum Blockchain was valuable.

Conclusion

It is possible to have an interface between the existing ERP systems and the Ethereum blockchain. Building an interface between the two is relatively straightforward when using third party products like Coinbase with its existing API library and functionality, however there are many barrier to adoption which include the cost of transacting with Blockchain, the additional complexity introduced to the organisation through having to have an additional interface to support, the financial risk associated with holding balances in non-domestic currencies e.g. Ether, the risk of transacting using a platform that is vulnerable to attack, the risk of change brought on by the regulation of an unregulated environment either by governments or through the execution of contract law, all introduces a degree of risk that a business would need to decide if it is acceptable or not.

This paper explored the origins and evolution of smart contracts. Future research should explore the interaction with an ERP system, which logically can be extended to:

Where can and should they go next?

Exploration into the value of using smart contracts and blockchain technology as complete alternatives to ERP systems?

Is using a third party service provider for payments (Coinbase) better than building your own Blockchain interface?

Can smart contracts be a viable and practical solution to cross border payments between UK and EU countries post Brexit?

Can on block and off block payment methods be combined into one payment method that can cope with lots of frequent low value transactions as well as infrequent ones?

Reference

Annesley, G. (2018, Jun 22). the enterprise journey to blckchain. Retrieved from

supplychainbeyond: 3/

baucherel, K. (2018). Blockchain from Hype to Help. BCS ITNow(Winter 2018), 4-7.

Bloomberg. (2015). Bloomberg. Retrieved December 15, 2018, from on-time

Browser. (2019, May 18). Google Scholar. Retrieved from Google:

, 5

Buterin, V. (2013). etherium white paper . Retrieved from :

a_next_generation_smart_contract_and_decentralized_application_platform-vitalik-buterin.pdf Casado-Vara, R., Briones, A. G., Prieto, J., & Corchado, J. (2019, Mar 23). researchgate. Retrieved from researchgate:

ntrol_of_Logistics_Activities_Pharmaceutical_Utilities_Case_Study

Catherine Mulligan, j. Z. (2018). Block Chain Beyond the Hype. Retrieved December 15, 2018, from



Combs, C. (2018, Feb 14). LinkSquares. Retrieved from IMF: Community, T. E. (2016). account types gas and transactions. Retrieved from ethdocs: transactions.html

Dossman, J. (2018, Nov 29). blockchain explained with pokemon cards. Retrieved from Medium:

ecdd90e4297a?source=emailShare-f065c1a9fe89- 1553759867&_branch_match_id=640855061846909908\

ECB. (2018, Mar 23). Explainers. Retrieved from What is bitcoin:



Emsley, J. (2018, Nov 8). Exclusive Interview: A briefing with Scott Stornetta. Retrieved from : founding-father-of-blockchain/

Ethereum Community. (2016). Contracts and Translations. Retrieved from Ethereum Homestead: transactions.html

ethereum organisation. (2019, Apr 25). platform. Retrieved from state of the dapps:

Foundation, T. S. (2016-2019). micro-payment channel. Retrieved from solidity.readthedocs.io:

Frantz, C. K., & Nowostawski, M. (2016, Sep 10). From Institutions to Code: Towards Automated Generation of Smart Contracts. Retrieved Dec 15, 2018, from

Fridgen, G., Radszuwill, S., Urbach, N., & Utz, L. (2018). Cross-Organizational Workflow Management Using Blockchain Technology - Towards Applicability, Auditability, and Automation. Retrieved Dec 15, 2018, from

GTNexus. (2016). gtnexus. Retrieved Dec 15, 2018, from MCL-531/images/GTNexus-Digital-Transformation-Report-US-FINAL.pdf

IBM. (2018, Jan 28). Insights on Business. Retrieved from Oracle Consulting: blockchain/

Infosys. (2018). Integrating blockchain erp. Retrieved from white papers:

Jesse Yli-Huumo, D. K. (2016). Where Is Current Research on Blockchain Technology?—A Systematic

Review. Retrieved Dec 15, 2018, from Johnson, S. (2018, Jan 16). Beyond the Bitcoin Bubble. Retrieved from nytimes:

Joseph J. Bambara, P. R. (2018). Blockchain - A Practical Guide to Developing Business, Law and Technology Solutions (1st ed.). McGraw- Hill Education.

Kari Korpela, J. H. (2017). Digital Supply Chain Transformation toward Blockchain Integration. Retrieved Dec 15, 2018, from

Kashima, M. (2018, Sep 25). IMF Conferences. Retrieved from : financial-stability

Kristian Lauslahti, J. M. (2017, Jan 9). ETLA Research Institute of the Finish Economy. Retrieved from ETLA:

Kulkarni, A. (2018, Apr 19). Blockchain versus ERP systems. Retrieved from :

chain-management-4486c12d56b2

loi lu, d.-h. c. (2016, Aug). eprint. Retrieved from cruptology eprint archive:



Maltverne, B. (2017, Jul 17). Capgemini Consulting. Retrieved from Medium: procurement-d38cfd5446fa

McConnell, P. (2019). Blockchain Examining the Technical Architecture. IT Now, 38-41.

Mearian, L. (2018, Jan 5). ethereum explores a fix for blockchain. Retrieved from computerworld: performance-problem.html

Merit Kolvart, M. P. (2016). The Future of Law and eTechnologies. In M. P. Merit Kolvart, The Future of Law and eTechnologies (pp. 133-146). Wiley.

Morris, D. Z. (2017, marcg 5). . Retrieved from Fortune:

Nakamoto, S. (2008, Oct 31). bitcoin. Retrieved from nakamotoinstitute:

Nakamoto, S. (2008). Bitcoin Whitepaper. Retrieved December 15, 2018, from

Norta, A. (2019, Mar 2). Creation of Smart Contracting Collaborations for Decentralized

Autonomous Organisations. Retrieved from ResearchGate: Contracting_Collaborations_for_Decentralized_Autonomous_Organizations . (2018). Blockchain technology saves global supply chains. Retrieved Dec 15, 2018, from supply-chains/48170/

pymnts. (2018, Oct 24). Oracle ERP Accelerates Treasury Transactions With Citi Integration.

Retrieved from : citi-treasury-api-banking/

Roberto Casado-Vara, A. G. (2018, june 7). Smart Contract for Monitoring and Control of Logistics Activities: Pharmaceutical Utilities Case Study. Retrieved dec 15, 2018, from

SanjaySaigal. (2017, May 22). sdcexec. Retrieved from Supply Chain Finance on the Blockchain:

the-blockchain-enables-network-collaboration

SHARMA, T. K. (2018, Jan). WHAT ARE THE ALTERNATIVE STRATEGIES FOR PROOF-OF-WORK.

Retrieved from Blockchain Counccil: the-alternative-strategies-for-proof-of-work/

Sillaber, C. (2019, 03 23). Life Cycle of Smart Contracts in Blockchain Ecosystems. Retrieved from Springer Link:

Sokolov B., K. A. (2018, 8 29). Comparison of ERP Systems with Blockchain Platform. Retrieved dec 15, 2018, from

SOng, J. (2018, Jun 11). the truth about smart contracts. Retrieved from medium: ae825271811f?source=emailShare-f065c1a9fe89- 1553760069&_branch_match_id=640855061846909908

Stefan Schmidt, M. J. (2018, Feb 26). Unibright White Paper. Retrieved from unibright:

Stuart Haber, W. S. (1991). Retrieved from anf.es:

Szabo, N. (1997). The Idea of Smart Contracts. Retrieved from fon.hum.uva.nl: ool2006/szabo.best.idea.html

Szabo, N. (2002). A Formal Language for Analyzing Contracts. Retrieved from fon.hum.uva.nl: ool2006/szabo.best.contractlanguage.html

Szabo, N. (2019, Mar 23). Smart Contracts: Building Blocks for Digital Markets. Retrieved from Smart Contracts: Building Blocks for Digital Markets: ool2006/szabo.best.smart_contracts_2.html

Thomson Reuters. (2019). Glossary. Retrieved from uk.practicallaw: 6271?transitionType=Default&contextData=(sc.Default)&firstPage=true&comp=pluk&bhcp=1

UK Gov. (1998). Late Payment of Commercial Debts (Interest) Act 1998. Retrieved Dec 15, 2018, from

UNIDROIT. (2018, Mar 27). Article 2.1.2 Manner of Formation. Retrieved from UNIDROIT: chapter-2-formation-and-authority-of-agents-section-1-formation/875-article-2-1-1-manner-of- formation

Wittenberger, J. F. (2002, Apr 21). Retrieved from :



................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download