Blockchain platform for trade contracts transactions based on smart contracts

On June 22, 2017, at Blockchain & Bitcoin Conference in St. Petersburg, our blockchain analyst, Marina Smancer, reported on the results of a research project to create an integrated platform for trade financing transactions based on smart contracts.

The 20-minute report format did not allow detailed technical aspects. Therefore, Raiffeisenbank’s access to habrahabr is a great opportunity to talk about our results in all details.

I note that the article is intended for the reader to understand the main aspects of the blockchain technology and the principles of operation of smart contracts. Since the review on each topic is a volume for a separate article, we look forward to understanding the community.

The first part will tell about the case with letters of credit, which we used, and how the platform was designed for the blockchain.
')
The second part is most saturated with technical details: the implementation of the platform (selection and integration of its components) and smart contracts for the letter of credit will be considered in detail. It will also describe step by step the process of settling the letter of credit through smart contracts.

In the third part, a lot of code: separate methods of smart contracts, the specification of its own provider of external requests (oracle) and a bonus for the community: an open API for testing it. Summarizing this section, we will talk about the problems with the components of the platform that we had to overcome.

In the final, let us dwell on the results of the project with the letter of credit, and on what the study of the development of decentralized technologies has shown regarding their use in banking.

We made the decision to highlight in detail our experience with the blockchain. Blockchain is a story about interaction and collaboration. A lot of projects appeared and developed thanks to the efforts of enthusiasts. All technologies are new, and there are enough difficulties with their use. We will be happy if our story becomes a useful source of knowledge.

Gelbplaneten actively participated in the preparation of the article .

Briefly about goals and results

At the end of 2016, the blockchain was in the zone of interest of our R & D department. It took some time to dive into the theory, after which we decided that it makes sense to make a practical implementation.

We considered several areas of the banking business as potential options: from optimizing internal business processes to managing collateral for transactions. In the area of ​​trade finance, we found an immediate interest from corporate businesses and customers, so it was decided to work it out in detail.

Specifically, we decided to stay on the letter of credit. In its simplest form, it implements a fairly simple to understand logic, while covering many aspects of transactions from a selected area.


The goal of the project is to investigate how technologically ready the blockchain is for real business cases from the field of trade finance. This also applies to the maturity of technology in its pure form, and the ability to transfer the process from corporate business to the blockchain, while maintaining its level of complexity. The second includes both the legal component for conducting transactions and the requirements for the reliability and security of the system.

We focused on open solutions, in particular, public Ethereum was chosen as the blockchain. Other technologies will be discussed in detail later in the article.

As a result, we developed a software platform that combines blockchain, decentralized repositories, external data sources and an API level to internal bank systems into a comprehensive solution. A detailed analysis of the most diverse applications of the blockchain in the bank, which we carried out before the launch of the project, helped design a modular and easily adaptable system. And although we were developing, focusing on a very specific business case (letter of credit), the modularity of the platform allows it to be used for other business solutions that use standardized terms of transactions (stocks, bonds, registration of pledges, exchange derivatives).

Tasks of a research project

As already mentioned, the study was tasked to determine the possibility of implementing trade finance transactions in the existing blockchain-ecosystem. By ecosystem we mean a set of technologies, including as a base both the implementation of the blockchain itself and various add-ons to them: interaction protocols and file exchange, libraries, distributed storages, etc.

In this case, it was intended to use solutions that came out in a stable version or are at the readiness stage close to the implementation. In the course of the study, it was intended to determine the conditions for successful integration of the selected technologies in a single platform together with the bank’s accounting systems, as well as to identify the obvious and hidden problems of such integration.

To determine the necessary functionality for the implementation of the platform, the following initial conditions were set:

• The execution of the transaction is accompanied by the exchange of documents between the parties.
• The main settlement of the transaction is made through ordinary (fiatnye) channels of calculation
• All transactions in a transaction must be as legally confirmed as possible, based on current regulatory documents and regulations (to ensure judicial practice “right now”)
• All operations and transition signals between operations should be as automated as possible.

The general scheme of the platform and the interaction of its elements

Architecture and interaction of platform components

The analysis of the baseline implies the need to use the following functional components:

• Blockchain - as a trusted registry of transaction operations and a smart contract execution environment providing a transaction
• Decentralized file storage (DFS) - as a medium for storing and exchanging files associated with a transaction
• Certified CIPF - as a means of providing additional encryption, legally significant electronic signatures and protected timestamps. In addition, it can be used to organize an additional virtual file access distribution layer if DFS does not support multi-user access mechanisms.
• Oracles and providers of external requests - for access to the accounting systems of the bank and sources of events of the outside world (registries, etc.)
• Document analyzers - for automatic analysis of documents submitted by the parties to confirm the terms of the transaction.

Considering that the basic calculations and analysis of documents in the realities of today are performed outside smart contracts, only data that they are able to process are transferred directly into smart contracts. The remaining information (justifying and administrative documents) is attached in the form of ordinary (for manual processing) or formalized (for automatic processing) documents signed by a strengthened qualified electronic signature to ensure legal significance.

In this case, the following logic may be assigned to the internal logic of a smart contract:

• Ensuring that the status matrix is ​​followed according to the current status and the initiator of the switching transaction
• Date control for limiting the period within which documents can be submitted
• Handling the occurrence of pivot events coming from External Request Providers

The following registration information was associated with each user of the platform:

• Unique identifier in the system
• Ethereum address from which the user sends transactions
• Address of the smart contract used to maintain a register of transactions owned or sent to the user (hereinafter referred to as the Mailbox)
• Identifier of the certificate of a strengthened qualified digital signature and its public key

The simplest explanation of the concept of oracles: blockchainhub.net/blockchain-oracles
There was no good article on DFS, I’ll leave a link to the Swarm documentation: swarm-guide.readthedocs.io/en/latest/introduction.html
And Storj: storj.io

Practical implementation

The figure below shows the general scheme of the platform and the main data exchange flows between its functional components (with green marked “alien” components, purple - certified, white - Bank software):


In the process of preparing and executing a transaction, the components of the platform interact as follows:

• Client software (for example, client-bank or mobile bank). Used to enter the initial information on the transaction, create the necessary smart contracts and manage the status of smart contracts at the manual stages of the business process. It should be noted that the manual steps of a business process can be understood as those steps that require real “personal” user actions - for example, attaching documents to a smart contract, and generally any steps at which changing the status of a smart contract is done without using its internal logic is outside the blockchain. The latter case includes checking the documents attached to the smart contract on the bank's accounting systems, which can occur automatically, but outside the blockchain.
  
  
• The files attached to the smart contract are signed by a reinforced qualified EDS creator for his (the creator) unambiguous legally significant identification. Further, the files are encrypted with the formation of a crypto package that can only be decrypted by the participants in the transaction. The resulting crypto packet is placed in DFS, while the context of the smart contract is preserved in the hash of the source file, as well as the address (link, manifest) of the storage object given to DFS. The address of the storage object allows you to extract the crypto packet from the DFS, decrypt it (the participants in the transaction) and process it properly.
  
  
• When processing transactions, a smart contract can use information from Broadcast oracles, for example, control the date of receipt of a transaction on a calendar, use currency rates, etc.
  
  
• When switching to a certain status, a smart contract may send a specific request to an external request provider for an expected external event or an order to execute an external action. When an external event “ordered” by a smart contract occurs, the Provider sends a transaction with event information to it. According to the results of processing this transaction, the smart contract may switch to a new state or remain in the same condition pending the onset of subsequent events.
  
  
• Similar to external requests, when you attach certain formalized documents to a smart contract, a smart contract can send them to the Document Analyzer for analysis, and then wait for a transaction with the results of the analysis.

Implementation of smart contracts for letter of credit

It was decided to start designing the platform in parallel with the development of a business case for implementation.

A simplified scheme of the process on the blockchain is presented in the figure, and a detailed description of the process is given below.



The participants in the transaction are the Buyer, the Seller and the Bank. The buyer and the seller enter into a contract for the provision of certain services or goods, and the fact of their provision can be identified automatically. For example, if a letter of credit is opened for settlements when transferring ownership of real estate, shares, shares, etc., information will be checked in submitted documents against information in external sources (for example, in the unified state register of real estate). Further operational support of the transaction is carried out through the Platform.

1. The buyer creates a smart contract "Application for letter of credit" (hereinafter referred to as "Application"), which receives the status of New .
   
   The address of the Application is placed in the Mailboxes of the Buyer and the Bank.
   
   
2. The buyer attaches to the Application a formalized document describing the details of the transaction and the necessary non-formalized documents, for example, a scanned copy of the contract for which the letter of credit is opened.
   
   After attaching all the necessary documents, the Buyer transfers the Application to InBank status.
   
   
3. The bank automatically (for formalized ED) or with the use of experts (for unformalized ED) checks the transaction. For example, a request is sent to the bank systems for checking client details in the client data catalog, for confirming the account balance and reserving funds for other checks (for example, checks for compliance, currency control, etc.)
   
   If the Bank has any claims regarding the content of the transaction or the attached documents, it refuses to accept the Application and establishes the status Rejected .
   
   If the Bank agrees to accept the application for execution, the Confirmed status shall be established.
   
   
4. On the basis of a formalized ED describing the transaction, the Bank’s accounting systems perform the necessary manipulations (transfer of the amount of the letter of credit from the client account to the “coverage account”, charge-off, etc.)
   
   The Bank issues a smart contract "Letter of Credit" (hereinafter referred to as Letter of Credit), which receives the status of New .
   
   The address of the letter of credit is placed in the mailboxes of the Bank and the Seller.
   
   The Letter of Credit preserves the address of the Application, which allows you to automatically “mirror” the key statuses of the Letter of Credit on the Application, so that the Buyer can monitor the status of the transaction.
   
   
5. The Bank attaches to the Letter of Credit a formalized ED (automatically generated from the conditions of the Application) with a description of the details of the transaction, other necessary documents and establishes its Released status.
   
   The status of the L / C Application is also switched to Released .
   
   When switching to Released status, the Letter of Credit automatically places two requests into the External Request Provider's queue:
   
   
   • Request to control the expiration of the Letter of Credit (triggered when the current date exceeds the term of the Letter of Credit)
   • Request to wait for the execution of the contract (the specific request template is determined by the content of the transaction)
6. The seller, after studying the issued Letter of Credit, may refuse to accept it: in this case, he transfers it to Invalid status, the letter of credit is canceled, and further manipulations with it become impossible.
   
   The status of the L / C Application is also switched to Invalid .
   
   
7. If the event of expiration of the Letter of Credit is the first to be triggered, then it receives the status of Overdue and further manipulations with it become impossible.
   
   The status of the L / C Application is also switched to Overdue .
   
   In this case, automatic orders are sent to the accounting systems of the Bank to initiate transactions that correspond to the cancellation of the letter of credit (return of coverage, termination of the bank’s obligations, etc.)
   
   
8. If the first event is the execution of the contract (or when the Seller attaches the ED, stipulated by the conditions of the Letter of Credit) - the Letter of Credit switches to InBank status. When switching to InBank status, the Letter of Credit automatically places a request in the External Request Provider's queue to wait for payment and removes the expiration control request from the queue.
   
   The Bank, on the basis of a formalized ED attached to the Letter of Credit, makes a payment in favor of the Seller by submitting the order to its settlement system and executing the Payment outside the blockchain (information on the actual execution of the Payment is returned to the blockchain).
   
   
9. After the execution of the payment execution event, the Letter of Credit switches to Closed status.
   
   The status of the L / C Application is also switched to Closed .
   
   
10. The transaction is completed.

Selection of platform components

When choosing the functional components of the platform, we focused on open solutions (Ethereum, Swarm, Storj). This is due to the following advantages:

• Presence of the developed and "self-supported" infrastructure
• Openness to users and the ability to control operations through alternative sources, not only through the interface offered by the bank
• High level of user confidence due to the presence of competitive consensus protocols and high-quality “non-tolerant” network of independent nodes

Thus, the choice was made in favor of the following implementations:

• Blockchain and smart contracts - Ethereum and Solidity;
• Decentralized file storage - Swarm and Storj.io;
• Certified SKZI - CryptoPRO and CryptoARM;
• Broadcast Oracle - own development;
• External requests providers are proprietary;
• Document analyzer - at this stage it was decided not to consider, since the principle of interaction with it of a smart contract is generally similar to the Provider of external requests, and the resources of the research team are limited.

Infrastructure

To deploy the necessary components:

• Ethereum, Swarm and Storj.io client parts,
• SKZI,
• Provider external requests
• UI applications
• Integration Core Platform

2 servers were allocated.

On the first server, the Ethereum node of the base blockchain of smart contracts was deployed. Initially, the Ropsten test network was used as the base blockchain, but in the final stages we switched to a more stable Rinkeby. The reason for this was the March incident with the DDOS attack on Ropsten , during which several days there were problems with the addition of transactions.

On the second server, the infrastructure was deployed to work with the files:

• DFS node Storj.io
• DFS Swarm with Ropston Ethereum
• SKZI CryptoPRO and CryptoARM

In addition, for reasons of convenience, the integration core of the platform was deployed there.

The provider of external requests was deployed on each of the servers and could, if necessary, run on any of them.

The UI application could be launched either on any of the servers, or use a special proxy protocol for working over the Internet.

Integration of components

Ethereum

Integration with the Ethereum blockchain was carried out using the RPC API JSON-RPC , Management-APIs .

There were no technical problems with its use.

As an external arbitration resource, ropsten.etherscan.io or rinkeby.etherscan.io was used , depending on the test network used.

Swarm

Integration with Swarm was carried out using the HTTP API: Swarm-guide , gist.github.com .

An HTTP PUT / bzz request was used to upload the file to SWARM : $ PATH $ ($ PATH $ is the path to the downloaded file).

in response to which came the 16th identifier of the manifest of the file that was used to extract it from the SWARM.

To retrieve a file from SWARM, an HTTP GET / bzzi request was used: / $ MANIFEST $ / ($ MANIFEST $ is the hexadecimal identifier of the manifest of the extracted file).

There were no problems with uploading / uploading files.

Unfortunately, no external monitoring tool (such as Etherscan for Ethereum) was found for Swarm, which in some way made it difficult to evaluate the success of file manipulations.

Storj.io

Integration with Storj using the proposed API by the developer turned out to be extremely difficult and inconvenient. As a result, the Storj node console was used to work with files.

To download the file, use the storj upload-file $ BUCKET $ $ PATH $ command (where $ BUCKET $ is the “basket” identifier, and $ PATH $ is the path to the file being downloaded).
Upon successful upload, the identifier of the uploaded file was given in response.

To upload the file, use the storj command download-file $ BUCKET $ $ FILE $ $ PATH $ (where $ BUCKET $ is the “basket” identifier, $ FILE $ is the file identifier, and $ PATH $ is the path to the local copy of the file).

The peculiarities of Storj include the fact that more than one file with the same name cannot be put into one “basket”, which requires the use of a mechanism for generating unique names when loading.

You can use https://api.storj.io as an external arbitration resource, which supports the API.

CryptoARM

Integration with CryptoARM was carried out using the COM-service it provides. For quick implementation, integration scripts were written on vbs.

External Request Provider

The interaction of smart contracts with the External Requests Provider is performed as follows.

To the benefit of the community

For those who want to try the technology of tracking external events and working with oracles and providers of external requests, we have deployed on the Ethereum Rinkeby network:

• Calendar oracle (gives the current date in Moscow)
• External Request Portal

Calendar oracle

The Oracle calendar is located in the Rinkeby test network at 79548a65e3ce179ec8d208c22ee84435dc34058f and gives the current calendar date in Moscow in the format YYYY / MM / DD.

An example of an appeal to the Oracle:

contract Check_request
{
Calendar Oracle ; // -
bytes32 Date ;
function Check_request()
{
// -
Oracle=Calendar(0x79548a65e3ce179ec8d208c22ee84435dc34058f) ;
//
Date=Oracle.GetDate() ;
}
}

//
//
//
contract Calendar
{
function GetDate() constant returns (bytes32 retVal) ;
}

External Request Portal

The queue of the smart contract of the External Requests Portal is located on the Rinkeby test network at d9b076d0b559f70782f379582bd3d54b85fc42cb .

The protocol for interacting with the External Request Portal is described above. The following query templates are currently open to the public:

• OVERDUE - control of the delay of the date, the request parameter - the date of the delay in the format YYYY / MM / DD
  The event transaction is transmitted to the requesting smart contract at the time of detection of the delay date and contains the current date.
• WEATHER_TEMP - Current temperature request (via the portal api.openweathermap.org ), query parameter — name of the city, for example, Moscow (details can be found on the source portal).
  The event transaction is transmitted to the requesting smart contract at the time of receiving the response from the source portal.

To access the External Requests Portal queue, you must tell us (in a comment or in a personal note) the address of the Ethereum account from which queuing transactions will be sent.
It is advisable to apply 0.1 Ether to the transaction (this is free, we are in a test network) to debug the mechanism of paid services. In Rinkeby, you can get air only with the help of a faucet , due to the lack of mining opportunities due to the PoA protocol.

Some comments on the experience of integrating third-party components.

Ethereum

When implementing paid services for smart contracts, it would be extremely useful to be able to execute transactions at the expense of the “accepting” smart contract, and not at the expense of the transaction initiator (of course, if the smart contract is in any way agreed to this - for example , due to the mechanism of trusted addresses or something like that). This will greatly simplify the mechanisms for calculating the “services”, since the initiator of the transaction also pays for the execution of the smart contract method, the cost of which (execution) cannot always be determined in advance.

Ethereum solidity

The development of non-trivial scenarios that interact with the "outside world" is greatly complicated by the lack of built-in functions for working with strings - concatenation, search, and fragment cutting.

Ethereum swarm

It is highly desirable to have, like the main Ethereum, a mechanism for confirming the download of a file to the Swarm (its distribution to other nodes) is similar to the confirmation of a transaction. For it is unclear whether the file is saved somewhere outside your node or not.

Building from sources and deploying a Swarm node for Windows is an extremely trivial task. The developers have tested and prepared documentation only for linux and OSX, which they honestly admit.

Storj.io

Extremely difficult to use, too detailed API. For simple integration, it is desirable to have an “integrated” API, similar to that implemented in Ethereum Swarm - put the file, extract the file.

Missing multi-user file access. That is, the file can be read only from under the account details under which it was recorded. This leads to the fact that for the organization of multi-user file sharing it is necessary to actually “disclose” your account details, which, given the payment for the service, is not a good practice.

The findings of the study

At present, the components of the blockchain ecosystem that are productive or close to production can fully realize the functionality necessary to support the execution of trade finance transactions.

Of course, there are certain non-technical issues that need to be resolved in order to be able to talk about the implementation of large projects for trade finance (and indeed many areas close to it in terms of objectives) on the blockchain.

Firstly, the legal issues of transactions carried out through the blockchain, including the legal status of entries in the blockchain.

Secondly, now in Russia, the use by banks of public blockchains is actually blocked by the position of the regulator in relation to cryptocurrencies: the ban on their use makes it impossible to pay a fee for adding a transaction (transaction fee). Transactions in this case are needed not for settlement, but as a way to create smart contracts and interact with them.

Thirdly, it is necessary to standardize the formats of electronic documents for the possibility of their automatic verification.

Finally, the blockchain ecosystem needs to be saturated with sources of external events: oracles to various registries, information systems of banks and transport companies, etc. This will help eliminate the need for manual entry of external events and make the execution of smart contracts truly automatic and depersonalized.

It becomes obvious that in such projects the technical side is not the most significant part of the work. Now that the development has been completed, we continue to work with lawyers and work with other banks on approaches to defining unified requirements for electronic document formats to automate the verification of their content.

The case with the letter of credit allowed us to get both the technical base and the experience of implementing decentralized applications in the field of TF. Now we are looking at several areas in which we are interested in making a pilot, we will tell about them later.

Stay tuned!