- 1. Abstract
- 2. Background
- 3. Use Cases/ Requirements
- 4. Method
- 5. Implementation
Document Metadata
-
Status: DRAFT
-
Scope: Internal
-
Changelog:
-
v.0.0.1
-
Abstract, Background and initial parts of Method added.
-
-
Off Chain Transaction Analytics(OCTA) system prototype is a proof of concept system that provides an off-chain transaction analytics system (OCTA for short) using Mina Snapps smart contracts. The motivation of it is to provide a way for the users to protect their sensitive financial data without exposing it to a third party while also gaining access to critical financial services such as credit. Such a system, with the aid of zk-SNARK technology, would allow one to prove one’s own financial standing using their verified transaction history records without the need of any centralized party’s approval. The prototype would provide a basic protocol and a set of tools for all the actors: lenders, borrowers and financial data repositories. We also aim to provide example use-cases such as proving a borrower’s average income over a requested period of time by a lender. Those examples would demonstrate how MINA Snapps could affect daily interactions involving financial data improving their security and privacy.
A person’s financial transaction history is one of the most important and private aspects of their lives. A third party gaining access to this information could in theory understand a person’s social/financial standing, inter-personal relationships and even health. As for now, many aspects of the present financial system is built on users voluntarily handing over this information in exchange for granting access to critical financial services. It often occurs without them being aware of the benefits the third party acquires from their data. This leads to a breach of privacy that could possibly lead to exposing this sensitive data to unintended parties. Eg:
-
All non-collateralized lending systems require some form of transaction history analysis/verification to understand the borrower’s financial standing. Most common way to do achieve this at the moment is through a personal credit score that is provided by a centralized entity that tracks the transactional habits between all the parties. This caused massive data breaches in the past.
-
Rewards systems such as credit card cashback schemes require explicitly access to one’s raw transaction history by a third party.
-
Mobile payment wallets such as Google Pay could mine a user’s transaction history data to provide a more personalized shopping experience.
To face this problem, Mina Snapps have potential to provide a solution that preserves user’s privacy without compromising the access to critical financial services. In our scheme, this is achieved using off-chain verifiable computation with aid of ZK-Snarks. This manuscript is a brief introduction to this idea, with potential use-cases, requirements and a draft of an architecture for a prototype Off-Chain Transaction Analytics system powered by MINA Snapps.
Following are some simplified use cases for the prototype.
-
As a lender I’m able to register in the system as being able to lend out a certain amount with a certain interest rate.
-
As a borrower I want to be able to view lenders(potential loans) registered on the system.
-
As a borrower I want to be able to request a loan from a lender registered on the system.
-
As a lender I want to be able to request a potential borrower to prove their regular income to be more than a certain amount(referred to as the Regular Income Proof) using their bank transaction records.
-
As a lender I want to be able to request a potential borrower to prove their average monthly balance to be more than a certain amount(Referred to as the Average Monthly Balance Proof) using their bank account balance and/or transactions.
-
As a borrower I want to be able to provide a Regular Income Proof without exposing my bank transaction history to the lender.
-
As a borrower I want to be able to provide an Average Monthly Balance Proof without exposing my bank transaction history to the lender.
-
As a lender I want to be able to verify the source of a Regular Income Proof as coming from the borrower’s bank.
-
As a lender I want to be able to verify the source of an Average Monthly Balance Proof as coming from the borrower’s bank.
-
As a lender I want to be able to verify a Regular Income Proof.
-
As a lender I want to be able to verify an Average Monthly Balance Proof.
-
As a lender I want to be able to approve and make a loan offer if the required transaction activity proofs are satisfied.
-
As a borrower I’m able to accept a loan offer if the conditions are agreeable, and receive the requested funds.
-
[Optional] As a Snapp developer I want to be able to write a Snapp that is capable of applying for loans using OCTA protocol
-
[Optional] As a Snapp developer I want to be able to write a Snapp that is capable of offering loans using OCTA protocol
actor "Lender" as L actor "Borrower 1" as B1 actor "Borrower 2" as B2 participant "Mina" as M participant "OCTA\n$10,000/8% Loan\nContract" as O participant "Data Repository(Bank)" as D group Deployment L->M: Deploy OCTA\ncontract\nwith minimum\nrequired proofs M->O: Publish end group Loan 1 B1->M: Browse Loans B1->D: Transaction Data Request D->B1: Send signed list of transactions B1->B1: Calculate Proofs B1->O: Request $500 Loan with Min Proofs L->O: Approve and offer loan to Borrower 1 B1->O: Accept loan offer O->B1: Disburse loan end group Loan 2 B2->M: Browse Loans B2->D: Transaction Data Request D->B2: Send signed list of transactions B2->B2: Calculate Proofs B2->O: Request $7000 Loan with Min Proofs L->O: Request additional proofs B2->B2: Calculate additional Proofs B2->O: Send additional proofs L->O: Approve and offer loan to Borrower 2 B2->O: Accept loan offer O->B2: Disburse loan end
package "Borrower Browser" {
[Borrower App] as ba
}
package "Lender Browser" {
[Lender App] as la
}
node "Mina" {
[Loan Index Smart Contract] as lisc
[Loan Smart Contract] as lsc
}
cloud "Transaction Data Repository" {
database "Data Store" {
[mock tx json] as data
}
folder "HTTPS API" {
[GET /api/transactions] as txapi
}
}
lsc --o lisc : indexed
txapi -up-> data
la -right-> lsc : deploy
la --> lisc : index
ba --> lisc : browse\nloans
ba --> txapi: request data to\nmake proofs
txapi --> ba: signed data
ba --> lsc : request\nloan\nwith\nproofs
la --> lsc : view loan\nrequests\n(and approve)
A simple smart contract that holds the account addresses of the currently published loan smart contracts in the system. The use of this is for the borrowers to be able to browse and see details of the available loan contracts in the system.
TODO: Specify interface.
The main smart contract for handling the business logic of the lender-borrower interactions. The interface would look like the following.
// Loan smart contract interface
class Loan extends SmartContract {
@state(Field) interestRate: State<Field>;
@state(Field) termInDays: State<Field>;
// Terms of the loan are injected at construction. Called by the lender.
constructor(
loanAmount: UInt64,
interestRate: Field;
termInDays: Field;
address: PublicKey,
requiredProofs: RequiredProofs (1)
) {
super(address);
this.balance.addInPlace(loanAmount);
this.interestRate = State.init(interestRate);
this.termInDays = State.init(termInDays);
}
// Request a loan with required proofs. Called by the borrower
@method async requestLoan(amount: UInt64, proofs: TransactionDataProofs) { (2)
(3)
}
// Approve the loan for the given address. Called by the lender.
// This would be useful when lenders optimize on the type of borrowers
// based on the demand and other factors.
@method async approve(address: PublicKey) {
}
// Accept the loan for the calling address. Called by the borrower.
@method async accept() {
}
}-
RequiredProofs data structure needs to be defined based on further research. Most probably an extension of CircuitValue class.
-
TransactionDataProofs is a proofSystem that need to be defined based on further research.
-
Verify proofs. Then at the initial phase possibly disburse the loan. Later an approval method would be implemented together with support for accepting the loan by the borrower to disburse the loan.
This is a new proofSystem for transaction statistics based on off chain transaction data. It also needs to index the proofs it’s provided to be able to be verified based on the requireProofs field of the LSC.
TODO R&D
This is a separate service representing a transaction storage backend for example of a bank. Proposed to be implemented as a nodejs application.
A REST API that received requests and provides signed transactions data(stored in it’s database) in return. Signature scheme could follow the same as what is used by Mina. Further details should be specified with research. For example the way to convert to fields, sign and prove parts of the transactions that are strings. A possible approach is using a merkle tree. The data format sent of over the wire could possibly use Google Protobuf.
Endpoint format,
-
HTTPS GET /api/transactions
-
Headers
-
x-signature: Signature for the payload
-
-
Body format of the output would follow,
{ "id": "id of the account", "balance": "latest available balance of the account", "timestamp": "timestamp when retrieved", "transactions": [ { "id": "id of the transaction", "amount": "amount", "sendingAccount": {}, "receivingAccount": {}, "type": "type of the transaction", "description": "description", "timestamp": "date of the transaction" } ] }
The Lender App serves as the user interface for lenders for performing the following actions,
-
Deploy new LSC to Mina.
-
Register the LSC on LISC (index).
-
View loans deployed.
-
View loan requests.
-
Approve loan requests.
@startuml
(*) --> "
{{
salt
{+
{* **New Loan** | View Loans}
Amount | "10,000"
Term | "18 Months"
Interest Rate | "8%"
[X] Register on Index
[Deploy]|[Clear]
}
}}
" as new
new -right-> "
{{
salt
{+
<b>Success
Contract Address: <sadsafw>
[ok]
}
}}
" as success
new -right-> "
{{
salt
{+
<b>Error
failed, sorry
[ok]
}
}}
" as error
new -down-> "
{{
salt
{+
{* New Loan | **View Loans**}
{#
Address | Amount | Available Amount | Interest Rate | Term | Actions
abcd | 10,000 | 1200 | 7.5% | 3 months | [Borrowers]
abaad | 15,000 | 14000 | 6% | 12 months | [Borrowers]
}
}
}}
" as view
view -down-> "
{{
salt
{+
Borrowers for Loan **abcd**
{#
Address | Amount | Actions
xxxx | 1200 | [Approve]|[Reject]
yyyy | 8800 |
}
[back]
}
}}
" as borrowers
borrowers -> view
borrowers -right-> "
{{
salt
{+
<b>Success
[ok]
}
}}
"
borrowers -right-> "
{{
salt
{+
<b>Error
failed, sorry
[ok]
}
}}
"
@enduml
The flow outlined is proposed to be built as typescript/react app integrated with snarkyjs.
The Borrower App serves as the user interface for borrowers for performing the following actions.
-
Browse available loans
-
Apply for a loan.
-
Accept a loan.
-
Browse already borrowed loans.
@startuml
(*) -down-> "
{{
salt
{+
{* Own Loans | **Available Loans**}
{#
Address | Amount | Available Amount | Interest Rate | Term | Actions
abcd | 10,000 | 1200 | 7.5% | 3 months | [Apply]
abaad | 15,000 | 14000 | 6% | 12 months | [Apply]
}
}
}}
" as view
view --> "
{{
salt
{+
{* **Own Loans** | Available Loans}
{#
Address | Principle | Interest Rate | Term Left
xxx | 2000 | 7.5% | 1 month
yyy | 500 | 6% | 2 days
}
}
}}
"
view -down-> "
{{
salt
{+
<b> Apply for Loan abcd
Amount | "2,000"
[OK]|[Cancel]
}
}}
" as apply
apply -up-> view
apply -right-> "
{{
salt
{+
<b>Success
[ok]
}
}}
"
apply -right-> "
{{
salt
{+
<b>Error
failed, sorry
[ok]
}
}}
"
@enduml
The implementation of this prototype would happen in two phases.
In this phase the major focus is on getting the Snapp working end to end while completing major research items. Key results,
. A lender is able to deploy a loan on-chain.
. A borrower is able to request data from the Transaction Data Repository.
. A borrower is able to calculate required proofs using the data returned.
. A borrower is able to call LSC.requestLoan method using required proofs.
This phase is expected to complete roughly 6 (?) weeks.
Refer Component: Transaction Data Repository for details.
-
❏ Create the basic app skeleton with Nodejs/Typescript/Protobuf combo?
-
❏ Define the transaction data format using Protobuf?
-
❏ R&D on signature scheme based on transaction data format. Refer Calculating the Signature.
-
❏ Implement Component: HTTPS API.
Refer Interface: Loan Smart Contract (LSC) for details.
-
❏ Research and define the
RequiredProofsdata structure and theTransactionDataProofsproofSystem. -
❏ Research and implement the circuit to prove a past 3 months average income is over x threshold proof(
RequiredProofs) usingTransactionDataProofs. -
❏ Research how
TransactionDataProofscould be extended to supportRequiredProofswith multiple proofs required. -
❏ Implement the LSC contract with the constructor to deploy a loan.
-
❏ Implement the
LSC.requestLoanmethod.
Refer Component: Borrower App for details.
-
❏ Setup the basic skeleton of the app using snapps cli without any UI parts.
-
❏ Research and implement Component: Transaction Data Downloader/Signature Verifier.
-
❏ Research and implement Component: Transaction Data JSON to Field Converter.
-
❏ Research and implement Algorithm: Apply for a Loan without the UI involvement.
Refer Component: Lender App for details.
-
❏ Setup the basic skeleton of the app using snapps cli without any UI parts.
-
❏ Research and implement the deployment of the LSC contract given the constructor parameters with or without the UI.