スマートコントラクトに基づく貿易金融取引のためのブロックチェーンプラットフォーム

2017年6月22日、 サンクトペテルブルクで開催されたBlockchain＆Bitcoin Conferenceで 、ブロックチェーンアナリストのMarina Smantserが、スマートコントラクトに基づく貿易金融取引の統合プラットフォームを作成するための研究プロジェクトの結果について報告しました。



レポートの20分形式では、技術的な側面を詳細に説明していませんでした。 したがって、Raiffeisenbankのhabrahabrへのアクセスは、結果について詳細に説明する絶好の機会です。



この記事は、読者がブロックチェーン技術の主要な側面とスマートコントラクトの原則を理解できるように設計されていることに注意してください。 各トピックのレビューは別の記事の巻であるため、habrasocietyを理解することを楽しみにしています。



最初の部分では、私たちが使用した信用状のあるケースと、ブロックチェーン上でプラットフォームがどのように設計されたかについて説明します。



2番目の部分は、技術的な詳細で最も飽和しています。プラットフォームの実装（コンポーネントの選択と統合）と信用状のスマートコントラクトが詳細に検討されます。 また、スマートコントラクトによる信用状の下での決済プロセスを段階的に説明します。



3番目の部分には、多数のコードがあります。スマートコントラクトの個別のメソッド、外部リクエストの独自のプロバイダー（oracle）の仕様、およびコミュニティのボーナス：テスト用のオープンAPIです。 このセクションの結果をまとめると、克服しなければならなかったプラットフォームコンポーネントの問題について説明します。



最後に、信用状でプロジェクトの結果と、分散技術の開発の研究が銀行業への応用に関して示したことについて説明します。



ブロックチェーンの経験をできる限り詳細にカバーすることにしました。 ブロックチェーンは、相互作用と協力についての物語です。 愛好家の努力のおかげで、多くのプロジェクトが登場し、発展しています。 すべてのテクノロジーは新しいものであり、それらを使用する際には十分な困難があります。 私たちの物語が有益な知識源になれば嬉しいです。



Gelbplanetenは、記事の準備に積極的に参加しました

目標と結果について簡単に

2016年の終わりに、ブロックチェーンはR＆D部門の関心領域に落ちました。 理論上の没入には時間がかかり、その後、実用的な実装を行うことが理にかなっていると判断しました。



銀行業務のいくつかの領域を潜在的なオプションと考えています。内部ビジネスプロセスの最適化から、取引の担保管理まで。 貿易金融の分野では、企業や顧客からすぐに関心が寄せられたため、正確に解決することが決定されました。



具体的には、信用状にとどまることにしました。 最も単純な形式では、選択した領域からのトランザクションの多くの側面をカバーしながら、理解するためのかなり単純なロジックを実装します。





このプロジェクトの目標は、貿易金融の分野の実際のビジネスケースでブロックチェーンがどの程度技術的に進歩しているかを調査することです。 これは、最も純粋な形のテクノロジーの成熟度、および複雑さのレベルを維持しながらブロックチェーンプロセスを企業ビジネスからシフトする機能にも適用されます。 2番目には、トランザクションを実行するための法的コンポーネントと、システムの信頼性とセキュリティの要件の両方が含まれます。



オープンソリューションに焦点を当てました。特に、パブリックイーサリアムがブロックチェーンとして選択されました。 他の技術については、この記事の後半で詳しく説明します。



その結果、ブロックチェーン、分散ストレージ、外部データソース、および銀行の内部システムに対するAPIレベルを組み合わせて包括的なソリューションを提供するソフトウェアプラットフォームを開発しました。 プロジェクトの開始前に実施した、銀行内のブロックチェーンのさまざまな適用分野の詳細な分析は、モジュール式で簡単に適応可能なシステムの設計に役立ちました。 そして、非常に特定のビジネスケース（信用状）に焦点を当てて開発を実施しましたが、プラットフォームのモジュール性により、標準化された取引条件（株式、債券、担保の登録、上場デリバティブ）を使用する他のビジネスソリューションに使用できます。

研究プロジェクトのタスク

既に述べたように、この研究は、既存のブロックチェーンエコシステムで貿易金融取引を実施する可能性を判断することを課題としました。 エコシステムとは、ブロックチェーン自体の実装とそれらへのあらゆる種類のアドオンの両方をベースとして含む一連のテクノロジーを意味します：相互作用およびファイル交換プロトコル、ライブラリ、分散ストレージなど



同時に、安定したバージョンでリリースされたソリューション、または実装に近い準備段階にあるソリューションを使用することが想定されていました。 この調査は、銀行の会計システムと一緒に単一のプラットフォームで選択された技術をうまく統合するための条件を決定し、そのような統合の明白で隠れた問題を特定することになっています。



プラットフォームの実装に必要な機能を決定するために、次の初期条件が設定されました。

• 取引の実行には、当事者間の文書の交換が伴います
• トランザクションの主な決済は、通常の（フィアット）決済チャネルを介して行われます
• すべての取引トランザクションは、現行の規制文書および規制に基づいて、可能な限り法的に確認する必要があります（「今すぐ」司法慣行を確保するため）
• すべての操作と操作間の移行信号は、可能な限り自動化する必要があります。

プラットフォームの一般的なスキームとその要素の相互作用

プラットフォームコンポーネントのアーキテクチャと相互運用性

初期条件の分析から、次の機能コンポーネントを使用する必要があることが示唆されます。

• ブロックチェーン-トランザクション操作の信頼できるレジスターおよびトランザクションを提供するスマートコントラクトの実行環境
• 分散ファイルストレージ（DFS）-トランザクション関連のファイルを保存および交換するための媒体として
• 認証された暗号情報保護証明書-追加の暗号化、法的に重要な電子署名、および安全なタイムスタンプを提供する手段として。 さらに、DFSがマルチユーザーアクセスメカニズムをサポートしていない場合、ファイルアクセス分散の追加の仮想レイヤーを編成するために使用できます。
• オラクルおよび外部リクエストのプロバイダー-銀行の会計システムへのアクセスおよび外部世界のイベントのソース（レジストリなど）
• 文書アナライザー-取引条件を確認するために当事者が提出した文書の自動分析用。

現在の現実のドキュメントの主要な計算と分析はスマートコントラクトの外部で実行されるため、処理できるデータのみがスマートコントラクトに直接転送されます。 残りの情報（実証および管理文書）は、法的重要性を確保するために、強化された適格なデジタル署名によって署名された通常の（手動処理用）または正式な（自動処理用）文書の形式で添付されます。



同時に、次のタスクをスマートコントラクトの内部ロジックに割り当てることができます。

• ステータスマトリックスが現在のステータスとスイッチングトランザクションのイニシエーターに従うようにする
• 文書を提出できる期間を制限する日付管理
• 外部要求プロバイダーからの参照イベントの発生の処理

次の登録情報は、各プラットフォームユーザーに関連付けられました。

• システム内の一意の識別子
• ユーザーがトランザクションを送信するイーサリアムアドレス
• 所有またはユーザーに送信されたトランザクションの登録を維持するために使用されるスマートコントラクトのアドレス（以降、メールボックスと呼びます）
• 拡張修飾デジタル署名の証明書識別子とその公開キー

Oracleコンセプトの最も簡単な説明： blockchainhub.net/blockchain-oracles

DFSに関する良い記事はありません でした。Swarmの ドキュメントへのリンクを残します： swarm-guide.readthedocs.io/en/latest/introduction.html

そしてStorj： storj.io

実用的な実装

次の図は、プラットフォームの一般的な図と、機能コンポーネント間の主なデータ交換フローを示しています（この場合、「エイリアン」コンポーネントは緑色で、認定済み-紫色で、銀行ソフトウェアは白色で強調表示されています）。





トランザクションを準備および実行するプロセスでは、プラットフォームのコンポーネントは次のように対話します。

• クライアントソフトウェア（クライアントバンクやモバイルバンクなど）。 トランザクションの初期情報を入力し、必要なスマートコントラクトを作成し、ビジネスプロセスの手動段階でスマートコントラクトのステータスを管理するために使用されます。 ビジネスプロセスの手動段階は、実際の「個人的な」ユーザーアクションを必要とする段階として理解できることに注意してください。たとえば、ドキュメントをスマートコントラクトに添付し、通常、スマートコントラクトのステータスが内部ロジックの使用はブロックチェーンを超えています。 後者のケースには、銀行の会計システムのスマート契約に添付されたドキュメントの検証が含まれます。これは、自動的に行われますが、ブロックチェーンの外部で行われます。
  
  
  
  
• スマートコントラクトに添付されたファイルは、作成者の（作成者）の法的に重要な明確な識別のための作成者の強化されたデジタル署名によって署名されます。 次に、ファイルは暗号化パッケージの形成で暗号化され、トランザクションの参加者のみが復号化に使用できます。 結果の暗号化パッケージはDFSに配置され、ソースファイルのハッシュとDFSに指定されたストレージオブジェクトのアドレス（リンク、マニフェスト）はスマートコントラクトのコンテキストに保存されます。 ストレージオブジェクトのアドレスを使用すると、DFSから暗号化パッケージを抽出し、（トランザクションの参加者に対して）解読して適切に処理できます。
  
  
  
  
• トランザクションを処理するとき、スマートコントラクトはブロードキャストオラクルからの情報を使用できます。たとえば、カレンダーでのトランザクションの受信日を制御したり、為替レートを使用したりできます。
  
  
  
  
• 特定のステータスに移行すると、スマートコントラクトは、予期される外部イベントに対する特定のリクエスト、または外部リクエストのプロバイダーによる実行のための外部アクションの実行命令を送信する場合があります。 スマートコントラクトによって「順序付けられた」外部イベントが発生すると、プロバイダーはイベントに関する情報を含むトランザクションを送信します。 このトランザクションの処理結果に基づいて、スマートコントラクトは新しい状態に切り替わるか、または後続のイベントの発生を待機して同じ状態のままになる場合があります。
  
  
  
  
• 外部リクエストと同様に、特定の正式なドキュメントがスマートコントラクトに添付されると、スマートコントラクトはそれらをドキュメントアナライザーに分析用に送信し、分析結果を伴うトランザクションを待機できます。

信用状のスマート契約の実施

プラットフォーム設計では、実装のためのビジネスケースの開発と並行して開始することが決定されました。



ブロックチェーンのプロセスの簡略図を図に示し、プロセスの詳細な説明を以下に示します。







取引の当事者は、買い手、売り手、銀行です。 買い手と売り手は、特定のサービスまたは商品の提供に関する契約を締結し、それらの提供の事実は自動的に識別できます。 たとえば、不動産、株式、株式などの所有権を譲渡する際に決済のために信用状が開かれている場合、提出された文書の情報は、外部ソースの情報（たとえば、不動産の統一された州の登録簿）に対してさらにチェックされます。 プラットフォームを通じて、さらなるトランザクションサポートが提供されます。

1. 買い手は、スマートコントラクト「信用状申請書」（以下「申請書」）を作成し、 新規契約のステータスを受け取ります。
   
   
   
   アプリケーションのアドレスは、バイヤーおよび銀行のメールボックスに配置されます。
   
   
   
   
2. 購入者は、正式なEDをアプリケーションに添付し、取引の詳細の説明と必要な非公式文書、たとえば信用状が開かれている契約のスキャンコピーを添付します。
   
   
   
   必要な書類をすべて添付した後、バイヤーはアプリケーションをInBankステータスに移行します。
   
   
   
   
3. 銀行は自動的に（正式なEDの場合）または専門家を使用して（正式なEDの場合）取引を確認します。 たとえば、銀行のシステムにリクエストが送信され、クライアントデータカタログ内のクライアントの詳細を確認し、その他のチェック（コンプライアンスのチェック、通貨管理など）のために口座残高と準備金を確認します。
   
   
   
   銀行は、取引の内容または添付書類に関する請求がある場合、申請の受理を拒否し、 拒否ステータスに設定します。
   
   
   
   銀行は、申請を実行することに同意した場合、 確認済みステータスを割り当てられます。
   
   
   
   
4. トランザクションを説明する正式なEDに基づいて、銀行は銀行の会計システムで必要な操作を実行します（信用状の金額をクライアントアカウントから「カバレッジアカウント」に転送する、手数料を償却するなど）
   
   
   
   銀行は、スマートコントラクト「信用状」（以下、信用状）を発行し、 Newのステータスを受け取ります。
   
   
   
   信用状は、銀行と売り手のメールボックスに置かれます。
   
   
   
   信用状はアプリケーションのアドレスを保持します。これにより、バイヤーがトランザクションのステータスを監視できるように、アプリケーションの信用状の主要なステータスを自動的に「ミラー」できます。
   
   
   
   
5. 銀行は正式なEDを信用状（申請書の条件から自動的に作成されます）に添付し、取引の詳細、その他の必要な文書の説明、およびリリース済みステータスを設定します。
   
   
   
   信用状に関連する信用状のステータスもリリース済みに切り替わります。
   
   
   
   リリース済みステータスに移行すると、信用状は自動的に2つのリクエストを外部リクエストプロバイダーのキューに入れます。
   
   
   
   
   • 信用状の有効期限の制御の要求（現在の日付が信用状の有効期限を超えたときにトリガーされます）
   • 契約の実行を待機するための要求（特定の要求テンプレートは、トランザクションのコンテンツによって決定されます）
6. 発行された信用状を調べた後、売り手はそれを受け入れることを拒否する場合があります。この場合、彼はそれを無効ステータスに移行し、信用状はキャンセルされ、それ以上の操作は不可能になります。
   
   
   
   信用状に関連する信用状のステータスも無効に切り替わります。
   
   
   
   
7. 信用状の有効期限が切れた最初のイベントが発生すると、 期限切れのステータスを受け取り、それ以上の操作は不可能になります。
   
   
   
   信用状関連の申請ステータスも期限切れに切り替わります。
   
   
   
   この場合、自動注文が銀行の会計システムに送信され、信用状の取り消しに対応する取引が開始されます（補償の返還、銀行の義務の終了など）。
   
   
   
   
8. 契約実行イベントが最初に発生した場合（または売り手が信用状の条件で規定されたEDを添付した場合）、信用状はInBankステータスに切り替わります。 InBankステータスに移行すると、 Letter of Creditは自動的に支払い要求を外部要求プロバイダーのキューに入れ、有効期限の制御要求をキューから削除します。
   
   
   
   銀行は、信用状に添付された正式なEDに基づいて、注文を決済システムに転送し、ブロックチェーン外で支払いを実行することにより、売り手に有利な支払いを行います（支払いの実際の実行に関する情報はブロックチェーンに返されます）。
   
   
   
   
9. 支払実行イベントがトリガーされた後、信用状は終了ステータスに切り替わります。
   
   
   
   信用状に関連する信用状のステータスもClosedに切り替わります。
   
   
   
   
10. トランザクションが完了しました。

プラットフォームコンポーネントの選択

プラットフォームの機能コンポーネントを選択する際、オープンソリューション（Ethereum、Swarm、Storj）に焦点を当てました。 これには、次の利点があります。

• 開発された「自立型」インフラストラクチャの存在
• ユーザーに対するオープン性と、銀行が提供するインターフェースだけでなく、代替ソースを介して操作を制御する機能
• 競争力のあるコンセンサスプロトコルと独立したノードの高品質な「非寛容な」ネットワークの存在による、ユーザー側の高レベルの信頼

したがって、選択は以下の実装を支持して行われました。

• ブロックチェーンとスマートコントラクト-イーサリアムとSolidity言語。
• 分散ファイルストレージ-SwarmおよびStorj.io。
• 認定された暗号情報保護証明書-CryptoPROおよびCryptoARM。
• 放送オラクル-独自の開発。
• 外部リクエストのプロバイダー-独自の開発。
• ドキュメントアナライザー-この段階では、一般的にスマートコントラクトとやり取りする原則は外部リクエストプロバイダーに似ており、研究チームのリソースは限られているため、考慮しないことにしました。

インフラ

必要なコンポーネントを展開するには：

• Ethereum、Swarm、Storj.ioのクライアント部分、
• CPSI、
• 外部リクエストプロバイダー、
• UIアプリケーション
• 統合コアプラットフォーム

2台のサーバーが割り当てられました。



最初のサーバーで、スマートコントラクトの基本ブロックのイーサリアムノードが展開されました。 当初、基本的なブロックチェーンとしてRopstenテストネットワークが使用されていましたが、最終段階ではより安定したRinkebyに切り替えました。 この理由は、 3月に発生したRopstenに対するDDOS攻撃の事件で、数日間トランザクションを追加する際に問題が発生しました。



インフラストラクチャは2番目のサーバーに展開され、ファイルを使用した作業を提供しました。

• DFS Storj.ioノード
• Ropston Ethereumサポートノードを備えたDarm Swarmノード
• CryptoProおよびCryptoARM

さらに、相互作用の利便性の理由から、プラットフォームの統合コアもそこに展開されました。



外部要求プロバイダーは各サーバーに展開されており、必要に応じて任意のサーバーで実行できます。



UIアプリケーションは、任意のサーバーで実行することも、インターネット経由で作業するために特別なプロキシプロトコルを使用することもできます。

コンポーネント統合

イーサリアム

Ethereumブロックチェーンとの統合は、RPC API JSON-RPC 、 Management-APIを使用して実行されました。



その使用に技術的な問題はありませんでした。



外部裁定リソースとして、 使用したテストネットワークに応じてropsten.etherscan.ioまたはrinkeby.etherscan.ioが使用されました。

群れ

Swarmとの統合は、HTTP API： Swarm-guide 、 gist.github.comを使用して実行されました 。



ファイルをSWARMにアップロードするために、HTTPリクエストPUT / bzzを使用しました：$ PATH $ （$ PATH $はダウンロードしたファイルへのパスです）。



これに応答して、SWARMから抽出するために使用されたファイルマニフェストの16進識別子が来ました。



SWARMからファイルを取得するために、HTTPリクエストGET / bzzi：/ $ MANIFEST $ / （$ MANIFEST $は、抽出されたファイルのマニフェストの16進識別子です）を使用しました。



ファイルのアップロード/ダウンロードに問題はありませんでした。



残念なことに、外部監視ツール（Etherscan for Ethereumなど）がSwarmに見つからなかったため、何らかの方法でファイル操作の成功を評価することが困難になりました。

Storj.io

開発者が提供するAPIを使用したStorjとの統合は、非常に困難で不便であることが判明しました。 その結果、Storjホストコンソールがファイルの操作に使用されました。



ファイルをダウンロードするために、コマンドstorj upload-file $ BUCKET $ $ PATH $ （$ BUCKET $は「バスケット」の識別子、$ PATH $はダウンロードしたファイルへのパス）を使用しました。

アップロードが成功すると、応答はダウンロードされたファイルの識別子でした。



ファイルをアップロードするには、コマンドstorj download-file $ BUCKET $ $ FILE $ $ PATH $を使用しました （$ BUCKETは「バスケット」の識別子、$ FILE $はファイルの識別子、$ PATH $は作成するファイルのローカルコピーへのパスです）。



Storjの特性には、同じ名前の複数のファイルを1つの「バスケット」に入れることができないという事実が含まれており、ダウンロード時に一意の名前を生成するメカニズムを使用する必要があります。



APIをサポートするhttps://api.storj.ioを外部裁定リソースとして使用できます。

CryptoARM

CryptoARMとの統合は、彼が提供するCOMサービスを使用して実行されました。 実装の速度を上げるために、統合スクリプトはvbsで作成されました。

外部リクエストプロバイダー

スマートコントラクトと外部リクエストプロバイダーとの対話は、次のスキームに従って実行されます。

コミュニティの利益のために

外部イベントを追跡し、オラクルや外部クエリプロバイダーと連携するためのテクノロジーを試したい人のために、Ethereum Rinkebyネットワークにデプロイしました。

• カレンダーの神託（モスクワで現在の日付を与える）
• 外部クエリポータル

カレンダーオラクル

カレンダーOracleは、Rinkebyテストネットワークの79548a65e3ce179ec8d208c22ee84435dc34058fにあり、モスクワの現在のカレンダー日付をYYYY / MM / DD形式で表示します。



オラクルへの訴えの例：



contract Check_request

{

Calendar Oracle ; // -

bytes32 Date ;

function Check_request()

{

// -

Oracle=Calendar(0x79548a65e3ce179ec8d208c22ee84435dc34058f) ;

//

Date=Oracle.GetDate() ;

}

}



//

//

//

contract Calendar

{

function GetDate() constant returns (bytes32 retVal) ;

}

外部クエリポータル

外部契約ポータルのスマート契約キューは、Rinkebyテストネットワークのd9b076d0b559f70782f379582bd3d54b85fc42cbにあります。



外部リクエストポータルとやり取りするためのプロトコルは上記のとおりです。 現在、次のクエリテンプレートが公開されています。

• 期限切れ-期限切れ日の制御、リクエストパラメータ-YYYY / MM / DD形式の期限切れ日
  
  イベントのトランザクションは、日付の遅延の検出時に要求されたスマートコントラクトに送信され、現在の日付が含まれます。
• WEATHER_TEMP-現在の温度の要求（ api.openweathermap.orgポータル経由）、要求パラメーターは都市の名前、たとえばモスクワ（詳細はソースポータルで確認できます）。
  
  イベントのトランザクションは、ソースポータルから応答を受信したときに、要求されたスマートコントラクトに送信されます。

外部リクエストのポータルのキューにアクセスするには、キューイングトランザクションの送信元であるイーサリアムアカウントのアドレスを（コメントまたは個人のメールで）お知らせください。

有料サービスのメカニズムをデバッグするには、トランザクションに0.1 Etherを適用することをお勧めします（無料で、テストネットワークにあります）。 Rinkebyでは、PoAプロトコルによるマイニングの不足のため、faucetを使用してのみエーテルを取得できます。

サードパーティのコンポーネントを統合した経験に関するいくつかのメモ

イーサリアム

スマートコントラクトの有料サービスを実装する場合、トランザクションの開始者を犠牲にするのではなく、「受信」スマートコントラクトを犠牲にしてトランザクションを実行できることが非常に便利です（当然、スマートコントラクトが何らかの方法で同意を表明する場合- 、信頼できるアドレスのメカニズムなどが原因です）。 これにより、「サービス」の決済メカニズムが大幅に簡素化されます。トランザクションの開始者は、スマートコントラクトメソッドの実行に対しても支払いを行うため、そのコスト（実行）は常に事前に決定できません。

イーサリアムの堅牢性

「外の世界」と相互作用する自明でないスクリプトの開発は、文字列を操作するための組み込み関数（連結、検索、フラグメントカット）がないため、非常に複雑です。

イーサリアムの群れ

メインのイーサリアムと同様に、Swarmへのファイルのアップロードを確認する（他のノードに配布する）メカニズムを持つことが非常に望ましいです-トランザクション確認と同様です。 ファイルがノードの外部のどこかに保存されているかどうかは不明です。



ソースからビルドし、WindowsでSwarmホストをデプロイすることは非常に重要なタスクです。 開発者は、LinuxおよびOSXのみのドキュメントをテストおよび準備しましたが、これは正直に認められています。

Storj.io

使用が非常に難しく、詳細すぎるAPI。 統合を容易にするために、Ethereum Swarmに実装されているものと同様の「拡大された」APIが必要です。ファイルを配置し、ファイルを抽出します。



ファイルへのマルチユーザーアクセスの可能性はありません。 つまり、ファイルは、記録されたアカウントの詳細からのみ読み取ることができます。 これは、マルチユーザーファイル共有の組織にとって、アカウントの詳細を実際に「公開」する必要があるという事実につながります。これは、有料サービスを考えると、良い習慣ではありません。

調査結果

現在、ブロックチェーンエコシステムの生産的なコンポーネントまたは生産的なコンポーネントに近づいていることにより、貿易金融取引の実行プロセスをサポートするために必要な機能を完全に実現することができます。



もちろん、特定の非技術的な問題がありますが、その解決策は、ブロックチェーン上での貿易金融のための大規模なプロジェクト（およびタスクの点でそれに近い多くの方向性）の実装について話すために必要です。



まず、ブロックチェーン内のエントリの法的ステータスを含む、ブロックチェーンを通じて実行されるトランザクションの法的問題。



第二に、現在ロシアでは、銀行による公共ブロックチェーンの使用は、暗号通貨に関する規制当局の立場によって実際にブロックされています：それらの使用の禁止により、取引（取引手数料）を追加するための手数料を支払うことができなくなります。 この場合、決済はトランザクションではなく、スマートコントラクトを作成し、それらと対話する方法として必要です。



第三に、電子文書形式の標準化は、自動検証の可能性のために必要です。



最後に、ブロックチェーンのエコシステムを外部イベントのソースで飽和させる必要があります：さまざまなレジストリのオラクル、銀行や輸送会社の情報システムなど。 これにより、外部イベントを手動で入力する必要がなくなり、スマートコントラクトの実行が完全に自動化され、非個人化されます。



そのようなプロジェクトでは、技術的な側面が作業の最も重要な部分ではないことが明らかになります。 開発が既に完了したので、私たちは引き続き弁護士と協力し、他の銀行と協力して、電子文書の統一フォーマット要件を定義してコンテンツの検証を自動化するアプローチについて取り組んでいます。



信用状のあるケースにより、技術分野とTFの分野での分散型アプリケーションの実装経験の両方を得ることができました。 現在、パイロットの作成に興味があるいくつかの領域を検討しています。それらについては後で説明します。



お楽しみに！