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.   

Hybrid blockchain applications and network segments

Some of the blockchain applications are not meant to be totally decentralized but they should work together with the corporate internal IT infrastructure. Such a solution requires special considerations, as the mission critical business logic is separated into two parts: 

1. on the one hand, critical decentralized business logic will run on the blockchain as smart contracts. 

2. on the other hand, critical centralized business logic should run on the corporate intranet, absolutely separated from the internet. 

To integrate these two requirements might seem to be contradictory for the first sight, what you can do to create a secure infrastructure is to have some proxy Blockchain nodes on the DMZ segment of the system to create an integration with the live blockchain network. On the other hand there should be some internal nodes in your internal network segment to be able to communicate with your internal centralized business logic. To integrate the two versions of the blockchain nodes, there should be a couple of mechanisms regarding offline signs and transferring the offline signed transactions from your offline nodes to your online nodes.     

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.  

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 ?

Fabric composer tips and tricks - revoking CRUD right for a resource

If you revoke the Create, Update or Delete access for a role in Hyperledger Fabric Composer, you have to pay attention to the following things:

- The evaluation of the ACL file is executed rule by rule, the first rule that matches the to the participant, asset and operation will be applied. 

- If no rule matches but there is an ACL file, the access will be denied. 

- So one way to do it is to give a general access to the given participant which is evaluated if no deny rule is found. If you use the Hyperledger Fabric Composer online playground, you might as well give for the user during the testing access even for the system resources as well, because otherwise you can not test your code with that identity from the playground.

- As a first rule however you have to explicitly deny the operations on the specific resource. 

Rule first: 

rule UserHasNoCreateUpdateDeleteRirght {

    description: "User can not create update or delete "

    participant: "org.model.User"

    operation: CREATE, UPDATE, DELETE

    resource: "org.bicyclesharing.model.Asset"

    action: DENY

}

Rule second: 

rule UserHasAccessForAll {

    description: "User role has access for everything"

    participant: "org.model.User"

    operation: ALL

    resource: "**"

    action: ALLOW

}

Blockchain solutions and operational cost structure

At designing a solution on the top of the blockchain requires always special considerations regarding costs, because of the transaction cost of most of the DLT platforms. The classical use-case is always the fully decentralized model, where the end-users communicating with the platform pay the transaction cost explicitly on their own. However there are sometimes requirements that would differ from this classical situation: 

- One way can be that a company or provider would like to offer services on the blockchain and want to take over the transaction fee of the end-user. In this use-case, the easiest way is to add the customer accounts to a pool of customers and monitor have a certain budget which can be stored in a smart contract for certain operation to be paid automatically. If this budget will reach a certain level because of too much expenditure, it has to be renewed. 

-   Another model is to innate some kind of a transaction autocratically, certainly, it is not possible directly from a third party, however there is a chance to initiate such a behavior from a trusted or semi-trusted third party. However, in this scenario as well, the accumulated transaction fee must be paid by the semi trusted-third party, so appears as a kind of operational cost. 

The aggregated transaction fee can be estimated in these situations as the average number of transactions to be executed times the average transition fee and appears as an operational cost of the system. The use-cases must be carefully analyzed as the operational cost in certain situations can enormous.

Blockchain development and project management

Blockchain development requires a new way of project management, let we call it SF-Agile, meaning that if it is possible agile, but basically Security First: security is the highest priority, agile is only the second. From a practical point of view until we are on a test network, the development itself can be agile, however as soon as we want to deploy to the live network, the requirements have to be fixed, everything has to be unit tested and possibly formally analyzed and verified. So in the last step Security First has to very strongly dominate, in this sense this step is similar to waterfall project.

Estimating the cost of a Blockchain project

Estimating the cost of a blockchain project is pretty tricky, as there is generally not much experience in the field. Usually it is not estimated apriori because on the one hand there are a lot of unexpected technological challenges and on the other hand the requirements are unclear as well. For this reason usually there is no cost estimation at the beginning of a project but the project is delivered in an agile way starting with a proof of concept, continuing with a working prototype, which is followed by the fine tuning of both the requirements and the technological architecture. 

Anyway, blockchain projects usually have the following factors to be considered, most of them based on the architectural requirements of the project:

- Smart contract development: key element of the architecture is the smart contract, developing such contracts is more or less resource intensive. Like in case of a solidity, Ethereum development of the code itself is not too much energy, however a lot of efforts have to be put into testing, quality assurance and formal verification as the contract will be deployed into a public immutable ledger. 

- Blockchain infrastructure: at public blockchain platforms, the blockchain infrastructure both the live and the different test networks are usually configured. For consortium blockchains, the whole infrastructure has to be planned, configured and delivered, which might be a huge task. There are some initiatives however to speed up the infrastructure deployment of a consortium blockchain networks, like Azure blockchain from Microsoft or Chello project from Hyperledger

- Fronted or UI: Fronted and user interface is usually required for every blockchain application. It usually requires classical fronted development with javascript, HTML and CSS. There are experimental platforms however where you can speed up the fronted development. Like in Azure Blockchain Workbench, you can click together some of the UI elements, or in Hyperledger Fabric composer, where based on the business blockchain definition file, there is the possibility to automatically generate a basic user interface. 

- Storage: If storage is required, the major question is if it is centralized or decentralized. If it is decentralized, like in IPFS or Swarm, usually the smart contract developers manage this part of the development as well. If it is a centralized storage, like a classical file system or an SQL DB, the integration must be implemented. There are already frameworks which can speed up some blockchain integration with existing storage systems, like Azure Blockhain from Microsoft.  

- System integration: In enterprise blockchain application, exiting legacy systems, like databases, existing ledgers, authentication providers... should usually be integrated with the Blockchain. This can mean atomic swaps, or simply import - exports. Some enterprise blockchain systems already provide experimental services in this direction. 

- Non-technical roles: usually some management roles should be considered as well in a Blockchain project, like a project manager if the project is getting more complex, a Blockchain consultant and requirement engineer to fine tune the business requirements.  

Fabric composer tips and tricks - issue identity programmatically

If you want to issue a new identity for a participant, you can do it only from outside of your chaincode. Unfortunately there is no support for issuing identities inside your transaction or contract, which might make sense, hence this kind of a management is usually not part of the transnational logic. If you want to issue an identity from the outside world, what you have to do is the following:

1. Get your business network connection:

const BusinessNetworkConnection = require('composer-client').BusinessNetworkConnection;

2. Connect to your network, with a certain network card:

await businessNetworkConnection.connect('admin@mynetwork');

3. Issue new identity:

let result = await businessNetworkConnection.issueIdentity('Participans#email', 'name);

4. Close the connection:

await businessNetworkConnection.disconnect();  

Fabric composer tips and tricks - create an event

Creating and rising an event is not complicated at all in Fabric composer. You need the following steps:

1. Define your event in the mode file

event MyEvent {
  o <type> Property1
  o <type> Property2
}

2. Create your event in the your transaction javascript logic.

 let myEvent  = await getFactory().newEvent(namespace, 'MyEvent'); 

3. Filling the event properties:

  MyEvent.Property1 = <value1>;
  MyEvent.Property2 = <value2>;

4. Raising the event:

  emit(MyEvent);