...by Daniel Szego
quote
"On a long enough timeline we will all become Satoshi Nakamoto.."
Daniel Szego
Showing posts with label IOU. Show all posts
Showing posts with label IOU. Show all posts

Tuesday, July 31, 2018

Simple IOU contract with optimization possibility on Ethereum

Simple systems administrating IUO contracts can be easily realized on the top of Ethereum. Let we say that accounts can issue new IOU-s that are administrated as credit and debit balance. Someone can issue an IOU to any particular account, but nobody can issue an IOU in the name of somebody else. There is a further external role for optimizing the IOU graph, for the first run optimizing only means reducing the difference of credit and debit balance for a certain node. The role can be at the moment anybody and for the activity there is an extra reward token as an incentive mechanism. A simple code is shown in the following example.

contract SimpleIOUWithOptimization {
    
 mapping(address => uint) creditBalances;
 mapping(address => uint) debitBalances;
 mapping(address => uint) rewardBalances;

    
 function issueCredit(address _to, uint _value) {
  creditBalances[msg.sender] += _value;
  creditBalances[_to] += _value;
    }
    
 function optimizeAccount(address _account){
  if((debitBalances[_account] - creditBalances[_account]) >= 0) {
   rewardBalances[msg.sender]+=  debitBalances[_account] -  
     creditBalances[_account];
   creditBalances[_account] = 0;
   debitBalances[_account] -= debitBalances[_account] -  
     creditBalances[_account]; 
  }
  else{
   rewardBalances[msg.sender] +=  creditBalances[_account] - 
     debitBalances[_account];
   debitBalances[_account] = 0;
   creditBalances[_account] -= creditBalances[_account] -
     debitBalances[_account]; 
  }
 }
}

Certainly in this use case, the optimization could be executed right at the credit issunance, however in more complicated scenarios this might be not the option. 

Tuesday, July 24, 2018

IOU debt graphs and trust lines on the blockchain


We were briefly brainstormed how IOU debt network can be represented on the blockchain and how it can be embedded into a mining process in the previous two blogs:  debt graph and mining. We can extend the model with trust lines as well, meaning that the IOU network can be optimized and a new IOU can be issued only if there is an existing trust line between two participants. Trust line can be represented again with a matrix T, where

T[i,j] = 0 if participant i does not trust participant j and
T[i,j] = 1 if participant i trusts participant j

It is an open question what further properties shall a trust matrix have. As an example, it might be reflexive and or transitive:

reflexive: if T[i,j] = 1 then T[j,i] =1 as well
transitive: if T[i,j] = 1 and T[j,k] = 1 then T[i,k] = 1

Having a trust matrix means that there is the possibility to issue a credit or to optimize a relationship between i an j if and only if T[i,j] = 1. Certainly, it is pretty much an open question what should happen if a trust line can be deleted as well.   

Monday, July 23, 2018

Optimizing IOU debts and mining


As we have seen in the previous blog, debt optimization is practically proposing a new directed graph structure in a way that balances of the individual accounts do not change. The easiest way to represent the debt graph is the adjacency matrix, where each A[i,j] element represents the the IOU contract from i to j. Based on that representation, we can formally define the balances of an account as well: 

Balance i = Sum (A[i,j]) - Sum k (A[k,i])

Considering a general mining process, there can be several {IT1, IT2, ... ITN} transactions issuing new IOU-s each transaction is signed by its creator. On top, there is a set of {OT1, OT2, ... OTN} optimization transactions either signed by trusted optimizer nodes, or by nobody. Both sets of transactions are in one two separate transactions pools. The idea of mining is to find a subsets of {IT1, IT2, ... ITK} and {OT1, OT2, ... OTK} transactions in a way that for all account balances, the change is initiated by only by the issuing transactions, meaning that:

Balance i (new) = Balance i (old) + Sum (OT[i,j]) - Sum k (OT[k,i]), where OT is a matrix built up by the {OT1, OT2, ... OTK} transactions. Certainly, the complexity of the network has to be reduced due to the optimization transactions, it is an open question how it can be measured. 

Based on these definitions, there can be a one shot or a two round transaction process: 
- if we imagine two rounds, the first round is a purely optimization round as the second one is a classical transaction round. 
- In a one shot process, both optimization and the new transactions take place. 




  


Optimizing IOU debt graphs on the blockchain


At optimizing an IOU debt graph on the blockchain we should consider the following properties:
- Issuing a new IOU debt must be associated with a digital identity. I should be able to issue a new IOU if I can sign with my private key that I am the issuer of the given identity. 
- There should be a balance for each identity on the blockchain accumulating the numbers how much do I own for someone and how much am I owned by someone. The balance can be changed only if someone creates a new IOU requires digital signatures. 
- The IOU network can be optimized either by everyone or by special optimizer roles. Network optimization can be executed only in a way that non of the account balances changes.
- The effect of the network optimization should be a decreased complexity of the graph, which can be manifested for example as the amount of edges of the depth graph, or the edges weighted by the debt amount. 
- The decreased complexity should be incentivezed, the increased complexity should not be allowed.  - The optimization should not be a totally independent round, optimization should run parallel and consistent with the issuance of new debt.
- It is an open question of a debt can be transferred or traded explicitly without the optimization mechanism.   

Modelling IOU contracts on the Bitcoin blockchain


One way to model an IOU contract on the Bitcoin Blockchain is to send them as a transaction with timelock. It practically means that the contract can not be mined if the time is earlier than the given timelock, with other words it works indirectly as a promise that I will pay a certain amount of money after a certain time. However, it does not work exactly with the same logic as a normal IOU contracts. The problem is that this transaction is not really in the blockchain itself, but only in a transaction pool, which means it can be overwritten any time with a double spending and after the given timelock it is only up to the miners when exactly the transaction will be placed into the blockchain.  

Sunday, July 22, 2018

Proof of useful work via optimizer transactions


Proof of useful work is one of the holy grail of the blockchain space. Although there are initiatives, like proof of useful work via proof of stake, where coins at stake would be generated at actually computing something useful, the scheme does not provide the possibility to integrate the useful work into the transaction processing itself. Platforms like decentralized IOU networks would require that the transaction processing and optimization form one common system and optimization is integrated part of the mining or transaction validation. 

One way of doing would be to have a separate kind of a transaction, called optimization transaction and a special type or role called optimizer. Optimizer would analyse the state of the last known blockchain and the other proposed but still not mined optimization transactions and it would propose new optimization transactions. These transactions would be placed in a special transaction pool, containing only the optimization transactions. The task of the miner is to collect a set of normal and optimization transactions and put them into a block in a way that the whole set is consistent. Consistency here does not only mean avoiding double spending, but it might be actually something more complicated. A new block is formed by a set of standard and optimization transactions, and the new system state appears as these transactions are applied to the existing state. 

Certainly, it is an open question how exactly the system can be fine-tuned, among the others, the following points should be considered:
- Blocks should be motivated to contain both standard and optimization transactions on average, otherwise we land either on a standard blockchain or on a kind of a  purely optimizer based structure. However finding such a set of transactions should happen in a computationally efficient way, otherwise there would not be any guaranteed blocktime.   
-  Optimizers should be motivated to create as efficient optimization transactions as possible. The incentive mechanism can be based like on the measurement of the efficiency of the optimization algorithm, an internal cryptocurrency, transaction fees ...
- It is an open question how the optimization transactions can be combined with the standard transactions in a cryptographical sense ?
- It is another open question how the 2 member market will change with the appearance of the third party (optimizer), it is similarly a question how classical attacks against the blockchain will be effected ?