...by Daniel Szego
"Simplicity is the ultimate sophistication."
Leonardo da Vinci

Friday, July 13, 2018

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.

Wednesday, July 11, 2018

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.

Monday, July 9, 2018

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();