How To Actually Disrupt Banks And P2P Lending

Many hodlers believe that Bitcoin will actually replace banks — but right now Bitcoin and Ethereum are seen largely as investing assets. Every economy needs capital to start new companies and to boost the growth of existing ones.

One of the biggest priorities of the GetLine Network is the safety of the loans active in the system. To do that, one good practice is to decouple each loan into a separate Ethereum contract, so that a bug in one loan can’t endanger all the others. This also provides immutability for the loaner and the borrower. Once deployed, both parties know exactly the terms on which the loan is given. New loans can be taken with new bug-fixes and improvements, but the old ones stay the same — everybody accepts the same terms without the fear of the smart contract changing at a later date to someone’s disadvantage. This kind of security is used for example in some 2-Factor Authentication USBs — once created, the USB device is not upgradable by design.

Each contract between Lender and Borrower can have different terms and version

The GetLine Network additionally will confirm the version of the loan contract in the Application layer, meaning that each contract must match byte-for-byte with the official version that the GetLine company releases before they are trusted. This provides two-fold safety for the users. First of all, you’ll know which smart contracts are trustworthy and aren’t a trick by a hacker to steal your money, and secondly — should bugs be discovered in the smart contract code, all previous loans will show up with a warning and participants will be notified optionally. In that way you’ll always be knowledgeable about the state of your transactions, as well as that of your wallet; You’ll also be able to make more informed decisions in which listed loans to invest your money in.

Decoupling comes at a price though — literally. Since each loan is a decoupled entity, each one has to hold everything connected with the process, including the code, which doesn’t really change from loan to loan. So now each loan is duplicating a lot of data, and each user would have to pay dollars for that duplication during deployment. Each deployed loan that has the same version will have the same code, duplicated multiple times throughout the blockchain. Each one costing a sizable fee in Ether.

Each Loan not only holds the information for the specific Loan, but also code that could be shared by all of the Loans

But, thankfully Ethereum has a nifty solution to that problem — Libraries. Libraries are contracts that are deployed once for each version of the code. Meaning there will be a Library for V1, for V2, for V3, etc. Each loan with the same version shares the same code with each other loan, while at the same time it’s state and information concerning specific loan terms is still completely separated from all the others.

Here’s an example technical flow:

1. Programmers write a new version of a loan.
2. They deploy the Loan Library once, paying a fee for the deployment, let’s assume $6.
3. The loan itself is linked to the already deployed Loan Library code.
4. So now the price of the loan contract has decreased, for example, from $6 to $1, meaning that you, as a user, save $5 on each loan.
5. When somebody calls a function in the loan contract, the function is delegated straight to the Loan Library (through the DELEGATECALL Ethereum opcode)
6. The Library doesn’t hold any state nor information, all information is still being held by the loan contract itself.

Now, all the Loans can share the same code, making each Loan cheaper

Small sample

Here’s a small sample in Solidity that showcases how Libraries work from the developer’s point of view. I’ll be using Truffle Framework as it provides an easy way to link smart contracts together. We’re going to create a simple escrow service. The creator of the contract shall put money into the escrow and designate a receiver of that money. The creator won’t ever be able to get their money out without giving it to the recipient.

Flow Of Escrow Service

1. Owner creates the contract, designates recipient and puts money into the contract.
2. Some service is provided off-chain by the recipient.
3. Owner confirms that the service was rendered and releases funds in the smart-contract.
4. The recipient then withdraws the funds.

The interface is quite simple:

contract Escrow {
    function Escrow(address recipient) payable;
    function confirmComplete();
    function widthdraw();
}

The confirmComplete() can be only called by the creator of the contract, while the widthdraw() only by the recipient, and only after the owner confirmed the service.

Now we’re going to create a library with the actual functionallity:

library EscrowLib {
  function init(address owner, address recipient, uint amount) internal returns (EscrowData data) {
    data.owner = owner;
    data.recipient = recipient;
    data.amount = amount;
  }
  function confirmComplete(EscrowData storage data, address sender) internal {
    require(data.owner == sender);
    require(data.wasConfirmed == false);
    require(data.isWithdrawn == false);
    data.wasConfirmed = true;
  }
    
  function withdraw(EscrowData storage data, address sender) internal {
    require(data.recipient == sender);
    require(data.wasConfirmed == true);
    require(data.isWithdrawn == false);
    data.isWithdrawn = true;
    data.recipient.transfer(data.amount);
  }
  struct EscrowData {
    address owner;
    address recipient;
    uint amount;
    bool wasConfirmed;
    bool isWithdrawn;
  }
}

First of all the Escrow contracts needs to hold the data on which the Library can operate. Remember — libraries can’t hold any data, only code.

contract Escrow {
  using EscrowLib for EscrowLib.EscrowData;
  EscrowLib.EscrowData data;
  function Escrow(address recipient) payable {
    data = EscrowLib.init(msg.sender, recipient, msg.value);
  }
}

As you can see, the functionality is now decoupled from where the data is actually being held. Now the functions in the Escrow contract now only need to pass the data along.

contract Escrow {
  ...
  function confirmComplete() {
   data.confirmComplete(msg.sender);
  }
  function withdraw() {
   data.withdraw(msg.sender);
  }
}

You’ve probably noticed a caveat here, we need to pass the sender to the Library. Since libraries are separate contracts in blockchain, their msg.sender is actually the Escrow contract, and not the one who’s calling it.

This example is pretty simple, but in bigger smart contracts it can be a powerful weapon, for security, readability, and reducing costs.

You can read more about libraries in the official Solidity documentation and get access to the whole sample in our Github repository.

Got questions? Hit me up on Getline’s Rocket Chat where I’m @ ritave