World to Peer

●Table of contents

1. Project name
2. Project description
   • Background
   • System overview
   • System requirements
   • Future work
3. Technologies used
   • Blind signature
   • ZK-SNARK
4. Basic architecture
   • Credit Information Acquisition Process
   • Borrowing Process
   • Repayment Process
5. Source code

●Project name

World to Peer: Unsecured × Personal × DeFi Lending

●Project description

▪Background

We focus on financial inclusion as a key financial challenge facing society today. Financial inclusion is an effort to provide equal access to financial services to those socially disadvantaged due to poverty and other factors. Accessing traditional financial services poses significant hurdles, such as the need to open an account and provide an address.
Protecting privacy is also a key issue. Currently, when applying for a loan, users must provide a significant amount of information to the lender, including their address, phone number, and occupation. Furthermore, credit bureaus can access a comprehensive view of a user's asset status across various financial services, making it difficult to say that user privacy is being protected.
We believe that Ethereum can address these challenges and become a platform for providing new financial services. With the largest total value locked (TVL) and a vibrant market, Ethereum is a likely community for both lenders and borrowers. Furthermore, its flexible program design allows for flexible design with a focus on privacy, such as selective information disclosure and zero-knowledge proofs. However, there are problems with the lack of unsecured loan protocols, the high collateral requirement, and the exclusion of those without capital from the DeFi market.

私たちは今日の金融上の課題として、金融包摂に着目している。金融包摂とは、貧困などの理由から社会的に弱い立場にある人にも、平等な金融サービスの機会を提供する取り組みである。従来の金融サービスを受けるためには、口座開設や住所の用意が必要であるなど、高いハードルがある。
また、プライバシーの保護も重要な課題である。現在融資を受けようとすると、住所や電話番号、職業情報を含めて非常に多くの情報を貸し手に提供する必要がある。また、信用情報機関はユーザーの利用する様々な金融サービスでの資産状況を統合的に知ることが可能であり、ユーザーのプライバシーが守られてる状況であるとは言いにくい。
Ethereumは上記の課題を解決しながら、新しい金融サービスを提供するためのプラットフォームになると考えている。ブロックチェーンコミュニティとしては最大のTVL(Total Value Locked)を持ち市場が活発であるため、資産の貸し手借り手ともに集まりやすいコミュニティであると考えた。また、自由度の高いプログラム設計が可能であるため、情報の選択的開示やゼロ知識証明といったプライバシーに重点を置いた柔軟な設計が可能である。しかしながら、無担保ローン・プロトコルが存在せず、高い担保率がもとめられ、資金を持っていない人がDeFi市場には排除される問題が存在している。

▪System overview

Based on the above background, we designed an unsecured lending system using the Ethereum platform. The system involves four players.
上記の背景を踏まえ、私たちはEthereumプラットフォームを用いて無担保融資システムの設計を行った。システムには以下の4つのプレイヤーが存在する。

• Credit Bureau (CB)
  A credit information agency that issues certificates containing credit information to borrowers. For simplicity, this certificate is issued in advance in this project.
  信用情報機関。Brrowerに対して信用情報を含めた証明書の発行を行う。本プロジェクトでは簡略化のため、この証明書の発行については事前に行っている。
  
  

• Borrower
  Based on credit information, the borrower calculates the borrowing limit and creates a proof. The borrower borrows assets up to the limit from a Smart Contract (SC) pool. The borrower also repays the assets to the pool with interest within the due date. A single borrower has multiple Ethereum addresses and can borrow from each address.
  信用情報をもとに借り入れ限度額を計算、証明の作成までをローカルで行い、Smart Contract(SC)のプールから限度額内の資産を借り入れる。また、期限内に利子をつけてプールへ資産を返済する。一人のBorrowerは複数のEthereumアドレスを持ち、それぞれのアドレスから借り入れを行うことが出来る。
  
  

• Smart Contract (SC)
  Collects assets from lenders and lends them to borrowers. The SC also determines whether a borrower can lend and maintains a transaction history. Only minimal information is saved for verification purposes.
  Lenderから資産を集め、Borrowerに貸し付ける。また、Borrowerに対して貸し付け可能かの判定を行い、取引履歴を保持する。この際、検証するために最低限の情報のみを保存する。

• Lender
  Contributes to the SC pool and earns revenue through interest distributions on loans. For simplicity, this project assumes that the borrower has contributed to the pool in advance. We will also not go into detail about interest distribution this time.
  SCのプールに出資を行い、貸付による利子の分配で収益を得る。本プロジェクトでは簡略化のため、プールへの出資は事前に行っているものとする。また、利子の分配についても今回は割愛する。

▪System requirements

The following five conditions were set for building the system.
システムの構築にあたり、次の5つの条件を設定した。

• Challenges in Building a Credit Market

1. Repayment Accumulation

Borrowers can accumulate their repayment history.Repayment history may be used in the future to increase borrower credibility.
Borrowerは自身の返済実績を蓄積することが出来る。返済実績はBorrowerの信頼を上げる要素として今後使用できるかもしれない。

2. Default Transparency

Defaults should be recorded because they are a factor in determining a borrower's creditworthiness. However, simply linking default information to an address would allow a borrower to take out a new loan without any problems by using a new address. This situation should be prevented.
債務不履行は、そのBorrowerの信用決定に関わる要素のため記録されるべきである。しかし、単純に債務不履行の情報をアドレスに紐づけた場合、Borrowerが新しいアドレスを利用することで問題なく新しいローンが組めてしまう。このような事態は防ぐべきである。

3. Limit Applications

A borrower's borrowing limit is determined based on credit information from a credit bureau. This credit information should not be reused across multiple addresses to borrow an amount exceeding the limit.
Borrowerの借り入れの上限額は、信用情報機関からの信用情報をもとに決定される。この信用情報を複数のアドレスで使いまわして、上限額を超える金額を借り入れることがあってはならない。

• Challenges from the Perspective of Privacy Protection

4. Minimal Disclosure

Certificates issued by credit bureaus include information such as the borrower's real name and specific annual income. However, when lending assets, all that is required is the borrower's lending limit, which is calculated based on a specified formula. Information that does not need to be disclosed is not disclosed at all.
信用情報機関から発行される証明書には、実名や具体的な年収額などが記載されている。しかし資産の貸付において必要なのは、所定の式に基づき算出されるBorrowerの貸し付け上限のみである。このような開示の必要がない情報は、一切開示しない。

5. Unlinkability

While limit applications are an important aspect, there are problems with inadvertently linking address holders. A design that allows anyone to link an address owner by checking it must be avoided.
Limit Applicationsは重要な観点である一方で、不用意にアドレスの保有者を結びつけることには問題がある。誰が確認してもアドレスの持ち主を結びつけることが出来る設計は避けなければならない。

The system has been designed to meet these conditions.
これらの条件を満たすように、システムの設計を行った。

▪Future works

• Revision of Credit Score and Loan Limit
  Since this project was created with financial inclusion in mind, we want to enable even those living in poverty to borrow larger amounts as they build up their credit. To achieve this, we need to update the credit score to a more appropriate assessment.
  金融包摂という観点で作成を行ったため、貧困などにある人でも信用の構築に伴いより大きな金額が借りられるようにしたい。そのため、信用スコアをより適切な評価へと更新していく必要がある。
• Proof of Proposal Security
  We would like to be able to provide a more rigorous explanation for whether our proposal is truly secure.
  提案が本当に安全なものなのか、より厳密な説明が行えるようにしたい。
• Improving the Efficiency of ZK-SMARK
  As we attempted to implement it within a limited time frame, there are still some inefficiencies. We would like to spend more time improving the code and structure.
  限られた時間の中で実装を試みたため、非効率的な部分が残っている。より時間をかけてコードと構造を改善していきたい。

●Technologies used

▪Blind Signature

The signer (in this case, a credit bureau) signs the document without knowing the contents of the document, including the personal information of the person receiving the signature (in this case, the borrower). After that, a base_id can be calculated uniquely for everyone.     
署名者(今回の場合は信用情報機関)が署名を受ける者(今回の場合は借り手)がランダムに選んだ文書に関する秘密sを知ることのないまま署名を付与する。s及び個人番号MYNからbase_idがハッシュ関数により各人に一意に与えられ、base_idを用いてハッシュ関数と組み合わせることでハッシュ値を計算してloanid_kを計算した。

▪ZK - SNARK

This is used to realize non-interactive zero-knowledge proofs on the blockchain. In addition to proving the interactions between the borrower and lender with zero-knowledge, the goal was to verify that our protocol is working correctly by taking advantage of its features that enable proof size to be kept small and proofs to be generated efficiently.
非対話のゼロ知識証明をブロックチェーン上で実現するために利用する。BorrowerとLenderとの間でのやり取りをゼロ知識で証明することに加え、証明サイズを抑えてかつ効率的に証明を生成することが可能となる特徴を活かすことで、正しく我々のプロトコルが動作していることを検証することを目的とした。

●Basic architecture

In this project, we built an architecture for the Lending Process, consisting of four players: CB, Borrower, SC, and Lender, as shown in the diagram below.
本プロジェクトでは、上述したようにLending Processとして、CB、 Borrower、SC、 Lenderの4プレイヤーから構成されるアーキテクチャを構築した。

In addition, to protect the borrower's personal information, we set up a system to issue a unique and unlinkable loan ID using blind signatures.
Based on the above, we will divide the process into Credit Information Acquisition Process, Borrowing Process, and Repayment Process and describe the algorithm for each scenario.
また、借り手の個人情報保護を実現するために、ブラインド署名を利用した一意でかつ連結不可能なloanidを発行するsetupを行った。
以上のことから、信用情報取得 Process、Borrowing Process、Repayment Processに分割してそれぞれのシナリオでのアルゴリズムを記載する。

1. Credit Information Acquisition Process

When a borrower borrows etherium from a lender, they must obtain the borrower's credit information and derive a score.In this project, we simplified the calculation of the credit score using Equation 1 below, but we believe this can be flexibly modified.
The factors used are annual income ($), years of employment (years), and an adjustment coefficient of 0.0001.
Credit Score = Annual Income × Adjustment Coefficient × (55 + Years of Employment) Equation 

BorrowerはLenderからetheriumを借りる際、Borrowerの信用情報を取得してスコアを導出する必要がある。今回のプロジェクトでは、信用スコアの算出を以下の式1で簡略化して表現したが、当該箇所は柔軟に変更が可能であると考える。
使う要素は、年収(＄)、就労年数(年)、調整係数 = 0.0001とする。

信用スコア  = 年収 × 調整係数 × (55+就労年数)  

2.  Borrowing Process

This section explains the interactions between the Borrower and the SC when borrowing.

π① Confirm that the most recent state_(k) is calculated correctly.
To ensure that the borrower's state before borrowing is recorded correctly.

π② Confirm that the desired borrowing amount is equal to or less than the borrowable amount.
 To determine whether the borrower's desired amount is within the acceptable range.

π③ Confirm that state_(k+1) is updated correctly.
To ensure that the result of π② correctly reflects the borrower's next state.

π④ Confirm that the NF (Transaction Record Number) is updated correctly.
To ensure that the transaction history on the blockchain is updated accurately.

この項目では、BorrowerとSCとの間での借入時のやり取りについて説明する。

π①  直近のstate_(k)が正しく計算されていることを確認する
借入前のBorrowerの状態が正しく記録されていることを保証するため

π②  借入希望額が借入可能額と同等か下回っていることを確認する
Borrowerが希望する金額が許容範囲か否かを判断するため

π③  state_(k+1)が正しく更新されていることを確認する
π②の結果からBorrowerの次の状態が正しく反映されているかを保証するため

π④   NF(取引記録番号)が正しく更新されていることを確認する
ブロックチェーン上での取引履歴が正確に更新されていることを保証するため

3. Repayment Process

This section explains the process between the borrower and the SC during repayment.

π① Check that the most recent state_(k+1) is included in loan_state
To determine whether the existing state is correct from the loan list

π② Check that state_(k+2) has been updated correctly
To determine that the correct transition to the post-payment state has been made

π③ Check that NF (Transaction Record Number) has been updated correctly
To ensure that the transaction history on the blockchain has been updated accurately

この項目では、BorrowerとSCとの間での返済時のやり取りについて説明する

π①  直近のstate_(k+1)がloan_stateに含まれているかを確認する
既存の状態がloanのリストから正しいもの下を判断するため

π②  state_(k+2)が正しく更新されてることを確認する
返済後の状態へと正しい遷移が進んでいることを判断するため

π③   NF(取引記録番号)が正しく更新されていることを確認する
ブロックチェーン上での取引履歴が正確に更新されていることを保証するため

●Source code

https://github.com/GomA16/W2P-ETHTokyo